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

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


On 11/4/08, casays <casays@...> wrote:
> --- In wmlprogramming@yahoogroups.com, Tom Hume <Tom.Hume@...> wrote:
>>
>> Does WML not support the META tag, and therefore http-equiv
>> as well?
>>
>> > Of course this is only of value for (X)HTLM, not for WML
>> > or anything else.
>
> WML does support the meta tag with the possibility to have an http-
> equiv attribute. It even has an additional attribute (forua) that
> indicates whether the meta-tag is intended for the recipient user
> agent or not, and thus whether it should be stripped before delivery
> to the terminal. The result is as follows:
>
> ...
> <wml>
> <head>
> <meta http-equiv="Cache-control"
> content="no-transform" forua="false"/>
> </head>
> ...
> </wml>
>
> Do WAP gateways interpret the meta tags inside WML? It should not be
> the case, but it they do, we are back to square one. Some
> verifications to do there.
>
>> If you can't work out how to send HTTP headers when
>> serving HTTP requests, then you deserve to have your
>> content transcoded.
>>
>> If you have technical limitations, fix the technical
>> limitations.
>
> I suggest you re-read carefully what has been said regarding the
> directive no-transform in the Cache-control HTTP header field. There
> are circumstances that make it technically impossible to customize
> that field, and there are other circumstances where one must _not_
> include that directive in order for content delivery to work at all.
> The idea with the http-equiv field is to avoid both stumbling blocks.
>
> E.Casais

Received on Monday, 24 November 2008 12:24:46 UTC