W3C home > Mailing lists > Public > public-bpwg-ct@w3.org > January 2009

Re: [wmlprogramming] Verizon, guidelines

From: Francois Daoust <fd@w3.org>
Date: Tue, 06 Jan 2009 11:33:05 +0100
Message-ID: <49633361.4060009@w3.org>
To: casays@yahoo.com
CC: public-bpwg-ct@w3.org

Eduardo Casais wrote:
> I would like to comment on one specific statement made 
> regarding the "no-transform" directive.
>> As of today, the directive is not respected by all the
>> existing content transformation proxies, and is 
>> unfortunately (incorrectly, some would say) respected by
>> some gateways, preventing WML to WMLC conversion
>> and/or other optimizations that are useful on mobile
>> networks.
> The fact that WAP gateways strictly enforce the directive
> is neither unfortunate, nor incorrect: this is exactly what
> the HTTP standard mandates -- indeed it "is the standard
> way to prevent content modifications under any 
> circumstances", including encoding to WBXML, GZIP or UUENCODE. 

I didn't intend to take any good/bad position here, but the way I 
phrased my comment indeed looks as if I did.

I meant "unfortunately" to say that it's not good news for us (i.e. the 
directive needs to be used with care), not to say that WAP gateways 
should not have followed the directive. The "incorrectly" that is 
sometimes heard here and there is triggered by the RFC2616 itself 
because the "Cache-Control: no-transform" directive is explicitly 
defined in section 14.9.5 for "an intermediate cache or proxy", and as 
such not explicitly for gateways. I have no idea whether this was really 
intended, and besides there is nothing there that prevents WAP gateways 
from applying the directive. It does not really matter anyway, there is 
nothing we can change here, the important fact to keep in mind is that 
the directive is applied by WAP gateways.


> There is also a reason why these WAP gateways operate
> like this. With the advent of WAP2.0, manufacturers 
> developed some models that could parse and render both
> XHTML mp and WML directly from the XML source file. 
> These terminals do not include an interpreter for the 
> WBXML format. Application servers can then serve WML
> content with the "no-transform" directive to ensure that
> gateways do not encode the content for those phones
> that do not handle it. One could think that a gateway 
> should actually determine whether to return source WML
> or WBXML-encoded WML depending on the "Accept"
> field sent by the terminal (one MIME type is for compiled
> WML, another for source WML), but this does not work.
> Every WML content is, by the standard, supposed to be
> encoded, and many terminals initially only provided the
> MIME type corresponding to source WML in their HTTP
> header. Devices that accept only source WML were
> considered an exception -- properly handled by application
> servers via "no-transform".
Received on Tuesday, 6 January 2009 10:33:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:06:30 UTC