Re: ABNF

In <[email protected]> Bruce Lilly <[email protected]> writes:

>That's nice, but it's not the format of I-Ds and RFCs, which is where ABNF
>is used.  Those documents might or might not have CR.  The recent IESG
>statement 
>http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg01196.html
>recommends automated validation, and an RFC 2234 (or draft successor)
>parser will reject "ABNF" w/o CR (or, conversely, any "ABNF" parser that
>does not reject content w/o CR is not compliant with 2234 et seq. and
>cannot be used as one of the fully conforming implementations for the
>purpose of advancing the specification to Draft), and is therefore
>useless for validating ABNF in I-Ds and RFCs, since I-Ds and RFCs in the
>IETF and RFC-Editor archives do not have CRs.

If RFC 2234 (or its bis) actually says that a grammar which is expressed
using other than CRLF to separate its lines is non-compliant, then RFC
2234 (or its bis) is a ass.

Clearly, in the real world, "CRLF" is a euphemism for whatever the system
concerned uses to distinguish line endings. If the material in question
should ever find itself being conveyed on some "wire" in accordance with
IETF protocols, then it had better be a genuine CRLF. And if I download
some RFC containing some ABNF from ietf.org, then it had better arrive
with genuine CRLFs throughout. But if I then choose to store it locally
using some other convention (e.g. just LF on some UNIX system), then the
RFC and the ABNF within it do not suddenly become invalid. And if RFC 2234
(or its bis) is actually trying to say otherwise then it is, as I have
alread said "a ass", and it needs to be fixed.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email protected]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5