ietf-822
[Top] [All Lists]

Re: General considerations for new message field specifications

2005-01-16 13:54:46

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

OK, I can add that as an informative reference.

Mind you, IANA seems to be more than a bit confused, as
their web page for the registry refers to "header messages"
and "message header messages", neither of which makes any
sense, but that's another matter...

The next point concerns the use of RFC 2822-style syntax, which you
rightly seek to encourage. A problem arises when you need to take or
modify something out of an earlier standard which was produced back in the
pre-2822 days. A good working example would be the MIME-style <parameter>.
There are now at least two other standards which have taken over the basic
idea first introduced in RFC 2045 (strictly, in its predecessor). One is
the Content-Distribution header and the other is the auto-submitted field
(RFC 3834). I have also seen a recent draft for an OpenPGP header.

I have never heard of "Content-Distribution". Do you have a reference?

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.

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.

4. Make it clear thqt RFC 2231 applies.

I hesitate to list every RFC that might apply to some extension field,
as that would be a very long list which would quickly become outdated.
 
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.