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

Hi,

We had considered extensions to the Cache-Control mechanism in the past. 
We wanted to use it for much finer control over the Content 
Transformation proxies behavior, making it possible to state things such 
as: "you may transcode but do not rewrite links", "do not transcode 
unless you really think the content will crash the phone" and so on.

We decided against it in the end for, I think, 2 main reasons:

- Although the Cache-Control mechanism is indeed open for extensions, 
extension values would have to be registered within an IETF draft, which 
we may or may not be allowed to do from our charter.

- We do not think that HTTP headers are meant to convey such semantics, 
which would better be expressed using some external mechanism to express 
metadata around transcoding associated with the resource being served. 
Such a mechanism does not exist yet. It may be POWDER. It may be RDFa 
embedded within the markup. It may be MetaTXT. In any case, a vocabulary 
and a way to link to the metadata needs to be defined.

In the end, we thus agreed to restrict ourselves to a "no 
transformation" flag. This is what "Cache-Control: no-transform" does. 
We acknowledge that this does not work for WML content.

We had left WML content mostly out of scope, as the evolution of the 
mobile Web goes toward XHTML MP/Basic and other "full" web markups. We 
are currently re-considering putting WML content back in scope. Instead 
of defining "no-transcode", we may end up with mandating that Content 
Transformation Proxies simply leave WML content untouched.

I confess I am not aware of specific problems created by the deployment 
of Content Transformation Proxies on WML content. I thought most of the 
problems arised with HTML-like content. Do you have any example?

Thanks,
Francois.



Jose Alberto Fernandez wrote:
> /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%40web45007.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-11-07%20%2F%20http-equiv%20%2F%20WML&In-Reply-To=%253C18331.78987.qm%40web45007.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
> 
>  
>

Received on Friday, 28 November 2008 17:14:36 UTC