Re: [W3C] Draft Mobile Web BPWG / comments

Thanks for these comments which are very useful.

I'd like to pick up on a couple of points in particular:

 > 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.

Thanks for the mild praise. In answer to the mild criticism:

This kind of specification doesn't have legal force anywhere (afaik) and 
so actually doesn't set out to be a legally binding kind of thing which 
catches people who deliberately try to flout reasonable behavior and rules.

What it tries to do is to provide a framework for improved 
interoperability. It tries to provide a baseline for content 
transformation proxies to work more effectively with sites that have 
never heard of this document and even better interoperability with those 
that have and that wish to comply with its conventions.

When you go to buy a refrigerator in the UK there is an indication of 
the energy efficiency of those products. You can buy a bad one. You'd 
probably prefer to buy a better one - even though you are not forced to.

In a similar way we can't force anyone to do anything. However, one of 
my hopes is that people who deploy content transformation proxies will 
look for conformance statements from vendors and judge the products 
based on that, knowing that improved interoperability makes for greater 
uptake of mobile services.

On Character Encodings:

Yes we did discuss this, but decided that we didn't have anything 
specific enough to say. There's scope for vendor differentiation here. I 
think that in light of your comments we should review this.

On WML:

This is a tricky one. We do actually want WML to be transformed to WMLC. 
Saying that it isn't to be transformed will mean it breaks, just as 
noted in the document setting a no-transform on WML sometimes breaks it 
depending on how this is interpreted by the gateway.

Copyright

It's not in scope of this document to deal with policy issues. It's 
about inter-working. However, we do need to verge on policy issues in 
places.

We took the view that a transforming proxy is not part of the user agent 
when deployed as described. However, there are some questions that arise 
by analogy with common user agent practice.

For example, users can substitute style sheets for those provided by the 
content provider, can put display: none to suppress display of things 
they don't want to see and can introduce various artefacts that 
substantially change the appearance from what the author had anticipated.

For example, again, assistive technologies change the appearance (or 
presentation medium) from what the author might have directly intended, 
especially when they create audio from text and so on.

Indeed, when authoring HTML, the author cannot have a precise view of 
the visual form of their work because intentionally, and by their 
nature, Web browsers do not set out to provide identical experiences. 
[Leave aside stuff like ACID tests for now, which demonstrate that they 
often don't create identical experiences even when they ought to]. Some 
of them even offer ad stripping technology.

I'm afraid that I don't know anything worth knowing about copyright. But 
it seems to me at least arguable that the point of authoring in HTML is 
to allow flexibility and freedom to create derivative works. At a 
minimum surely there is an implied license to create a visual 
representation that is not inherently present in the markup?

Consequently though having a copyright statement might be useful, I'm 
not sure that constitutes a restriction of the kind you suggest. There 
seem to me plenty of cases where it's perfectly reasonable to change 
things around at the user's request.

In the end, this document is not about copyright, or policy. If a meta 
copyright element has the force you suggest then I certainly think we 
should take account of it. But my understanding is that it does not.

Like I say, my words are legally uninformed opinion, if you know of some 
legally informed source on this it would be very interesting to hear 
about it.

Thanks again for your input.
Jo

PS. Ref your comment on wmlprogramming, we will split your comment up 
when responding formally to it.


On 04/08/2008 16:36, casays wrote:
> To the W3C Mobile Web BPWG.
> 
> This is a response to the call for comments regarding the "Working
> Draft of the Content Transformation Guidelines" from 1.8.2008.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 
> 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.
> 
> Eduardo Casais
> areppim AG
> Bern, Switzerland
> 
> 
>

Received on Tuesday, 5 August 2008 14:33:48 UTC