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

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



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

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.