FW: ACTION-540 CT taskforce guidelines section 2.1

I've been meaning to comment on this for ages. Thanks Magnus, I think
that spelling it out in words and only then looking at the HTTP
mechanisms available is the right approach to looking at the problem
holistically.

 

Two elaborations come to mind:

 

1. Should we have a "points of principle" bit where we say things like
we prefer HTTP based mechanisms to content based mechanisms, because
those mechanisms are open whereas scraping HTML is not. What if the
content is SVG, for example? (Nonetheless I think it's fine to use clues
in existing markup as additional "evidence".)

 

2. I wonder if we should draw up a truth table for components of the
delivery context and enumerate the cases for "transformation aware" so
we can refer to behaviours in each of the cases - i.e.

                        UA       Proxy   Server

Case 0 :            N         N         N         Nobody transforms,
static pages, everyone's happy

Case 1:             N         N         Y         Server Varies, no-one
transforms, everyone's happy

...

Case 7:             Y         Y         Y         Your worst nightmares
realized ...

 

Jo

 

________________________________

From: public-bpwg-ct-request@w3.org
[mailto:public-bpwg-ct-request@w3.org] On Behalf Of Magnus Lonnroth
Sent: 18 September 2007 15:14
To: public-bpwg-ct@w3.org
Subject: CT taskforce guidelines section 2.1

 

Here's some initial first draft material for section 2.1. I'll start
writing the actual guidelines soon, but I'd appreciate feedback on the
requirements part asap.





Communication Between Components


The purpose of this section is to explore the need for actors (clients,
proxy servers, gateways, origin servers, etc) to communicate with each
other, and also suggest guidelines for doing so. The relevant scenario
involving a content transformation proxy is as follows:

client browser <---HTTP---> content transformation proxy <---HTTP--->
origin server

There may be other scenarios as well but they will initially be ignored
for the sake of simplicity. The needs of these three actors are as
follows:

1.      The client browser needs to be able to tell the content
transformation proxy: 

1.      that all content transformation should be avoided.

2.      what type of mobile device and what user agent is being used.

3.      what media-type is desired.

2.      The content transformation proxy needs to be able to tell the
origin server:

1.      that some degree of content transformation can be performed.

2.      that content is being requested on behalf of something else.

3.      about the delivery context (for example mobile device type and
user agent).

3.      The origin server needs to be able to tell the content
transformation proxy:

1.      that content is already optimized and no additional
transformation is required.

2.      that it's OK to perform additional content transformation.

4.      The content transformation proxy needs to be able to tell the
client browser:

1.      that content has been transformed.

2.      that content is untouched.

3.      where to find the original content if it has been transformed.

It is expected that many of these requirements can be fully satisfied
with existing HTTP headers and directives. However, some will most
likely require new mechanisms. Special consideration needs to go into
defining the "default" behavior when an actor that is unaware of
potential new mechanisms participates in the request processing. For
example, if there is no standard way for a client browser to specify
that all content transformation should be avoided in a request, then we
must define a default behavior for a well-behaved content transformation
proxy that receives a request from such a client.






-- 
Magnus Lonnroth
CTO, EVP Engineering
Drutt Corporation