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

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 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 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).

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.

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.


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 Friday, 28 November 2008 18:01:52 UTC