- From: Jo Rabin <jrabin@mtld.mobi>
- Date: Tue, 22 Jul 2008 18:32:52 +0100
- To: MWI BPWG Public <public-bpwg@w3.org>
Dear BP "Mother Ship" On behalf of the CT Task Force I have been asked to bring you attention to the following antepenultimate draft of CT Guidelines. As noted below there are some example sections to complete as well as a conformance statement, but this is no "jury rig" - we have "made good headway". "With a fair wind and a following sea" we plan to add these by Friday, resolve on Tuesday next week to ask you to request transition of this document to Last Call on the call on Thursday next week. Since the changes planned between now and then are "by and large" for non-normative (aside from the formal conformance statement) text you will not be "taken aback" by any changes, we request that you take this opportunity to review the document in preparation for a resolution to transition on next week's call. [That's enough nautical references, Ed.] Your coxswain Jo PS Why are pirates called "pirates"? Answer: They just Arrr (Jim Lad). -------- Original Message -------- Subject: Content Transformation Guidelines 1m (Rev 13) [was Re: Content Transformation Guidelines 1l (Rev 12) and Change List] Resent-Date: Tue, 22 Jul 2008 17:01:47 +0000 Resent-From: public-bpwg-ct@w3.org Date: Tue, 22 Jul 2008 18:00:48 +0100 From: Jo Rabin <jrabin@mtld.mobi> To: public-bpwg-ct <public-bpwg-ct@w3.org> References: <4877E034.8080108@mtld.mobi> <24889886D84B794A9259323D7354CF3306A65135@novarrainet2.internalnt.novarra.com> 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:34:09 UTC