Re: Last Call: draft-resnick-2822upd (Internet Message Format) toDraft Standard

[Brian E Carpenter <[e-mail]>]

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
> <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf
> 
_______________________________________________
IETF mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf