- From: <fd@w3.org>
- Date: Tue, 06 Oct 2009 15:34:18 +0000
- To: Luca Passani <passani@eunet.no>
- Cc: public-bpwg-comments@w3.org
Dear Luca Passani ,
The Mobile Web Best Practices Working Group has reviewed the comments you
sent [1] on the Last Call Working Draft [2] of the Content Transformation
Guidelines 1.0 published on 1 Aug 2008. Thank you for having taken the time
to review the document and to send us comments!
The Working Group's response to your comment is included below, and has
been implemented in the new version of the document available at:
http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/.
Please review it carefully and let us know by email at
public-bpwg-comments@w3.org if you agree with it or not before 6 November
2009. In case of disagreement, you are requested to provide a specific
solution for or a path to a consensus with the Working Group. If such a
consensus cannot be achieved, you will be given the opportunity to raise a
formal objection which will then be reviewed by the Director during the
transition of this document to the next stage in the W3C Recommendation
Track.
Thanks,
For the Mobile Web Best Practices Working Group,
Dominique Hazaël-Massieux
François Daoust
W3C Staff Contacts
1. http://www.w3.org/mid/4896D55B.8060807@eunet.no
2. http://www.w3.org/TR/2008/WD-ct-guidelines-20080801/
=====
Your comment on 4.1 Proxy Forwarding of Request:
> Also, I see that CTG does not mention "whitelists". I think it should,
> since many transcoders manage that. The rule (consistently with the
> concept that transcoders must err on the side of not transcoding) should
> be that whitelists can only specify which potentially mobile sites can
> be forced to be trascoded (and not the other way around as happens to be
> common today, thus potentially forcing mobile developers to ask
> operators in different countries to whitelist their service, which is of
> course unacceptable).
Working Group Resolution (LC-2003):
We have had considerable discussion about "allow" and "disallow" lists and
came to the conclusion that it was preferable to discuss a proxy's behavior
rather than its (presumed) internal method of operation. Instead we refer
to a notion that includes allow and disallow lists under 4.1.5 and 4.2.6.
This approach allows us to specify that servers have a way of overcoming
mis-configuration without recourse to administrative contact with any
operator of a proxy and without specifying the exact configuration
mechanism, which is usually not open to public inspection or evaluation.
See updated sections 4.1.5:
http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-altering-header-values
... and 4.2.6:
http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-receipt-of-vary-header
----
Your comment on 4.1.5 Alteration of HTTP Header Values:
> - the styleguide should spell out very clearly "The Transcoder is NOT
> allowed to change the User-Agent String".
> I understand that the current document says "do not change headers",
> but at the same time, there are clauses ("the user has specifically
> requested a restructured desktop experience") which would allow abusive
> transcoders to find an excuse and keep being abusive of the rights of
> content owners. Preventing transcoders from changing the UA string is an
> effective way to avoid this abuse.
Working Group Resolution (LC-1996):
Section 4.1.5 on alteration of HTTP Header Field Values remains
substantially as in the previous version of the document, but has been
reinforced by saying that proxies must not delete headers and that is must
be possible for the server to reconstruct the original User Agent
originated headers by using the X-Device-* HTTP header fields:
http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-altering-header-values
We have strengthened section 4.2.6 Receipt of Vary HTTP Header Field:
http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-receipt-of-vary-header
We have also introduces new guidelines in section 4.2.2 User Preferences
that forces proxies to provide a means for users to express their
preferences for inhibiting content transformation:
http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-administrative-arrangements
In addition, we have updated the conformance section to state that
Transformation Deployments that choose to claim conformance with these
guidelines need to spell out the circumstances in which they deviate from
"should" clauses by providing a conformance statement that comes as a
separate document referenced by the guidelines:
http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-transformation-deployment-conformance
----
Your comment on 4.1.5.5 Original Headers:
> - original headers MUST not be changed (User-Agent string has a special
>
> place, but also the UAProf x-wap-profile is very very relevant). This
> makes it unnecessary to explain how original header values are recast to
> different headers (this is not supposed to happen in any case). In
> short, 4.1.5.5 should be removed.
Working Group Resolution (LC-1997):
The text surrounding which HTTP request headers can be altered and under
what circumstances has been tightened up in another part of 4.1.5. However,
section 4.1.5.5 remains - because if request headers have been altered, for
whatever reason, it is useful for website technicians to be able to see the
complete and original information from the device so that they can find out
what is happening.
The updated text is available at:
http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-original-headers
----
Your comment on 4.3.6 Proxy Decision to Transform:
> - the "|application/xhtml+xml" MIME type should be the basis for an
> heuristics that informs transcoders that no transcoding must be
> applied.
> The rationale for this is obvious: this MIME type is being used for
> mobile content virtually exclusively these days
Working Group Resolution (LC-1998):
A list of content type heuristics has been added to Appendix C, which is
where the example content types associated with mobile content delivery
have been moved.
The application/xhtml+xml is not among the content types listed in this
Appendix, because although it is true that this content type has primarily
been used to serve mobile content as of today, its meaning is broader than
that and encompasses any kind of XHTML content.
It should also be noted that transformation proxies need to be careful
when employing these heuristics. For example, the application/xhtml+xml
content type is the recommended content type for all XHTML and not just for
mobile content (see http://www.w3.org/TR/xhtml-media-types/). Although it
may only be used for mobile content as of today, there is no way to predict
the future and no reason to restrict its meaning.
The appendix is available at:
http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-Mobile-Content-Types
----
Your comment on 4.3.6 Proxy Decision to Transform:
> - There should be restrictions over how short a page transcoders are
> allowed to reformat. In no case should a page smaller than 10kb be
> reformatted (ideally this threshold should be higher, but 10kb will
> make
> it consistent with BT, so it would be a step in the right direction)
Working Group Resolution (LC-1999):
Size of page on its own is not a safe indicator that a page is designed
for mobile, so this heuristic has not been added to the working draft.
Some examples of pages where page size is not a good indicator of mobile
friendliness include: pages that consist of one large Flash animation,
small pages linked off the main page (e.g., login pages), google.com, etc.
----
Your comment on 4.3.6 Proxy Decision to Transform:
> - Navigation bars: this is something that I would like to introduce in
> the Manifesto too. In no event should a transcoder add extra footers or
>
> headers (logos, extra navbars, advertisement and similar) without the
> consent of the content owner.
Working Group Resolution (LC-2000):
This restriction is not necessary. Content providers can use the
Cache-Control: no-transform HTTP header if they want to make sure that
additional content is not added to their pages. Proxies are forbidden from
adding content to pages when this header is present.
----
Your comment on 4.3.6 Proxy Decision to Transform:
> - The list of "safe" URL patterns should be improved to support iphone.*
> and */iphone/
Working Group Resolution (LC-2002):
After considerable discussion the group decided not to recommend any URI
patterns other than those listed in Appendix E.
----
Your comment on 4.3.6.2 HTTPS Link Re-writing:
> - Messing with HTTPS should not be permissible under any circumstances.
>
> Disrupting HTTPS they way transcoder do today is probably illegal and
> certainly unethical. HTTPS is built to guarantee end2end security.
> Breaking end2end security is probably illegal and certainly not an
> activity that W3C should endorse in any way.
Working Group Resolution (LC-2001):
We agree and have added text to this section that goes some way to
addressing your concern.
----
Received on Tuesday, 6 October 2009 15:34:25 UTC