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
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: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk 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