"Joel M. Halpern" <joel at stevecrocker.com> writes:
> Actually, if I am reading Simon right this suggests that there is no
> need to cover ABNF in the code requirements.
I believe ABNF should be counted as code, since it is technically
possible, and sometimes useful, to use ABNF definitions in code.
Consider ABNF validating parsers. For another reason ABNF should be
regarded as code, see below... My comment should be read as an
argument against Brian's definition of "code".
> If the human being has to write the code that has the same meaning,
> then the copyright on the ABNF is irrelevant to that code segment.
> This argues that ABNF should be considered text, not code. It does
> not argue that there is an error in the suggested definition of
> code. Copyright does not protect the idea of the ABNF, only the
> expression.
>
> Remember that the point of allowing code to be modified is that you
> need to include the code in the program, and you may have to modify
> the code to make it work.
The ABNF is often quoted in code comments to explain a particular
state in a parser. If there is a bug in the ABNF, you'd want to fix
that in the comment, so the comment reflect reality. It doesn't seem
like the license for text would allow that, would it? If not, using a
code license for ABNF higher quality implementations.
/Simon
> Yours,
> Joel M. Halpern
>
> At 09:53 AM 12/6/2006, Simon Josefsson wrote:
>>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