ietf
[Top] [All Lists]

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

2008-04-04 14:47:48


--On Friday, 04 April, 2008 14:43 +0200 Frank Ellermann
<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf