W3C home > Mailing lists > Public > public-bpwg-ct@w3.org > November 2008

Re: [CTG] Draft 2008-11-07 / http-equiv / WML

From: Jose Alberto Fernandez <jalberto@cellectivity.com>
Date: Fri, 28 Nov 2008 15:29:08 -0000
Message-ID: <3AAB09AEC806CB469174F8CC39E5781801BF9B0D@lonex01.Cellectivity.local>
To: <public-bpwg-ct@w3.org>
With respect to the comments expressed by Eduardo below, I just want to
bring to your attention that given the extensibility of the
Cache-Control directive as formulated on the HTTP specification, it
would be completely appropriate to simply add a new Cache-Control
directive as oppose to a new HTTP field as defined on solution (a).
Cache-Control: no-transcode
As per the HTTP spec, gateways should ignore any directive that they do
not recognize and hence the new additions should not affect the
processing of other components on the communication chain.
Section 14.9 defines the syntax as:
    Cache-Control   = "Cache-Control" ":" 1#cache-directive
    cache-directive = cache-request-directive
         | cache-response-directive
    cache-request-directive = ... | cache-extension
    cache-response-directive = ... | cache-extension
    cache-extension = token [ "=" ( token | quoted-string ) ]
Notice, that such addition does not mean that the "no-transform"
directive would not be taken into account. To the contrary, a
transcoding gateway must obey such directive as it is a general
directive of HTTP that applies to all components. But the new directive
would allow for finer control, by signalling only the components
involved in the transcoding process. As per the concerns about adoption
of the new directive, application code could continue using the more
aggressive "no-transform" or move to use the new directive based on the
value of the "Via" header indicating whether the transcoder is CTG
compliant or not.
This provides an easy migration path for applications.
Jose Alberto Fernandez
From: Eduardo Casais <casays@yahoo.com
.sp1.yahoo.com%253E> > 
Date: Mon, 24 Nov 2008 04:23:17 -0800 (PST)
To: public-bpwg-ct@w3.org
Message-ID: <18331.78987.qm@web45007.mail.sp1.yahoo.com> 
An issue that has been discussed several times concerns WML content. In
1. WML content may have to be encoded by WAP gateways into WBXML, so
that it
can be rendered on mobile phones, as specified by the standards.
2. The no-transform directive in the HTTP header shuts off every
This includes not only those performed by content transformation
proxies, but
also those performed by WAP gateways. Hence, it is not possible at the
time to protect WAP content against unwanted transformations by proxies
authorize the desired re-encoding to WBXML by gateways.
3. A suggested solution was to insert the directive as an http-equiv in
the WML
content. Andrea Trasatti from dotMobi informs us that this leads to the
dilemma. WAP gateways do inspect http-equiv tags inside WML content and
their behaviour accordingly, following the standards (see appendix).
This is a confirmation that a full-fledged protocol would be required
entities in a network to signal to other entities which transformations
authorize and which they forbid. The current mechanisms are crude
because they
are binary (either everything is allowed or nothing is allowed at all).
Till such a protocol is specified, we must find a way to deal with the
with the case at hand, i.e. WML. Leaving the matter unsettled is not an
WML is a fact of the mobile Web, and quite relevant in low-end phones, 
third-world countries, specific markets (Sprint Nextel comes to mind),
as lowest-common denominator. 
I see the following possibilities.
a)      HTTP field.
We introduce a special field (for the sake of the example, let us call
X-CTG-authorize) that is sent in responses in the HTTP header, and that
be embedded in the content as an http-equiv element as well. The value
of the
field indicates whether a proxy is authorized to transform content or
not, and
applies if a no-transform directive is not present.
i. The directive applies only to CT-proxies.
ii. This can serve as the basis for a true transformation signalling
iii. At such a stage, it would only be a fragmentary protocol, which
will have
to undergo a thorough revision (or else we must invest all the effort
right now
to get it complete).
iv. Both applications and CT-proxies must be upgraded to deal with a new
HTTP header field.
b)      Meta element
Instead of an HTTP field, we define a meta element that is included in
content, and whose value is interpreted by CT-proxies in a way similar
the one described in (a). The meta element does not appear as an
and is thus not an HTTP protocol entity; it is a convention between WML
applications and CT-proxies.
i. No need to register and introduce new HTTP fields.
ii. The meta element is interpreted only by CT-proxies; by relying upon
forua attribute, it is possible to strip it off before passing content
to WAP
gateways and mobile phones, thus entirely avoiding possible confusion 
iii. This kind of signalling occurs as a convention inside the content.
It is
not elegant, and some people may qualify it as a hack.
iv. Both applications and CT-proxies must be upgraded to deal with the
meta tag.
c)      Mandatory heuristics
Excise the part of heuristics on MIME types in the HTTP header and on
in the content that apply to WML; make them into a mandatory rule with
following stipulation: if a response contains WML content (as determined
by the
MIME type or the DOCTYPE), the only transformation allowed are those
by the WAP standard (i.e. encoding to WBXML).
i. Applications need not be modified at all. Only CT-proxies must take
rule into account.
ii. It is consistent with the current guidelines, only stronger.
iii. It only applies to WML; the other schemes in (a) and (b) could
be incorporated in other content formats. Insofar as we seek a special
only for WML, this is the intended effect.
iv. This shuts off every transformation (except WBXML encoding) on WML
Insofar as transcoders target (X)HTML content for transformations, and
not WML,
this ought not to be a serious constraint.
v. It is not general. There might be future content that will face
hurdles at WML (i.e. some forms of transformations are necessary, but
may have to be disallowed), and these heuristics are customized for WML.
d)      transformers.txt
One installs a transformers.txt file in the root of a server. The syntax
operation of the file is similar to robots.txt: it indicates which
and sub-directories can be or not transformed by CT-proxies. CT-proxies
the file and adjust their behaviour accordingly.
i. Neither applications nor server configurations must be modified. A
is installed in a well-known location. CT-proxies retrieve the file,
its contents and deal with it like they would deal with robots.txt data.
ii. It can apply to all sort of contents, and allows customization of
authorizations (certain paths can be, other paths cannot be
iii. The proposal has not been formalized yet. 
e)      POWDER/metatxt
A resource file describing applications and their properties, and
with the application server, is retrieved by CT-proxies which adjust
behaviour accordingly.
i. Could apply to all sorts of contents, and describe a number of
properties in detail.
ii. Neither applications nor server configurations must be modified. A
is installed in a well-known location or as a service. CT-proxies must
the file or the service description, parse its contents and deal with
iii. The proposals have not been formalized in a usable way yet;
between metatxt and POWDER are only at the initial stage.
iv. There is a semantic difference between describing properties ("This 
application is...") and authorization to perform operations ("A proxy is
allowed to perform ... on this application"); it is not clear how to
bridge it.
v. At least POWDER may require a new infrastructure (with certifiers of 
descriptors, service discovery, etc).
vi. Metatxt seems only to handle the top-level entry point, and may
force an
entire site to follow the same policy without regard for the differences

between various sections of the same site.
If we look at some general properties, we have:
1.      (e) is very general, not focused on transformations per se.
2.      (a), (b), (d) can serve to specify multiple forms of
3.      (c) is only allowing/disallowing transformations other than
        encoding on WAP1 content.
1.      (d), (e) apply to any content, and might handle different parts
of an
        application differently.
2.      (a), (b) apply to any markup content.
3.      (c) applies only to WML.
1.      (c) does not require any new mechanism at all; everything is
        within existing standards.
2.      (b) uses the slack allowed by an existing mechanism, but does
        require any new mechanism or the modification of a standard.
3.      (a), (d), (e) require new mechanisms, and corresponding
extensions of
        existing standards, or the introduction of new ones.
1.      (c) does not require any change in the existing application or
        infrastructure; it is ready to deploy.
2.      (d) does not require changes in the applications or servers, but
        requires an additional server file.
3.      (a), (b), (e) require changes in the applications, servers and
        additional infrastructure.
1.      (c) does not require any more specification, the scheme is
2.      (b) requires a very limited amount of specification.
3.      (a), (d), (e) requires an undetermined, but probably substantial

        specification effort.
I have tested myself adding the no-transform to wml pages and I would
not recommend it, in fact gateways that respect the standard will not
turn wml in wmlc and wap1 devices will not displ page.
I think I had also posted something about this on mobiForge.
- Andrea

Received on Friday, 28 November 2008 15:28:08 UTC

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