RE: [ACTION 897] Establish best current practice regarding withrawal of use of X- form

> In short, you are asking that servers fail to correctly handle the
request
> as
> specified and make caching far less effective at the same time, in
> addition to
> doubling the latency on request parsing due to these useless header
fields
> being sent to servers that have no interest in reading them."

The point of informing the server of the original headers is so that if
a webmaster was ever to review the logs they would be able to answer the
question "how much mobile traffic do I get". We're keen that sites
should support a mobile experience and if there is no evidence in the
logs of ever being visited by mobile the motivation for creating mobile
experiences will be reduced.

Jo
> -----Original Message-----
> From: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org]
On
> Behalf Of Eduardo Casais
> Sent: 02 February 2009 09:30
> To: public-bpwg@w3.org
> Subject: [ACTION 897] Establish best current practice regarding
withrawal
> of use of X- form
> 
> 
> 1.	FEEDBACK.
> 
> Five persons responded privately and in two different mailing lists.
Here
> is the
> list of public message exchanges, ordered chronologically.
> 
>
www.ietf.org/mail-archive/web/ietf-message-headers/current/msg00097.html
>
www.ietf.org/mail-archive/web/ietf-message-headers/current/msg00096.html
> lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/0066.html
> lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/0044.html
> lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/0034.html
> lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/0029.html
> lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/0026.html
> lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/0022.html
> lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/0019.html
> 
> 
> 2.	HEADER FIELD MANAGEMENT.
> 
> Information about the registration and retirement of HTTP header
fields is
> summarized as follows:
> 
> a) There is no complete process for managing the life-cycle of HTTP
header
> fields. The only formalized aspect is the registration of fields on
the
> IANA
> registries, which is specified in RFC3864 (also known as BCP90). The
IETF
> considers things pragmatically on a case by case basis before fixing a
> policy.
> 
> b) There are two IANA registries: a provisional and a permanent one.
The
> provisional header field registry is intended to help developers and
> others
> find useful information about header fields and avoid naming
conflicts,
> even
> for fields whose usefulness is unclear; it is specifically not a
> declaration
> of standardization -- contrarily to the permanent registry. The
registries
> are
> found at www.iana.org/assignments/message-headers/message-header-
> index.html.
> 
> c) As such, it is possible to register a X-prefixed field in the
> provisional
> registry. This has been the case for X-Archived-At, marked as
> "deprecated",
> and a corresponding non-prefixed field Archived-At, permanently
registered
> and
> marked "standard". However, X-prefixed header fields are generally not
> registered at all.
> 
> d) Section 4.5 of RFC3864 indicates that a procedure similar to
> registration
> serves to retract a field or change its status. From the document,
> retracting a
> registered field requires the standard where the field is defined to
> specifiy a
> status change or a phasing-out procedure as well (e.g. marking a field
as
> "deprecated", then "historic" in revisions of the standard, before
> deleting it
> from the registry).
> 
> 
> 3.	RECOMMENDATIONS.
> 
> >From the received feedback, it was suggested to proceed as follows if
the
> non-X-prefixed header fields prove to be indeed useful:
> 
> a) Formally document the non-X-prefixed form in a standard with
whatever
> status
> is appropriate (possibly as a proposal for an IETF standards track).
> 
> b) Prepare a registration template for the non-X-prefixed field, with
> information about the standard and its current status.
> 
> c) Include a second template for the X-prefixed field to be lodged in
the
> provisional registry, marking its status as "deprecated", and
indicating
> the
> name of the preferred replacement field name (i.e. the non-X-prefixed
> one).
> 
> d) Submit header fields for registration as appropriate. If the fields
are
> already in use, or likely to be deployed soon in a significant number
of
> software systems, both submissions may take place sooner than later
for
> inclusion in the provisional IANA registry.
> 
> e) Later, when sufficient consensus is demonstrated for the new
proposals,
> an
> application may be made for making the new header field permanent
> (inclusion in
> a W3C REC-track specification would generally be considered indicative
of
> sufficient consensus).
> 
> f) Stop using the X-prefixed fields in implementations as soon as
> possible.
> 
> 
> 4.	X-DEVICE SCHEME.
> 
> Out of five correspondents, two were completely neutral with respect
to
> the
> (X-)Device-* scheme; one did not see the point of it and why we would
need
> these
> header fields; two were clearly hostile, considering the scheme as
> inherently
> flawed.
> 
> The fundamental criticism is that a proxy must fill the standard
fields
> with
> that information that allow the servers to produce optimal content. It
> should
> ask the server for the most appropriate representation for the device,
and
> transform the response only if it is not ideal. If substitute values
are
> unsuitable to generate mobile-optimized content, this means that the
> original
> HTTP header fields must not be modified.
> 
> Quoting:
> 
> "A content transformation proxy does not want the "server of mobile
web
> applications" to return content that is adjusted specifically for that
> terminal.
> If they did, they wouldn't need to change all of the request fields in
the
> first
> place to pretend not to be that terminal. They would just forward the
> original
> request without change, or adjust the parameters in the modified
request
> such
> that device-specific media types are preferred over standard media
types.
> 
> A content server DOES NOT want to know about some request parameters
other
> than
> what it is already designed to vary the representation. What you
suggest
> would
> require those servers to also Vary the content by these X-Device
header
> fields
> and specifically not comply with the standard fields for content
> negotiation.
> In short, you are asking that servers fail to correctly handle the
request
> as
> specified and make caching far less effective at the same time, in
> addition to
> doubling the latency on request parsing due to these useless header
fields
> being sent to servers that have no interest in reading them."
> 
> These criticisms correspond pretty much to the issue the community of
> mobile
> developers has been raising regarding that specific aspect of
CT-proxies;
> they
> thus indicate that the W3C would presumably have a hard time
registering
> the
> X-prefixed or non-X-prefixed capability backup fields at IANA.
> 
> 
> 5.	OTHER ISSUES.
> 
> One of the correspondents mentioned that earlier work at IETF on
mobile
> applications may be relevant for the W3C BPWG:
www.imc.org/ietf-medfree.
> 
> Quoting:
> 
> "In particular, the thrust of the work was to guide content adaptation
> through
> the description of fine-grained "media features" rather than
> identification of
> devices [...].
> Some of the ideas were carried through into W3C work on CC/PP, though
the
> RDF
> format is, of course, very different.  In particular, I always felt
that
> the
> media features registry could be embedded in URI space (for use with
CC/PP
> and
> other RDF formats) through proposals like www.rfc-
> editor.org/rfc/rfc3553.txt
> and www.ninebynine.org/IETF/URNs/draft-klyne-urn-ietf-conneg-01.txt
(the
> latter
> fizzled out for lack of support).
> I note that the model underpinning the content negotiation framework
we
> created
> has some similarities with a (simplified) form of OWL (DL), and the
> mechanisms
> for content negotiation and selection described there might
alternatively
> be
> provided by an OWL or description logic reasoner."
> 
> This may result in an action for somebody to investigate in the
context of
> future work.
> 
> 
> 
> E.Casais
> 
> 
> 
>

Received on Monday, 2 February 2009 13:00:48 UTC