--On Friday, 04 April, 2008 14:43 +0200 Frank Ellermann <nobody@xxxxxxxxxxxxxxxxx> wrote: > Brian E Carpenter wrote: > >> I am disturbed that the messy situation of X- headers, >> created by RFC 2822's silence on the subject, has not >> been fixed. > > As far as 2822 and 2822upd are concerned header fields > not specified in 2822 or 2822upd resp. are covered by > <optional-field> in section 3.6.8. This section does > not talk about field-names starting with "X-" or not. > >> See http://www.ietf.org/IESG/APPEALS/klensin-response.txt >> for an example of the issues that this silence can create. > > Gateways are always a difficult topic, and the 2822upd > syntax *minus* obs-* constructs is hopefully friendlier > to gateways than RFC 2822 *minus* obs-*. > > Including obs-* constructs: 2822upd is slightly better > than before, a few RFC 822 #-cases not covered in 2822 > are now accepted as obsolete, ASCII art with commas and > similar oddities. Yes, but that has little or nothing to do with Brian's comment, at least as I understand it. >> I believe it would be appropriate to document that >> although X- headers are widely used, they are not part >> of the standard format and their treatment by Internet >> MTAs MUST NOT be relied on, unless registered under >> RFC 3864. Yes, but registering them really isn't a good idea either, IMO. > RFC 822 said that X- headers will *not* be standardized, > they are reserved for e-X-periments (my interpretation). > Do you propose that 2822upd should copy this rule from > RFC 822 ? Sorry, but I'm not sure what you are up to. > > An MTA not supporting header X-foobar is not forced to > support header foobar only because it has no X-. As > far as 2822upd is concerned both are <optional-field>s. There are two ways to interpret the "X-" and I think they yield different answers about what should be done. If they are seen as experimental, we promptly run into the problem that, if I recall, caused DRUMS to remove the text: If the experiment succeeds, it is hard to get rid of the "X-" part. If it doesn't succeed, then the header is likely to vanish with little trace whether it contains "X-" or not. And one clearly, at least in the retrospect of the last many years, wants to have experimental headers registered (presumably in the 3864 registry) to reduce the odds of header names being reused for conflicting purposes. On the other hand, they can be seen as "private-use between parties who have adequately identified each other and therefore know what they mean". For a private-use header, there is no requirement to register the thing externally because, once one registers (and ideally describes) them, they are no longer private. Our history of putting "X" (with or without the subsequent hyphen) in front of things --remembering that there have been similar provisions at one time or another in FTP, SMTP, and elsewhere-- has tended to get "experimental" and "private use" muddled, muddled enough that I think we've often not understood, or lost sight of, the difference. I don't know if Brian would agree, but my inference from the Lemonade appeal and a couple of other rough edges consequent of removing 822's text about X- headers is that, ideally, we should (1) Partially restore the 822 text, stressing "private use", rather than "experiental". (2) Treat <optional-field> as consisting of either "X-headers" or "Non-X-headers" (probably there are better names). (3) Encourage X-headers for strictly private use, i.e., they SHOULD NOT be used in any context in which interchange or communication about independent systems is anticipated and therefore SHOULD NOT be registered under 3683. (4) Make it clear that the distinction between X-headers and Non-X-headers is guidance, not firm rules. Should an X-header become widely deployed (for a definition of "widely" I don't think we need to pin down), then it is perfectly reasonable to treat it as an ordinary (non-X) header, register it, and even potentially write up RFCs describing it. We just recommend against getting into that situation if possible. Note that this proposed remedy restores the 822 behavior and recommendations for headers that are _never_ expected to enter standard use, so it is not a new feature. It preserves the 2822 recommendations for optional (unspecified) header names, including preserving it for X-headers that have become popular. So this is a conceptual improvement and better guidance for designers of new protocols or features (in or out of the IETF) without changing anything operationally. Just my opinion. And I don't feel strongly about it as evidenced by the observation that I probably wouldn't have bothered to say anything had Brian and others not brought it up. john _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf