W3C home > Mailing lists > Public > public-bpwg-ct@w3.org > November 2008

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

From: Rotan Hanrahan <rotan.hanrahan@mobileaware.com>
Date: Thu, 13 Nov 2008 11:40:13 -0000
Message-ID: <D5306DC72D165F488F56A9E43F2045D301CBE2F1@FTO.mobileaware.com>
To: "Jo Rabin" <jrabin@mtld.mobi>
Cc: <casays@yahoo.com>, <public-bpwg-ct@w3.org>

I suppose one point is that "the best possible user experience" might be
possible to achieve without delivering well-formed markup (thanks to
built-in browser tolerance) but despite this you should really aim to
produce well-formed markup. This might be important if, for example, the
end-user has some assistive technology attached to the device of which
you are not aware.

Saying that where a target markup type has a requirement to be
well-formed, the markup generated by the proxy MUST also be well-formed,
seems like good advice.

Staying silent on the matter of validation of generated markup would, to
me, be fair enough given the previous discussion.

Put simply: the base-line is "well-formed where applicable".


-----Original Message-----
From: Jo Rabin [mailto:jrabin@mtld.mobi] 
Sent: 13 November 2008 11:32
To: Rotan Hanrahan
Cc: casays@yahoo.com; public-bpwg-ct@w3.org
Subject: Re: [AP880] Review LC-2053 and clarify to group

I don't disagree with this argument, but am not sure what specific 
change to the text are entailed.

"Under Alteration of Response

A proxy should strive for the best possible user experience that the 
user agent supports. It should only alter the format, layout, dimensions

etc. to match the specific capabilities of the user agent. For example, 
when resizing images, they should only be reduced so that they are 
suitable for the specific user agent, and this should not be done on a 
generic basis."

In what respects should this text be altered, and is there anywhere else

in the document that requires clarification?


On 13/11/2008 08:43, Rotan Hanrahan wrote:
> 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
> general term "Evidence" but to cite a specific example where Evidence
> 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:
> 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
> 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
> intercepted by a transcoder (usually in the operator's
> 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
> it wants to allow automatic conversion to mobile-compatible formats
> 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
> such. This affects mainly i-Mode devices, but similar conditions
> 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
> include a no-transform directive.
> Hence, neither the URI, nor the MIME type, nor the (absent) DOCTYPE,
> 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 11:41:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:06:30 UTC