 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
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?
Thanks, Francois.
Regards, -sm