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

Jo Rabin wrote:
>> 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.

[I know I already expressed my concerns about the X-Device-* headers 
during last F2F, but...]

I wonder how many content providers actually log the whole HTTP header 
of the request? (apart from "mobile" content providers, that is, who are 
probably already aware of content transformation proxies)

I think most of the Web servers are configured to log few HTTP header 
fields, those that may be useful to compute stats afterwards: 
User-Agent, Accept, Accept-Charset, Referer, that kind of fields. I 
don't think any of them logs by default any of the X- headers Eduardo 
mentioned.

That is not to say that it can't be done, but merely that Webmasters 
would already have to know what they are looking for. If they know what 
they are looking for, then they may as well run a little experiment by 
sending a "Vary: User-Agent" to force intermediary proxies to send back 
the original request and see what changes. Extracting logs information 
is often flawed anyway, because of caching.

If, on the contrary, the rationale is to ensure that mobile Content 
Providers can always reconstruct the original HTTP request and reply to 
the "real" user agent, why isn't the use of the "Vary: User-Agent" HTTP 
header and the emphasis that the original request should be sent first 
enough? I understand it has a cost (a potential additional round trip), 
but at least it doesn't require the Content Provider to change anything 
in his code and doesn't create any architectural problem from an HTTP 
point of view.

[Note that I'm sure many Content Providers around vary their 
representations and do not use the "Vary" header. But then that means 
they probably do not use caching either, so that could be a good 
opportunity to have them start improving caching directives]

In short, I find that having the X-Device-* headers is somehow 
misleading, especially if the rationale to have them is the need for 
logs that could eventually be used by Webmasters.

I share Eduardo's thoughts, though I probably go one step further: I 
don't think we should register new HTTP header fields. I don't think we 
should use X-Device-* header fields at all. We should just ensure that 
the original header fields can be received by Content Providers!

Or we could reference them informatively in the Content Providers 
section "By the way, if you're looking for some stats, here are places 
where you may find the original header fields".

I think there was another rationale to have them in, which I confess I 
forgot...

Francois.




> 
> 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 14:40:55 UTC