[Ietf-message-headers] [W3C BPWG] HTTP header fields X-* and normal ones / request for advice

[<eduardo.casais at areppim.com>]

I am writing on behalf of the W3C Mobile Web Best Practice Working Group
(W3C 
BPWG). 


1) CONTEXT. 

The W3C BPWG is currently elaborating guidelines for content transformation 
proxies, i.e. proxies that modify HTTP requests sent by terminals and
responses returned by application servers; the paramount case is
transforming WWW sites 
intended for desktops in a format suitable for mobile devices, notably
mobile 
phones. 

Some of these proxies utilize additional X- prefixed header fields. The W3C
is 
considering formalizing best practices for this technology, introducing
normal 
(i.e. non X- prefixed) header fields, and registering them at IANA. Details 
about these extra fields are given in the appendix below. 


2) ISSUE. 

There are already commercial systems in production use that send these X- 
prefixed header fields, and that cannot be updated to use the new header
fields 
in a "big-bang" upgrade. Hence, we realize there might be a migration period

where both X- prefixed and non-prefixed fields coexist. 

RFC3864 specifies a procedure to register HTTP header fields. It also lists 
the statuses that a header field can have ("standard", "informational", 
"historic", etc). 

There are several provisional and permanent fields marked "deprecated" in
that 
registry. Despite RFC822, there is also an X- prefixed field provisionally 
registered at IANA (X-Archived-At), marked as "deprecated", and a
corresponding 
non-prefixed field Archived-At, permanently registered and marked
"standard". 

All this seems to indicate that the IETF has experience in managing a
migration 
from experimental (X- prefixed) fields to standard ones, and hopefully that
it 
has devised a life-cycle management scheme for header fields. 


3) QUESTIONS. 

We would be grateful to get advice from the IETF with respect to handling
the 
coexistence of X- and non-X- prefixed fields, and the phasing out of
deprecated 
fields.

3.a: What is the IETF policy regarding the registration of X- prefixed
fields? 

3.b: What is the IETF policy regarding the promotion of X- prefixed header 
fields (registered or not) to non-X-prefixed, standard registered ones? 

3.c: What is the IETF policy regarding the simultaneous deployment and 
utilization of two sets of header fields, which have the same semantics, one

comprising X- prefixed and the other equivalent non-prefixed fields? 

3.d: What is the IETF policy regarding the deprecation and discontinuance of

HTTP header fields? 


Many thanks in advance for your answers.


Eduardo Casais
areppim AG
Bern, Switzerland

----------------------------------------

APPENDIX

Background information on content transformation proxies. 


A) REFERENCE. 

http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guideline
s/latest


B) CT-PROXIES. 

Content transformation proxies (CT-proxies) are intended to convert Web
content 
designed for desktop computers into a form suitable for mobile devices (most

notably mobile phones). 

Application servers that cater for desktop users generally produce either 
generic Web content, or perform some adjustments to browser quirks by 
recognizing the kind of browser that issues the requests (e.g. Opera vs. 
Firefox vs. IE). 

Application servers that cater for mobile users most of the time perform a 
thorough analysis of the request in order to produce Web content that is 
optimized not only for the browser, but also for the end-user device itself 
(e.g. depending on the screen dimensions, acceptable page size, presence of 
special keys, etc); they generally recognize and deal with desktop browsers 
as such.

Some CT-proxies assume that a desktop-oriented application server will not 
respond properly if original requests from a mobile terminal are forwarded
to 
it, since the server may not be able to recognize the browser issuing the 
request. Hence, they substitute the values in the original HTTP request
header 
fields "User-Agent", "Accept", "Accept-Charset", "Accept-Language", "Accept-

Encoding" to make it appear as if the request comes from a well-known
desktop 
browser. 

There is no reliable way to determine a priori whether the target of a
client request serves only desktop-suitable content, or mobile-optimized
content. The 
above substitutions prove detrimental to mobile-oriented servers, which are 
lured into producing generic desktop Web content (which is then converted by

the CT-proxy into some mobile format) instead of a carefully optimized 
mobile-specific version of the site directly. 

In order to allow these mobile-aware sites to perform their optimizations 
despite masquerading mobile requests as desktop requests, some CT-proxies
place the original information in extra backup header fields. The backup
fields are 
prefixed with "X-Device-" -- "X-Device-User-Agent",
"X-Device-Accept-Encoding", 
"X-Device-Accept-Charset", "X-Device-Accept-Language", "X-Device-Accept".
This 
is the set of fields under discussion. CT-proxies assume that
desktop-oriented 
sites do not look into these backup fields, whereas mobile-aware sites can
and 
will. This scheme and the assumption underlying the spoofing of requests has

been and still is being debated within and outside the W3C. 
----------------------------------------

_______________________________________________
Ietf-message-headers mailing list
Ietf-message-headers at ietf.org
https://www.ietf.org/mailman/listinfo/ietf-message-headers