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

John C Klensin <> Fri, 04 April 2008 21:47 UTC

Return-Path: <>
Received: from (localhost []) by (Postfix) with ESMTP id A015D3A6895; Fri, 4 Apr 2008 14:47:11 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 577C63A6895 for <>; Fri, 4 Apr 2008 14:47:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[AWL=0.611, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KZF2kTMSsSCV for <>; Fri, 4 Apr 2008 14:47:09 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EE6D13A676A for <>; Fri, 4 Apr 2008 14:47:08 -0700 (PDT)
Received: from [] (helo=p3.JCK.COM) by with esmtp (Exim 4.34) id 1Jhtkf-000Nt5-SJ; Fri, 04 Apr 2008 17:47:14 -0400
Date: Fri, 04 Apr 2008 17:47:12 -0400
From: John C Klensin <>
To: Frank Ellermann <>,
Subject: Re: Last Call: draft-resnick-2822upd (Internet Message Format) toDraft Standard
Message-ID: <8BB8410A1437A8973C333DCE@p3.JCK.COM>
In-Reply-To: <ft57m4$csu$>
References: <> <> <ft57m4$csu$>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Disposition: inline
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

--On Friday, 04 April, 2008 14:43 +0200 Frank Ellermann
<> 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
>> 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

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.


IETF mailing list