Re: [Ietf-message-headers] Provisional registration of 5 X-Device-* HTTP Header fields for use in content transformation guidelines

Francois Daoust <> Mon, 17 August 2009 07:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0757C3A6950 for <>; Mon, 17 Aug 2009 00:27:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.854
X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CWIrAxkPG+Mp for <>; Mon, 17 Aug 2009 00:27:55 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9B4663A6940 for <>; Mon, 17 Aug 2009 00:27:53 -0700 (PDT)
Received: from ([]) by with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <>) id 1Mcwd1-0007xC-8F; Mon, 17 Aug 2009 07:27:39 +0000
Message-ID: <>
Date: Mon, 17 Aug 2009 09:27:39 +0200
From: Francois Daoust <>
User-Agent: Thunderbird (X11/20090608)
MIME-Version: 1.0
To: Graham Klyne <GK@ACM.ORG>
References: <> <> <> <> <> <> <> <> <4A86AC16.70609@ACM.ORG>
In-Reply-To: <4A86AC16.70609@ACM.ORG>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Ietf-message-headers] Provisional registration of 5 X-Device-* HTTP Header fields for use in content transformation guidelines
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Discussion list for header fields used in Internet messaging applications." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 17 Aug 2009 07:27:56 -0000


I will report to the working group, and will likely proceed with the 
provisional registration of the header fields, with a clear 
understanding that thorough discussion with IETF is needed to transition 
from provisional to permanent:
  1. because of the use of the "X-" prefix, and
  2. because the introduction of new HTTP header fields require as wide 
a review as possible anyway.


Graham Klyne wrote:
> As designated reviewer for registrations, here's my current position:
> If this were a mail header, I think the response would be fairly 
> clear-cut:  the email standards prohibit the standardization of headers 
> named X-whatever.  But this is HTTP, and the last time I checked I 
> didn't see any specific status for X-headers there.  And there is a 
> general feeling that, while it sometimes serves a purpose, the approach 
> of using X-headers for experimentation generally does not work, for 
> reasons that are exemplified by this debate.
> This leaves us with the strong expectations of developers who have 
> worked with IETF protocols that X-headers are experimental, and not to 
> be taken seriously.
> The header registration procedure itself deliberately does not take a 
> position on X- headers, so there is nothing there specifically 
> prohibiting the permanent registration of X-headers - it's up to the 
> protocol concerned (HTTP in this case) to specify what is the minimum 
> requirement for standardization.  Permanent registration requires 
> publication as "open standard", which means a clear community consensus 
> is required;  this is not necessarily an IETF standard - W3C REC is good 
> - but I'd expect some dialog with the IETF if there appears to be a 
> conflict of styles or expectations.
> Thus: if the document is approved as an IETF proposed standard with the 
> X-header specifications (which I think may be effectively required for 
> all but new HTTP entity-header fields), then I would have no problem 
> agreeing to the permanent registration of the X-headers.  Otherwise, I 
> would look for IETF review and consensus by IESG and/or HTTP protocol 
> experts that permanent registration of an X-header is not likely to 
> cause any problems in other areas.
> Personally, if I have to make the call, I'd allow it because I can't see 
> any fundamental reason not to do so.  But I really would prefer to see 
> wider review.
> None of this in any way impedes provisional registration.
> #g
> -- 
> SM wrote:
>> Hi Francois,
>> At 00:57 13-08-2009, Francois Daoust wrote:
>>> I'm not sure I understand why you directly jump to deprecated at this 
>>> step.
>> A provisional registration is a step towards permanent registration.  
>> Omitting the depreciated status would be an encouragement to adopt 
>> that header field name.  Once that is done, it will be argued that the 
>> "X-" cannot be dropped.
>> In future, someone will come up with an argument that there is already 
>> some "X-" header names in the permanent registry.
>>> I thought the purpose of the provisional registry was to reserve 
>>> names while the underlying specification matures along the 
>>> standard-track. The underlying specification is not definitive, and 
>>> there will be at least one other Last Call working draft period 
>>> during which the working group expects to receive external comments 
>>> both on the choice of names and the usefulness of these HTTP header 
>>> fields.
>> Yes.  But if the working group is not agreeing on the change now, it 
>> is improbable that they will agree to it on another Last Call.
>>> The use of the "X-" prefix has been extensively discussed both 
>>> formally within the group and informally with some IETF contributors. 
>>> The fact that companies use private "X-" header field names on a 
>>> public level is a pity, but it is unfortunately common practice 
>>> within mobile networks. We are trying to move away from a situation 
>>> where there exist 5 different sets of "X-" header field names to a 
>>> situation where there's only one. Mobile content developers complain 
>>> about the existence of these different sets that were imposed on 
>>> them. They do not want to hear about a new one, introduced for the 
>>> sake of removing the "X-" prefix, in particular if that means they 
>>> would still have to be prepared to receive the "X-" form and the non 
>>> "X-" during the transition period.
>> The transition period can be now or later.  The longer we wait to do 
>> such changes, the more difficult it will be.
>>> That is the reason why the mobile web best practices working group 
>>> thinks it is reasonable to bend the naming rule here. We are not 
>>> aware of any real difference between "X-" header fields and regular 
>>> non "X-" ones, apart from their intended use.
>> When using "X-" headers, it is difficult to tell whether anyone 
>> outside the working group is using the headers for other purposes.
>> Regards,
>> -sm
>> _______________________________________________
>> Ietf-message-headers mailing list