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

Re: [wmlprogramming] Verizon, guidelines

From: Eduardo Casais <casays@yahoo.com>
Date: Tue, 6 Jan 2009 01:48:09 -0800 (PST)
To: public-bpwg-ct@w3.org
Message-ID: <993325.34785.qm@web45010.mail.sp1.yahoo.com>

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

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. 

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:01:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:09:20 UTC