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

Brian E Carpenter <> Sat, 05 April 2008 04:05 UTC

Return-Path: <>
Received: from (localhost []) by (Postfix) with ESMTP id 1B7EA3A685E; Fri, 4 Apr 2008 21:05:59 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 832F13A689C for <>; Fri, 4 Apr 2008 21:05:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.709
X-Spam-Status: No, score=-1.709 tagged_above=-999 required=5 tests=[AWL=0.890, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xZy8JfZ6q8ef for <>; Fri, 4 Apr 2008 21:05:55 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5D9C23A67A4 for <>; Fri, 4 Apr 2008 21:05:55 -0700 (PDT)
Received: by with SMTP id k40so319029wah.25 for <>; Fri, 04 Apr 2008 21:06:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=7bJXqoTHgAJRN6WR9EG4SYIwXUpTqBsn7J2Akb5jA94=; b=hA2hK103N95N70piP45KiI/SlvT26IWbZ+M1zFpouxLOkqms3G90baZBrJu6f9gA0LHcNPt0CPqCCk9hL6K9sYcMIv4+rIsysqodexxcJhHUGkK1ZBl/RZwQr/Lre3G5FzU4KDB76LtGLTw0AgaFh6mmzRCUpBs1X/JDWozoj6g=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=bgLYqj0WnAdx3eQtNr8qso+tV+fd3NdEjUttLeZ7yT6dO1+BSRjXpEMcwRwn12naP9a8ZWSKtU9ZETYKCfHddluVnqxDNYr+tZNiK3Y9TWXgWRAGZcrFGKpY2lCwCFOEY10yzVGeqyAdq3BHmLztyKg4pdMrl/HnT1v1QLEuRIM=
Received: by with SMTP id f5mr3206499wad.125.1207368361783; Fri, 04 Apr 2008 21:06:01 -0700 (PDT)
Received: from ? ( []) by with ESMTPS id z20sm9567100pod.4.2008. (version=SSLv3 cipher=RC4-MD5); Fri, 04 Apr 2008 21:06:00 -0700 (PDT)
Message-ID: <>
Date: Sat, 05 Apr 2008 17:05:55 +1300
From: Brian E Carpenter <>
Organization: University of Auckland
User-Agent: Thunderbird (Windows/20070728)
MIME-Version: 1.0
To: John C Klensin <>
Subject: Re: Last Call: draft-resnick-2822upd (Internet Message Format) toDraft Standard
References: <> <> <ft57m4$csu$> <8BB8410A1437A8973C333DCE@p3.JCK.COM>
In-Reply-To: <8BB8410A1437A8973C333DCE@p3.JCK.COM>
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


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.


On 2008-04-05 10:47, John C Klensin wrote:
> --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
> 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 mailing list