[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 [127.0.0.1] (localhost [127.0.0.1]) 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 [127.0.0.1]) 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-Level:
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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (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 [195.186.19.62]) 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[62.202.154.210] Epoch[1232979068]
Received: from [62.202.154.210] ([62.202.154.210:7658] helo=AREPPIM002) by mail14.bluewin.ch (envelope-from <eduardo.casais@areppim.com>) (ecelerity 2.2.2.36 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 (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@ietf.org https://www.ietf.org/mailman/listinfo/ietf-message-headers