John, I think I agree with your suggested path. On 2008-04-05 02:03, Simon Josefsson wrote: ... > Can X-* headers really be registered under RFC 3864? One X- header is provisionally registered under RFC 3864 (and is marked in the registry as 'deprecated'). On 2008-04-05 01:43, Frank Ellermann wrote: ... > Sorry, but I'm not sure what you are up to. My underlying concern is that 2822upd should not appear ridiculous to anyone who looks at a typical mail header and sees the X-headers. John's message reached me with X-Original-To, X-Virus-Scanned, X-Spam-Flag, X-Spam-Score, X-Spam-Level, X-Spam-Status, X-Mailer, X-BeenThere, and X-Mailman-Version. Leaving this completely undocumented harms the relevance of the standard. Brian On 2008-04-05 10:47, John C Klensin wrote: > > --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 > _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf