- From: Francois Daoust <fd@w3.org>
- Date: Wed, 24 Sep 2008 13:21:23 +0200
- To: Jo Rabin <jrabin@mtld.mobi>
- CC: public-bpwg-ct <public-bpwg-ct@w3.org>
Jo Rabin wrote: > Sorry I couldn't make it to the call yesterday - I have a couple of > comments on the minutes - and apologies for seeming to make this two > steps forward one step back. > > 1) RESOLUTION: The title of the spec will be "Guidelines for Web Content > Transformation Proxies" > > I can live with that but think that "Mobile" should have been left in, > primarily because it's out of scope for us to talk about the Web as a > whole, but partly also because it makes it clearer that we are trying to > fix a specific problem, not invent a new way of allowing proxies to > interoperate ... Yes. I fancied "Mobile" as well, but Bryan made a really good point: having "Mobile Web Content Transformation" in the title really looks as if we're talking about transformation of "Mobile Web Content", which is really not the case. We're talking about transformation of "Content" to make it suitable for the "Mobile Web". We may review this resolution though. So as not to spend "call-time" on that, I suggest that we use the mailing-list if we choose to do so! > > 2) > RESOLUTION: re. LC-2012, use Tom's wording above, (and note we may >> have to further clarify the introduction for other reasons anyway) >> ... re. LC-2012, use Tom's wording above, (and note we may have to >> further clarify the introduction for other reasons anyway) > > I'm sorry, I did contribute on this but find that my email went the > wrong way so didn't arrive on list. What I said was: > > As the original author of that tangled web of words, I would elaborate > it further - a) to refer to the whole response (i.e. the headers too, > not just the content) and b) take the opportunity to rephrase he reason > for doing it to make it more general: > > "Within this document content transformation refers to the manipulation > of requests to, and responses from, an origin server. This manipulation > is carried out by proxies in order to provide a better user experience > of content that would otherwise result in an unsatisfactory experience > on the device making the request." OK, let's re-examine this next week. I don't think there will be any strong objection to being clearer... > > 3) > RESOLUTION: re. LC-2068, we think the text is as clear as possible. >> Stick to the text in the spec. > > I don't think that we should. The commenter noted that "transparent HTTP > behavior" was not clear, iirc, and I think he's right and I think that > pointing the reader to the relevant sections of RFC 2616 is the right > thing to do. So here's a modified proposal: > > If the request contains a Cache-Control: no-transform directive, proxies > must not alter the request other than to follow HTTP sections 14.9.5 and > 13.5.2. and to add headers as described in 4.1.6 Additional HTTP Headers > below. I do not see any particular reference to "transparent HTTP behavior" in the comment. The reason why we thought it was clear enough was that: 1/ "transparent" is defined in section 2.1 and specifically refers to the HTTP RFC 2/ "as noted below" already contains a reference to section 4.1.6 That said, I doubt anyone would object to replace "as noted below (see 4.1.6 [...])" by "as described in 4.1.6 [...]". And I'm fine with referencing sections of the HTTP RFC as well. I think we should keep "transparent" in the text though. It is consistent with the definition. Francois. > > On 23/09/2008 16:47, Francois Daoust wrote: >> >> Hi, >> >> The minutes of today's call are available at: >> http://www.w3.org/2008/09/23-bpwg-minutes.html >> ... and copied as text below. >> >> >> Resolutions taken during the call: >> - The title of the spec will be "Guidelines for Web Content >> Transformation Proxies" >> - re. LC-2012, use Tom's proposed wording (and note we may have to >> further clarify the introduction for other reasons anyway) >> - LC-2064 is a mistake. There are no duplicated IDs in the document. >> - re. LC-2068, we think the text is as clear as possible. Stick to the >> text in the spec. >> - re. LC-2008, update the text according to Jo's proposal >> >> ... and we've been discussing some more about white lists, and the >> fact that content providers expect to see some reference to white >> lists in the document because it's something they have to deal with in >> practice, and the fact that we have diverging views on white lists. >> Bryan agreed to propose some text about that to see if we could >> eventually come to an agreement. >> >> We'll start next week where we left: on headers/footers being out of >> scope but again something readers expect to see in the spec. >> >> Francois. >> >> >> >> 23 Sep 2008 >> >> [2]Agenda >> >> [2] >> http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Sep/0053.html >> >> See also: [3]IRC log >> >> [3] http://www.w3.org/2008/09/23-bpwg-irc >> >> Attendees >> >> Present >> Francois, Bryan_Sullivan, hgerlach, rob, AndrewS, tomhume >> >> Regrets >> SeanP, jo >> >> Chair >> francois >> >> Scribe >> Bryan >> >> Contents >> >> * [4]Topics >> 1. [5]New comments received >> 2. [6]LC-2018: on the title >> 3. [7]LC-2025: On the quality and purpose of the doc >> 4. [8]LC-2012: clarification of the introduction >> 5. [9]LC-2064: duplicated IDs in the document >> 6. [10]LC-2003: no mention of whitelists >> 7. [11]LC-2068: on requests that contain Cache-Control: >> no-transform directives >> 8. [12]LC-2008: on use of Vary header >> 9. [13]LC-2090, LC-2091 on headers/footers >> * [14]Summary of Action Items >> _________________________________________________________ >> >> New comments received >> >> -> >> [15]http://lists.w3.org/Archives/Public/public-bpwg-comments/2008Jul >> Sep/0154.html fd's no-comment comment >> >> [15] >> http://lists.w3.org/Archives/Public/public-bpwg-comments/2008JulSep/0154.html >> >> >> <hgerlach> [16]http://cgi.w3.org/member-bin/irc/irc.cgi works >> >> [16] http://cgi.w3.org/member-bin/irc/irc.cgi >> >> <francois> [17]IAB message >> >> [17] >> http://lists.w3.org/Archives/Public/public-bpwg-comments/2008JulSep/0152.html >> >> >> Francois: may be some comments coming from W3C internal review of >> the CT guidelines. >> >> Francois: these offer W3C staff the chance to comment given they are >> very busy >> >> LC-2018: on the title >> >> <francois> - Content Transformation Proxies: Guidelines >> >> <francois> - Guidelines for Mobile Web Content Transformation >> Proxies >> >> Francois: on the doc name, we can narrow the choice between two >> >> <hgerlach> b) +1 >> >> Francois: we are more about web browsing than web, but browsing may >> be a confusing term to include; mobile web seems fine >> >> <andrews> I favour the second >> >> <francois> PROPOSED RESOLUTION: The title of the spec will be >> "Guidelines for Mobile Web Content Transformation Proxies" >> >> <andrews> +1 >> >> Bryan: recommend to leave out mobile as this is whole web content >> >> <andrews> Good point - I agree >> >> <hgerlach> Guidelines for Content Transformation Proxies in Mobile >> Networks >> >> <tomhume> +1 >> >> <andrews> +1 >> >> <hgerlach> -1 >> >> Heiko: proposes "in Mobile Networks" >> >> <francois> PROPOSED RESOLUTION: The title of the spec will be >> "Guidelines for Web Content Transformation Proxies" >> >> <francois> +1 >> >> Bryan: we are not limiting this to mobile networks; limited >> capability devices in general >> >> +1 >> >> <andrews> +1 >> >> <hgerlach> +1 >> >> <tomhume> +1 >> >> <rob> +1 >> >> Francois: suggests we come to agreement to close this item as we >> could spend a lot of time on it >> >> RESOLUTION: The title of the spec will be "Guidelines for Web >> Content Transformation Proxies" >> >> Heiko: for new people, it may be hard to know that a key use case is >> in the mobile network context >> >> Francois: the abstract of the title could include mobile and a >> proposal can be sent to the mailing list for that >> >> LC-2025: On the quality and purpose of the doc >> >> <francois> close ACTION-831 >> >> <trackbot> ACTION-831 Continue discussion of the title on the list >> closed >> >> <francois> [18]heiko's comments >> >> [18] >> http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Sep/0004.html >> >> Francois: what can we resolve to do on this? >> >> Heiko: this will come out of the whole comment resolution process; >> dont want to question the whole objective, this just provides >> general guidelines on how to improve the doc >> >> Francois: we can include better examples and will come back to this >> in the end >> >> <francois> Close ACTION-829 >> >> <trackbot> ACTION-829 Detail his thoughts arising from discussion of >> LC-2025 closed >> >> LC-2012: clarification of the introduction >> >> <francois> [19]Tom's proposal >> >> [19] >> http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Sep/0015.html >> >> <tomhume> Apologies all, I appear to have lost my telephone >> connection :( >> >> <francois> "Within this document content transformation refers to >> the >> >> <francois> manipulation of requests made to, and content delivered >> by, an origin >> >> <francois> server. This manipulation is carried out by proxies with >> a view to >> >> <francois> making content delivered more suitable for mobile >> presentation." >> >> Francois: we should keep this for now, we do need to improve the >> intro, and can resolve to accept Tom's wording, about the 1st >> sentence of the intro >> >> +1 >> >> <francois> PROPOSED RESOLUTION: re. LC-2012, use Tom's wording >> above, (and note we may have to further clarify the introduction for >> other reasons anyway) >> >> +1 >> >> <francois> +1 >> >> <rob> +1 >> >> <hgerlach> +1 >> >> RESOLUTION: re. LC-2012, use Tom's wording above, (and note we may >> have to further clarify the introduction for other reasons anyway) >> ... re. LC-2012, use Tom's wording above, (and note we may have to >> further clarify the introduction for other reasons anyway) >> >> LC-2064: duplicated IDs in the document >> >> Francois: this one is a mistake; a bug in firefox >> >> <francois> PROPOSED RESOLUTION: LC-2064 is a mistake. There are no >> duplicated IDs in the document. >> >> +1 >> >> RESOLUTION: LC-2064 is a mistake. There are no duplicated IDs in the >> document. >> >> LC-2003: no mention of whitelists >> >> <francois> [20]jo's proposal >> >> [20] >> http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Sep/0026.html >> >> <francois> PROPOSED RESOLUTION: re. LC-2003, stick to our position >> and use Jo's proposed response in public-bpwg-ct/2008Sep/0026.html >> >> <hgerlach> -1 >> >> Francois: the essence is that this is an internal proxy issue >> >> Heiko: don't agree, but can accept a team agreement >> >> Bryan: we can consider content management interfaces through other >> specifications or fora, e.g. OMA >> ... OMA is working on content management interfaces for example >> >> Francois: agree that new technologies may be needed, if there is >> some clear work going on, we can mention it in the appendix >> >> <Zakim> rob, you wanted to support Heiko's point that whitelists do >> exist - and won't go away just because we don't mention them >> >> Rob: there is talk of mechanisms, but CP's are aware of the need to >> be on whitelists, so it is strange that we don't mention it in more >> detail >> >> Francois: the rationale is that it is not needed for our guidelines, >> and is just the internal processing of proxies; we could add a note >> mentioning whitelists >> >> Rob: a note should tell CP to contact the network operator if they >> are having trouble >> >> Bryan: should be called the "proxy operator" >> >> Francois: we could note that whitelist require CPs to submit some >> request to manage their handling >> >> Rob: it should be the proxy operator who takes the action >> >> Heiko: the diverging views here indicate the need for clarity; the >> history of this is that the use of lists in the proxy were to >> prevent adaptation; the same concept can be applied to user-agents >> ... the only issue left is that 200 OK pages; for dedicated URL we >> see issues with 200 OK instead of 406; human launguage guidance of >> incompatibility cannot be used semantically and thus we need >> whiltelists >> >> Francois: proposes someone take an action to propose text so we can >> try to get agreement on it >> >> Bryan: we could just list the types of functions that could be >> controlled by whitelists in tyhe document and leave the details out >> ... we can just list the functions e.g. don't modify this user agent >> or that site >> >> Francois: the listing of the functions is where the opinion >> divergence happens >> >> Heiko: we had another item about the manipulation of other headers >> as well; we can expand the user-agent mod control whitelist text (if >> we had it) to include other headers as well >> >> Francois: the relationship between whitelists and headers is unclear >> >> Heiko: to control the changing of the user agent for specific pages >> >> <Zakim> rob, you wanted to say we don't want to go into too much >> detail >> >> Heiko: the decision on whether the UA is changed should be the site >> provider's >> >> Rob: we should not go into too much detail about the purpose of the >> controls; just note that there may be functions that control the >> automatic behavior >> >> Bryan: I can try to provide some more generic text that will >> hopefully be useful >> >> <francois> ACTION: Bryan to provide some text on whitelists to see >> if we can include them somehow and come to an agreement re. LC-2003 >> [recorded in >> [21]http://www.w3.org/2008/09/23-bpwg-minutes.html#action01] >> >> <trackbot> Created ACTION-850 - Provide some text on whitelists to >> see if we can include them somehow and come to an agreement re. >> LC-2003 [on Bryan Sullivan - due 2008-09-30]. >> >> LC-2068: on requests that contain Cache-Control: no-transform >> directives >> >> <francois> [22]Jo's proposal >> >> [22] >> http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Sep/0029.html >> >> <francois> "If the request contains a Cache-Control: >> >> <francois> no-transform directive proxies must follow HTTP sections >> 14.9.5 and >> >> <francois> 13.5.2." >> >> Francois: HTTP RFC talks about presence of the cache control header; >> we need to improve the clarity of the text and would like to hear >> proposals for that >> ... text in the CT guidelines of course... >> >> <andrews> I think that we should leave the text unchanged. >> >> <francois> "If the request contains a Cache-Control: no-transform >> >> <francois> directive proxies must forward the request unaltered to >> the server, >> >> <francois> other than to comply with transparent HTTP behaviour and >> as noted >> >> <francois> below." >> >> Francois: we could clarify the "as noted below" part. >> >> <francois> "If the request contains a Cache-Control: no-transform >> directive proxies must forward the request unaltered to the server, >> other than to comply with transparent HTTP behavior and as noted >> below (see 4.1.6 Additional HTTP Headers)" >> >> Andrew: would not suggest any changes; it would probably just make >> it less clear >> >> Francois: we could ref the transparent HTTP behavior, but the whole >> spec is assumed to be on top of HTTP anyway >> >> <francois> PROPOSED RESOLUTION: re. LC-2068, we think the text is as >> clear as possible. Stick to the text in the spec. >> >> <andrews> +1 >> >> <francois> +1 >> >> +1 >> >> <hgerlach> +1 >> >> <rob> +1 >> >> RESOLUTION: re. LC-2068, we think the text is as clear as possible. >> Stick to the text in the spec. >> >> LC-2008: on use of Vary header >> >> <francois> [23]Jo's proposal >> >> [23] >> http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Sep/0030.html >> >> <tomhume> Apologies to all, I'm unable to keep a mobile signal here >> and am about to lose net.connection :( >> >> <francois> "If a server varies its representation according to >> examination of >> >> <francois> received HTTP headers then it must include a Vary HTTP >> header indicating >> >> <francois> the headers it examines in accordance with [ref]. >> >> <francois> " >> >> Francois: The text is too long and thus obscure; Jo proposes to >> simplify the text >> >> <francois> Current text: "If a server varies its representation >> according to examination of >> >> <francois> received HTTP headers then it must include a Vary HTTP >> header indicating >> >> <francois> this to be the case. If, in addition to, or instead of >> HTTP headers, a >> >> <francois> server varies its representation based on other factors >> (e.g. source IP >> >> <francois> Address) then it must, in accordance with [RFC 2616 >> >> <francois> >> [ HTTP]<[24]http://www.w3.org/TR/2008/WD-ct-guidelines-20080801/#ref-H >> TTP>, >> >> [24] >> http://www.w3.org/TR/2008/WD-ct-guidelines-20080801/#ref-HTTP%3E >> >> <francois> include a Vary header containing the value '*'. >> >> <francois> " >> >> Francois: fine with Jo's proposal; we don't need to restate the RFC; >> readers can go there to get details >> >> <andrews> Agree >> >> <francois> PROPOSED RESOLUTION: re. LC-2008, update the text >> according to Jo's proposal, as pasted above >> >> <andrews> +1 >> >> <rob> +1 >> >> <francois> +1 >> >> RESOLUTION: re. LC-2008, update the text according to Jo's proposal, >> as pasted above >> >> LC-2090, LC-2091 on headers/footers >> >> <francois> [25]Heiko's proposal >> >> [25] >> http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Sep/0038.html >> >> Heiko: adpated pages could include headers/footers, for non-adapted >> pages we should not add these >> >> Francois: these should be out ot scope of the document; there were >> comments on copyright issues >> >> <Zakim> rob, you wanted to agree that just because it's possible >> does not mean it's recommended >> >> Bryan: we should leave this off the table >> >> <francois> PROPOSED RESOLUTION: re. LC-2090, leave headers/footers >> off the table. Out of scope of this document. >> >> rob: agree that just because it's possible does not mean it's >> recommended >> >> <hgerlach> -1 >> >> <francois> linked to >> [26]http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Sep/0004. >> html >> >> [26] >> http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Sep/0004.html >> >> Heiko: with RC-2025, we discussed changes related to request for >> more details; now we are being less specific >> >> <hgerlach> ok, bye >> >> Francois: suggests that people think about this over the list in the >> meantime >> >> Summary of Action Items >> >> [NEW] ACTION: Bryan to provide some text on whitelists to see if we >> can include them somehow and come to an agreement re. LC-2003 >> [recorded in >> [27]http://www.w3.org/2008/09/23-bpwg-minutes.html#action01] >> >> [End of minutes] >> >
Received on Wednesday, 24 September 2008 11:22:00 UTC