From: Paul Overell (paulo@turnpike.com)
Date: Fri Feb 01 2002 - 04:22:28 CST
In message <Gqsv3y.A6s@clw.cs.man.ac.uk>, Charles Lindsey
<chl@clw.cs.man.ac.uk> writes
>In <sG4qHjCgY9V8QAsy@pillar.turnpike.com> Paul Overell
><paulo@turnpike.com> writes:
>
>
>>>
>>>B.3 Headers
>>>
>>> <CONTROL>-verb =3D <the verb defined in this standard
>>> (or an extension of it) for a specific
>>> <CONTROL> message>
>>> <CONTROL>-arguments =3D <the arguments defined in this standard
>>> (or an extension of it) for a specific
>>> <CONTROL> message>
>>> <USENET>-header-content
>>> =3D <the header-content defined in this standard
>>> (or an extension of it) for a specific
>>> <USENET> header>
>>> <USENET>-header-parameter
>>> =3D <an other-header-parameter defined in
>>> this standard for use in conjunction with
>>> a specific <USENET>-header-content>
>>> <USENET>-token =3D <A token defined in this standard for
>>> use in conjunction with a specific
>>> <USENET>-header-parameter>
>>>
>
>>This isn't syntactically valid ABNF, can't have <> on the left of =3D. Are
>>you using this as an ABNF schema?
>
>Yes, this is a schema (or, if you want to get terribly technical, it is a
>Van Wijngaarden grammar).
>
>Actually, in our earlier drafts, those '<' and '>' were omitted. I just
>inserted them now so as to make it more obvious that it was a schema. I
>could add a description of the notation in a suitable place if you like,
>though I think it is pretty obvious what it means.
>
I don't want to get into a discussion of the various merits of different
syntactic meta-languages. ABNF may not be perfect but it has become the
syntactic meta-language of choice for RFCs, it is a proposed standard.
We should use it as is, without extensions. The above is not ABNF.
>>I found the headers section hard to read because nowhere are the
>>header-names defined, are they missing or is the reader supposed to
>>deduce them from the above schema?
>
>They are implicit in the schema (and the collected syntax is actually the
>first time they have all been written down in one place). The advantage is
>that it enables additional headers to be added in this, as well as future,
>standards.
>
>Note that we inherited the practice of using 'Foo-content' to define the
>Foo header from Son-of-1036.
>
>>e.g. where is
>
>>expires =3D "Expires:" Expires-content CRLF
>
>I might be persuaded that we need a <USENET>-header-name rule within the
>schema, so that the rule for 'header' would become
> header = <USENET>-header-name ":" 1*SP <USENET>-header-content CRLF
>
If I were to produce an ABNF parser (i.e. one that doesn't understand
your schemas) from your grammar then it could not correctly parse
From: paulo@turnpike.com
Because without an explicit production for the from header there is
nothing in your syntax to link "From" with from-content. The best it
could do is the general header-content.
To work properly the parser would have to understand your schema. ABNF
doesn't have schemas.
What is the objection to explicit productions for headers? What could
be clearer? As so much of our syntax comes from RFC2822 we should be
following their style.
Keep the schema (without <> so that it is syntactically ABNF) to give
guidance for future headers, but include explicit productions for
everything that we define so that it is a complete ABNF grammar.
Regards
-- Paul Overell T U R N P I K E