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

Jose Alberto Fernandez wrote:
> Hi Francois,
> 
> I have a general problem on this position of expecting to solve a
> problem based on something that in reality not exists (e.g. POWDER,
> etc.). Time and again I see this spec referring to such things as the
> way to go but no effort on moving new requirements in tandem with the
> specification.

I apologize if I gave the feeling that we were pretending to solve the 
generic case by referring to things that do not even exist. The reason 
we have this "Scope for future Work" section is to potentially trigger 
new efforts that we cannot do by ourselves within this group. These 
efforts may or may not be worked upon at all, and other ways to go may 
appear. I mentioned POWDER to illustrate the fact that we think 
introducing extensions to the Cache-Control directive is not a good idea 
to address the issue.


> 
> I have not personally faced this WML issues mostly because we are a
> white-listed site in the UK which is our main territory. You are correct
> that mobile is moving towards XHTML-MP and such, but for applications
> with a world-wide reach you have to take into account the fact that the
> adoption rate of new devices on different countries varies largely from
> one country to another. Even in the UK we see old devices still around
> and here the average upgrade time is 18 months. But this is just an
> average.

I do see content transformation as a way to make HTML content accessible 
to WML browsers. My question is whether transcoding from WML to WML is a 
real use case. Do others know about it?


> 
> I think that the issue with WML is just an expression of a more
> fundamental issue which has to do with the interaction of your
> recommendation with different technologies that may be involved on the
> pipeline. No-transform is a very wide and encompassing directive that
> can be interpreted by many components. The spec at this point assumes
> that the only components on the pipeline are transcoders (of course the
> document does not say so, but as there are no analysis of the
> interactions with other components, that is the result).

Do you have other examples of different technologies that would be 
affected by the directive?

The reason I am asking this it that the RFC HTTP, section 14.9.5, on the 
no-transform directive explicitly refers to "intermediate cache or 
proxy", terms defined in section 1.3 Terminology. In particular, a 
strict reading of the RFC entails that the directive does not apply to 
gateways. This is the reason why some people say that it is a bug when 
WAP gateways follow this directive. Now the distinction between "proxy" 
and "gateway" is not always that clear, so it is an important case we 
must take into account. Are you aware of other cases?

I see one annoying and important drawback of this directive, in that it 
indeed prevents content compression, which is of much importance in 
mobile networks. That does not break things in non WAP1.x networks, but 
that is still a problem (Again, it is probably done by "gateways" rather 
than "proxies" in practice).


> 
> As I have mentioned in several discussions, even for requests not
> originating from browsers the current transcoders do not act on a
> transparent way. Even as white-listed, we had to make changes to our
> application to make the gateway leave our traffic alone. The transcoders
> will change headers, re-encode the data stream and all kinds of things
> even though we are sending no-transforme; in particular Novarra.

The addition of the directive to the guidelines is fairly recent, and 
the guidelines are still a draft, so it is a bit early to talk about 
implementations. Sure enough, you might say it was defined in the RFC 
HTTP all that time.


> Anyway, back to the point, if you are to use no-transform as your
> mechanism, then you need to add a whole chapter discussing what the
> consequences are with respect to other components on the pipeline and
> how they should be overcome. Otherwise it is impossible for people to
> understand and comment on the spec with a full picture in mind.

OK. We will consider it.

Thanks,
Francois.


> 
> 
> Jose Alberto Fernandez
> 
>> -----Original Message-----
>> From: Francois Daoust [mailto:fd@w3.org]
>> Sent: 28 November 2008 17:14
>> To: Jose Alberto Fernandez
>> Cc: public-bpwg-ct@w3.org
>> Subject: 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=%25
> 3C
>> 18331.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=%25
> 3C
>> 18331.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 Monday, 1 December 2008 10:50:46 UTC