Content Transformation 1k - and Change List

Please find Draft 1k at [1]

Extensive changes so I haven't done a formal diff but feel free to use 
the DOM-in-ator at [2]


to generate one.

Extensive notes of things done and not done and some notes of decisions 
yet to be taken follow.


1. from the minutes of the BP call of 5th June

- Remove references to normative and remove section on conformance.

- Adjust wording of Normative Language for Conformance Requirements to
suit above.

2. from the minutes of 15 April

Resolutions taken during the call:
- to replace the editorial note in 4.1.2 re alteration of request
bodies, write something along the lines of "the CT-proxy MUST ensure
that the origin server receives the form it expects"
- list "Always request the desktop presentation of the resource" as one
of the examples in 3.2.1
- add a bullet to the first list of bullets in 4.1.2 "any knowledge it
has of user's preferences"
- remove first bullet that says: "any administrative arrangements that
are in place with the user, or the server" (in 4.1.2 as well)

3 from the minutes of 22 April

ACTION-738 - Create text about transforming
     proxies generating valid documents and propose it in next draft [on
     Jo Rabin - due 2008-04-29].

RESOLUTION: to replace paragraph on "advanced browsers" and CT, add
     it as an example to "any knowledge it has of user agent
     capabilities" in 4.1.2 and add it as a bullet point in the list of
     heuristics in 4.4

ACTION-740 - Find a way of crafting FD's text
     above and weaving it skilfully into the flow of the text [on Jo
     Rabin - due 2008-04-29].

4. From the minutes of 29 April

RESOLUTION: in 4.4, add a bullet point to the list of heuristics
     that says "examination of the content reveals that the page contains
     client-side scripts that may mis-operate if the page gets adapted"

RESOLUTION: In 4.1.1, "As an example of this, a web page sending
     asynchronous HTTP requests (e.g. XHR calls) may include a
     no-transform directive if it doesn't want the message to be
RESOLUTION: format of the VIA header comments: either the URI
     "[17]", a URI derived from this one
     (that defines properties such as "active"), or a URI to a POWDER
     resource that describes the capabilities of the proxy
RESOLUTION: Rewrite 3.2.1 roughly based on what it was before:
     "They MAY also provide the ability for their users to make a
     persistent expression of preferences."
(not sure in what way this was meant to be different to a similar
resolution from 15 April)

RESOLUTION: at the end of 4.1.2, add "The proxy MUST NOT issue a
     POST/PUT request with altered headers when the response to the
     unaltered POST/PUT request contains an HTTP status code 200" (in
     other words, it may only send the altered request for a POST/PUT
     request when the unaltered one was refused with a clear 406)
RESOLUTION: at the end of 4.1.2, add a "The theoretical idempotency
     of GET requests is unfortunately not always respected in practice.
     Not to break existing content, the proxy SHOULD send only one

5. From the minutes of 6 May

RESOLUTION: Note: CT Proxies SHOULD avoid sending duplicate requests
     where possible and specifically SHOULD NOT send duplicate requests
     for comparison purposes only
(merged with previous resolution per)
ACTION-752 - Propose text for the final part
     of 4.1.2 taking into account resolutions and discussion on this and
     the previous call [on Jo Rabin - due 2008-05-13].

RESOLUTION: Mention content type as a contributory heuristic (no
     specific mentions) and list the DOCTYPEs mentioned by Sean in

RESOLUTION: Include X-Forwarded-For and use of meta http-equiv in
     next rev

6. From the minutes of 13 May

Resolutions taken during the call:
- don't go any further with the XHR topic [fd to write a "thank you"
email to public-webapi]
- Mention examination of URIs in the list of heuristics in 4.4
(transformation of the response) and mention SeanP's list (wap.*, m.*,
...) as examples
NOT DONE [- Mention examination of URIs also in 4.1.2 (transformation of
request) to complete the list after "the proxy SHOULD analyze whether it
intends to offer transformation services by referring to:".]

7. No meeting 20 May

8. From the minutes of 20 May

Resolutions taken during the call:
- One-time URIs are already addressed in the guidelines. Close the
- Keep things as resolved re. idempotency for the end of 4.1.2. Valid
use of "idempotent".
- for sessions: replace the editorial note with the above note. Do not
mention sessions. Do not go into more details.
[where "above note" is:
	Note: When possible, the consistency of user experience should be
maintained across a sequence of related requests.]

*** Editorial discretion: reworded the bullet


any knowledge it has of server preferences, derived either from a 
repository of such preferences, or from previous interaction with the 


any prior knowledge it has of server behavior, derived from previous 
interaction with the server - and in particular to preserve the 
consistency of user experience across a sequence of related requests;

9. From the minutes of 3 June

- keep it simple for the VIA header comment format: http://[ct
namespace] and no mention of properties + the possibility to replace the
URI with a link to a POWDER-like resource
- if an HTML response includes a <link rel="alternate" media="handheld"
type="[content-type]" href="[uri]" /> tag, the CT-proxy SHOULD request
and return the resource pointed to by [uri] instead of the current one.
- don't recommend the addition of a "Warning" HTTP header to the request
- leave the "2 CT-proxy on the line" tricky issue out of scope and
reference it the "Scope for Future Work" appendix
- Final name for the "X-Device" header is "X-Device"
- do not say anything on "Content-Location" and other generic caching

Jo is to provide an updated draft by next week.

and so he has ...

10. Additionally

Scope of further work - moved all POWDER references
Mention need for changes to HTTP.

A. Editorial Note: The BPWG requests feedback on the degree to which it 
is necessary to distinguish between Content Transformation proxies that 
interact with user agents using HTTP, and other types of arrangements 
where a (proprietary) client application interacts with an in-network 
component using other techniques.

this needs resolution

B. normative Need link to definition

Where is the discussion of types of document?

C. Editorial Note: The BPWG is studying how to clarify the scope of 
"persistent" and "semi-persistent".

Are we still?

D. Editorial Note: The BPWG is studying heuristics for determining when 
a response with a 200 Status should be treated as a response with a 406 

We need an answer on this

E. Editorial Note1k: Need to put something at the end of the rainbow in 
case the URI is ever resolved.

Need to action someone to make sure that a pointer to this document is 
put at that URI ...

F. Editorial Note: The BPWG is studying the use of the link element of 
HTML which is used for this purpose. It is noted that the link element 
is not available in formats other than HTML, and it is noted that there 
is currently active discussion about the use of the Link HTTP header, 
which would serve this purpose well.

We have resolved that the proxy should follow links, but we never 
discussed what the server should do by way of inserting links. 
Additionally I'm unclear how to point to "self". Additionally we need to 
be clear what happens to the link element in the multi-serving case ...

G. Editorial Note: The BPWG is aware that more precision may be needed 
in the above statement. If a transforming proxy has followed the 
guidelines in this document, then it should not receive a response with 
a Vary header if it has not already received such a response to a 
request with unaltered headers.

Don't find any discussion on this, suggest we just drop this note

H. unless the resource referenced is the current resource (1k) as 
determined by [unresolved discussion] ....

I. 4.1.2 Proxy Decision to transform - this needs a bit of a write 
through as discussed under ISSUE-255

J. Need to review all ISSUES and ACTIONS to make sure they are dealt with.



Received on Friday, 6 June 2008 17:22:44 UTC