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

I think the fact that *some* WAP Gateways treat "no-transform" that way 
is indeed a problem, but the point is that WAP gateways are not proxies 
according to earlier advice and discussion in this group - and so this 
behavior needs to be regarded as mis-operation, in that light.

That said, my preference would be to say that CT Proxies should treat 
WML content as though it had a no-transform specified in it, since there 
is no way within existing mechanisms reliably for a server to tell CT 
Proxies anything else.

Jo

On 24/11/2008 12:23, Eduardo Casais wrote:
> 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:35:25 UTC