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

In the interest of being useful, here's a possible text:

A proxy should strive for the best possible user experience that the 
user agent supports.
<INSERT>
Markup generated by a proxy MUST be well-formed if the specification
of the markup requires it to be well-formed, even if a mal-formed
version of the content would produce an equally good or better
experience.
</INSERT>
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.



-----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 4.2.8.1 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?

thanks
Jo

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
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 11:47:17 UTC