RE: Content Transformation 1k - and Change List

Thanks for the update, Jo!

Here are my comments on draft 1k:

Section 1.3:  (minor) Last paragraph in section 1.3:  Replace comma with semicolon (or dash) in sentence "The BPWG is not chartered to create new technology, its role is to ...".

Section 2.1:  The definition of a transparent proxy has square brackets around the entire definition, while the definition of a non-transparent proxy has square brackets around just part of it.  Was this done on purpose?  I guess I'm not clear on the purpose of the square brackets here.

Section 2.1:  (minor) In some places "non-transparent" has a hyphen and some places it does not ("non transparent").  RFC 2616 uses the hyphen, so we probably should too.

Section 4.4:  My comments to the second to last paragraph of this section are at [1].


Sean


[1] http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Jun/0009.html


> -----Original Message-----
> From: public-bpwg-ct-request@w3.org [mailto:public-bpwg-ct-request@w3.org]
> On Behalf Of Jo Rabin
> Sent: Friday, June 06, 2008 12:22 PM
> To: public-bpwg-ct
> Subject: Content Transformation 1k - and Change List
> 
> 
> Please find Draft 1k at [1]
> 
> http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-
> drafts/Guidelines/080606
> 
> Extensive changes so I haven't done a formal diff but feel free to use
> the DOM-in-ator at [2]
> 
> [2] http://www.w3.org/2007/10/htmldiff
> 
> to generate one.
> 
> Extensive notes of things done and not done and some notes of decisions
> yet to be taken follow.
> 
> Cheers
> Jo
> 
> 
> 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
>      transformed"
> RESOLUTION: format of the VIA header comments: either the URI
>      "[17]http://www.w3.org/2008/04/ct", 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
>      request."
> 
> 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
>      [16]http://lists.w3.org/Archives/Public/public-bpwg-ct/2008May/0000.
>      html
> 
> 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
> the
> 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
> discussion.
> - 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
> 
> from
> 
> any knowledge it has of server preferences, derived either from a
> repository of such preferences, or from previous interaction with the
> server;
> 
> to
> 
> 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
> 
> Resolutions:
> - 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
> techniques
> 
> 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.
> etc
> 
> 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
> Status.
> 
> 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.
> 
> Cheers
> Jo
> 
> 
> 
> 
> 
> 
> 
> 
> Jo
>

Received on Monday, 9 June 2008 19:47:38 UTC