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

Francois Daoust <> Fri, 14 August 2009 14:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 569BC3A6A22 for <>; Fri, 14 Aug 2009 07:15:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.24
X-Spam-Status: No, score=-6.24 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ImteRgawMuFA for <>; Fri, 14 Aug 2009 07:15:07 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2EAF73A69F6 for <>; Fri, 14 Aug 2009 07:15:07 -0700 (PDT)
Received: from ([] helo=[]) by with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <>) id 1MbuGZ-0001Ul-2i; Fri, 14 Aug 2009 10:44:11 +0000
Message-ID: <>
Date: Fri, 14 Aug 2009 12:44:11 +0200
From: Francois Daoust <>
User-Agent: Thunderbird (X11/20090409)
MIME-Version: 1.0
To: SM <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Graham Klyne <>,
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: Fri, 14 Aug 2009 14:15:08 -0000

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.

That makes sense.
In our case, note the "X-" header field names have already been adopted 
in mobile networks, the "X-Device-" form being the most common ones. 
This is why the group argues that the "X-" *already* cannot be dropped.

> In future, someone will come up with an argument that there is already 
> some "X-" header names in the permanent registry.

Perhaps it would be better to issue some recommendation that says "Do 
not use X- prefix at all for new HTTP header fields!". They seem to have 
often been used as synonym to a vendor-specific namespace rather than 
for private experiments. For new HTTP header fields, why not use a 
"real" name and register it provisionally without much ado, perhaps in a 
"private provisional" registry and simply drop this "X-" convention?

For instance, your email client adds an X-Mailer HTTP header field to 
the message. There are other ways such information may be defined in an 
email: Mail-System-Version or Originating-Client for instance. These are 
non-standard HTTP header fields, but they are pretty common. I am not 
aware of any attempt to standardize one of them. If the info were deemed 
essential in the end, I guess one of the non "X-" HTTP header fields 
would probably be used and properly defined and standardized. And yet, 
whoever introduced them had no real "right" to do that. He should have 
used an "X-" HTTP header field.

Once an "X-" HTTP header field has managed to escape the private sphere, 
the transition period lasts as long as the header field is in use when 
the transition affects millions of content authors.

Don't we end up with locked situations where a given HTTP header field 
cannot be properly standardized because of the transition period? 
X-Forwarded-For, X-Wap-Profile have been used for years in mobile 
networks. It's a pity they cannot be registered properly, simply because 
they were not introduced with a correct name. Standardisation often has 
to compose with already existing stuff, and cannot just pretend nothing 
existed in the first place. The real discussion should be on the 
usefulness of the header fields.

>> 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.

I do not think the working group can move ahead against the rest of the 
world. At the very least, It would have to justify why it thinks it's right.

>> 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.

Agreed. The group does not think that this is a real problem in this case.

Trying to summarize to see if we are on the same grounds. If I get you 
right, you suggest that we do not register any HTTP header field at this 
step OR that we register the new HTTP header fields as "depreciated". 
The argument in favor of that is that the draft is not stable enough and 
registration of new HTTP fields in the provisional registry would seem 
like an encouragement to adopt them.

If we do register HTTP fields names as depreciated, can we update their 
status to "non-depreciated" at a later time and thus use the provisional 
registry as a mere name reservation mechanism?


> Regards,
> -sm