W3C

Disposition of comments for the Mobile Web Best Practices Working Group

Single page view

1-20 21-40 41-60 61-80 81-85

In the table below, red is in the WG decision column indicates that the Working Group didn't agree with the comment, green indicates that a it agreed with it, and yellow reflects an in-between situation.

In the "Commentor reply" column, red indicates the commenter objected to the WG resolution, green indicates approval, and yellow means the commenter didn't respond to the request for feedback.

CommentorCommentWorking Group decisionCommentor reply
LC-2090 Luca Passani <passani@eunet.no> (archived comment)
Hi, I think that CTG should mention the fact that, in case of
transcoding, no extra content should be injected without the consent of
the original content owner. The idea is to avoid that W3C
protocols/guidelines implicitly endorse the attempt by those who
manage the transcoder to monetize on the effort/investment of other
people. Of course, there is also a point that injecting extra content
will invariably affect usability negatively and as such should be avoided.

I suggest the following addition:

"4.3.6.3 Injection of external content
In its effort to optimise the user experience of non-mobile optimised
sites, a proxy *should not* inject extra content into the transcoded
pages, where the term 'extra content' refers to text, links, banners
and other multimedia content which is not available on the original
untranscoded page. Addition of links aimed at implementing pagination
and navigational shortcuts is admissible.

Note: For clarity, it is emphasised that W3C does not endorse injection
of third-party content into a transcoded page without the explicit
consent of the content owner"

Can this comment be added to the tracking system?

Thank you

Luca Passani
The goals of this specification is to provide guidance to Content Transformation proxies and Content Providers as to how inter-work when delivering Web content. In other words, the guidelines are focused on defining means for the various actors of the delivery chain to communicate their intent and expectations.

The details of how a Content Transformation proxy performs restructuring operations is out of scope of this specification. The notion of user experience is by essence vague, and one design may be regarded as providing a better user experience by some and a lesser one by someone else.

The Working Group notes that alteration and thus injection of extra content is forbidden in responses served with a Cache-Control: no-transform.

Content Providers who do not want their content to be altered in any way should use this directive.
no
LC-2034 Mark Baker <distobj@acm.org> (archived comment)
4.1.1 Applicable HTTP Methods

"Proxies should not intervene in methods other than GET, POST, HEAD and PUT."

I can't think of any good reason for that. If a request using an
extension method wants to avoid transformation, it can always include
the no-transform directive.
This "should not" note shows the scope of Content Transformation as discussed in the Guidelines Recommendation. It is not envisaged that a content transformation proxy will intervene in a HTTP CONNECT for example. Or that a content transformation proxy will transform anything in any WebDAV methods. In fact we don't envisage any intervention in PUT either, so we will drop this to clarify that the scope of the document is limited to web browsing, using GET, POST & HEAD requests and their responses.

The updated text is available at:
http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-applicable-HTTP-methods
no
LC-2036 Mark Baker <distobj@acm.org> (archived comment)
4.1.5 Alteration of HTTP Header Values

RFC 2616 already says a lot about this. See sec 13.5.2 for example.

"The theoretical idempotency of GET requests is not always respected
by servers. In order, as far as possible, to avoid mis-operation of
such content, proxies should avoid issuing duplicate requests and
specifically should not issue duplicate requests for comparison
purposes."

First of all, do you mean "safe" or "idempotent"? That you refer only
to GET suggests safety, but the second sentence suggests you are
referring to idempotency. So please straighten that out. Oh, and
there's nothing "theoretical" about GET's safety or idempotency; it's
by definition, in fact.

Secondly, if the server changes something important because it
received a GET request, then that's its problem. Likewise, if it
changes something non-idempotently because it received a PUT request,
that's also something it has to deal with. In both cases though, the
request itself is idempotent (and safe with GET), so I see no merit to
that advice that you offer ... unless of course the problem you refer
to is pervasive which clearly isn't the case.

I also wonder if most of 4.1.5 shouldn't just defer to 2616. As is,
large chunks of this section (as well as others) specify a protocol
which is a subset of HTTP 1.1. (see also the RFC 2119 comment above)
Based on our experience and feedback from servers whose operators take strong exception to the practice of repeating GETs, we think it is reasonable to advise content transformation proxies operators of this situation. We're not prohibiting reissuing requests, we're just observing that content providers don't like it. no
LC-2071 Mark Nottingham <mnot@mnot.net> (archived comment)
* Section 4.1.5 Bullet points one and 3 are get-out-of-jail-free cards
for non-transparent proxies to ignore no-transform and do other anti-
social things. They should either be tightened up considerably, or
removed.
What is now section 4.2.3 makes it clear that no-transform must be respected:
http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-receipt-of-cache-control-no-transform

Bullets 1 and 3 only refer to alteration of the User-Agent and Accept-* headers and not to transformation of the response.
no
LC-2073 Mark Nottingham <mnot@mnot.net> (archived comment)
* Section 4.1.5 "proxies should use heuristics including comparisons
of domain name to assess whether resources form part of the same "Web
site." I don't think the W3C should be encouraging vendors to
implement yet more undefined heuristics for this task; there are
several approaches already in use (e.g., in cookies, HTTP, security
context, etc.); please pick one and refer to it specifically.
We are not aware of any satisfactory heuristics. We acknowledge the fact that Transformation Deployments will need to adopt heuristics of some kind, and that this must be left open. no
LC-2074 Mark Nottingham <mnot@mnot.net> (archived comment)
* Section 4.1.5.1 Proxies (and other clients) are allowed to and do
reissue requests; by disallowing it, you're profiling HTTP, not
providing guidelines.
Based on our experience and feedback from servers whose operators take strong exception to this practice, we think it's reasonable to advise operators of CT-proxies of this situation. We're not prohibiting reissuing requests, we're just observing that content providers don't like it. no
LC-2075 Mark Nottingham <mnot@mnot.net> (archived comment)
* Section 4.1.5.2 Again, not specifying the heuristics is going to
lead to differences in behaviour, which will cause content authors to
have to account for this as well.

* Section 4.1.5.2 "A proxy must not re-issue a POST/PUT request..." Is
this specific to POST and PUT, or all requests with bodies, or...?
We now limit the scope to HEAD GET and POST. We observe that duplicate POSTS are seen "in the wild" and think it important to point out to operators of content transformation proxies that this is problematical.

We acknowledge that not specifiying heuristics will lead to differences in behaviour. However, this is something that content transformation providers will need to do to provide the service they set out to provide.

The updated text is available at:
http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-avoiding-request-unacceptable
no
LC-2077 Mark Nottingham <mnot@mnot.net> (archived comment)
* Section 4.1.5.5 This is specifying new protocol elements; this is
becoming a protocol, not guidelines.
We are reflecting current practice as implemented by content transformation proxies. It is not our intention to create a new protocol, just to try to reduce the chaos that is currently perceived to be out there.

The newly introduced HTTP Header Fields have been provisionally registered with IANA:
http://www.iana.org/assignments/message-headers/prov-headers.html
no
LC-2083 Mark Nottingham <mnot@mnot.net> (archived comment)
* Section 4.3.3 Sniffing content for error messages is dangerous, and
also unlikely to work. E.g., will you sniff for all languages and all
possible phrases? How will you avoid false positives? Remove this
section and require content providers to get it right. People may
still do this in their products, but there's no reason to codify it.
Sniffing content is an important part of the mechanism described in 4.1.5 so has to be mentioned here in some form. But we don't mean to propose this as a fail safe mechanism, we merely mean to indicate that Content Transformation proxies may need to employ heuristics to provide an improved service for their users. Therefore we have removed any reference to conforming servers.

The updated text is available at:
http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-unacceptable-response
no
LC-2067 Mark Nottingham <mnot@mnot.net> (archived comment)
* Section 3.4 / 3.5 "A [Content|Transformation] Deployment conforms to
these guidelines if it follows the statements..." What does "follows"
mean here -- if they conform to all MUST level requirements? SHOULD
and MUST?
We agree that this is unclear. The guidelines now state that conformance applies to SHOULD statements as well and that a justification is required for each circumstance in which a SHOULD statement is not followed. Transformation Deployments willing to claim conformance to the spec must make available a conformance statement available as a separate document and referenced from the guidelines.

Check the updated version of the text:
http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-transformation-deployment-conformance
no
LC-2069 Mark Nottingham <mnot@mnot.net> (archived comment)
* Section 4.1.3 "Proxies must act as though a no-transform directive
is present (see 4.1.2 no-transform directive in Request) unless they
are able positively to determine that the user agent is a Web
browser." How do they positively" determine this? Using heuristics is
far from a guaranteed mechanism. Moreover, what is the reasoning
behind this? If the intent is to only allow transformation of content
intended for presentation to humans, it would be better to say that.
In any case, putting a MUST-level requirement on this seems strange.
We agree that there is no applicable mechanism to determine that the user agent is a Web browser, and have removed any normative statement from the section.

The section was substantially reworded and now refers to the notion of "Traditional Browsing".

The updated text is available at:
http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-non-web-browsers
no
LC-2072 Mark Nottingham <mnot@mnot.net> (archived comment)
* Section 4.1.5 What is a "restructured desktop experience"?
We agree and have added a term reference to the definition of "restructuring" and a cross reference to the section that describes the user selection of restructured experience.

The updated text is available at:
http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-altering-header-values
no
LC-2076 Mark Nottingham <mnot@mnot.net> (archived comment)
* Section 4.1.5.4 Use of the term 'representation' is confusing here;
please pick another one.

* Section 4.1.5.4 Using the same headers is often not a good idea.
More specific, per-header advice would be more helpful.
Ref 'representation', we agree and have used the term "included resources", as defined in the W3C mobileOK Basic Tests standard:
http://www.w3.org/TR/mobileOK-basic10-tests/#included_resources

Ref per-header advice, we agree and have clarified that we are only talking about keeping the User-Agent HTTP header field consistent.

The updated text is available at:
http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-sequence-of-requests
no
LC-2078 Mark Nottingham <mnot@mnot.net> (archived comment)
* Section 4.1.6.1 When a proxy inserts the URI to make a claim of
conformance, exactly what are they claiming -- all must-level
requirements are met? Should-level? What is the use case for this
information?
We agree and have clarified that inclusion of a Via comment of the form indicated is not a conformance claim, but is an indication that the proxy may restructure or otherwise modify content.

The updated text is available at:
http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-via-headers
no
LC-2079 Mark Nottingham <mnot@mnot.net> (archived comment)
* Section 4.2.1 Requiring servers to respond with 406 is profiling
HTTP; HTTP currently allows the server to send a 'default'
representation even when the headers say that the client doesn't
prefer it.
We agree and have moved server behavior into an "Informative Guidance for Origin Servers" non-normative appendix where we point out that servers should consider using an HTTP 406 Status if a request cannot be satisfied.

The updated text is available at:
http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-server-use-of-406
no
LC-2080 Mark Nottingham <mnot@mnot.net> (archived comment)
* Section 4.2.2 "Servers must include a Cache-Control: no-transform
directive if one is received in the HTTP request." Why?
We agree and have moved server behavior into an "Informative Guidance for Origin Servers" non-normative appendix where we point out that servers should consider including a Cache-Control: no-transform directive if one is received as it may be an indication that the client does not wish to receive a transformed response.

The updated text is available at:
http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-cache-control-no-transform
no
LC-2082 Mark Nottingham <mnot@mnot.net> (archived comment)
* Section 4.3.2 Why can't proxies transform something that has already
been transformed?
We agree and have replaced the section with a section that notes that intermediate proxies may add a Cache-Control: no-transform directive if they want to inhibit further transformation.

The updated text is available at:
http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-proxy-use-of-no-transform
no
LC-2084 Mark Nottingham <mnot@mnot.net> (archived comment)
* Section 4.3.4 What's the purpose behind this behaviour?
This section is part of the fail safe mechanism described in 4.1.5.2 Avoiding "Request Unacceptable" Responses. The reference to 4.1.5.2 was moved to the beginning of this section and the wording simplified.

The updated text is available at:
http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-receipt-of-vary-header
no
LC-2066 Mark Nottingham <mnot@mnot.net> (archived comment)
* Section 2.1 - "Alteration of HTTP requests and responses is not
prohibited by HTTP other than in the circumstances referred to in
[RFC2616 HTTP] Section 13.5.2." This isn't true; section 14.9.5 needs
to be referenced here as well.
We agree that section 14.9.5 refers to this and have changed the reference accordingly.

The updated text is available at:
http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-types-of-proxy
no
LC-2068 Mark Nottingham <mnot@mnot.net> (archived comment)
* Section 4.1.2 "If the request contains a Cache-Control: no-transform
directive proxies must forward the request unaltered to the server,
other than to comply with transparent HTTP behaviour and as noted
below." I'm not sure what this sentence means.
We agree and have added references to the revelant sections of RFC2616, as well as to the section of the guidelines that points out the HTTP header fields proxies should add.

The updated text is available at:
http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-request-no-transform
no

1-20 21-40 41-60 61-80 81-85


Developed and maintained by Dominique Hazaël-Massieux (dom@w3.org).
$Id: index.html,v 1.1 2017/08/11 06:43:21 dom Exp $
Please send bug reports and request for enhancements to w3t-sys.org