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

[SM <[e-mail]>]

Hi Francois
At 03:44 14-08-2009, Francois Daoust wrote:
>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?

Private would also cover what vendors do internally.  Once they seek 
interoperability with other vendors or use over the Internet, they 
can ask for a registration in the provisional registry.

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

The "X-Mailer:" is a common Internet Message header.  It is 
documented as not part of an Internet Standard and is not in any of 
the message header field names registries.  There are also other 
issues with the message format emitted by my mail server. :-)  It's 
not really about whether we have the "right" to introduce a 
header.  It's more about avoiding conflict by using a common 
namespace as reference and to avoid interoperability issues.

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

Yes.  There are some problems that can't be fixed. :-)

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

I suggest that the group determines the naming of its HTTP header 
fields and requests a registration in the provisional message header 
registry.  If the header field name begins with "X-", mark it as 
"depreciated", i.e. it is or will be superceded by another field 
name.  If the draft is not stable enough or you don't want to 
encourage others to adopt the field name, don't register it in the 
provisional registry now.  If the draft is an open specification, an 
implementor outside the group might read the draft and use the 
headers in his or her implementation.  It's up to the group to decide 
whether to provide guidance on adoption of the headers and if so, how to do so.

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

I'll defer to IANA on the status update as it is an unusual move to 
go from "depreciated".    The provisional registry acts as a name 
reservation mechanism.  If I see "Device-User-Agent:" in there, I'll 
have to come up with a different field name if I am requesting a registration.

Regards,
-sm