Re: General considerations for new message field specifications

In <[email protected]> Bruce Lilly <[email protected]> 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: [email protected]      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