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

On Mon, 02 Feb 2009 16:54:44 +0100, Luca Passani <passani@eunet.no> wrote:

> Maybe everything would be solved in a more logical and coherent way if  
> the group accepted the viewpoint that transcoding is a "hack", no matter  
> how you look at it.

Maybe, but I don't see any clear reason why one would accept that  
viewpoint - it is not self-evident to me, and if the group has not  
accepted it en masse already that suggests that it is really rather less  
than self-evident.

cheers

Chaals

> If you accept this simple (and self-evident) viewpoint, than a very fair  
> compromise can be found in accepting the fact that transcoders can keep  
> on hacking happily as much as they want, but they just shouldn't be  
> doing so in W3C's name, since this brings chaos to established web  
> standards and practices.
>
> cheers
>
> Luca
>
> Francois Daoust wrote:
>>
>> 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
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>



-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com

Received on Monday, 2 February 2009 16:06:43 UTC