[Top] [All Lists]


2005-05-16 09:14:44

In <200505140806(_dot_)32995(_dot_)blilly(_at_)erols(_dot_)com> Bruce Lilly 
<blilly(_at_)erols(_dot_)com> 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
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, 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:
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk      Snail: 5 Clerewood Ave, 
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

<Prev in Thread] Current Thread [Next in Thread>