RE: [AP880] Review LC-2053 and clarify to group

To be consistent with the work of the DDWG, I would rephrase the
conclusions of the two cases to say: "the transcoder must inspect
evidence from the HTTP request (mainly the user-agent id of the
requesting client) so as to take the appropriate decision not to
transform."

The point is that the HTTP request header contains a lot of evidence
about the delivery context that generally proves useful to adaptation
technology. Admittedly the User-Agent field is the most useful
determinant amongst this evidence. In the DDWG it was agreed to use the
general term "Evidence" but to cite a specific example where Evidence is
constructed from data in the HTTP request header. This terminology is
also reflected in the API [1].

---Rotan.

[1] http://www.w3.org/TR/DDR-Simple-API/#sec-Evidence


-----Original Message-----
From: public-bpwg-ct-request@w3.org
[mailto:public-bpwg-ct-request@w3.org] On Behalf Of Eduardo Casais
Sent: 13 November 2008 08:27
To: public-bpwg-ct@w3.org
Subject: [AP880] Review LC-2053 and clarify to group


The comment LC-2053 is found here:
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-200
80801/2053


a)    Context

LC-2053 assumes the main scenario of the CTG: transcoders adapting
desktop-optimized content into a mobile-compatible format.

It considers the following situations:

1. Servers that produce desktop-optimized content, with mobile clients
that are able to process desktop-optimized content directly.

2. Servers that produce mobile-optimized content and clients that only
accept mobile-optimized content, but the format of the content itself
(i.e. internal declarations and HTTP MIME type declarations) cannot
serve to determine whether it is mobile-compatible, and can even be
mistaken for a desktop-optimized one.

The intent of LC-2053 is to enforce a basic consistency requirement that
content not be transcoded when the terminal can handle the original
content directly.

The difficulty alluded to in LC-2053 is that the mechanisms and
heuristics presented in the CTG draft do not deal adequately with the
aforementioned cases.


b)    Case 1 rationale

Contrarily to conventional mobile phones, some classes of wireless
devices (PDA, tablets, communicators) have a built-in browser (derived
from desktop software) which is able to process desktop-optimized Web
content directly.

Since the device is wireless, its requests and responses to them may be
intercepted by a transcoder (usually in the operator's infrastructure).

When the content accessed is desktop-optimized, it will have
corresponding MIME type (e.g. text/html), declarations, DOCTYPE (e.g.
for HTML 4.0, 3.2), etc. The server may omit a no-transform directive if
it wants to allow automatic conversion to mobile-compatible formats for
other mobile phones.

Neither the URI, nor the MIME type, nor the DOCTYPE, nor the
content-cache field indicate that a transformation is unsuitable.

Conclusion: the transcoder must inspect the user-agent id of the
requesting client so as to take the appropriate decision not to
transform. 


c)    Case 2 rationale

There is a whole class of mobile devices that only accept
mobile-optimized content, but the content itself cannot be identified as
such. This affects mainly i-Mode devices, but similar conditions prevail
in other environments (such as Softbank).

i-Mode content is usually presented in a variant of HTML that is
advertised as text/html, but does not include a DOCTYPE (as per i-Mode
specifications).

Because of the long standing of i-Mode, corresponding Web sites do not
necessarily follow a pattern imode.* or */imode.

Because i-Mode service provisioning is mediated through operator
gateways that take care of some automatic adaptations (notably mapping
between UTF-8 and Shift_JIS in Japan), origin servers do not necessarily
include a no-transform directive.

Hence, neither the URI, nor the MIME type, nor the (absent) DOCTYPE, nor
the content-cache field indicate that a transformation is unsuitable
(which would convert i-Mode mobile-optimized content to a lower-grade
mobile-compatible format without the extra features of i-Mode).

Conclusion: the transcoder must inspect the user-agent id of the
requesting client so as to take the appropriate decision not to
transform. 


The conclusions are generalized to ensuring the avoidance of
transformations when devices accepting a certain class of content and
accessing the same class of content.

E.Casais

Received on Thursday, 13 November 2008 08:44:17 UTC