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 Graham,

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.

That said, I have nothing against provisional registration of both forms. I add the topic to the working group's agenda for discussion. I suppose that, in any case, if we register the 'X-Device-User-Agent' header field, the 'Device-User-Agent' header field de facto would become "unavailable", not to trigger any confusion.

Francois.



Graham Klyne wrote:
Concerning the use of X- headers.

A similar situation existed with the X-Archived-At header field [1]. When that proposal went to standard/recommendation, the 'X-' was dropped for the permanent registration [2], but the 'X-' version was retained in the provisional registry [3], marked as 'Deprecated'.

Assuming that you intend your specification to proceed to REC, I would suggest a similar approach here. In which case, you may wish to consider provisional registration of both forms.

(The provisional header registry was intended, in part, to address unsatisfactory aspects of the 'X-' naming convention illustrated by cases like this.)

[1] http://www.rfc-editor.org/rfc/rfc5064.txt
[2] http://www.iana.org/assignments/message-headers/perm-headers.html
[3] http://www.iana.org/assignments/message-headers/prov-headers.html

#g
--


Francois Daoust wrote:
Hi,

Please find below the registration template for 5 HTTP header fields the W3C Mobile Web Best Practices Working Group would like to provisionally register for use in the "Guidelines for Web Content Transformation Proxies" specification it is currently working on.

Note on the presence of the "X-" prefix: names were chosen on the basis that there are a already existing and deployed convention. Since there is no easy way to transition out of a situation where an "X-" prefix has been used for other purpose than a purely experimental one, the W3C Mobile Web Best Practices Working Group acknowledges that these HTTP header field names are already in use and requests that the "X-" prefix be (exceptionally) kept.


-----
Header field names:
X-Device-User-Agent (request header)
X-Device-Accept (request header)
X-Device-Accept-Charset (request header)
X-Device-Accept-Encoding (request header)
X-Device-Accept-Language (request header)

Applicable protocol:
http

Status:
provisional

Author/Change controller:
W3C Mobile Web Best Practices Working Group
http://www.w3.org/2005/MWI/BPWG/

Specification document(s):
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/latest
(Editor's Draft)
http://www.w3.org/TR/ct-guidelines/ (Working Draft)

See section "4.1.5.5 Original Header Fields" in the documents.
-----


I will submit the above template to the designated IANA e-mail address beginning of August, unless some explicit disagreement is made on this list.

Regards,

On behalf of the W3C Mobile Web Best Practices Working Group,
Francois Daoust,
W3C Staff Contact for the group.
_______________________________________________
Ietf-message-headers mailing list
Ietf-message-headers at ietf.org
https://www.ietf.org/mailman/listinfo/ietf-message-headers



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