- From: Francois Daoust <fd@w3.org>
- Date: Mon, 23 Jun 2008 12:17:28 +0200
- To: public-bpwg-ct <public-bpwg-ct@w3.org>
Hi, Back to the usual weekly call! We've spent one complete day during last week's F2F on Content Transformation, and resolved all the issues but one. ----- Chair: François Staff Contact: François Known regrets: none Date: 2008-06-24T1400Z for 60mn Phone: +1.617.761.6200, +33.4.89.06.34.99, +44.117.370.6152 Conference code: 2283 ("BCTF") followed by # key IRC channel: #bpwg on irc.w3.org, port 6665. Latest draft: http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/080606 ... which obviously doesn't reflect the resolutions taken during the F2F! 1. Where we stand: a quick review of the F2F -------------------------------------------- See the minutes of Day 1, entirely spent on Content Transformation: http://www.w3.org/2008/06/16-bpwg-minutes.html a) The group will be rechartered to switch the document from informative to normative. b) Using the link element to "link to self" was emphasized as being a way to determine that an HTTP Status 200 response is not a "rejected" response. A handheld "link to self" such as: <link rel="alternate" media="handheld" href="" /> ...has 2 meanings: I "am" the handheld representation of the resource, or I "can be" a handheld representation if I detect that the device is a handheld device. To clearly identify the first case, some way of saying "this particular" representation was required. We agreed to say that when the "href" attribute refers to a location within the current representation (by use of a fragment such as "#top"), then the representation is a handheld representation. We'll include a note to explain that the meaning of an empty "href" is ambiguous. c) Current section 4.1.2 is to be rewritten in a clearer algorithm that explains how a CT-proxy should handle HTTP requests, as detailed in the minutes: http://www.w3.org/2008/06/16-bpwg-minutes.html#item_issue257 d) The use of OPTIONS will be mentioned in the "Scope for Future Work" appendix. e) We'll remain silent on whether CT-proxies should be mobileOK. f) It's not forbidden to transform mobileOK content but that should be part of the heuristics to determine if a page is mobile-friendly g) No mention of the confusing term "session" in the doc. We'll use the notion of "web site", leaving the scoping of "web site" boundaries up to CT-proxy vendors. Content tasting may not be done on different pages of the same web site, but should be done whenever a request is made for a linked resource that is on a new web site. h) As far as the CT guidelines are concerned, there is no difference between a URI-rewriting proxy and a regular non-transparent one i) Section 3.1 on requirements is to be moved (and refreshed) to the Scope section. Requirements that could not be addressed are to be moved to the "Scope for Future Work" appendix. j) Remaining issue: persistent expression of user preferences 2. Any other comments? ---------------------- 3. Close without much discussion -------------------------------- ACTION-769 on fd to ping Soonho on providing feedback about CT ACTION-711 on Soonho to provide feedback on the document Soonho was moved to another position and cannot work on the document for the time being 4. ISSUE-242: Persistent expression of user preferences ------------------------------------------------------- We started the discussion during the F2F, but were both too tired and running out of time to come to a conclusion... What we've resolved so far: - It is permissible for the proxy to offer the user a restructured desktop presentation on a 'site' by 'site' basis - If there is a blanket user preference asserted for any specific representation option and multiple representations are found to exist then the CT proxy server SHOULD inform the user of this fact and provide the user with an option to change to one of the alternative representations. - Clarification that a CT-proxy for which there exists an arrangement with a content provider is an adaptation solution part of the origin server of the content provider, and as such out of scope. - Clarification that HTTP redirects is one way to go for a URI-rewriting proxy to behave transparently on receipt of a Cache-Control: no-transform directive (internal clarification, "transparent" should be enough, we probably won't mention it in the guidelines) - Emphasis on the need for a strong Cache-Control: no-transform directive - Alternative representations of a resource should be indicated with link elements/headers. Some remaining points to address (taken from the minutes): a. how the CT proxy should react against specific user preferences when a site becomes more capable b. that the default experience should be for the mobile experience c. that blanket expression of preferences should be interpreted in the context that if an origin server can provide a choice of experience then it should do so d. that CT proxies should, in restructured content, provide links to alternative representations e. how would a CP indicate to a CT Proxy that it offers user choice of representation? f. allow users to change previously expressed preferences In terms of sections, what we're talking about is section 3.2 Control of the Behavior of the Proxy, and its possible merging with other parts of the document for the sake of clarity. 5. Schedule ----------- - Updated draft? - Last Call? 6. AOB? -------
Received on Monday, 23 June 2008 10:18:03 UTC