In <200501161554(_dot_)37914(_dot_)blilly(_at_)erols(_dot_)com> Bruce Lilly
<blilly(_at_)erols(_dot_)com> writes:
On Fri January 14 2005 11:32, Charles Lindsey wrote:
The most prominent of these would be to mention Graham Klyne's RFC 3864,
which introduces the IANA header registry
I have never heard of "Content-Distribution". Do you have a reference?
Sorry. Content-Disposition.
The problems all such proposal have in common is the necessity to:
1. Make it clear where [CFWS] can be inserted (currently, it is hard work
to deduce this from RFC 2045 cum RFC 822).
Yes, that is an issue with RFC 822, which affects several RFCs
that use 822 syntax, and is addressed to some extent by RFC 2822
(and will hopefully be improved in 2822's successor). It is addressed
by the draft.
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.
2. Make it clear that more parameters will appear in future extensions,
which MUST NOT be generated yet, but MUST be accepted and ignored now.
Except that paramaters with x-tokens MAY be generated now.
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.
RFC 3834 makes a reasonable job of all these things, except that it avoids
#3 by not actually defining any parameters :-) . But the OpenPGP draft is
a bot weak, hence the need for you to cover thses issues.
Specific concerns w.r.t. a specific draft are probably best addressed
to the author(s) of that draft at this time.
Yes, I have done, and had a nice acknowledgement too.
--
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