Brian E Carpenter <brc at zurich.ibm.com> writes:
> I thought we had agreed that "code" is text intended to be read by
> a computer program.
I don't believe that is a good definition.
I have implemented several protocols that use ABNF, even multiple
times in different languages, and in no case (that I recall now) did
the computer parse the ABNF directly. Typically, I translated the
ABNF syntax into parser code by hand. The problem is that many common
programming languages are imperative and not declarative; it's
difficult to use ABNF directly in an imperative language.
Look at any software that deals with SMTP, e-mail, etc, and you will
find that few, for good and bad, that actually use the official ABNF
definition. I'd be surprised if any of the more popular MUAs on the
Internet have the RFC 2822 ABNF be part of the real source code.
I do not think that the "intention" in protocols such as DIGEST-MD5 is
that the ABNF should be read by a computer program. No
implementation, as far as I know, do that. So the definition, at
least as phrased above, doesn't seem to work.
In general, I haven't seen any sufficiently strict definition of
"code" that is applicable to text input that doesn't lead to
corner-cases that need human interpretation sooner or later.
It is possible to give a non-exhaustive list of examples that we do
consider to be code (ABNF, ASN.1, XML, source code, pseudo-code, data
tables, ...), and also include some general discussions that help
humans to get a feel of what is code and what is not code. That will
not help to decide whether some new notation should be considered text
or code.
I believe that separation of code and text ultimately leads to only
two situations that can work in practice:
1) An informative document lists various notations (ABNF, ASN.1, etc)
and discusses properties that are typically present for code, to
let humans decide what is code and what is not code, when
interpreting what should be released under the "IETF code license".
2) Code excerpts in IETF documents are marked with special markers to
indicate that the particular portion is considered to be "code" and
released under the "IETF code license".
I'm not sure which I prefer, they seem to both have their own
problems. Perhaps a combination is better than either of the choices
separately.
Rather than trying to strictly define what "code" is, I believe either
1), 2), or possibly (and perhaps even most likely) both, should be
discussed and fleshed out in more detail.
If I can dream, I'd wish we don't have to define what code is. Look
at the problems related to code vs documentation that the Debian
GNU/Linux distribution has been discussing for years. Currently I
believe Debian don't consider there to be any difference between code
and text, and apply the same rules for both. I believe the IETF will
eventually arrive at the same conclusion, or that a lot of frustration
will result from any separation between the two.
/Simon
_______________________________________________
Ipr-wg mailing list
Ipr-wg at ietf.org
https://www1.ietf.org/mailman/listinfo/ipr-wg