RE: Scope of CT Guidelines

Some obervations on Seans comments:

> -----Original Message-----
> From: public-bpwg-ct-request@w3.org
[mailto:public-bpwg-ct-request@w3.org]
> On Behalf Of Sean Patterson
> Sent: 31 October 2007 04:34
> To: public-bpwg-ct@w3.org
> Subject: RE: Scope of CT Guidelines
> 
> 
> My comments are below.
> 
> Sean Patterson
> 
> > -----Original Message-----
> > From: public-bpwg-ct-request@w3.org [mailto:public-bpwg-ct-
> request@w3.org]
> > On Behalf Of Jo Rabin
> > Sent: Tuesday, October 23, 2007 12:12 PM
> > To: public-bpwg-ct@w3.org
> > Subject: Scope of CT Guidelines
> >
> >
> > I thought it worth making a note and stimulating further discussion
> > following today's productive CT TF call.
> >
> > I'm worried that if we step into the space of how to do 3 way
content
> > negotiation we will be opening the lid on Pandora's box.
> 
> For version 1.0 of the guidelines, I think we should mainly focus on
the
> communication between the CT proxy and the origin server.  However,
there
> are probably also some things we want to say about the communication
> between the client and the CT proxy.
> 
>From the sake of simplicity I'd like it to be that way. But I don't
think that will be sufficient.

> >
> > The starting point, I think, is that there are three types of
component,
> > server, proxy and browser. Each of those can be capable of
> > transformation. Add to this that each of them will independently
also be
> > aware or unaware of whatever our guidelines state about how to
> > cooperate. So in theory at least there are 64 different combinations
of
> > aware/capable component types in the delivery chain. That's a bit
too
> > complicated for my taste.
> >
> > So I wonder if it's worth considering the question of repurposing
the
> > presentation separately from markup and formatting fixups?
> >
> > So far as presentation is concerned I think there's a relatively
small
> > set of cases, though each of them undoubtedly has its own
complexity.
> >
> > Case 1.
> > a) the Server has only a desktop oriented presentation only
> > b) the browser has mobile presentation only
> >
> > A proxy may have a useful role in re-presenting the content.
> >
> > Note though, that in this case, the server's desktop presentation
may
> > actually be a universal presentation (call my web pages boring but
they
> > are designed to render across all delivery contexts) so in that case
the
> > proxy should not interfere either.
> 
> Agreed.  A CT proxy normally should transform desktop content by
default
> in this case.  If the server says something like "Cache-control: no-
> transform" then the CT proxy should leave the content alone.

I think I'm saying that the CT proxy should not assume that by default
it should do anything. When it does it should be "reluctantly".

> 
> An additional note:  In reality there is a spectrum of device and
browser
> capabilities and dividing clients into mobile and desktop capable is
> somewhat simplistic.  There are many levels of mobile browser
capabilities
> (e.g., WAP-only, subset of HTML with a subset of CSS, etc.).  There
are
> different levels of desktop-capable as well.

I agree and it would be best to avoid that use of language in the
recommendation. Also I think, as I mentioned before, we need carefully
to distinguish transforming the presentation from transforming the
encoding.

> 
> >
> > Case 2.
> > a) The Server has both a mobile and a desktop experience
> > b) Client has mobile experience only
> >
> > Server presents mobile experience. Proxy stays out of the way.
> 
> What if the user prefers the desktop content transformed for mobile?
> There needs to be a way for the client to specify that it wants the
> transformed desktop content.

Er, yes, modulo some hard thinking about under what circumstances the
client's preferences over-rule the content provider's rules, or license
for use of their content.

> 
> Also, even if the origin server determines that it should present a
mobile
> experience, the mobile experience(s) that an origin server can present
may
> not be suitable for all mobile clients.  There may be a need to do
some
> transformation even on mobile content if that mobile content does not
work
> properly on a given client.
> 
This comes back to the point about presentation vs encoding.

> >
> > Case 3.
> > a) The Server has a desktop oriented presentation only
> > b) Client can simulate desktop
> >
> > Client goes ahead and simulates desktop
> >
> > (There is an argument that says that this could land the user in a
delay
> > and cost nightmare. So is that an argument against the concept of
> > simulating desktop on a mobile, or is it an argument for saying that
> > there is a role for transforming proxy to reduce that delay and cost
> > nightmare?)
> >
> > Also same case as in 1, where the server has a single presentation,
but
> > that presentation is suitable across the board.
> 
> There can be a role for the CT proxy in this case if the user wants
> transformed content because the original desktop content takes too
long to
> load, is too large for the available memory of the device, etc.  There
may
> also be some desktop content that doesn't work properly on a
particular
> client even if it can handle most desktop content.

Well again the question is whose preferences take priority and indeed
who is to say that the transforming proxy "knows better" than the
content provider?

> 
> >
> > Case 4.
> > a) The server has a choice of presentations
> > b) The client has a choice of presentations
> >
> > The user should be able to get either i) the mobile presentation ii)
the
> > simulated desktop presentation. That choice may be triggered by
> > selection locally to the client or at the server.
> 
> As in cases 2 and 3, the user may prefer to get the desktop content
> transformed for mobile.  If that is the case, the user should be able
to
> get what he/she wants.

Well, forgive me for saying I think it unlikely that a choice of
deliberately crafted user presentations by the content provider, done
with this exact scenario in mind, is actually going to be "bettered" by
a mechanical process, but yes, I agree this is a possibility that we
should consider.
 
I think also that one should bear in mind, when considering the
desirability or viability of this scenario, that transforming proxies
apply to a single access network. From the content provider's
perspective worrying about providing support for all the possible
transformed variations of their content across all the different
operators and their differing takes on which devices should be
transformed which way, makes a truly unsupportable proposition. 

> 
> >
> > Case 5.
> >
> > Although this looks like a Web request, in fact it isn't. It's some
ad
> > hoc protocol xmlhttprequest-like thingy.
> >
> > (Proxy leaves well alone)
> 
> Request and/or response should be marked to tell the CT proxy to avoid
any
> transformations.

Well, but the question is "how" and they aren't today and those
applications won't change overnight since they are typically downloaded
to the device.

> 
> >
> > I'm assuming that this is a more of less complete list of scenarios
> > where the presentation is adjusted at most once.
> 
> Case 6.
> a) Server a choice of presentations
> b) Client can do desktop
> 
> This is similar to case 3.  Server would send desktop content and
client
> may want the CT server to do some transformation of the content so
that it
> loads more quickly, fits into available memory, etc.
> 
> >
> > Now I think that we can consider on top of this whether the proxy
has a
> > role adjusting not the presentation, but details of the formatting -
> > e.g. to tweak the content type header, or to tweak the DOCTYPE to
avoid
> > problems. Possibly to re-render images from one format to another.
> 
> We should certainly consider these issues.
> 
> >
> > To my mind, that is almost certainly enough to do deal with in
volume 1
> > of the guidelines. I think we should leave the door open to later
> > elaborations that discuss 3 way content negotiation, servers
> > deliberately delegating formatting or presentation tasks to proxies
and
> > so on. However all that falls firmly in a volume 2.
> 
> I agree with this.
> 
> >
> > I'm hoping that by restricting the initial scope we stand a chance
of
> > meeting the proposed timescales for the deliverable, and of
addressing
> > in a timely way the key point of the Task Force's existence - which
is
> > to provide a way for Transforming Proxies to get out of the way of
> > mobile ready content.
> >
> > Hope this makes sense and looking forward to comments.
> >
> > Jo
>

Received on Wednesday, 31 October 2007 22:07:18 UTC