On Mon May 16 2005 07:23, Charles Lindsey wrote:
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.
The -02 draft says:
rulelist = 1*( rule / (*c-wsp c-nl) )
rule = rulename defined-as elements c-nl
; continues if next line starts
; with white space
rulename = ALPHA *(ALPHA / DIGIT / "-")
defined-as = *c-wsp ("=" / "=/") *c-wsp
; basic rules definition and
; incremental alternatives
elements = alternation *c-wsp
c-wsp = WSP / (c-nl WSP)
c-nl = comment / CRLF
; comment or newline
comment = ";" *(WSP / VCHAR) CRLF
[...]
CR = %x0D
; carriage return
CRLF = CR LF
; Internet standard newline
[...]
LF = %x0A
and (elsewhere)
CRLF = %d13.10
There is no question about what it says, that ABNF uses only CRLF line
endings, and that without at least one CR in CRLF somewhere, there is
nothing that can possibly qualify as an ABNF rulelist.
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.
HTTP is a protocol specified in IETF RFC 1945, and it imposes no such condition.
Indeed:
Media subtypes of the "text" type use CRLF as the text line break
when in canonical form. However, HTTP allows the transport of text
media with plain CR or LF alone representing a line break when used
consistently within the Entity-Body. HTTP applications must accept
CRLF, bare CR, and bare LF as being representative of a line break in
text media received via HTTP.
RFC 1945 predates BCP 14, but the meaning of "must" is crystal clear.
And if I download
some RFC containing some ABNF from ietf.org, then it had better arrive
with genuine CRLFs throughout.
Downloading RFC 1945 via the RFC-Editor's web site search seems appropriate
given the discussion. Some Ethereal IP capture excerpts:
0040 3a 20 48 54 54 50 2f 31 2e 30 20 33 30 32 20 4d : HTTP/1 .0 302 M
0050 6f 76 65 64 20 54 65 6d 70 6f 72 61 72 69 6c 79 oved Tem porarily
0060 0d 0a 53 65 72 76 65 72 3a 20 4e 65 74 73 63 61 ..Server : Netsca
0070 70 65 2d 45 6e 74 65 72 70 72 69 73 65 2f 33 2e pe-Enter prise/3.
0080 36 20 53 50 33 0d 0a 44 61 74 65 3a 20 4d 6f 6e 6 SP3..D ate: Mon
0090 2c 20 31 36 20 4d 61 79 20 32 30 30 35 20 31 36 , 16 May 2005 16
00a0 3a 35 37 3a 33 32 20 47 4d 54 0d 0a 4c 6f 63 61 :57:32 G MT..Loca
00b0 74 69 6f 6e 3a 20 66 74 70 3a 2f 2f 66 74 70 2e tion: ft p://ftp.
00c0 72 66 63 2d 65 64 69 74 6f 72 2e 6f 72 67 2f 69 rfc-edit or.org/i
00d0 6e 2d 6e 6f 74 65 73 2f 72 66 63 31 39 34 35 2e n-notes/ rfc1945.
00e0 74 78 74 0d 0a 43 6f 6e 74 65 6e 74 2d 74 79 70 txt..Con tent-typ
00f0 65 3a 20 74 65 78 74 2f 68 74 6d 6c 0d 0a 0d 0a e: text/ html....
N.B. the HTML served has CRLF... so does the FTP greeting (ftp having been
specified in the referred URI above -- FTP is an IETF Standard protocol
(STD 9)):
0040 49 c4 32 32 30 20 66 74 70 2e 69 73 69 2e 65 64 I.220 ft p.isi.ed
0050 75 20 4e 63 46 54 50 64 20 53 65 72 76 65 72 20 u NcFTPd Server
0060 28 66 72 65 65 20 65 64 75 63 61 74 69 6f 6e 61 (free ed ucationa
0070 6c 20 6c 69 63 65 6e 73 65 29 20 72 65 61 64 79 l licens e) ready
0080 2e 0d 0a ...
but here's the start of the actual RFC 1945 FTP download:
0040 4e 20 0a 0a 0a 0a 0a 0a 4e 65 74 77 6f 72 6b 20 N ...... Network
0050 57 6f 72 6b 69 6e 67 20 47 72 6f 75 70 20 20 20 Working Group
0060 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
0070 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
0080 20 20 54 2e 20 42 65 72 6e 65 72 73 2d 4c 65 65 T. Ber ners-Lee
0090 0a 52 65 71 75 65 73 74 20 66 6f 72 20 43 6f 6d .Request for Com
00a0 6d 65 6e 74 73 3a 20 31 39 34 35 20 20 20 20 20 ments: 1 945
00b0 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
00c0 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
00d0 20 20 4d 49 54 2f 4c 43 53 0a 43 61 74 65 67 6f MIT/LC S.Catego
No 0x0d anywhere in sight.
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.
The RFC certainly doesn't become invalid. But there is nothing (N.B. on
the wire as shown above, or) in the stored file that meets the ABNF syntax,
as there is no CR.
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.
We're agreed on that (doesn't happen often, does it?).