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

<eduardo.casais@areppim.com> Mon, 26 January 2009 14:34 UTC

Return-Path: <ietf-message-headers-bounces@ietf.org>
X-Original-To: ietf-message-headers-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-message-headers-archive@core3.amsl.com
Received: from [] (localhost []) by core3.amsl.com (Postfix) with ESMTP id 8174B3A6A77; Mon, 26 Jan 2009 06:34:12 -0800 (PST)
X-Original-To: ietf-message-headers@core3.amsl.com
Delivered-To: ietf-message-headers@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id C3D373A6A6A for <ietf-message-headers@core3.amsl.com>; Mon, 26 Jan 2009 06:11:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.299
X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id suSSIUkYdF96 for <ietf-message-headers@core3.amsl.com>; Mon, 26 Jan 2009 06:11:38 -0800 (PST)
Received: from mail14.bluewin.ch (mail14.bluewin.ch []) by core3.amsl.com (Postfix) with ESMTP id F3C7628C237 for <ietf-message-headers@ietf.org>; Mon, 26 Jan 2009 06:11:27 -0800 (PST)
X-FXIT-IP: IPv4[] Epoch[1232979068]
Received: from [] ([] helo=AREPPIM002) by mail14.bluewin.ch (envelope-from <eduardo.casais@areppim.com>) (ecelerity r(27513/27514)) with ESMTP id 7A/CE-29597-B74CD794; Mon, 26 Jan 2009 14:11:08 +0000
From: <eduardo.casais@areppim.com>
To: <ietf-message-headers@ietf.org>
Date: Mon, 26 Jan 2009 15:11:17 +0100
Organization: areppim AG
Message-ID: <000001c97fbf$f4de4be0$d29aca3e@AREPPIM002>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6838
Importance: Normal
Thread-Index: Acl9ZhV3mXmgqwnaTy2wqWNPWYBNegCWce+w
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Subject: [Ietf-message-headers] [W3C BPWG] HTTP header fields X-* and normal ones / request for advice
X-BeenThere: ietf-message-headers@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Discussion list for header fields used in Internet messaging applications." <ietf-message-headers.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf-message-headers>, <mailto:ietf-message-headers-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ietf-message-headers>
List-Post: <mailto:ietf-message-headers@ietf.org>
List-Help: <mailto:ietf-message-headers-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-message-headers>, <mailto:ietf-message-headers-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-message-headers-bounces@ietf.org
Errors-To: ietf-message-headers-bounces@ietf.org

I am writing on behalf of the W3C Mobile Web Best Practice Working Group


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

Some of these proxies utilize additional X- prefixed header fields. The W3C
considering formalizing best practices for this technology, introducing
(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
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
registry. Despite RFC822, there is also an X- prefixed field provisionally 
registered at IANA (X-Archived-At), marked as "deprecated", and a
non-prefixed field Archived-At, permanently registered and marked

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


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

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

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



Background information on content transformation proxies. 




Content transformation proxies (CT-proxies) are intended to convert Web
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
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
fields "User-Agent", "Accept", "Accept-Charset", "Accept-Language", "Accept-

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

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-Charset", "X-Device-Accept-Language", "X-Device-Accept".
is the set of fields under discussion. CT-proxies assume that
sites do not look into these backup fields, whereas mobile-aware sites can
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