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

At 23:10 09/01/21, eduardo.casais@areppim.com wrote:
>2) Issue.
>
>Some content transformation proxies modify the HTTP request header, and
>place
>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?


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

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

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

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.

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

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

>
>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?

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

>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?

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.

>3.c: What is the procedure, policy, standard or best practice of the IETF
>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:duerst@it.aoyama.ac.jp

Received on Thursday, 22 January 2009 06:13:51 UTC