- From: Jo Rabin <jrabin@mtld.mobi>
- Date: Tue, 22 Jul 2008 18:00:48 +0100
- To: public-bpwg-ct <public-bpwg-ct@w3.org>
Hi I started this draft [1] in the hope of having it ready for today's meeting, but in the event was not able to. The following update notes are based around Sean's notes some typos and clarification I spotted. I've also added notes regarding changes arising from today's meeting and last week's too. Read below for the full and gory details. [1] http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/080722 Diffs are linked from within the document. @@TODO - Add examples [that means YOU!] @@TODO - Conformance Statement [Francois, please? pretty please?] @@TODO - Final references for BP Guidelines and mobileOK @@TODO - Anything else that you spot and that I have missed :-( Jo On 18/07/2008 21:47, Sean Patterson wrote: > Comments on the draft 1l: > > Section 2.1: > --Bracket and quote nesting problem. In the definition of > non-transparent proxy, there is a left bracket ([) followed later by a > double quote. However, the closing right bracket (]) appears before the > closing double quote. I'm assuming that the closing double quote should > actually appear right immediately before the closing right > bracket--right after "anonymity filtering." Yes, it's a mess. I'll do something about sorting out the mess that XMLSpec's default <termdef> leaves in its wake. > > Section 3.1.3 > --Missing right parenthesis after "see 3.1.2 no-transform directive in > Request". tks > > Section 3.1.4 > --Response to the editorial note: For responses that are paginated, the > CT proxy will need to cache the response for a finite amount of time in > order to be able to return subsequent sections of a paginated Web page, > even for no-cache responses or responses the expire very quickly. > OK - as discussed on today's call. > Section 3.1.5 > --Missing right parenthesis at the end of item 1. > tks > Section 3.1.5.2 > --In the second paragraph, "A proxy must not issue a POST/PUT..." should > be "A proxy must not *reissue* a POST/PUT...". OK > > Section 3.1.5.3 > In response to the editorial note: Isn't it good enough for the origin > server to include the Cache-Control: no-transform header when the origin > server wants to make sure that client receives the origin server's > choice of representation? (As mentioned in section 3.2.3.2.) Yes, I think it is, on reflection. And as resolved today. > > Section 3.1.6.1 > --The word "should" in the first sentence should be in bold. > tks > Section 3.2.2 > --I agree with the suggestion in the editorial note that the note about > the META HTTP-Equiv element should be moved to an appendix. It doesn't > really seem to fit here and since there is no explanation of why META > HTTP-Equiv might be necessary, readers might be scratching their heads > about this note. Following discussion today, which resolved to move it to an appendix, I actually didn't do that I left it in under Proxy Forwarding of Response seems like more of the right kind of place for it to be, on reflection. > > Section 3.2.3.2 > --I had a bit of trouble comprehending the bullet list in this section > because the sentence introducing the list seems to indicate that both > bullets will be about LINK elements that refer to the representation of > the page containing the LINK element(s). In reality the second bullet > is about representations other than the current representation. Maybe > this section could be improved by removing the bullet list and combining > the introductory sentence and the first bullet into one paragraph and > the second bullet into another paragraph (with some additional > introductory text such as "To indicate additional available > representations of the HTML content, [bullet 2 text]"). Seems like a > small point, but I think this would make this section easier to > understand. Good idea, done, tks > --I was going to suggest that there should be some examples of what the > LINK elements would look like, but it looks like those will be covered > in an appendix. This is a good idea since it may not be immediately > obvious how these LINK elements should look. References to the relevant > W3C recommendations (or a glossary at least) might also be in order for > the definitions of fragment identifiers and media types. good point, RFC 3986 is the reference in question. > > Section 3.3.4 > --In this section, it is stated that if a request from the CT proxy is > made with altered headers and the origin server responds with a Vary > header referring to one of the altered headers, unaltered headers should > *always* be presented first on subsequent requests for this resource. I > don't think it is out of the realm of possibility that a lower traffic > web site (for example) might create a mobile version of its site then > determine that it is too much work for the amount of traffic received. > Such a site might then just start sending back a 406 for all mobile > requests. The restriction of "always" means that heuristics of section > 3.1.5.2 can no longer be used to allow the CT proxy to send altered > headers first even thought the CT proxy is going to send a 406 every > time. A statement that unaltered headers should be sent first unless > the server modifies its behavior to no longer handle the unaltered > headers would be a good idea here. OK so I altered this hopefully to suit. > > Section 3.3.5 > --For consistency reasons, "SHOULD" should be lowercase and in bold. > thanks, done > Section 3.3.6 > --The third bullet could use some improved formatting to make it easier > to read. Perhaps as a list. Did we resolve to remove examples of > content types? Seems odd that we list several DOCTYPE examples but no > content type examples. OK have reformatted ref content-type as discussed today. > > Section B.1 > --As mentioned by someone else (I can't remember whom), we should > replace "bogus" by "unacceptable" since we haven't defined "bogus." fair enough. As discussed today, we need contributions to these examples. > > Section D.5 > --In response to the editorial note: The last sentence makes more sense > if you change "recoding" to "recording". I am assuming that this > sentence is referring to the fact that we had to resort to X-headers to > send the original headers to the origin server. yes, you are right. Clearly needs re-wording if the editor can't make head or tail of it. Have tried new wording > > General comment: > --I still think there should be some mention of how users can make their > preferences known to the CT server. Perhaps a non-normative appendix > that mentions the stuff in the old 3.2.1 and 3.2.3 sections as examples > of how a user would specify his/her preferences. I've offered some text in a new Appendix. > > > Sean > From Today's Agenda/Call 1. Appendix B: Example Transformation Interactions -------------------------------------------------- Awaiting examples 2. CT and direct choice of user experience ------------------------------------------ per above, dropped 3. HTTPS link re-writing ------------------------ Note added per above 4. No mention of Content-Types in 3.3.6 --------------------------------------- reworded per above 5. meta http-equiv note in 3.2.2 -------------------------------- removed from Server actions, retained in Proxy Actions, not added as a note in a non normative appendix - as described above 6. Pagination and caching directives ------------------------------------ Text amended per above 7. Link element section structure (3.2.3.2) ------------------------------------------- reworded per above 8. Receipt of Vary HTTP header (3.3.4) -------------------------------------- reworded per above 9. Typo fixes ------------- per above 10. Allow/Disallow lists ------------------------ PROPOSED RESOLUTION: allow/disallow lists fit in "heuristics of various kinds" in 3.1.5.2. Do not mention allow/disallow lists explicitly on the grounds that we do not want to prescribe how a CT-proxy works internally. No mention added. New Appendix on Admin Arrangements has some bearing on this. 11. Persistent expression of user preferences --------------------------------------------- PROPOSED RESOLUTION: mention Administrative arrangements as out of scope in a non-normative appendix done. From minutes of 15th July Resolution taken: - Remove Caveat on WML from scoping statement (it appears further down in the document) done > > >> -----Original Message----- >> From: public-bpwg-ct-request@w3.org > [mailto:public-bpwg-ct-request@w3.org] >> On Behalf Of Jo Rabin >> Sent: Friday, July 11, 2008 5:36 PM >> To: public-bpwg-ct >> Subject: Content Transformation Guidelines 1l (Rev 12) and Change List >> >> >> Please find Draft 1l at [1] >> >> http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors- >> drafts/Guidelines/080712 >> >> I haven't linked to a diff as the changes are very extensive. >> >> This draft is not as polished as I would have liked, but it is more or >> less there. Some links missing and undoubtedly some typos, but I have >> run out of time and wanted to get this out in good time for Tuesday's >> meeting. >> >> I hope to be able to attend that meeting but I'm afraid I am not sure >> yet exactly what my availability is. >> >> Extensive notes of things done follows. >> >> Cheers >> Jo >> >> >> Changes to draft 1l >> >> Section numbers per draft 1k >> >> 1. In response to Sean's comments [1] >> [1] > http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Jun/0018.html >> Editorial changes to 1.3, 2.1. Sean's comments on 4.4 overtaken by > events. >> 2. Minutes of CT Call 10 June: >> a. Normative ... the document is to become normative so the section on >> RFC2119 has changed. >> >> b. Proxy vendors to determine when a 200 response is really a 406 - >> editorial note removed, existing Note stands but remains silent on how >> to detect. Overtaken by subsequent events in large part in any case. >> >> c. Drop editorial note at end of 4.3 >> >> 3. > http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Jun/0023.html >> CT Namespace >> a. Edited to become http://www.w3.org/ns/ct >> >> 4 http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Jun/0025.html >> >> Insert new section on applicability to solutions that are not in > scope. >> 5. Remove section 4.3 and rewrite its contents to fit under 4.2 and > 4.4 >> 6. ACTION-732 HTTPS link re-writing >> >> 7. ACTION-766 Note on X-Device >> >> 8. ACTION-770 semi-persistent (section has been restructured anyway) >> >> 9. Resolutions from F2F >> >> RESOLUTION: Restart rechartering process now, where the only changes: >> would be the informative to normative change for this doc, as well as >> extend the WG, 6 months into 2009 >> >> reword section on rfc2119, reword caveat text to refer to a proposed >> normative Recommendation. >> >> RESOLUTION: a Link header/element with media type of handheld and a > URI >> referring to a location within the resource indicates that the current >> representation of the resource is intended for handheld presentation >> >> RESOLUTION: Make the point explicitly in the document that an href > which >> refers to this resource but which does not have a fragment identifier > on >> a link header/element means that this resource is capable of being >> rendered in a way that is suitable for handheld presentation, but that >> without the above link element there is a question as to whether this >> representation is or is not... >> >> RESOLUTION: Make the point explicitly in the document that an > href >> which refers to this resource but which does not have a fragment >> identifier on a link header/element means that this reource is >> capable of being rendered in a way that is suitable for handheld >> presentation, but that without the above link element there is a >> question as to whether this representation is or is not... >> >> RESOLUTION: Regarding ISSUE-261, adopt Jo's proposal for a process >> for a process for CT bogus 200 response detection (4.1.2) and > close >> ISSUE-261. >> ACTION-777 - Edit 4.1.2 according to above resolution >> [as an illustrative appendix] >> >> RESOLUTION: Adopt Jo's wording for 4.1.2 of the CT document (pending >> some editorial "tweaking") >> >> ACTION-778 - Add the stuff on possible use of >> OPTIONS to the appendix >> ACTION-779 - Transcribe points 7 8 9 and 11 of >> ISSUE-223 into Scope for future work >> [done except for the stuff on DPE] >> ACTION-780 - Add text to section 4.4 referencing >> above resolution on mobikeOK >> RESOLUTION: Close ISSUE-243 and mention this topic in the appendix >> as scope for future work. >> RESOLUTION: For CT guidelines, for included resources within a page, >> additional content tasting is not required. >> RESOLUTION: For CT guidelines, except in the case of https, the >> content transformation guidelines document does not differentiate >> between URI rewriting and so-called "transparent" proxy > operation. >> [not quite sure where to put the above] >> >> RESOLUTION: Regarding ISSUE-241, in the CT guidelines we agree that >> the proxy does not have to taste every linked resource (for the > sake >> of clarity). >> RESOLUTION: Regarding ISSUE-241, in the CT guidelines we should >> state that when the proxy makes a request for a linked resource > to a >> new "web site", then what's in section 4.1.2 should happen > (allowing >> for different heuristics for determining whether request is to a >> different or the same "web site" but giving "hitting a new domain >> name" as a good example. And remove the word "session" from the >> previous resolution on 4.1.2. And close ISSUE-241. >> ACTION-781 - Enact changes sugegsted by the >> previous 4 resolutions >> RESOLUTION: re. ISSUE-255, drop mention of examination of URI from >> 4.1.2 as it's a heuristic to scope rejected 200 responses, > detailed >> in 4.4, and 4.1.2 already precises to examine the response (with > a >> link to 4.4) >> RESOLUTION: Regarding ISSUE-258, move section 3.1 of CT Guidelines >> document into Scope section (and refresh to synchronize with the >> rest of the document) moving removed requirements into scope for >> future work (and close ISSUE-258). >> RESOLUTION: On point 12 of ISSUE-223 (whether CT proxies should > refrain >> from transforming MobileOK content) we should allow for the > possibility >> that CT proxies should be able to transform MobileOK content but that >> they should take into account MobileOK-ness as part of the heuristics >> involved in determining whether content is mobile-friendly (but remain >> silent on how you check if something is mobileOK). >> >> [done under heuristics and added bibref] >> >> ACTION-782 - Draft text on which aspects of the >> CT guidelines should be followed by e.g. Opera Mini >> >> RESOLUTION: It is permissible for the proxy to offer the user a >> restructured desktop presentation on a 'site' by 'site' basis >> RESOLUTION: Insert into the document a scoping statement that says >> that a proxy is a CT proxy in scope of this document only where > no >> prior arrangement exists between the operator of the proxy and a >> content provider. One where an arrangement exists with the > content >> provider is an adaptation solution, is considered to be part of > the >> origin server and is therefore out of scope >> RESOLUTION: In the context of tasting content, if header comes back >> as cache-control no-transform, then CT proxies SHOULD change to >> transparent proxy operation (e.g. sending a http redirect) >> [not sure where to put the above] >> >> RESOLUTION: If the response includes a Cache-Control: no-transform >> directive then the response must remain unaltered other than to >> comply with transparent HTTP behavior and other than as follows. > If >> the proxy determines that the resource as currently represented > is >> likely to cause serious mis-operation of the user agent then it > may >> advise the user that this is the case and must .provide the > option >> for the user to continue with unaltered content. >> >> RESOLUTION: If the server has alternative representations then it >> should indicate this using link header/elements >> >> >
Received on Tuesday, 22 July 2008 17:01:46 UTC