- From: Jo Rabin <jrabin@mtld.mobi>
- Date: Tue, 25 Mar 2008 20:48:53 -0000
- To: "Francois Daoust" <fd@w3.org>, "public-bpwg-ct" <public-bpwg-ct@w3.org>
Ref the resolution on ACTION-709 in the following, I think we should amplify the text on white lists to say that maintaining them and expecting Web site owners to apply for membership of them is likely to be difficult and it's unreasonable to expect origin servers to make individual applications to be admitted to white lists. (who would they make them to, for a start) Jo > -----Original Message----- > From: public-bpwg-ct-request@w3.org [mailto:public-bpwg-ct-request@w3.org] > On Behalf Of Francois Daoust > Sent: 25 March 2008 16:40 > To: public-bpwg-ct > Subject: [minutes] CT Teleconference Tuesday 25 March 2008 > > > Hi, > > Minutes of today's call are available at: > http://www.w3.org/2008/03/25-bpwg-minutes.html > ... and copied as text below. > > > Thanks for scribing, Sean. > François. > > > 25 Mar 2008 > > [2]Agenda > > [2] > http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Mar/0029.html > > See also: [3]IRC log > > [3] http://www.w3.org/2008/03/25-bpwg-irc > > Attendees > > Present > MartinJ, SeanP, francois, jo, rob > > Regrets > kemp, Magnus, Bryan, andrews > > Chair > francois > > Scribe > SeanP > > Contents > > * [4]Topics > 1. [5]ACTION-682: Write a proposal on the HEAD request > handling (§3.1.2) > 2. [6]ACTION-683: Inference on URIs (§3.1.2) > 3. [7]ACTION-684: Bad practice to strip comments in VIA header > (§3.1.4) > 4. [8]ACTION-685: how to embed original headers (§3.1.4) > 5. [9]ACTION-706: Reword §2.5.1 > 6. [10]ACTION-707: Include examples in §2.5.1 bullet 3 > 7. [11]ACTION-708: Update 2.5.2 > 8. [12]ACTION-709: Write some examples for 2.5.3 > 9. [13]ACTION-718: re Ajax/XHR requests and CT > * [14]Summary of Action Items > _________________________________________________________ > > > > <trackbot-ng> Date: 25 March 2008 > > Zakim aadd is me > > <francois> Scribe: SeanP > > <francois> ScribeNick: SeanP > > Francois: Today we should go through our actions. > > ACTION-682: Write a proposal on the HEAD request handling (§3.1.2) > > Francois: Based on Martin's text > > <francois> [15]Martin's proposal > > [15] > http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Mar/0009.html > > Francois: I simplified one of the sentences. > > <francois> "Clients can issue HTTP HEAD requests in order to > determine if a > > <francois> resource is of a type and/or size that they are capable > of handling. A > > <francois> proxy may convert a HEAD request into a GET request if it > requires the > > <francois> response body to determine the characteristics of the > transformed > > <francois> response that it would return if the client issues a GET > request. Where > > <francois> this occurs, the proxy should (subject to HTTP cache > directives) cache > > <francois> the response that it receives so that if the client > immediately follows > > <francois> the HEAD request with a GET request for the same URI, the > proxy is not > > Francois: Any problems with the proposed text? > > <francois> required to send a second GET request to the server." > > <francois> PROPOSED RESOLUTION: use above text to resolve ACTION-682 > > <jo> subject to HTTP cache directives => providing in accordance > with normal HTTP caching rules > > <francois> PROPOSED RESOLUTION: leave above text to resolve > ACTION-682 in the hands of the editor > > <jo> +1 > > <MartinJ> +1 > > <rob> +1 > > <francois> RESOLUTION: leave above text to resolve ACTION-682 in the > hands of the editor > > <francois> Close ACTION-682 > > <trackbot-ng> ACTION-682 Write a proposal on the HEAD request > handling. closed > > ACTION-683: Inference on URIs (§3.1.2) > > <francois> [16]rob's contribution > > [16] > http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Mar/0019.html > > Francois: Rob, you suggested we no change anything > > Rob: I think the statement that is already there is all we can say. > > Francois: I think that is fine. We'll leave it up to CT proxy > vendors. > ... Jo are you OK with that? > > Jo: This is another "remaining silent" thing. > ... It is worth mentioning that the server could give you some > clues. > ... If we are going to go with POWDER we should mention it in this > section > > Francois: Unsure about what we should say about POWDER. > > Jo: Should say that these resources do this, those do that, etc. > ... I think we have time. We've have time to find out how we should > do the POWDER > > Francois: Not sure how to put it in the document given that POWDER > does not exist. > > Jo: I think we are pretty close to resolving everything we want to > put in the document except for the POWDER stuff. > ... I think it is time to go to a FPWD and leave as editorial notes > about the richer vocabulary. > > <francois> PROPOSED RESOLUTION: for ACTION-683, no change in bullet > 3 of 3.1.2 > > <francois> PROPOSED RESOLUTION: for ACTION-683, no change in bullet > 3 of 3.1.2 save POWDER editorial's note > > <rob> +1 > > <MartinJ> +1 > > <jo> +1 > > <francois> RESOLUTION: for ACTION-683, no change in bullet 3 of > 3.1.2 save POWDER editorial's > > <francois> Close ACTION-683 > > <trackbot-ng> ACTION-683 Raise an issue on inferencing from the > structure of the URI what assumptions to make about another from the > point of view of the CT Proxy closed > > ACTION-684: Bad practice to strip comments in VIA header (§3.1.4) > > Francois: Jo, you mentioned in 3.1.4 that this reverses HTTP > ... HTTP says the proxy may strip comments. > > Jo: It is probably worth finding out why HTTP says this. > ... It seems kind of odd that HTTP says this. > > Francois: Good point. I'll ask an HTTP expert. > > Jo: Should say that if you are complying with transformation > guidelines, you should not strip the comment. > > <francois> ACTION: daoust to check why HTTP RFC states comments MAY > be removed from a VIA header. [recorded in > [17]http://www.w3.org/2008/03/25-bpwg-minutes.html#action01] > > <trackbot-ng> Created ACTION-722 - Check why HTTP RFC states > comments MAY be removed from a VIA header. [on François Daoust - due > 2008-04-01]. > > Francois: Jo, do you think you will come up with a note. > > Jo: The answer about having the editorial note is yes. > > <jo> PROPOSED RESOLUTION: Yes we should add a note, pending FD's > ACTION-722 > > <jo> PROPOSED RESOLUTION: Yes we should add a note on it being bad > practice to strip comments from Via HEader (ACTION-684), pending > FD's ACTION-722 > > +1 > > <MartinJ> +1 > > <jo> PROPOSED RESOLUTION: Yes we should add a note on it being bad > practice to strip comments from Via Header (ACTION-684) and that > this is not consistent with HTTP, pending FD's ACTION-722 > > <francois> +1 > > <jo> RESOLUTION: Yes we should add a note on it being bad practice > to strip comments from Via Header (ACTION-684) and that this is not > consistent with HTTP, pending FD's ACTION-722 > > ACTION-685: how to embed original headers (§3.1.4) > > Francois: I sent an email on Friday about this. > > <inserted> I do not see any possibility to embed original headers in > the generic case without requiring changes on the content providers > side > > Francois: Maybe we could address this next week since everyone was > on vacation at the end of the week. > ... HTTP doesn't say anything about bodies in GET requests. > > Jo: I think it does. > ... We could do some tests with real web servers. > ... We can test whether if we put an extra thing in a request, > existing servers fail. > > Francois: We may have to make a test. > > Jo: Agreed. > > ACTION-706: Reword §2.5.1 > > Jo: We'll need to read your email about this and have a discussion > next week. > > Francois: We had a discussion about control by the user. > > <francois> [18]2.5.1 > > [18] > http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors- > drafts/Guidelines/080313#d0e331 > > Francois: Jo, you added an editorial note. Do we need to resolve on > this? > > Jo: The text of 2.5.1 as it stands was proposed by Bryan. > ... I'm wonding if what is in 2.5.1 is strong enough. > > Rob: My comment is that some of the CT servers are on particular web > sites. They wouldn't bother to set up a session. > ... It is probably best to leave it is "MAY". > > Francois: I may agree. > ... We agree that static settings are out of scope. > ... What we are really talking about is session settings. > ... We'll leave it as a MAY? > > <francois> PROPOSED RESOLUTION: stick to "may" in 2.5.1, and change > "persistent" to something less strong > > Jo: I think we need to think about what a "session" is. > ... not sure what we mean by session right now. > ... I think 2.5.1 needs to be taken on the list. > > <francois> ACTION: daoust to raise discussion on session settings vs > persistent settings for 2.5.1 and 2.5.3 [recorded in > [19]http://www.w3.org/2008/03/25-bpwg-minutes.html#action02] > > <trackbot-ng> Created ACTION-723 - Raise discussion on session > settings vs persistent settings for 2.5.1 and 2.5.3 [on François > Daoust - due 2008-04-01]. > > ACTION-707: Include examples in §2.5.1 bullet 3 > > Francois: Examples look fine to me. > > <francois> Close ACTION-707 > > <trackbot-ng> ACTION-707 Include examples in 2.5.1 bullet 3 per the > dicussion above closed > > ACTION-708: Update 2.5.2 > > <jo> ACTION-708? > > <trackbot-ng> ACTION-708 -- Jo Rabin to update 2.5.2 in accordance > with discussion and Seoul resolution on preferences -- due > 2008-03-18 -- OPEN > > <trackbot-ng> > [20]http://www.w3.org/2005/MWI/BPWG/Group/track/actions/708 > > [20] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/708 > > Francois: Not sure I remember what this action was about. > ... Was to rewrite section 2.5.2 given what happened a the Seoul F2F > ... It was about if the user preferences contradict the server > preferences. > ... We do have a resolution on this. > > Jo: Discussed this in the context of that this is the way CSS works. > ... we need a better way to say this. > > <jo> ACTION: Jo to raise discussion on list as to clarification of > 2.5.2 "In cases where user preferences contradict server > preferences, server preferences prevail, except where the user > specifically requires their preferences to over-rule those of the > server." [recorded in > [21]http://www.w3.org/2008/03/25-bpwg-minutes.html#action03] > > <trackbot-ng> Created ACTION-724 - Raise discussion on list as to > clarification of 2.5.2 \"In cases where user preferences contradict > server preferences, server preferences prevail, except where the > user specifically requires their preferences to over-rule those of > the server.\" [on Jo Rabin - due 2008-04-01]. > > <francois> Close ACTION-708 > > <trackbot-ng> ACTION-708 Update 2.5.2 in accordance with discussion > and Seoul resolution on preferences closed > > ACTION-709: Write some examples for 2.5.3 > > <francois> [22]fd's proposal > > [22] > http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Mar/0018.html > > <francois> "The preferences of users and of servers MAY be > ascertained by means > > <francois> outside the scope of this document. These means include > but are not > > <francois> limited to: > > <francois> - the use by transforming proxies of a disallow-list of > Web sites for > > <francois> which content transformation is known to be useless > and/or to break > > <francois> delivered content. > > <francois> - the use by the transforming proxies of an allow-list of > Web sites for > > <francois> which content transformation is known to be necessary. > > <francois> - user static preferences, e.g. provisioned by their CT > service provider > > <francois> or directly by the user through self-care web sites. > > <francois> - terms and conditions of service, as agreed upon between > the user and > > <francois> the CT service provider." > > Francois: This is where I had a chat with Bryan about static and > persistent settings as opposed to session settings. > ... The third point needs to be re-examined in light of the earlier > discussion on this call. > > <francois> PROPOSED RESOLUTION: remove user static preferences in > above text for the time being, and use the resulting text for 2.5.3 > under ACTION-709 > > Jo: These look pretty complete. > > <jo> +1 > > <francois> RESOLUTION: remove user static preferences in above text > for the time being, and use the resulting text for 2.5.3 under > ACTION-709 > > ACTION-718: re Ajax/XHR requests and CT > > <francois> [23]fd's thoughts on this > > [23] > http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Mar/0028.html > > Francois: I raised this problem. > ... I tried to rephrase the discussion about this problem. > ... the XHR request will use the same headers as a normal request, > so there is no way to tell if it is XHR request. > ... for simple calls in a web page; it it transformed the page, the > CT proxy should know how to handle the request. > ... the problem is for untransformed pages, it doesn't know that an > XHR request should not be transformed as well. > ... Martin said that requests and responses should only be > transformed when the CT proxy knows that they originated from a > transformed request. > ... Bryan said that as a best practice, XHR request should change > the UA. > ... Good idea, will be hard to ask all developers to do this. > ... Could recommend that developers add no-transform to XHR request. > > Jo: no-transform is consistent with other things we have said in the > document. > > Francois: We've already said that elsewhere in the document. > > Jo: We said we weren't going to discuss clients and users and we are > drifting back to that. > ... In this case it may we worth saying something. > > Francois: I don't see how we can make it work. > ... How can the proxy determine that calls originate from a page if > it did not transform the page. > ... Suppose you have a web page that contains too much JavaScript to > transform. In the page there are some XHR calls. > ... The CT proxy must be consistent.. It must not transform these > XHR calls. There is no real way to detect that it is an XHR call. > ... It will work in the future. We need to worry about legacy stuff. > > Jo: Is this much of an issue. What are the chances that what comes > back is in the form that needs to be transformed? > > Francois: We may be creating an issue out of nothing. > ... Let me come up with some smarter text on that. > ... I'll come up with something along the lines of a warning about > XHR. > > Jo: I don't see anywhere in this document about what content types > the CT proxy will intervene in. > ... We should put something in about that. > > Francois: We mention content types in the list of heuristics for > determining whether a page is mobile. > > Jo: It would be interesting to learn what is left alone. > > <francois> ACTION: SeanP to send a list of content-types for which > content transformation applies [recorded in > [24]http://www.w3.org/2008/03/25-bpwg-minutes.html#action04] > > <trackbot-ng> Sorry, couldn't find user - SeanP > > <francois> ACTION: Patterson to send a list of content-types for > which content transformation applies [recorded in > [25]http://www.w3.org/2008/03/25-bpwg-minutes.html#action05] > > <trackbot-ng> Created ACTION-725 - Send a list of content-types for > which content transformation applies [on Sean Patterson - due > 2008-04-01]. > > <jo> action- 4 > > Summary of Action Items > > [NEW] ACTION: daoust to check why HTTP RFC states comments MAY be > removed from a VIA header. [recorded in > [26]http://www.w3.org/2008/03/25-bpwg-minutes.html#action01] > [NEW] ACTION: daoust to raise discussion on session settings vs > persistent settings for 2.5.1 and 2.5.3 [recorded in > [27]http://www.w3.org/2008/03/25-bpwg-minutes.html#action02] > [NEW] ACTION: Jo to raise discussion on list as to clarification of > 2.5.2 "In cases where user preferences contradict server > preferences, server preferences prevail, except where the user > specifically requires their preferences to over-rule those of the > server." [recorded in > [28]http://www.w3.org/2008/03/25-bpwg-minutes.html#action03] > [NEW] ACTION: Patterson to send a list of content-types for which > content transformation applies [recorded in > [29]http://www.w3.org/2008/03/25-bpwg-minutes.html#action05] > > [End of minutes] >
Received on Tuesday, 25 March 2008 20:49:38 UTC