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

From: Francois Daoust <[email-masked]>
Date: Tue, 04 Aug 2009 18:31:00 +0200

Apologies for the late reply, I somehow managed not to see it up until now.

SM wrote:
> Hi Francois,
> At 08:34 10-07-2009, Francois Daoust wrote:
>> The situation the Mobile Web Best Practices working group is trying to 
>> address is one where different vendors used different HTTP header 
>> field conventions (all starting with 'X-') for the same use in their 
>> proxies, requiring content providers to support the different names 
>> when they wanted to do things properly. What the working group would 
>> like to do is to shrink the list of existing conventions to one and 
>> only one convention, but would prefer not to introduce any new 
>> convention (be it the last one) for that to happen. The 'X-Device-foo' 
>> format is the most commonly used format in the list based on the 
>> group's experience, and thus the chosen one.
> 
> I'll encourage you to adopt Graham's suggestion of moving to 
> "Device-foo" or any other valid name that does not start with "X-".  
> These "X-" headers are generally for private use where the 
> interpretation is by private agreement.  There are people outside the 
> group that might use that header field for other purposes and they are 
> unlikely to look it up in the registry.  If your working group already 
> agrees on having one convention, it is better to do away with the "X-".
> 

Thanks. I understand the suggestion and the implications of not 
following the suggestion.

At this point, the working group agrees on having one convention among 
the existing ones, which unfortunately all start with "X-". But the 
working group does not agree to do away with the "X-" not to introduce 
any kind of new notation. If you're fine with it, the group would thus 
like to proceed only with the registration of the "X-" versions of the 
HTTP header fields.

Francois.

[...]

---

From: SM <[email-masked]>
Date: Tue, 11 Aug 2009 23:38:40 -0700

Hi Francois,
At 09:31 04-08-2009, Francois Daoust wrote:
>At this point, the working group agrees on having one convention 
>among the existing ones, which unfortunately all start with "X-". 
>But the working group does not agree to do away with the "X-" not to 
>introduce any kind of new notation. If you're fine with it, the 
>group would thus like to proceed only with the registration of the 
>"X-" versions of the HTTP header fields.

The alternatives are:

   (i) Reject the request as "X-" message header fields names are 
generally not registered in the provisional and permanent Message 
Header Fields registries given that "X-" message header field names 
are reserved for private use.

  (ii) Accept the request for the registration of the five 
"X-Device-*" message header fields in the provisional Message Header 
Field Names registry with a "depreciated" status.

There aren't any "X-" headers in the Permanent Message Header Field 
Names registry.  As the working group does not agree to do away with 
the "X-", there may be a request to register the five "X-Device-*" 
message header fields as permanent Message Header field names.  I 
suggest using the first alternative as the working group does not 
plan to obsolete the five "X-Device-*" HTTP Header fields.

Regards,
-sm

---

From: Francois Daoust <[email-masked]>
Date: Thu, 13 Aug 2009 09:57:58 +0200

SM wrote:
> generally not registered in the provisional and permanent Message Header 
> Fields registries given that "X-" message header field names are 
> reserved for private use.
> 
>  (ii) Accept the request for the registration of the five "X-Device-*" 
> message header fields in the provisional Message Header Field Names 
> registry with a "depreciated" status.
> 
> Names registry.  As the working group does not agree to do away with the 
> "X-", there may be a request to register the five "X-Device-*" message 
> header fields as permanent Message Header field names.  I suggest using 
> the first alternative as the working group does not plan to obsolete the 
> five "X-Device-*" HTTP Header fields.

I'm not sure I understand why you directly jump to deprecated at this step.

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.

The intent of the working group is indeed to send a request to register 
the header fields in the permanent registry when (and if) the 
specification reaches a more stable level.

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.

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.

Regards,
Francois.

---

From: SM <[email-masked]>
Date: Thu, 13 Aug 2009 23:50:28 -0700

Hi Francois,
>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.

>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

---

From: Francois Daoust <[email-masked]>
Date: Fri, 14 Aug 2009 12:44:11 +0200

SM wrote:
> 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.

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

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

Thanks,
Francois.

---

From: SM <[email-masked]>
Date: Fri, 14 Aug 2009 13:22:25 -0700

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

---

From: Francois Daoust <[email-masked]>
Date: Mon, 17 Aug 2009 09:27:39 +0200

Thanks,

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.

Francois.

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,
>> 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.
>>
>>> 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.
>>
>> _______________________________________________
>> Ietf-message-headers mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ietf-message-headers
>>
>