In <200501131927(_dot_)49708(_dot_)blilly(_at_)erols(_dot_)com> Bruce Lilly
<blilly(_at_)erols(_dot_)com> writes:
I've thrown together an Internet Draft based on our discussion
a few months ago. It should appear soon at the usual places.
Actually, it showed up at the "usual places" before I saw it here.
This mailing lists is as good a place as any for discussion;
private comments are of course welcome.
OK. Essentially it is fine as far as it goes, but there are a few further
things that could usefully be said.
The most prominent of these would be to mention Graham Klyne's RFC 3864,
which introduces the IANA header registry. Writers of drafts for new
headers should be encouraged to take out a provisional registration of the
header-name at the same time as the initial draft, and also to include
instructions for the header to be added to the permanent registry in an
IANA Considerations section.
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.
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).
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.
3. Make it clear when the value part of any parameters that are defined
need to be quoted.
4. Make it clear thqt RFC 2231 applies.
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.
--
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