On Mon January 17 2005 11:33, Charles Lindsey wrote:
Yes, but if a document makes normative reference to earlier standards,
some written in RFC 822 style and some in RFC 2822 style, then life get
complicated. I think you could usefully give more guidance on how to cope
with this, or at least warn them that the problem has to be addressed
somehow.
Do you believe that the recommendations in draft section
4.2.1 do not adequately address whitespace, line folding,
and comments (which are the principal differences in BNF
between 822 and 2822)?
As for addressing both EBNF and ABNF, I believe that's
not particularly difficult to do, as in RFC 3282 for
example. The only significant reason to use RFC 822
EBNF for new general extension fields is for drafts that
are expected to progress along the Standards Track faster
than 2822, and in light of RFC 3967, that is arguably not
as great a factor as it is sometimes taken to be.
There are only three fields out of about 140 that use those
so-called "parameters". They are the MIME fields Content-Type
and Content-Distribution, and Keith's Auto-Submitted field
(which is probably partially my fault, as otherwise it would
have introduce a third syntax for parameters (the second being
that used by the Disposition-Notification-Options field).
3. Make it clear when the value part of any parameters that are defined
need to be quoted.
That's covered by RFCs 2045 and 2231 for the fields where it
applies.
Yes, but you are writing an informational document for people who may be
inventing new headers. They need to be warned of things they might easily
overlook.
It hardly seems worthwhile expanding the draft to cover a
little-used (ca. 3% of fields) feature. It is, however
addressed by the general text of section 4.2.1, which recommends
careful review of ABNF. I certainly don't intend to turn the
draft into a hundred page behemoth that will put off potential
readers.