[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-20080801/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:29:30 UTC