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

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).
E.g.:
 
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
<mailto:casays@yahoo.com?Subject=Re%3A%20%5BCTG%5D%20Draft%202008-11-07%
20%2F%20http-equiv%20%2F%20WML&In-Reply-To=%253C18331.78987.qm%40web4500
7.mail.sp1.yahoo.com%253E&References=%253C18331.78987.qm%40web45007.mail
.sp1.yahoo.com%253E> > 
Date: Mon, 24 Nov 2008 04:23:17 -0800 (PST)
To: public-bpwg-ct@w3.org
<mailto:public-bpwg-ct@w3.org?Subject=Re%3A%20%5BCTG%5D%20Draft%202008-1
1-07%20%2F%20http-equiv%20%2F%20WML&In-Reply-To=%253C18331.78987.qm%40we
b45007.mail.sp1.yahoo.com%253E&References=%253C18331.78987.qm%40web45007
.mail.sp1.yahoo.com%253E>  
Message-ID: <18331.78987.qm@web45007.mail.sp1.yahoo.com> 
 
An issue that has been discussed several times concerns WML content. In
short:
 
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
transformation.
This includes not only those performed by content transformation
proxies, but
also those performed by WAP gateways. Hence, it is not possible at the
same
time to protect WAP content against unwanted transformations by proxies
and
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
same 
dilemma. WAP gateways do inspect http-equiv tags inside WML content and
adjust
their behaviour accordingly, following the standards (see appendix).
 
This is a confirmation that a full-fledged protocol would be required
for
entities in a network to signal to other entities which transformations
they
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
matter
with the case at hand, i.e. WML. Leaving the matter unsettled is not an
option.
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),
and
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
it
X-CTG-authorize) that is sent in responses in the HTTP header, and that
can
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.
 
Advantages:
i. The directive applies only to CT-proxies.
ii. This can serve as the basis for a true transformation signalling
protocol.
 
Shortcomings:
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
WML
content, and whose value is interpreted by CT-proxies in a way similar
to 
the one described in (a). The meta element does not appear as an
http-equiv,
and is thus not an HTTP protocol entity; it is a convention between WML
applications and CT-proxies.
 
Advantages:
i. No need to register and introduce new HTTP fields.
ii. The meta element is interpreted only by CT-proxies; by relying upon
the 
forua attribute, it is possible to strip it off before passing content
to WAP
gateways and mobile phones, thus entirely avoiding possible confusion 
downstream.
 
Shortcomings:
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
DOCTYPES
in the content that apply to WML; make them into a mandatory rule with
the 
following stipulation: if a response contains WML content (as determined
by the
MIME type or the DOCTYPE), the only transformation allowed are those
specified
by the WAP standard (i.e. encoding to WBXML).
 
Advantages:
i. Applications need not be modified at all. Only CT-proxies must take
the
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
conceivably
be incorporated in other content formats. Insofar as we seek a special
solution
only for WML, this is the intended effect.
 
Shortcomings:
iv. This shuts off every transformation (except WBXML encoding) on WML
content.
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
similar 
hurdles at WML (i.e. some forms of transformations are necessary, but
others
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
and
operation of the file is similar to robots.txt: it indicates which
directories
and sub-directories can be or not transformed by CT-proxies. CT-proxies
retrieve
the file and adjust their behaviour accordingly.
 
Advantages:
i. Neither applications nor server configurations must be modified. A
file
is installed in a well-known location. CT-proxies retrieve the file,
parse 
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
the
authorizations (certain paths can be, other paths cannot be
transformed).
 
Shortcomings:
iii. The proposal has not been formalized yet. 
 
 
e)      POWDER/metatxt
 
A resource file describing applications and their properties, and
associated
with the application server, is retrieved by CT-proxies which adjust
their
behaviour accordingly.
 
Advantages:
i. Could apply to all sorts of contents, and describe a number of
application
properties in detail.
ii. Neither applications nor server configurations must be modified. A
file
is installed in a well-known location or as a service. CT-proxies must
retrieve
the file or the service description, parse its contents and deal with
it.
 
Shortcomings:
iii. The proposals have not been formalized in a usable way yet;
harmonization
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:
 
Focus
1.      (e) is very general, not focused on transformations per se.
2.      (a), (b), (d) can serve to specify multiple forms of
transformations.
3.      (c) is only allowing/disallowing transformations other than
WBXML
        encoding on WAP1 content.
 
Generality
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.
 
Mechanism
1.      (c) does not require any new mechanism at all; everything is
handled
        within existing standards.
2.      (b) uses the slack allowed by an existing mechanism, but does
not 
        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.
 
Infrastructure
1.      (c) does not require any change in the existing application or
server
        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
possibly
        additional infrastructure.
 
Specification
1.      (c) does not require any more specification, the scheme is
basically
        ready.
2.      (b) requires a very limited amount of specification.
3.      (a), (d), (e) requires an undetermined, but probably substantial

        specification effort.
 
 
 
E.Casais
--------
 
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