RE: [minutes] CT Call 6 january 2009

> True, if the user has requested a restructured desktop experience, 
> HTTP requests will be made with altered headers and the user will 
> view transformed versions of desktop sites (except for sites that 
> would prefer that the user see the mobile version).
>
> However, if the user prefers to have a mobile experience, then the 
> user will see the mobile version of sites that have both a mobile 
> and desktop version.  In that case, the user may still want some 
> "light transformation" applied to mobile sites--assuming that content 
> provider has not disallowed transformation with a "no-transform".  
> This is the user choice I am proposing.

Let me try to clear up my reasoning.

1. The user may have a choice of going through a CT-proxy, so
	1.1 the user chooses to go through the CT-proxy, or
	1.2 the user decides to avoid the CT-proxy

2. Or the user may not have a choice of going or not through a CT-proxy
	2.1 because there is no CT-proxy at all to send traffic through
	2.2 or because all requests go through the CT-proxy anyway, and then
		2.2.1 the user chooses to enable CT functions
		2.2.2 or the user chooses to disable CT functions.

Let us consider each case in turn, starting with the easiest one.

2.1 Since there is no CT-proxy, there can be no transformations whatsoever,
so the point of allowing them or not is moot. The user will get whatever
content corresponds to the followed links, including those unsuitable for
a mobile.

1.2 If the user has a choice between an unadulterated browsing experience
and one mediated by an opt-in out-of-band CT-proxy, and selects the former 
one, then we are back on situation 2.1: there are no transformations 
whatsoever, and whatever content there is will be returned as is.

2.2 If all requests pass through the CT-proxy (i.e. in-band proxy), obviously 
every request for a URL is intercepted. Hence, it is entirely superfluous to
perform any modification on mobile-friendly content, especially rewriting 
links: since _all_ requests and _all_ responses go through the CT-proxy, it 
is useless to change URL to force diversion of requests to the proxy -- the 
CT-proxy gets all of them no matter what.

2.2.2 At this stage, if the user selects an unadulterated browsing
experience, then we are back to what happens in 2.1 and 1.2: the CT-proxy,
even when intercepting all requests and responses, must let them pass
through transparently.

2.2.1 On the other hand, if the user chooses to enable CT functions, 
presumably desktop-specific content is converted to mobile-compatible one
as it is returned from WWW sites and passes through the CT-proxy, but other 
transformations are possible. There is nothing in the CTG that prohibits 
CT-proxies to offer a variety of transformation options that a user can pick 
and choose -- "light", "medium", "heavy", whatever. The important point is
that the user has a choice, and has explicitly selected transformations.

1.1 Finally, if the user decides to browse through an out-of-band CT-proxy,
then it means that further requests and responses must be diverted through
it -- which implies rewriting URL in all pages. Additionally, the CT-proxy
may present the user with a catalogue of transformation possibilities (i.e.
"light", etc), just as in 2.2.1.

What is important to note is:

a) In-band CT-proxies do not need URL rewriting at all to force diversion
of requests through them; only out-of-band proxies require this.

b) Since there are many reasonable sets of transformation possible, a CT-proxy
may provide a series of options as regards the way content is processed, e.g.
"select [] access non-mobile sites (default) [] adjust to my profile 
[] optimize for speed [] translate to English [] ..." instead of the generic 
"type in a destination URL" common in current proxy interfaces.

c) In the end, whether content gets transformed or not depends on a decision
of the end-user.


> I was thinking more in terms of transformations to fix things that 
> plainly don't work on a particular device, not trying to improve the 
> usability of a site in general.  However, there may still be some 
> general things that could be done, e.g., detection of phone numbers.

Then we are talking about compensating for discrepancies in the
way devices handle content, not usability. 

Mobile-optimized generally rely upon click-to-call URI or WTA 
functions for phone numbers, or at least indicate them as such in
their pages, so why do you want to detect them and what exactly do 
you want to do with them?


> Obviously, a CT proxy wouldn't want to make a transformation to remedy 
> a problem that has already been compensated for by the CP.  CT proxies 
> look for conditions in the markup that would cause a problem on a particular 
> device or group of devices.  If the problematic condition does not exist 
> or it is ambiguous whether the CP has already corrected for the condition, 
> then probably no transformation should be made.

Then "_certainly_ no transformation should be made" in this respect. The
big issue is whether a CT-proxy can detect whether a browser problem
has already been dealt with at the application level. If it is a matter
of converting "/>" to " />" it can be done via careful parsing. If it
is something more semantic, like explicit insertion of a title instead
of using the markup <title>, then this becomes unreliable.


> There are some transformations that almost always make sense, however. 
> For example, a page designed for high end phones like the N95 might 
> require pagination to work on a less capable device.

This is an accessibility issue, not a usability, device discrepancy
compensation, or function enhancement one. This shows that your idea 
of explicitly specifying in the CTG the conditions under which mobile 
content may be adapted is fraught with difficulties: we would have to
define accurately these conditions, and list them exhaustively --
you gave examples that do not even fit in the categories you proposed...
I prefer the proposal made two weeks ago -- i.e. not listing these 
situations and transformations.

Apart from that, the idea that it "almost always makes sense" to try
making sites optimized for specific devices available to other devices
is highly contestable. A mobile portal providing downloadable applications
intended for Palm or Series60 terminals is pretty useless for low-end
phones. Needless to say, detecting whether a site is optimized for
specific categories of terminals or not is difficult. And the fact is 
that very many mobile Web applications, and most of the commercially
relevant ones, are inherently tailored for specific devices: whether it 
is ringing tones, games, maps, wallpapers, Java utilities, etc, they are 
all customized for specific devices or device classes -- adapting such 
sites to other devices or device classes is impractical and pointless.


> As mentioned above, the user may not have requested a restructured 
> desktop experience, so the user will get mobile sites.  The user 
> may still want some transformation--like toolbars.  The fact that 
> this adds functionality and doesn't correct device discrepancies 
> is probably of no concern to the user.

I cannot really comment on the toolbars example -- toolbars are
generally impossible on low-end phones and some middle-of-the-road
browsers. I surmise you are hinting at functionality similar to
bookmarklets -- but these are installed and attached to browsers, 
not to Web pages themselves. Without more details, it is really 
difficult to assess this use case. 


> This is true if all traffic between the device and the CP goes through 
> the CT proxy.  However, in deployments where the CT proxy depends on 
> links to be rewritten to receive traffic, this won't work.  If the 
> mobile page contains a link to a desktop site that isn't rewritten, 
> the CT proxy is taken out of the equation and is not able to transform 
> the response.

See above. I do not think our viewpoints are at odds, really.


E.Casais

Received on Thursday, 15 January 2009 11:15:35 UTC