Subject: [W3C BPWG] HTTP header fields X-* and normal ones / question

From: <[email-masked]>
Date: Wed, 21 Jan 2009 14:10:11 +0000

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

2) Issue.

Some content transformation proxies modify the HTTP request header, and
place
the original information in extra backup header fields. These header fields
concern the client capabilities. The backup fields are prefixed with
"X-Device-"  
-- X-Device-User-Agent, X-Device-Accept, X-Device-Accept-Charset, 
X-Device-Accept-Language, X-Device-Accept-Encoding.

The W3C BPWG is looking into formalizing these backup fields and registering
them as proper HTTP header fields in the IANA registry according to RFC3864.
This implies that they be renamed in view of eliminating the X- prefix (for
instance, Device-Accept instead of X-Device-Accept), since it appears that
HTTP header fields of the pattern X-... are not allowed to be registered (a
probable consequence of RFC822).

Because deployed transformation proxies rely upon the backup fields with the
X-Device- prefix, and all deployed proxies cannot be updated to use new
field
names in a "big bang" switch-over, the W3C BPWG is potentially facing a
migration period where both the old, X-Device- fields, and the newer, e.g.
Device- fields, may have to coexist.

3) Questions to the IETF.

3.a: What is the IETF procedure, policy, standard, or best practice
regarding
the promotion of X- header fields to normal, registered (provisionally or 
permanently) header fields?

3.b: What is the policy, standard or best practice of the IETF regarding the
simultaneous deployment and utilization of two sets of header fields, which 
have the same semantics, one comprising fields of the pattern X- and the
other
fields of a normal pattern?

3.c: What is the procedure, policy, standard or best practice of the IETF
regarding the deprecation and discontinuance of HTTP header fields?

Many thanks in advance for your answers.

Eduardo Casais
areppim AG
Bern, Switzerland

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 21 Jan 2009 11:55:04 -0800

<[email-masked]> wrote:
> I am writing on behalf of the W3C Mobile Web Best Practice Working  
> Group
> (W3C
> BPWG).
>
>
> 1) Context.
>

WTF?  That's insane.

> Device- fields, may have to coexist.

That's even more insane.  If the request is being rewritten then it  
is not
the same request -- the old request fields should not be sent at all.
The inbound server doesn't care about these values and sure as hell
doesn't want to parse them as part of the request. As such, your  
deployed
proxies are irrelevant.

> permanently) header fields?

Never use them in deployed software. The X-prefix is for private use in
experiments that are NOT EXPOSED TO THE INTERNET.

> fields of a normal pattern?

There is none.

> regarding the deprecation and discontinuance of HTTP header fields?

Just stop using them.  In this case, there is no reason to send
any such header fields, so just remove them from your specs and
your implementations and you are done.

Cheers,

Roy T. Fielding                            <http://roy.gbiv.com/>
Chief Scientist, Day Software              <http://www.day.com/>

---

From: Martin Duerst <[email-masked]>
Date: Thu, 22 Jan 2009 15:11:50 +0900

>the original information in extra backup header fields.

Same as Roy Fielding, I have a hard time understanding what that's
good for, as the origin servers will honor the converted request,
and ignore any X-Device-... or similar headers. Maybe you can explain?

>them as proper HTTP header fields in the IANA registry according to RFC3864.

If you plan on doing so, you should also write to the relevant mailing
list (ietf-message-headers.ietf.org).

>probable consequence of RFC822).

There's at least one exception, namely X-Archived-At.
See http://www.iana.org/assignments/message-headers/prov-headers.html.
This was provisionally registered to allow people to find out
what it was supposed to mean. Archived-At is permanently registered,
see http://www.iana.org/assignments/message-headers/perm-headers.html.

In my understanding, at least provisional registration for headers
without the "X-" prefix should not be a problem, because provisional
registration is to avoid conflicts, even with headers who are not
yet in use or who's usefullness is unclear.

>Device- fields, may have to coexist.

I'm not sure in which way the proxies *rely* on these. They
produce them, but *rely* suggests some form of consumption.

>permanently) header fields?

If they are indeed useful, headers without X- should indeed be
created to aid interoperability.

>fields of a normal pattern?

The headers without X- should be deployed as soon as it is clear that
they are useful. The fact that X- headers may still be used for a while
isn't something affected by policy, just a fact of life.

>regarding the deprecation and discontinuance of HTTP header fields?

See http://www.rfc-editor.org/rfc/rfc3864.txt. As an example,
the X-Archived-At header is explicitly deprecated.

Regards,    Martin.

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]