Re: [W3C] Draft Mobile Web BPWG / comments ( LC-2025 LC-2019 LC-2020 LC-2021 LC-2022 LC-2023 LC-2024)

 Dear casays ,

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/g777l1+b4so@eGroups.com
 2. http://www.w3.org/TR/2008/WD-ct-guidelines-20080801/


=====

Your comment on the document as a whole:
> In general, I must state unequivocally that our experience with
> current transformation proxies deployed throughout the world has
> always been negative, since all proxies seem to transform original
> mobile content regardless, with results ranging from passable to
> outrageously unusable.  The draft, while an interesting attempt to
> bring some order in the wild practices that abound in the mobile Web,
> is still vague and incomplete in several points, and thus, in its
> present form, may not stem some of the more egregious forms of
> transcoding we have witnessed so far.


Working Group Resolution (LC-2025):
We have attended to the main thrust of the comments here and the document
reflects the commenters points more than it did at least

----

Your comment on 4.1.1 Applicable HTTP Methods:
> 1) Section 4.1.1
> 
> Add to the section:
> 
> Proxies MUST NOT convert POST methods into GET ones, or vice-versa.
> 
> Rationale: This kind of transformation may make exchanges between
> clients and servers inoperative. In particular, this kind of
> substitution has been known to cause problems for content downloading
> applications in the mobile Web.


Working Group Resolution (LC-2019):
Final resolution:
- re. LC-2019, amend text on conversion between HEAD and GET to say that
other conversions are not allowed, and resolve partial to LC-2019

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

----

Your comment on 4.3 Proxy Forwarding of Response to User Agent:
> 2) Section 4.3
> 
> Following item to be added to the guidelines:
> 
> A Content Transformation Proxy receiving a response that contains a
> non-empty meta-tag "Copyright" MUST NOT restructure or recode the
> content, nor dependent resources (such as pictures or videos, or other
> textual content).
> 
> Rationale: The following content alterations may constitute willful
> copyright violations:
> a) Insertion of additional links, advertisements, navigation elements
> (e.g. scroll bars), or extraneous content.
> b) Modification of the look and feel (e.g. through reorganization of
> the page, filtering out elements such as pictograms). 
> 
> The following alterations may also constitute defacement of trade
> marks and other registered elements:
> c) Changing the representation of trademarks, logos and other
> registered design elements, as a change in the representation may
> affect its legibility, the colours or the colour palette.
> 
> The following alterations may also constitute disactivation of or
> bypassing IPR protections:
> d) Re-encoding images or videos which embed steganographic IPR
> protection information may eliminate or render ineffective these
> mechanisms.
> 
> A copyright meta-tag, in the absence of any other indication, is
> enough to signal that the content must not be transformed. This
> meta-tag is widely used in the WWW, and its inclusion in content as a
> meta-tag (invisible to end-users) is precisely intended to control
> automatic processing in the delivery chain.


Working Group Resolution (LC-2020):
We think that the presence or absence of a Copyright is not a clear
indication of the rights associated with a Web page.

----

Your comment on 4.3.6 Proxy Decision to Transform:
> 3) Section 4.3.6
> 
> Under "Examples of mobile specific DOCTYPEs:", add:
> 
> 	-//WAPFORUM//DTD WML 1.3//EN
> 	-//WAPFORUM//DTD WML 1.1//EN
> 
> Rationale: WML is still in use in the mobile Web. Responses of this
> type are precisely the kind that should not be transformed, as WML is
> intrinsically targeted at mobile devices only. WML can also be
> delivered over HTTP, so the draft applies to this content as well.


Working Group Resolution (LC-2021):
The list of doctypes associated with mobile content was moved to Appendix
D referenced by the second bullet in section 4.2.9 Proxy Decision to
Transform. It contains the requested doctypes:
http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-Mobile-DOCTYPES

----

Your comment on 4.3.6 Proxy Decision to Transform:
> 4) Section 4.3.6
> 
> The proposed heuristics seem to fail completely for i-mode sites,
> because:
> a) i-Mode sites often do not have peculiar URL distinguishing them
> from (non-mobile) sites, and in any case the prefix imode.* is not
> included in the list of URI patterns to check for.
> b) i-Mode sites return mostly their content as text/html.
> c) i-Mode sites do not include a DOCTYPE.
> d) The markup for i-Mode does not cater for the utilization of the
> link element as proposed in the draft, which is therefore not included
> in i-Mode content.
> e) i-Mode servers do not have much use for the "no-transform"
> directive, and hence do not necessarily implement it.


Working Group Resolution (LC-2022):
i-Mode DOCTYPEs were added to the list of DOCTYPEs associated with mobile
Content:
http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-Mobile-DOCTYPES

----

Your comment on 4.3.6.1 Alteration of Response:
> 5) Section 4.3.6.1
> 
> I miss any discussion or reference in the document about the issue of
> character encodings.
> 
> Transforming content across different charsets is a mine-field and
> affects a number of aspects:
> a) Content may rely upon widely different character encodings,
> depending on the targetted devices and markets. In particular, the
> trio China -   Japan - Korea (CJK) continues to rely on a number of
> encodings (such as Shift_JIS, BIG5, etc) whose handling is a complex
> matter; for instance, there are not necessarily bijective mappings
> between these encodings and others, including UTF-8. 
> b) Documents may have multi-encoding representations. Different
> encodings may be associated with external entities through the charset
> attribute (see HTML 4.0.1). How transformation proxies deal with such
> a situation is left undefined.
> c) Similarly, the draft does not explain what happens when a server
> associates an attribute accept-charset to a form, and whether proxies
> respect or manipulate such information.
> d) In i-Mode, and at least in the Softbank environment (Japan),
> unreserved character points in the character encoding space are used
> to represent pictograms. Any attempt to convert these characters
> directly will fail; they should therefore not be transformed, but
> preserved, taking into account the fact that the character points thus
> referred to differ between Unicode and Shift_JIS, and that DoCoMo and
> Softbank do not use the same code points for the same pictograms.
> 
> A consequence of all this is that if a proxy does not operate natively
> with the character encoding of the content returned by the server, or
> is not able to ensure a bijective mapping between this encoding and
> other encodings it deals with, recurrent and irrecoverable problems
> will creep.
> A simple way that could go some way towards alleviating this risk
> would be to forbid any transformation if the server announces (either
> via the HTTP field Content-type: charset=..., the XML declaration, or
> a meta-tag) an encoding different from ASCII or perhaps UTF-8.


Working Group Resolution (LC-2023):
Character encoding alterations are out of scope of these guidelines. A
note was added in 4.2.9.1 Alteration of Response:
http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-alteration-of-response

----

Your comment on 4.3.6.2 HTTPS Link Re-writing:
> 6) Section 4.3.6.2
> 
> The possibility to break the end-to-end security of an HTTPS
> connection is unacceptable and must be forbidden. This jeopardizes the
> set-up of mobile e-commerce, which had difficulties to get established
> in part because of the point-to-point, hop-wise secure connection with
> WTLS, and makes a sham of security for other applications that require
> it.
> 
> Besides, there is no guarantee that transformations performed by a
> proxy preserve the content being exchanged between client and server
> to a point that does not further disturb the secure exchange. As an
> example, there is no explicit prohibition in the draft against turning
> POST requests into GET ones, the resizing of images may make visual
> captchas unreadable, and reordering elements may make forms or
> security information difficult to figure out at the client side.


Working Group Resolution (LC-2024):
We agree and have added text to this section that goes some way to
addressing your concern.

----

Received on Tuesday, 6 October 2009 15:49:33 UTC