09:31:43 RRSAgent has joined #bpwg 09:31:44 logging to http://www.w3.org/2009/12/10-bpwg-irc 09:31:45 RRSAgent, make logs public 09:31:46 Zakim has joined #bpwg 09:31:47 Zakim, this will be BPWG 09:31:48 ok, trackbot, I see MWI_BPWG(F2F)4:30AM already started 09:31:48 Meeting: Mobile Web Best Practices Working Group Teleconference 09:31:49 Date: 10 December 2009 09:31:54 EdC has joined #bpwg 09:32:10 DKA has joined #bpwg 09:32:14 Hi - 09:32:17 we are here - 09:32:27 Jo is having trouble getting here so we may start a bit late 09:32:34 (he is stuck somewhere in the Tube) 09:33:07 No - just shoddy workmanship as usual. 09:36:10 Agenda: http://www.w3.org/2005/MWI/BPWG/Group/Meetings/London4/logistics.html#agenda 09:40:19 Present: EdC, DKA, Sean, chaals, francois 09:40:25 Chair: DKA 09:40:36 SeanP has joined #bpwg 09:41:59 zakim, what's the code? 09:41:59 the conference code is 2794 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), DKA 09:42:57 +Vodafone 09:45:28 Present: 09:45:30 ? 09:51:50 Is there going to be a formal (i.e. recorded in minutes) discussion about the continuation of the group? I can not really follow everything that is being said right now. 09:52:03 Yes - there will be - 09:53:41 Present+ jo 09:55:03 chaals has joined #bpwg 10:02:51 francois has changed the topic to: BPWG F2F Day 2 10:03:29 Meeting: BPWG F2F - London - Day 2 10:03:42 Present+ achuter 10:04:09 eduardo can you hear that? 10:04:33 (banjos?) 10:05:11 Jo has joined #bpwg 10:07:19 eduardo can you say something? 10:07:37 zakim, who is on the phone? 10:07:37 On the phone I see +41.31.972.aaaa, Vodafone 10:07:44 zakim, aaaa is EdC 10:07:44 +EdC; got it 10:08:55 achuter has joined #bpwg 10:09:01 we can hear you (but badly) 10:15:22 -Vodafone 10:15:32 zakim, what's the code? 10:15:32 the conference code is 2794 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), DKA 10:16:06 +Vodafone 10:21:43 -Vodafone 10:23:11 +Vodafone 10:28:51 Present+ Sean, Eduardo(phone) 10:29:03 zakim, agenda? 10:29:03 I see nothing on the agenda 10:29:09 rrsagent, draft minutes 10:29:09 I have made the request to generate http://www.w3.org/2009/12/10-bpwg-minutes.html chaals 10:29:45 My prioritization: 2316+2034, then 2269, 2270, remark 406, 2318, then the rest. 10:30:45 ScribeNick: chaals 10:31:07 FD: Suggest we follow the order listed in the agenda, inserting HTTPS issues ASAP (before Chaals leaves) 10:31:13 http://www.w3.org/2005/MWI/BPWG/Group/Meetings/London4/logistics.html#agenda 10:31:26 Topic: CT last call comments 10:31:39 ok with me. Go on calling out which LC is being handled. 10:32:01 Topic: http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20091006/2289 and http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20091006/2323 10:32:22 FD: We should take a step back and see if we agree that this document is useful for the community 10:32:44 DKA: What is "imprecise terminology" in Mnot's comment? 10:33:03 FD: There was some more email clarifying this 10:33:32 SP: He gives a few examples, but doesn't clarify it completely 10:33:53 DKA: This is HTTP fundamentalism? 10:33:56 FD: Yes. 10:34:25 DKA: The problem is that reality isn't the same as what HTTP claims. This is a field manual, not an academic treatise. 10:34:41 JR: I think it is inappropriate to say MNot doesn't understand the wild 10:34:50 DKA: Sure... 10:35:24 FD: I think HTTP(bis) was chartered because the HTTP spec could be interpreted in too many different ways. In that regard we are doing similar things, imprecisely interpreting HTTP. 10:35:44 ... I think the question is whether we are really willing to push this document because we strongly believe that it is useful. 10:35:59 What are these interpretations (imprecise) that are relevant to the current work? 10:36:06 JR: I think there needs to be a sounder basis of the premise on which we are doing this, in view of the comments of Mark and Luca 10:36:28 ... right now we see egregious disregard of HTTP, and requirements that go beyond what HTTP formally allows. 10:37:15 ... we are trying to encourage people to comply with HTTP more closely. The question is are we sufficiently successful to warrant continuing the document. 10:38:45 ... the further point is that whatever we say is not the last word. It is an attempt right now to make things better right now. We are not creating new technology to answer the problem formally, we are trying to reconcile the competing objectives of "HTTP compliance is a Good THingâ„¢" but we cannot answer the requirements of application developers completely in that way. 10:39:10 ... I believe the contribution is sufficiently sound to be valuable, but I am more than willing to listen to people who do not think it is sufficiently sound. 10:39:21 s/THing/Thing/ 10:39:54 DKA: So what bits of what you said go into the document, and what bits are comment to MNot/Luca 10:40:11 Regarding imprecise terminology: this is relevant to section 2.2, but there was a decision already not to formalize the concepts further. So this might be made clear with one sentence? 10:40:13 q? 10:40:21 JR: I am not the person to answer that question... I am too close to the text 10:41:00 FD: MNot says we are too loose. We should read the document and try to be as precise as possible - either drop things or make them more precise. That is the gist of the change proposals I tried to send before coming to this meeting. 10:41:26 ... I think if we can make this as precise as possible, the document is useful 10:41:34 DKA: IF we can tighten it up, that is good. 10:42:26 FD: One way to do so is to extract requirements to build a test suite, as a way to discover what needs tightening. "THIS" shows that there are various pieces which need to be tightened. 10:42:37 DKA: Do you think those are substantive changes 10:43:01 FD: I think we will see that by going through the pieces 10:43:21 [DKA calls the dutch guys again to find out if we can make the screen and the phone work at the same time] 10:44:28 q 10:44:30 +q 10:46:11 EC: Referring to imprecise terminology - a point I had already raised in regards to 2.2 but there had been a decision not to formalise definitions... 10:46:55 s/definitions/the definitions of those concepts/ 10:47:21 ... but that decisions is not reflected clearly in the document. Maybe a sentence there would clarify that the vagueness here is a deliberate choice. 10:47:25 PROPOSED RESOLUTION: add a comment to sect 2.2 stating that these are generic concepts which we choose not to formalise further 10:47:33 +1 10:47:34 +1 10:47:52 +1 10:49:22 I note that the notion of restructuring is used in a normative statement in 4.1.5: "the user has specifically requested a restructured desktop experience" 10:49:30 -Vodafone 10:49:47 zakim, what's the code? 10:49:47 the conference code is 2794 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), DKA 10:49:54 ... so this particular definition should be as precise as possible. I think it is. 10:50:28 +Vodafone 10:51:22 We can state: anything that changes the body of the HTTP response, or any of its elements that implies a modification of the HTTP header fields listed last in RFC2616, section 13.5.2. 10:52:22 +1 10:53:24 FD: On the proposed resolution, the notion of restructuring is used in the document, referring back to this definition. So I think it should be precise, but I think it is sufficiently clear. The other concepts defined are not referred to by the document. 10:53:35 +1 10:53:48 RESOLUTION: add a comment to sect 2.2 stating that these are generic concepts which we choose not to formalise further 10:54:35 JR: Ultimately normative concepts have to be based on language, so we cannot rely on some attempt t make everything normative. 10:54:48 ... IMHO this does not represent a substantive change 10:55:27 s/IMHO/IMO/ 10:56:30 q+ 10:56:44 q- 10:57:02 JR: We have two comments. On the one hand there is too much said, in a way that is too imprecise, and on the other hand "you are not saying enough" 10:58:19 ... displeasing everyone equally might mean we are right. But there is not much more we can do to reconcile those points of view. I think that the experience of dealing with Luca suggests that nothing less than simply copying everything he says word for word will satisfy him. Noting that we are not intending to do that, I do not see that there is much point in following up the request 10:58:31 ack me 10:58:40 q+ 10:59:36 q? 11:01:36 CMN: There are some points of Luca's comment that I think we can do this. "Content Providers don't want their content messed with". Somehow assuming that they can gurantee that their content won't be altered is unrealistic, so we can dismiss that point. His statement about telcos avoidiung liability is out of scope in a techincal document. This document does not describe how mobile develops... 11:01:38 ...should develop apps so the first point is irrelevant to the document at hand. 11:01:55 q+ 11:02:00 DKA: surely it is for developers 11:02:37 q+ 11:02:54 ack edc 11:02:58 CMN: no it is not it is for transformation deployments. Developers can infer the behaviour that platofrms will exhibit 11:03:09 EC: A few comments... 11:03:13 s/platofrms/platforms/ 11:03:13 ack edc 11:03:40 ... regarding the comment "it is not good for content owners", 'not quite'. We will see that under testing. 11:04:14 ... Arguing that it is a technical document and liability is out of scope is debatable. Laws on liability refer to technical ways of protecting content. 11:04:28 ... "The document is not for developers" is a kind of sophistry. Of course it is. 11:04:30 q+ 11:05:06 PROPOSED RESOLUTION: Have the document make explicit, if it does not do so sufficiently already, that moral and legal questions are out of scope 11:05:10 ... otherwise why would we explain how developers can ensure that their content is handled a specific way by content transformation proxies 11:05:12 ack cha 11:07:01 CMN: Refine document is not for developers comment. Luca's comment is predicated on his assumption that developers can guarantee a certain treatment of their content. Doc is not about that it's about how devs can request specific treatment, and a request that proxies respect thsoe requests. They can't be guaranteed - so this isn't guaranteeing the platform that Luca would like to have. 11:08:17 DKA: I think that a lot of this stuff is outside the realm of current laws. It has nothing to do with anything we can talk about it here. 11:09:16 PROPOSED RESOLUTION: Have the document make explicit, if it does not do so sufficiently already, that moral and legal questions are out of scope and that this group does not ahve the authority or expertise to comment one way or another about setting precent or authorising any specific behavior or its absence. 11:09:22 i/DKA/CMN: I think the decision to avoid trying to make statements based on a clear understanding of the current and future legal systems of all the jurisdictions in which the Web is used would be a pointless exercise/ 11:09:46 EC: That is reasonable. Please put an explicit sentence in the document. 11:09:58 +1 11:10:00 +1 11:10:07 +1 11:10:07 DKA: We're not lawyers. It isn't clear that we have the expertise to do this 11:10:12 +1 11:10:16 +1 11:10:56 q? 11:11:23 CMN: It isn't a question of authority and expertise, it is simply an unrealistic aim 11:11:31 JR: So add that it is an unrealistic aim? 11:11:36 CMN: sure 11:11:54 No. There are IPR laws, so we could refer to normative specs (legal ones that is). 11:12:48 Proposed RESOLUTION: Have the document make explicit, if it does not do so sufficiently already, that moral and legal questions are out of scope and that this group does not have the authority or expertise to comment one way or another about setting precedent or authorising any specific behavior or its absence - nor is such a task feasible in this group. 11:13:03 q+ 11:13:25 ack ed 11:13:31 JR: Do we want to add further clarity that this is not an answer to all the world's problems, but an attempt to provide guidance towards ameliorating a bad situation 11:13:58 EdC: I wouldn't say that. Would you say "this document was produced by lazy slobs who didn't work out the problem?" 11:14:33 ... the only requirement is to state what is important about this document. That it is based on the state at a point in time and may need to be refined in the future, rather than being the last word on the topic. 11:14:44 JR: "Is unlikely to be the last word on the topic" 11:14:49 SP: We say that, right? 11:15:00 JR: Sure. We could say it until it swamps the document... 11:15:09 SP: Do not think we need more disclaimers 11:15:33 +1 11:15:37 +1 11:15:40 +1 11:15:44 +1 11:15:45 +1 11:15:52 +1 11:15:55 RESOLUTION: Have the document make explicit, if it does not do so sufficiently already, that moral and legal questions are out of scope and that this group does not have the authority or expertise to comment one way or another about setting precedent or authorising any specific behavior or its absence - nor is such a task feasible in this group. 11:16:22 [CMN notes that "precedent" refers to "legal precedent"] 11:16:42 PROPOSED RESOLUTION: Editor to add further text to scope section along lines of his earlier minuted statement and Eduardo's recapitualtion of it above 11:16:45 [... and authorising is used in a legal rather than technical sense here] 11:17:20 [.. and stating that "while there is indeed a body of IPR laws, the group does not have...] 11:18:03 +1 11:18:04 +1 11:18:06 SP: Isn't that implied already? 11:18:13 FD: Yeah, but this is about being explicit 11:18:22 RESOLUTION: Editor to add further text to scope section along lines of his earlier minuted statement and Eduardo's recapitualtion of it above 11:18:46 JR: So, response to Luca and MNot 11:19:06 DKA: Don't we need to go through FD's precision stuff before responding to MNot? 11:19:26 FD: Should create specific comment issues in tracker based on Mark's stuff. 11:19:34 should we not recapitulate the LC and summarize answers to all of them at the end of the session? 11:19:47 ACTION: Francois to enter specific issues from Mark into tracker, due now 11:19:48 Created ACTION-1027 - Enter specific issues from Mark into tracker, due now [on François Daoust - due 2009-12-17]. 11:19:59 I would prefer to handle the concrete issues first. 11:20:40 q+ 11:21:29 ack edc 11:22:04 EC: Let's deal with the concrete issues rather than trying to formalise something that may change based on what we discuss afterwards? 11:22:52 [I just created LC-2327, LC-2328 and LC-2329 for ACTION-1027] 11:25:14 [fire alarm. Instructions are *not* to leave... but we are taking a break anyway] 11:25:55 -EdC 11:30:06 +EdC 11:31:08 -EdC 11:31:30 EdC has joined #bpwg 11:40:16 EdC has joined #bpwg 11:43:33 François. please note that there are no trackers for 2034 and 2036 (listed in the agenda). 11:55:45 +EdC 11:56:52 EdC, I'll update the broken links, that's because the comments applied to the previous version of the spec: 11:56:54 http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20080801/2034 11:56:57 http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20080801/2036 11:58:23 Present+ PhilA 12:00:46 Scribe: SeanP 12:01:18 [back from enforced break due to fire alarm] 12:01:32 phila has joined #bpwg 12:01:48 Jo: We've decided that we have enough to answer Luca's comments. We will defer comming up with a response to Mark's comment until we've covered the rest of the comments. 12:03:16 Francois: Let's talk about the content tasting comments? 12:03:21 -> http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20091006/2321 LC-2321 12:03:29 ->http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20091006/2324 LC-2324 12:03:33 s/comments?/comments 12:03:38 -> http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20080801/2036 LC-2036 12:05:18 Which exact section is being discussed here? Only 4.1.5.1 ? 12:05:44 Francois: My suggestion is to remove the first part of 4..15.1. Remove the phrase about "theoretical idempotency" and put something in that some servers have trouble with dup requests. 12:06:15 s/4..15.1/4.1.5.1 12:06:31 s/4..15.1/4.1.5.1/ 12:06:57 EdC: Why is the "theoretical idempotency" a problem? 12:07:23 Jo: The server statistics could get messed up. 12:07:40 From RFC2616, sec 9.1.2: 12:07:44 However, it is possible that a sequence of several requests is non- 12:07:44 idempotent, even if all of the methods executed in that sequence are 12:07:44 idempotent. (A sequence is idempotent if a single execution of the 12:07:44 entire sequence always yields a result that is not changed by a 12:07:44 reexecution of all, or part, of that sequence.) For example, a 12:07:44 sequence is non-idempotent if its result depends on a value that is 12:07:47 later modified in the same sequence. 12:07:49 Francois: I'm not sure we're solving any specific problem, so we should go along with the commenters. 12:08:12 Jo: We could just delete this whole section. 12:08:48 [Choices for 4.1.5.1: 12:08:53 - remove the whole section 12:09:01 - remove the first normative statement 12:09:05 Jo: Eduardo, what would you like to see changed about this section? 12:09:18 q+ 12:09:34 ... and rephrase the incriminated "theoretical idempotency" sentence is less affirmative form] 12:09:47 ack SeanP 12:11:58 PROPSOED RESOLUTION: Remove initial part of sect 4.1.5.1 up to "such content" - i.e. Proxies should avoid issuing ... and specifically should not on a routine basis, other than as desribed in 4.1.5 and 4.2.6 issue duplicate requests for comparison purposes 12:12:12 Sean: It seems like the main part is that proxies should not issue duplicate requests for comparison purposes. 12:13:35 PROPSOED RESOLUTION: Remove initial part of sect 4.1.5.1 up to "such content" - i.e. Proxies should avoid issuing ... and specifically should not on a routine basis, other than as desribed in 4.1.5 and 4.2.6 issue requests for the same resource for comparison purposes 12:14:14 Francois: The objection was about the phrase "theoretical idempotency" and the other objection is that saying that proxies should not issue duplicate requests forbids sending a request with the unaltered headers and then sending a request with the altered headers. 12:14:43 EdC: Does "duplicate requests" mean exactly the same request twice? 12:15:15 Francois: That's a good point. Should clarify that. 12:16:08 PROPSOED RESOLUTION: replace 4.1.5.1 with:. Other than to respect 4.1.5 and 4.2.6 proxies should avoid making repeated requests for the same resource and should not on a routine basis, issue requests for the same resource for comparison purposes 12:16:53 PROPSOED RESOLUTION: replace 4.1.5.1 with:. Other than to respect 4.1.5 and 4.2.6 proxies should avoid making repeated requests for the same resource 12:18:42 Francois: What is it we are trying to say here. 12:19:14 Jo: We're saying that if you think you know or should know the result, then don't re-request it. 12:19:48 Chaals: If you think you know, then why re-request? 12:19:57 Jo: They have done it. 12:20:19 For comparing the results, as stated in the initial resolution proposal. Why compare results? Ask the proxy implementors about it... 12:21:11 PROPOSED RESOLUTION: replace 4.1.5.1 with:. In complying with 4.1.5 and 4.2.6 proxies should, where possible, avoid making repeated requests for the same resource using the same headers 12:21:41 It does not make much sense, does it? 12:21:58 Francois: It is not repeated requests with the same headers; it is requests for the same resource. 12:22:33 ...Shouldn't send multiple requests for the same resource just to compare. 12:23:06 ...Sending the same request with the same headers has nothing to do with transcoding. 12:23:22 Why would you actually duplicate a request? Except if the idempotency is not respected by the server, of course, you will receive a duplicate, i.e. identical (up to timestamps), response. 12:23:53 PROPOSED RESOLUTION: replace 4.1.5.1 with:. In complying with 4.1.5 and 4.2.6, when forwarding a request, proxies should minimize making repeated requests for the same resource 12:24:18 Proposed Resolution: Delete 4.1.5.1 12:24:26 Not testable -- except if minimize == make no repeated requests. 12:24:52 I liked the original proposal Other than to respect 4.1.5 and 4.2.6 proxies should avoid making repeated requests for the same resource and should not on a routine basis, issue requests for the same resource for comparison purposes 12:25:10 Sean: In section 4.1.1 we also say that multiple requests for the same resource can be sent. 12:25:28 Chaals: I have another proposal: delete 4.1.5.1 12:25:34 no. 12:25:40 DKA: I don't support that. 12:26:32 DKA: We want to avoid substantive changes to avoid another last call. 12:27:58 Chaals: You're saying avoid making repeated requests to the server? I can live with that. It's fairly untestable. 12:28:18 Jo: We need to recognize what Luca is saying. We don't want to contradict ourselves. 12:29:39 PROPOSED RESOLUTION: While complying with sects 4.1.5 and 4.2.6 proxies should minimise requests to the server. 12:29:57 +1 (but agree with chaals about testability) 12:30:01 minimize == ? How to test it. 12:30:09 testable, scmestable 12:30:38 s/testable, scmestable// 12:30:40 Phil: Are we trying to produce testable guidelines? 12:30:49 DKA: Ideally, yes. 12:31:01 Francois: We receive comments about that. 12:31:09 Well, we tried to enforce testability so far. 12:31:16 We should continue in this way. 12:31:30 DKA: It is testable if you are sending the same request for the same resource with the same headers, then it is testable. 12:31:50 Chaals: We are no longer saying that. 12:31:51 q+ 12:32:00 ack ed 12:32:06 DKA: It's a "should" not a "must". 12:33:43 EdC: The proposed resolution doesn't say anything about avoiding requests for the "same resource". 12:34:03 PROPOSED RESOLUTION: While complying with sects 4.1.5 and 4.2.6 proxies should avoid making repeated requests for the same resource. 12:34:09 ...About "minimise": what are you going to compare it with? 12:34:36 +1 (but still hard to test) 12:35:26 Jo: It's one of those things "I'll know it when I see it". You can tell when a proxy is making to many requests, but it is hard to define. 12:36:17 EdC: "Minimize" says that proxies should optimize as much as possible; compared to what? 12:37:26 Francois: In the conformance statement, CT operators would need to say how they are minimizing. 12:37:49 ...We could just remove the paragraph. 12:37:58 PROPOSED RESOLUTION: While complying with sects 4.1.5 and 4.2.6 proxies should avoid making repeated requests for the same resource. 12:38:01 +1 12:38:05 +1 12:38:12 +1 (and still hard to test) 12:38:23 Jo: That would ignore one of the few data points that we have: multiple requests have been sent. 12:39:14 DKA: What is your objection? 12:40:03 Chaals: It is not testable. It's not clear that the justification for sending multiple requests would be a valid reason. 12:40:27 ...everyone has a reasonable justification for what they do. 12:40:34 Yes, but this is an argument against all SHOULD as well... 12:41:14 Francois: We could take this resolution; we could add a section to the document that the feature was at risk. 12:41:24 Jo: It's too late for that. 12:41:33 Francois: Yes, your right. 12:42:02 So, has the poll been taken? 12:42:37 DKA: Chaals can you live with it? 12:43:05 Chaals: I can live with it, but we'll get comments that say this is meaningless. 12:45:01 Jo: I think we need to say more than "think and behave courteously". 12:45:08 q+ 12:45:21 ack ed 12:46:04 EdC: Wasn't the original justification for the sentence to avoid mult requests for comparison purposes. 12:47:26 Jo: We seem to be saying other than to make comparisons, don't issue mutiple requests for comparison purposes. 12:47:48 Chaals: Unclear guidelines won't help the web. 12:47:53 which indeed sounds odd. 12:48:06 [which I agree is unclear] 12:48:33 DKA: How about you should only make repeated requests to satisfy 4.1.5 and 4.2.6? 12:48:48 Chaals: Doesn't change the semantics of the statement. 12:48:56 Francois: I think that does help. 12:49:11 I think this goes into the right direction, though it is just a step. 12:50:11 proxies should only make repeated requests for the same resource in the context of complying with 4.1.5 and 4.2.6 12:51:58 Francois: Mark's comments are that proxies already send repeated requests. 12:52:54 Chaals: What we should do is recommend that proxies not send unnecessary multiple requests, but not as a requirement. 12:53:49 Phil: Is this more normative than the BP? 12:54:13 Francois: Yes, this is a normative document. 12:57:36 PROPOSED RESOLUTION: Change 4.1.5.1 to say: Content providers have found unnecessary repeated requests for the same resource operationally difficult, so proxies should (non normative) take steps to respect this and as far as possible minimise requests. The working group has not found a meaningful way to make a normative requirement around this stated objective. 12:59:49 Phil: I've never seen a spec that says something like that: We don' know how to work out what we want to say. 13:00:10 DKA: Let's table this and come back to it? 13:00:50 We identify a problem (...operationally difficult...) but we state we are not solving it? 13:00:50 +1 to what Dan just said 13:00:51 PROPOSED RESOLUTION: While complying with sects 4.1.5 and 4.2.6 proxies should avoid making repeated requests for the same resource. 13:01:04 +1 13:01:06 +1 13:01:13 (to Jo's +1 of my +1) 13:01:14 s/just said/just said as scribed below 13:01:34 RESOLUTION: While complying with sects 4.1.5 and 4.2.6 proxies should avoid making repeated requests for the same resource. 13:02:47 Scribe: Phil 13:02:53 ScribeNick: PhilA 13:02:57 PROPOSED RESOLUTION: Ref. LC-2321 and LC-2036, resolve partial, noting that we do not talk about "theoretical idempotency of GET requests" anymore, but that we are still advising to reduce the number of requests sent for the same resource. 13:03:18 +1 13:03:21 +1 13:03:31 +1 13:03:40 RESOLUTION: Ref. LC-2321 and LC-2036, resolve partial, noting that we do not talk about "theoretical idempotency of GET requests" anymore, but that we are still advising to reduce the number of requests sent for the same resource. 13:03:45 +1 13:04:12 -> http://lists.w3.org/Archives/Public/public-bpwg-comments/2009OctDec/0067.html reply to LC-2036 13:04:45 PROPOSED RESOLUTION: Ref. LC-2324, resolve yes, the inconsistency was removed in 4.1.5.1 13:04:48 FD: Mar's comment says more than he said in LC-2036 13:04:56 s/Mar's/Mark's 13:05:01 +1 13:05:18 +1 13:05:39 +1 13:05:41 RESOLUTION: Ref. LC-2324, resolve yes, the inconsistency was removed in 4.1.5.1 13:06:22 See that? We just resolved yes to a comment from Luca http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20091006/2324?cid=2324 13:07:20 Jo: So in addition to the text we just areed, should we add an explanatory note so that we can say to Mark that we agree 13:07:28 s/See that? We just resolved yes to a comment from Luca http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20091006/2324?cid=2324// 13:07:34 s/areed/agreed/ 13:07:56 s/See that? We just resolved yes to a comment from Luca// 13:09:32 PROPOSED RESOLUTION: In addition to above add a note to 4.1.5.1 stating that while HTTP does not prohibit repetition of GET requests servers find this troublesome and so it should be avoided 13:10:15 +1 13:10:16 should as SHOULD ? 13:10:53 this is a note, so inherently non normative, I think, but indeed for clairty that is should (non normative) 13:11:17 +1 13:11:19 +1 13:11:22 +1 13:11:25 RESOLUTION: In addition to above add a note to 4.1.5.1 stating that while HTTP does not prohibit repetition of GET requests servers find this troublesome and so it should be avoided 13:11:27 +1 13:12:54 replace troublesome in the above with p"places an unnecessary load on the network and server" 13:13:25 PhilA: That makes more sense, yes. 13:13:27 Not just that, if I understand correctly the comments; they also might confuse some servers. 13:13:58 edc: yes but we can't state this precisely 13:14:06 s/:/-? 13:14:41 SeanP has joined #bpwg 13:15:02 RESOLUTION: Rephrase previous resolution (In addition to above add a note to 4.1.5.1 stating that while HTTP does not prohibit repetition of GET requests servers find this troublesome and so it should be avoided) to talk about places an unnecessary load on the network and server and not 'troublesome'. 13:15:42 What about this -- distorts statistics about traffic. 13:16:13 Chaals who just left said "that's not a problem" when I raised it earlier, EdC 13:16:32 FD: Suggest we jump to LC-2316 http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20091006/2316?cid=2316 13:17:01 fwiw I don't agree with Chals on tis (as in so much else :-) ) but think the text is sufficient as it stands 13:17:14 ... and response to LC-2034: http://lists.w3.org/Archives/Public/public-bpwg-comments/2009OctDec/0067.html 13:17:54 Regarding 2316, intervene can be a) modify HTTP header fields b) modify body c) modify method. 13:18:04 We have a reply from Mark Baker that we list the methods that a proxy may play with and he's saying it's unnecessarily restrictive 13:18:21 ... MNot says the server shouldn't intervene and should always behave transparently 13:19:03 ... the argument as ever is that we shouldn't restrict ourselves 13:19:36 Jo: We have scoped this to talk about traditional web browsers and we say that proxies shouldn't mess around with non-traditional web browsers 13:20:08 Jo: PUT is a bit of a problem... 13:20:21 Sean: MNot may be misunderstanding the scope of the document 13:20:46 FD: Maybe we should just say that the scope is just GET nad HEAD 13:21:00 DKA: Maybe we should say that proxies should be transparent to PUT? 13:21:13 DKA: Could we add to 1.3 scope that clarifies the scope? 13:21:18 Jo: We don't need to 13:21:55 What is the detailed issue with PUT? I just could not hear. 13:23:16 So is the opinion here to delete the very first sentence of 4.1.1? 13:23:29 ed, no 13:23:37 PROPOSED RESOLUTION: We add language calling out HEAD, POST, and GET methods as being in scope into the Scope section. 13:23:55 we are saying that the scope of the document is Web browsing and that PUT is not part of that 13:24:37 q+ 13:25:52 ack edc 13:26:00 FD: If we take the resolution -which I agree with then that makes the whole thing moot 13:26:25 EdC: There is a difference between the proposed resolution and what is in the doc now 13:27:05 ... the proposer resolution means only POST HEAD and GET are in scope and everything else is out of scope and I'm not sure that's what's intended? 13:27:30 FD: Yes it is. And I think that's what Mark and Mark are saying. We will therefore avoid restricting other HTTP methods 13:27:51 FD: WE don't want to play with options, for example, as the body is not defined 13:28:35 +1 to the resolution 13:28:41 s/for example/for example with an OPTIONS response/ 13:29:09 DKA: I retract my proposed resolution since it's already in the document 13:29:51 Jo: We used to say 'unless you're sure it's traditional web browsing, don't mess with it' Then we realised that's not realistic 13:30:12 ... then we said don't mess with anything other than GET POST and HEAD. 13:30:44 ... Mark & Mark would be happy with saying 'this doc only applies to GET POST & heAD'. 13:30:52 Jo: Would you be nhappy if we said that? 13:31:08 s/nhappy/unhappy/ 13:32:05 Eduardo - can you live with us scoping the document to GET POST and HEAD. 13:32:29 Sean: I can live with it since we really haven't thought about other things 13:32:57 EdC: Are there any generic references to HTTP Methods? 13:33:01 DKA: 4.1.1 13:33:06 EdC: That's the only place 13:33:18 ... look at 4.2.1 as well 13:33:48 FD: It's symmetry since one is about requests and one about responses 13:34:04 Jo: this is a substantive change 13:35:10 DKA: How can we change the sentence about PST GET and HEAD to say that those that do handle such methods do so outside the scope of this document 13:35:54 Jo: How about this (we wait...) 13:37:08 General question -- it is possible to define PUT methods in forms within web pages, is it? Are there browsers that do not respect this? 13:37:46 Jo: Call this casuistry ... if the scope of the doc is traditional web browsing, we find that comments about 4.1.1 and 4.2.1 allow us to change the doc without it being a substantive change as it's out of scope. 13:38:17 edc - I thought not - let's check 13:39:10 not in HTML 4.0.1, checking others... 13:39:25 HTML 4.0.1 only accepts post and get. Checking HTML 5.0, XHTML... 13:39:42 Jo: if HTML does not provide a mechanism for PUTting a form then PUT is out of scope 13:39:47 FD: What, like HEAD? 13:39:53 Jo: Ah... 13:40:49 -> http://www.w3.org/TR/html4/interact/forms.html#adef-method Form possible methods in HTML4 13:40:58 FD: I'm fine with the scope being HEAD GET and POST 13:41:25 FD: It doesn't change anything with the proposed resolution 13:41:37 PROPOSED RESOLUTION: While complying with sects 4.1.5 and 4.2.6 proxies should avoid making repeated requests for the same resource. 13:42:02 Jo: The binding between HTMl and HTTP is unspecified 13:42:04 PROPOSED RESOLUTION: We add language calling out HEAD, POST, and GET methods as being in scope into the Scope section. 13:42:06 FD: true 13:43:18 XHTML 1.1 -- only post, get. 13:43:36 PROPOSED RESOLUTION: Remove scoping statements from 4.1.1 and 4.2.1 on the basis that these are redundant; add a note in the scope section that the scope of the document is EAD, POST, and GET methods. 13:44:03 WML 1.3 -- only post, get. 13:44:14 PROPOSED RESOLUTION: Remove scoping statements from 4.1.1 and 4.2.1 on the basis that these are redundant; add a note in the scope section that the scope of the document is HEAD, POST, and GET methods. 13:45:04 PROPOSED RESOLUTION: Remove scoping statements from 4.1.1 and 4.2.1 on the basis that these are meaningless recapitulation; add a note in the scope section that the scope of the document is EAD, POST, and GET methods. 13:45:04 FD: Why redundant? 13:45:27 PROPOSED RESOLUTION: Remove scoping statements from 4.1.1 and 4.2.1 on the basis that these are meaningless recapitulation; add a note in the scope section that the scope of the document is HEAD, POST, and GET methods. 13:45:30 Why EAD again. 13:46:01 Jo: I don't think we should specify the methods we talk about as that could open unnecessary comments 13:46:01 PROPOSED RESOLUTION: Remove scoping statements from 4.1.1 and 4.2.1. 13:46:18 Serious problem -- HTML 5.0: 13:46:20 The method and formmethod content attributes are enumerated attributes with the following keywords and states: 13:46:20 The keyword GET, mapping to the state GET, indicating the HTTP GET method. 13:46:20 The keyword POST, mapping to the state POST, indicating the HTTP POST method. 13:46:20 The keyword PUT, mapping to the state PUT, indicating the HTTP PUT method. 13:46:20 The keyword DELETE, mapping to the state DELETE, indicating the HTTP DELETE method. 13:46:40 Hey, I just consult the standards... 13:47:22 +1 13:47:25 +1 13:47:30 +1 13:47:35 RESOLUTION: Remove scoping statements from 4.1.1 and 4.2.1. 13:47:37 PROPOSED RESOLUTION: Remove scoping statements from 4.1.1 and 4.2.1. as they are unnecessary given the scoping statement in 1.3 13:48:06 q+ 13:48:14 ack ed 13:48:16 ack ed 13:49:25 Jo: We're removing first sentence of 4.1.1 and 4.2.1. This is a non substantive change on the basis that 1.3 (scope) already covers this. We're not saying anything about specific methods 13:49:37 rrsagent, draft minutes 13:49:37 I have made the request to generate http://www.w3.org/2009/12/10-bpwg-minutes.html phila 13:49:44 Jo: What is the response to the comments? 13:50:05 DKA: I think it' resolved partial as we are making a clarification 13:50:31 PROPOSED RESOLUTION: ref. LC-2316, resolve yes, we have removed the mention of HTTP methods in 4.1.1 and 4.2.1 13:51:05 PROPOSED RESOLUTION: ref. LC-2316, resolve yes, we have removed the mention of HTTP methods in 4.1.1 and 4.2.1 because they are not in scope of this document as stated in 1.3. 13:51:07 Jo: can we say "because they're not in scope, as stated in 1.3?" 13:51:30 +1 13:51:38 +1 13:51:41 It is not that they are not in scope (some are), it is that the scope is dealt with in 1.3 ! 13:51:55 +1 13:52:02 RESOLUTION: ref. LC-2316, resolve yes, we have removed the mention of HTTP methods in 4.1.1 and 4.2.1 because they are not in scope of this document as stated in 1.3. 13:52:12 PROPOSED RESOLUTION: ref. LC-2034, resolve yes, we have removed the mention of HTTP methods in 4.1.1 and 4.2.1 because they are not in scope of this document as stated in 1.3. 13:52:44 (edc agree) 13:54:05 PROPOSED RESOLUTION: ref. LC-2034, resolve yes, we have removed the mention of HTTP methods in 4.1.1 and 4.2.1 because it is unnecessary to mention this in this document. 13:54:40 which is scoped to traditional web browsing 13:54:54 With the addendum by Jo, it seems ok. 13:58:37 PROPOSED RESOLUTION: ref. LC-2034, resolve yes, we have removed the mention of HTTP methods in 4.1.1 and 4.2.1 because it is unnecessary to mention this in this document which is scoped to traditional web browsing. 13:59:05 +1 13:59:07 +1 13:59:08 +1 13:59:15 RESOLUTION: ref. LC-2034, resolve yes, we have removed the mention of HTTP methods in 4.1.1 and 4.2.1 because it is unnecessary to mention this in this document which is scoped to traditional web browsing. 14:00:09 10 minute break 14:00:11 -- 10 min break -- 14:00:18 rrsagent, draft minutes 14:00:18 I have made the request to generate http://www.w3.org/2009/12/10-bpwg-minutes.html phila 14:01:08 -EdC 14:12:59 EdC has joined #bpwg 14:14:29 DKA: Next LC-2317 http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20091006/2317?cid=2317 14:14:33 +EdC 14:14:43 -> http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20091006/2327 LC-2327 14:15:01 FD: And we have LC-2327 http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20091006/2327?cid=2327 14:15:08 FD: COmplaint is about imprecise language 14:16:26 FD: Explains the problem in more detail. A 406 response does not mean that the server hasn't processed the request 14:16:32 Sean: That doesn't make sens 14:16:44 FD: It says the response is unacceptable 14:16:49 DKA: But I did it anyway?? 14:17:13 DKA: Are you saying that your understanding of HTTP is in alignmnt with that? 14:17:16 Strictly speaking, it means (from RFC2616): The server understood the request, but is refusing to fulfill it. 14:17:28 FD: Yes. And I don't think this brings a lot to teh doc. If it's a problem, let's just remove it 14:17:45 Sean; 406 is pretty rare, right? 14:17:54 FD: yes in practce no one sends a 406 14:17:58 PROPOSED RESOLUTION: Remove language on issuing repeated POST requests on 406 responses and resolve yes on LC-2327. 14:18:10 ... and secondly I can't see where a proxy would want to repeat a POST request 14:18:36 D: Let's stick with proxy must not repeat a POST request when received a 406 14:18:48 Jo: This is again in response to real world situations 14:18:55 s/D:/FD:/ 14:19:25 Jo and Francois continue discussion 14:20:08 Sean: This is so unlikely 14:20:10 FD: yes 14:20:18 ... that's why I think we can remove it 14:20:38 Where does RFC2616 state that repeating a POST on 406 is disallowed? This is the case for 403, but I cannot find it for 406. 14:21:06 PROPOSED RESOLUTION: replace final paragraph in 4.1.5.2 with "A proxy MUST NOT reissue a POST request". 14:21:41 (The guidelines could be fine-tuned to say "In accordance with the HTTP RFC" or to add "even with altered HTTP headers". 14:21:53 +1 14:21:59 +1 14:22:13 +1 14:22:54 RESOLUTION: replace final paragraph in 4.1.5.2 with "A proxy MUST NOT reissue a POST request". 14:23:11 s/RESOLUTION: replace final paragraph in 4.1.5.2 with "A proxy MUST NOT reissue a POST request".// 14:23:41 Jo: It looks as if HTTP does not specify a way to say that a post was not actioned 14:25:10 Jo: I think it's probably unsafe to take this resolution 14:25:19 DKA: Can you live with it? 14:25:29 where does the danger lurk? 14:25:48 FD: Should we strike the whole paragraph? 14:26:01 What is the issue? 14:26:10 FD: I think we should clarify the doc as much as possible 14:26:19 DKA: Yes but what are saying about this thing? 14:27:02 DKA: You want to rephrase to say that a proxy shouldn't issue a repeated POST request without alerting the user? 14:27:15 rrsagent, draft minutes 14:27:15 I have made the request to generate http://www.w3.org/2009/12/10-bpwg-minutes.html phila 14:27:27 I think that saying that it MUST not reisuuse a POST is contrary to HTTP - probably best to say MUST NOT without informing the user of the possible consequences 14:28:32 informing and giving a choice to the user, or just telling him "this may be bad, hold on while I do it" ? 14:28:55 solicit the users approval is what I meant, though did not say so explicitly 14:29:32 Sean: would this also apply if the user went back? 14:29:41 I note we will have to go back to the notion of "user interaction" as it is defined in several places in the spec. 14:29:42 Jo: That's a browser function 14:29:59 Sean: yes but the proxy would be re-issuing the same request 14:30:34 Not exactly the same, I gather. To the same resource with the same arguments, but with different HTTP header fields. 14:32:01 the point, I think, Edc, is that a 406 response does not indicate that the original POST has not beein actioned 14:33:56 Well, this is what it states: The resource identified by the request is only capable of generating response entities which have content characteristics not acceptable according to the accept headers sent in the request. 14:33:56 Unless it was a HEAD request, the response SHOULD include an entity containing a list of available entity characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. 14:34:35 FD: Can we say that a proxy shouldn't reissue a POST request and check it with MNot? 14:34:54 edc: The action performed by the POST method might not result in a 14:34:56 resource that can be identified by a URI. In this case, either 200 14:34:57 (OK) or 204 (No Content) is the appropriate response status, 14:34:58 Now are you stating that the server would go in a mode where it first applies side-effects and then attempts to generate content just to find out it cannot do so with an appropriate format? 14:34:59 depending on whether or not the response includes an entity that 14:35:01 describes the result. 14:35:31 we are only responding to MNot's comment about the semantic of 406 14:36:22 Comment is: "e.g. it allows retrying a POST request upon a 406, even though this isn't allowed in HTTP." 14:36:50 I don 't see a reference in HTTP where it is not allowed, but he is the expert 14:36:58 Well, as I said, this is true for 403, but I cannot find anything conclusive about such a prohibition for 406. 14:37:15 edc - agree 14:37:46 but equally 406 doesn't specifically mean that the change had not been applied 14:40:20 Further discussion around the topic continues 14:40:45 Jo begins to come to a conclusion 14:41:01 OK, so the situation is that repeating a POST might have unintended (cumulative) side effects. On the other hand, a 406 response SHOULD include a list of alternative resources to select from. So couldn't the CT proxy deal with that -- i.e. either select the best one, or failing which, sending back a generic "no response available" to the client? 14:41:05 Jo: apologises for taking so long but having discussed around the subject I now agree with the resolution. 14:41:11 FD: Ah but I disgree with it now 14:41:47 ... (kidding) 14:42:06 edc - this discussion is limited to 406 in response to a POST 14:42:48 indeed, but 406 applies to POST as well: Unless it was a HEAD request, the response SHOULD include an entity 14:42:48 containing a list of available entity characteristics and location(s) 14:42:48 from which the user or user agent can choose the one most 14:42:48 appropriate. 14:43:47 PROPOSED RESOLUTION: replace final paragraph in 4.1.5.2 with "A proxy MUST NOT reissue a POST request as it is unsafe (see section 9.1.1 of RFC 2616)" 14:44:09 +1 14:44:11 right, but then reissuing the POST is still not right 14:44:24 +1 14:44:55 +1 14:44:59 s/right/edc, right/ 14:45:01 I was not sure whether the topic was 406 as such, or being allowed to reissue a POST, or whether it was safe. It's ok now. 14:45:13 +1 14:45:16 RESOLUTION: replace final paragraph in 4.1.5.2 with "A proxy MUST NOT reissue a POST request as it is unsafe (see section 9.1.1 of RFC 2616)" 14:45:18 +1 14:45:53 PROPOSED RESOLUTION: ref. LC-2327, resolve yes, and note that we have removed the exception. 14:46:08 +1 14:46:12 +1 14:46:15 +1 14:46:17 RESOLUTION: ref. LC-2327, resolve yes, and note that we have removed the exception. 14:46:28 +1 14:46:51 -> http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20091006/2269 LC-2269 14:47:06 LC-2269 from EdC http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20091006/2269?cid=2269 14:47:26 FD: it's about avoiding interference with MIME type changes 14:47:37 s/changes/exchanges 14:47:47 s/MIME type/data MIME type 14:48:00 scribe: francois 14:48:22 given that we are in substantive changes already I agree with Edc and further think a note is needed to watch out for new MIME types as circumstances move on 14:48:28 -Vodafone 14:48:42 Basically, the problem is acknowledged in 4.1.3. Unfortunately, there is no guidance about how to do it with two important applications based on HTTP. 14:49:01 zakim, code? 14:49:01 the conference code is 2794 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), DKA 14:49:30 PROPOSED RESOLUTION: Adopt the additional MIME types suggested by EdC and make note about this list not being complete 14:49:33 With respect to the original comment on SOAP, proxies should handle as SOAP forwarding proxies (SOAP specs, 2.7.2). 14:49:42 +Vodafone 14:49:53 ref soap - it's out of scope 14:49:53 These allow some manipulations that transparent proxies do not perform. But they are defined in a standard. 14:50:19 This is a similar point as with WAP gateways (they can perform some standard manipulations). 14:50:56 this is about Web browsing as previously discussed, not SOAP or WAP or Thought Transference or ... 14:51:18 +1 to Jo 14:51:52 [[ List of proposed MIME types: 14:51:52 application/json 14:51:52 application/xml 14:51:52 text/xml 14:51:52 application/soap+xml 14:51:53 application/soap+fastinfoset 14:51:54 application/fastsoap 14:51:56 application/fastinfoset 14:52:00 ]] 14:52:39 mea culpa, as previously discussed ad nauseam, pls srike application/xml from the list 14:52:43 francois: I think we should remove application/xml and text/xml as previously discussed. 14:52:57 ... They may be used to serve XHTML content, even though this is not encouraged. 14:53:34 sean: Where would this go? In 4.2.9? 14:54:02 francois: We need to discuss the SHOULD/MUST level, as EdC suggests that it should be a MUST. 14:54:30 (and they do not exactly fit into the list of "Internet Content Types associated with Mobile Content") 14:54:56 jo: aren't they out of scope? They're not associated with traditional Web browsing. 14:54:58 (although... It is Internet content, though not browsing). 14:55:18 dka: they can't be out of scope because Web applications more and more involve JSON parsing. 14:55:35 But they are carried over HTTP (raw) and this is acknowledged as a problem in 4.1.3. 14:56:27 jo: on that basis, almost any kind of MIME type could be listed here. 14:57:26 dka: no, we're just listing MIME types that are commonly associated and used with data exchanges. 14:57:50 jo: isn't XHTML extensible so that it can be used to transport data? 14:58:11 AJAX is becoming widespread -- as elements of Web pages and applications. 14:59:03 francois: I agree that we cannot address the XHTML case that is common: retrieving some XHTML fragment and including it in the page. 14:59:13 jo: I think we are opening a can of worms here. 14:59:40 Is this specific XHTML case not homologous to the types application/xml text/xml ? 14:59:55 sean: This would naturally fit in 4.1.3 15:00:11 francois: 4.1. is about HTTP requests, 4.2 is about HTTP responses. This should go to 4.2 15:00:46 Wait. Do AJAX pages not send also snippets to servers? 15:00:58 In this situation, it applies both to request and response. 15:01:30 francois: I propose to add a bullet point to 4.2.9 with "the Content-Type has a value listed in [an appendix with data MIME types]" 15:01:32 PROPOSED RESOLUTION: add a bullet point to 4.2.9 for "content that is data - e.g. [list of mime types]" 15:01:55 PROPOSED RESOLUTION: add a bullet point to 4.2.9 for "content that is data - [list of mime types]" 15:02:12 The list of mime types being? 15:02:12 PROPOSED RESOLUTION: add a bullet point to 4.2.9 for "content that is data - [appendix with list of data mime types]" 15:02:29 (this must be included in a resolution). 15:03:11 PROPOSED RESOLUTION: add a bullet point to 4.2.9 for "content that is data - [appendix with list of data mime types]"; application/json ; application/soap+xml ; application/soap+fastinfoset ; application/fastsoap ; application/fastinfoset 15:03:26 PROPOSED RESOLUTION: Under 4.1.3 add "and responses" to alteration of requests and add also the sentence, Increasingly browser based applications involve exchanges of data using XMLHTTP request(see 4.2.9 bullet x) and alteration of such exchanges is likely to cause misoperation. 15:04:20 Make sure the spelling is XMLHttpRequest . 15:05:01 dka: both proposed resolutions are compatible and on the table 15:05:03 s/XMLHTTP request/XmlHttpRequest/g 15:05:16 +1 to both 15:05:23 +1 to both. 15:05:25 +1 to both 15:05:26 +1 to everything 15:05:28 francois: I am not sure that I understand the need to add a reference to HTTP responses in 4.1.3, but that looks good 15:05:33 +1 15:05:40 jo: [explaining to francois] 15:05:51 RESOLUTION: add a bullet point to 4.2.9 for "content that is data - [appendix with list of data mime types]"; application/json ; application/soap+xml ; application/soap+fastinfoset ; application/fastsoap ; application/fastinfoset 15:06:00 RESOLUTION: Under 4.1.3 add "and responses" to alteration of requests and add also the sentence, Increasingly browser based applications involve exchanges of data using XMLHTTP request(see 4.2.9 bullet x) and alteration of such exchanges is likely to cause misoperation. 15:06:16 s/XMLHTTP request/XmlHttpRequest/g 15:06:49 PROPOSED RESOLUTION: ref. LC-2269, resolve yes, and note that we have added a bullet point under 4.2.9, an appendix and a reference in 4.1.3 to address this situation 15:06:56 +1 15:07:01 +1 15:07:11 +1 15:07:50 0 (I am on the receiving side on this one). 15:07:56 RESOLUTION: ref. LC-2269, resolve yes, and note that we have added a bullet point under 4.2.9, an appendix and a reference in 4.1.3 to address this situation 15:08:01 PROPOSED RESOLUTION: Add a cautionary not under 4.2.9 that the list is not exhaustive and is likely to change 15:08:38 jo: I have a further point to make on this, see proposed resolution 15:08:42 Alternatively, the cautionary note can be put in the relevant appendix. 15:08:57 francois: this comment applies to multiple appendices 15:09:02 +1 15:09:09 +1 15:09:26 PROPOSED REVOLUTION: Add the above-mentioned cautionary note to all applicable appendices 15:09:30 +1 15:09:35 +1 15:09:39 +1 15:10:13 RESOLUTION: Add the above-mentioned cautionary note to all applicable appendices 15:10:33 -> http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20091006/2270 LC-2270 15:11:42 francois: comment is from Eduardo on the need for proxies to give the possibility to servers to express their preference re. HTTPS links re-writing 15:11:47 [[ "Proxies must provide a means for servers to express preferences for inhibiting 15:11:47 HTTPS URL rewriting regardless of the preferences expressed by the user. 15:11:47 Those preferences must be maintained on a Web site by Web site basis." ]] 15:12:12 jo: chaals wanted to comment on that. I think he wanted to disagree, but he's not here anymore. 15:12:29 Did he write down something? 15:12:57 francois: one objection we had is that it is not testable. 15:13:30 Does this objection apply to 4.2.2 as well then? 15:15:18 I don't think so in the sense that we are going to (or we should at least) try to precise what we mean with user interaction. There is no real way for a proxy to interact with servers. 15:17:55 dka: so what do we do with this question? 15:18:03 jo: what does Eduardo suggest? 15:19:03 This specification reserves the method name CONNECT for use with a 15:19:03 proxy that can dynamically switch to being a tunnel (e.g. SSL 15:19:03 tunneling [44]). 15:19:09 EdC: does anyone know the internals of the CONNECT HTTP method? 15:19:40 9.9 CONNECT 15:19:42 This specification reserves the method name CONNECT for use with a 15:19:44 proxy that can dynamically switch to being a tunnel (e.g. SSL 15:19:45 tunneling [44]). 15:19:50 Sean: I know a little bit on that, yes. 15:20:25 fd: what are you getting at, EdC? 15:21:42 EdC: if we provide a very precise mechanism, we're going to do non-standard things. If we leave it out, then we say that it is not testable and that we have to remove it. 15:21:53 francois: what is the relationship with CONNECT here? 15:23:01 ... The CONNECT request occurs after HTTPS URL rewriting, not before. 15:23:09 EdC: right, so that's off the table. 15:23:17 ... My proposal remains. 15:23:30 DKA: can you turn that into a proposed resolution, EdC? 15:24:32 PROPOSED RESOLUTION: add to 4.2.9.4 "Proxies must provide a means for servers to express preferences for inhibiting 15:24:32 HTTPS URL rewriting regardless of the preferences expressed by the user. Those preferences must be maintained on a Web site by Web site basis." 15:25:05 PROPOSED RESOLUTION: add to 4.2.9.4 "Proxies must provide a means for servers to express preferences for inhibiting HTTPS URL rewriting regardless of the preferences expressed by the user. Those preferences must be maintained on a Web site by Web site basis." 15:25:30 -1 15:28:14 -1 because it can be interpreted freely by proxy implementers 15:28:59 jo: what Eduardo seems to be saying is that proxies should be maintaining whitelists, which is contrary to the spirit of what we are trying to do in my view. 15:29:19 The preferences must not necessarily be maintained by proxies. There can be a "favicon/robots.txt" mechanism -- which servers maintain. 15:29:21 +1 to jo -1 to this proposal 15:29:53 the point being tnhat those whitelists have to be maintained by arbitrary and opaque mechaniusms for each of the 600 odd operators around the world 15:30:34 francois: may I suggest that we add this to "Scope for Future Work" as we're talking about things that do not exist yet. 15:30:47 robots.txt etc. looks to me like "new technology" so not in scope for this WG 15:31:32 Eduardo - can you live with it if we move this to a scope for future work? 15:32:04 OK, if the scope includes a specific statement about requirements as in proposed resolution. 15:32:16 jo: I think there's already some text about this in that appendix. 15:32:28 I.e. preferences of server regardless of user preferences, website by website basis. 15:33:00 jo: so the note under 4.2.9.3 could be completed to reference to the scope for future work section. 15:33:45 francois: not sure I see what we're going to put under section J. though. 15:33:55 jo: let me type in some proposed resolution 15:34:15 PROPOSED RESOLUTION: Add a section under J saying that a mechanism for establishing two party consent as discussed under 4.2.9.3 is needed 15:34:23 +1 15:35:16 francois: EdC wants to add some more precise text as written in IRC. 15:35:26 jo: I believe it is implicit in "two party consent". 15:36:20 suggest EdC proposes a phrase containing "two party consent" to have more precise semantics that he requires 15:36:40 I missed something there about two party consent... Basically, a requirement is that the server must have a possibility to negotiate or deny HTTPS link rewriting. 15:37:06 And this in a handshake of some sort with the proxy. 15:37:12 francois: I think you are both talking about the same thing 15:38:04 jo: let me try to rephrase the proposed resolution 15:38:11 edc - see the note under 4.2.9.3 referring to two party consent that is to be linked to a new section in J that states that such a mecahnism is needed 15:39:11 EdC: I wanted to make sure that the rationale of my comment was not lost, i.e. why a server must be granted the possibility to deny HTTPS links rewriting. 15:39:42 jo: all I want is some proposed text as I don't quite get where the problem here is with the current proposal to add a further section in Appendix J. 15:39:49 ... and link to it from 4.2.9.3. 15:39:56 ... mentioning two-party consent. 15:40:13 PROPOSED RESOLUTION: Add a section under J saying that a mechanism for establishing two party consent (that the server must have a possibility to negotiate or deny HTTPS link rewriting) as discussed under 4.2.9.3 is needed. 15:40:23 One point: but such mechanisms do not exist at the time of writing of this document should actually be but such _standard_ mechanisms do not exist at the time of writing of this document. 15:40:50 OK, let's take that precision on board 15:41:14 PS - in English we don't use the word precision in that sense, but we should 15:41:26 PROPOSED RESOLUTION: Add a section under J saying that a standard mechanism for establishing two party consent (that the server must have a possibility to negotiate or deny HTTPS link rewriting) as discussed under 4.2.9.3 is needed. 15:41:29 +1 15:41:34 +1 15:41:39 +1 15:41:42 +1 15:43:07 +1 15:43:08 RESOLUTION: Add a section under J saying that a standard mechanism for establishing two party consent (that the server must have a possibility to negotiate or deny HTTPS link rewriting) as discussed under 4.2.9.3 is needed. 15:44:34 PROPOSED RESOLUTION: ref. LC-2270, resolve partial, and note that no standard mechanism can be used for establishing two party consent at the time of writing of this document and that a section was added in the Scope for Future Work appendix. 15:44:37 +1 15:44:40 0 15:44:43 +1 15:44:50 +1 15:44:57 +1 15:45:04 RESOLUTION: ref. LC-2270, resolve partial, and note that no standard mechanism can be used for establishing two party consent at the time of writing this document and that a section was added in the Scope for Future Work appendix. 15:46:27 5 minutes 15:46:50 -EdC 15:52:22 EdC has joined #bpwg 15:54:26 I am suggesting two confromance levels: 15:54:45 one which treats 4.2.9.2 as MUST NOT 15:55:14 the other demans a conformance statement regarding NOT RECOMMENDED specifying when and how it does it 15:55:24 +EdC 15:56:21 Are you sure it is 4.2.9.2, and not rather 4.2.9.3? 15:56:47 no, I am sure I am wrong and you are right 15:58:26 rrsagent, draft minutes 15:58:26 I have made the request to generate http://www.w3.org/2009/12/10-bpwg-minutes.html phila 15:59:51 dka: We're back on. Jo, can we leave that aside for the moment and deal with last call comments first? 16:00:12 if there is no support for this I will move on in the interests of being able to live with the conformance statement as it stands 16:00:18 s/statement/classes 16:00:57 q+ 16:01:08 ack edc 16:01:23 francois: are we getting back to this later, or throwing the proposal away? 16:01:33 jo: if there's no support, let's drop it. 16:01:49 dka: I'm not saying I approve or not, just that we should deal with LC first. 16:02:54 jo: I am suggesting that we have one class of product for which re-writing HTTPS links is a "MUST NOT", and one class of product for which re-writing HTTPS links is a "STRONGLY NOT RECOMMENDED" and needs to be explained in the ICS. 16:03:39 EdC: but you would have to add this second level 16:03:47 jo: yes, that's precisely the idea 16:04:01 francois: I note that we would have to find implementations of both levels to move the document forward 16:04:16 dka: good point. I don't support things that would delay us any further. 16:04:36 ... can we drop it for now and move on to the next LC comment? 16:05:16 -> http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20091006/2317 LC-2317 16:05:58 This is what Rotan proposed http://lists.w3.org/Archives/Public/public-bpwg/2009Dec/0008.html 16:07:01 DKA: that's about user notification 16:07:57 francois: yes, we need to precise what "user interaction" means when we mention it in the guidelines, because it can be interpreted in many different ways. Mark suggests that a Warning HTTP header could then be enough. And this is not what we want, clearly. 16:08:03 ... Rotan suggested some text. 16:09:04 jo: so that's another LC? 16:09:25 Probably, in the same category as LC2317. 16:09:27 francois: no, I just referenced more guidelines than Mark, but it's the same comment as LC-2317 16:10:11 jo: I wouldn't use exactly Rotan's wording. 16:10:33 dka: can we action you to do that, jo? 16:10:36 jo: you can. 16:11:05 So a resolution proposal is in the making? 16:11:50 PROPOSED RESOLUTION: ref. LC-2317, resolve yes, and add a definition of user interaction that mentions the communication channel. Exact wording to be defined by the Editor. This definition should be used in all the guidelines that mention user interaction. 16:12:25 I would prefer to define it once, give it a standard name, and use the standard name wherever needed in the guidelines. 16:12:40 PROPOSED RESOLUTION: ref. LC-2317, resolve yes, and add a definition of user interaction that mentions the communication channel. Exact wording to be defined by the Editor. This definition should be used in all the guidelines that mention user interaction similarly to Rotan's proposal in http://lists.w3.org/Archives/Public/public-bpwg/2009Dec/0008.html 16:12:48 +1 16:12:52 That is also what I have in mind, EdC. 16:12:56 +1 16:12:58 +1 16:13:01 +1 16:13:04 +1 16:13:06 It is ok. 16:13:19 RESOLUTION: ref. LC-2317, resolve yes, and add a definition of user interaction that mentions the communication channel. Exact wording to be defined by the Editor. This definition should be used in all the guidelines that mention user interaction similarly to Rotan's proposal in http://lists.w3.org/Archives/Public/public-bpwg/2009Dec/0008.html 16:13:44 On to LC-2318 16:13:55 -> http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20091006/2318 LC-2318 16:14:35 francois: it's a request to clarify section 4.1.5 and in particular the fact that Cache-Control: no-transform takes precedence. 16:15:21 jo: fair enough. 16:16:02 PROPOSED RESOLUTION: re LC-2318 resolve yes and add text to clarify 16:16:05 +1 16:16:07 +1 16:16:11 +1 16:16:12 +1 16:16:20 +1 16:16:33 phila has left #bpwg 16:16:33 RESOLUTION: re LC-2318 resolve yes and add text to clarify 16:17:33 On to LC-2320 16:17:40 -> http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20091006/2320 LC-2320 16:18:09 francois: the comment is about the third bullet point in 4.1.5 16:19:25 francois: first thing we can do is to add a link to 4.1.5.4 on Sequences of requests that contain some normative statements. 16:19:29 I get the justification for the second part of the sentence, but does anybody have a clear example where "it is technically infeasible not to adjust the request because of earlier interaction" ? 16:19:59 jo: I agree that you can certainly get a wide van through this. 16:21:11 francois: I agree with EdC here. Let's drop this part if it doesn't address any real use case. 16:21:35 jo: I agree. I had made a mental note to add a backward reference in 4.1.5.4 anyway. 16:25:35 PROPOSED RESOLUTION: ref LC-2320, resolve yes, remove "it is technically infeasible not to adjust the request because of earlier interaction", and add a link to 4.1.5.4 on sequence of requests. 16:25:49 +1 16:25:55 +1 16:26:08 PROPOSED RESOLUTION: remove all following Web site in bullet 3. of 4.1.5 and add a reference to 4.1.5.4 16:26:28 +1 to jo's proposed resolution 16:26:36 +1 to me, I rock 16:26:43 +1 to either resolution 16:26:45 +1 16:26:48 +1 to rock 16:27:39 remove all following "Web site" in bullet 3. of 4.1.5 and add a reference to 4.1.5.4 16:28:20 "can you live with it?" 16:29:06 EdC: you are broadening the bullet point, right? 16:29:40 francois: no, because the "see 4.1.5.4" will define the context 16:30:10 EdC: 4.1.5.4 is about included resources, here it's about sequences of requests in the same Web site. 16:30:17 francois: oops. You're right. 16:31:01 4.1.5.4 deals with included and linked resources. 16:31:29 dka: so how can we rephrase this 16:32:36 jo: I think it's fine, actually. 16:32:49 "the request is part of a sequence of requests to retrieve linked or included resources from the same Web site as in 4.1.5.4". 16:32:51 3. the request is part of a sequence of requests to linked and included resources (see 4.1.5.4) 16:33:13 And actually we can drop "same web site" really. 16:33:26 since included or linked resources might be on another web site. 16:33:33 edc - agree, that is what we are saying 16:33:41 but 16:34:01 in 4.1.5.4 linked resources on another Web site are carved out 16:34:17 OK, so the sequence only referes to included resources. 16:34:22 jo: I think we can drop "same Web Site" indeed 16:35:05 no, linked resources on same Web site are included 16:35:20 so it is included resources or linked resources on same site? 16:36:34 PROPOSED RESOLUTION: remove all following "sequence of requests" in bullet 3. of 4.1.5 and add a reference to 4.1.5.4 16:37:07 PROPOSED RESOLUTION: replace bullet 4 of 4.1.5 with: 3. the request is part of a sequence of requests to included resources AND LINKED RESOURCES ON THE SAME wEB SITE (see 4.1.5.4) 16:37:22 phila has joined #bpwg 16:37:33 +1 16:37:36 PROPOSED RESOLUTION: replace bullet 4 of 4.1.5 with: 3. the request is part of a sequence of requests to included resources and linked resources on the same Web site (see 4.1.5.4) 16:37:39 substitute AND with OR? 16:37:40 +1 16:38:02 included resources or to linked resources... 16:38:18 +1 16:38:27 OR=> either one, or the other, or both. 16:38:52 The sequence of requests must be for both, if with AND. 16:38:57 PROPOSED RESOLUTION: replace bullet 4 of 4.1.5 with: 3. the request is part of a sequence of requests comprising either iincluded resources or linked resources on the same Web site (see 4.1.5.4) 16:39:10 +1 16:39:10 not in english, EdC 16:39:23 +1 16:39:25 +1 16:39:28 +1 16:39:32 +1 16:39:34 +1 16:39:38 +1 16:39:41 RESOLUTION: replace bullet 4 of 4.1.5 with: 3. the request is part of a sequence of requests comprising either included resources or linked resources on the same Web site (see 4.1.5.4) 16:40:11 PROPOSED RESOLUTION: ref. LC-2320, resolve yes, and point to the changes just resolved 16:40:13 +1 16:40:19 +1 16:40:22 RESOLUTION: ref. LC-2320, resolve yes, and point to the changes just resolved 16:40:23 +1 16:40:27 +1 16:41:09 On to LC-2328 16:41:13 -> http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20091006/2328 LC-2328 16:41:46 MNot didn't make any specific reference in the spec 16:41:54 FD: I think he means 2.4.3 16:42:07 s/MNot/FD: MNot/ 16:42:16 scribe: PhilA 16:42:21 scribeNick: PhilA 16:43:02 Sean: That seems reasonable to me 16:43:06 FD: I agree 16:43:26 ... does it occur in practice? Who uses cache control no transform now? 16:43:40 Jo: it was added y Bryan Sullivan 16:43:52 rrsagent, draft minutes 16:43:52 I have made the request to generate http://www.w3.org/2009/12/10-bpwg-minutes.html phila 16:43:58 Does the comment apply to the first or the second paragraph of 4.2.3? 16:44:08 s/4.2.3/2.4.3/ 16:44:20 Sean: It allows proxies to tell the client that there could be a problem 16:44:53 Jo: I'm more than happy to strike this paragraph which I've never been happy with 16:45:06 Sean: I don't think we've ever done this 16:45:16 ... I think this is more of a forward-looking thing 16:45:28 Jo: There are probably more effective remedies. 16:46:01 PROPOSED RESOLUTION: Remove 2nd para of 4.2.3 and adjust end of first para to suit 16:46:13 +1 16:46:18 s/FD: I think he means 2.4.3/FD: I think he means 4.2.3/ 16:46:31 +1 16:46:34 +1 16:46:34 0 16:47:24 +1 16:47:30 Sean: proxies are going to ignore this if they think it's going to cause problems for the user - nad I think that's reasonable behaviour 16:47:38 s/nad/and 16:47:44 Jo: I sort of agree 16:48:04 ... they must provide the option of delivering the content unaltered which reduces the power of the statement 16:48:33 ... the primary use case is if the proxy thinks that some stuff is intended for display even though it's not 16:49:05 Sean: I would think it could kick in if the server sends a large page that the proxy knows will be too large for the client 16:49:17 FD: But we're restricted to cache-control: no transform 16:49:25 Sean: That's why I say 0 not -1 16:49:28 no objections then 16:49:28 RESOLUTION: Remove 2nd para of 4.2.3 and adjust end of first para to suit 16:49:36 PROPOSED RESOLUTION: ref. LC-2328, resolve yes, exception to the rule in 4.2.3 was removed. 16:49:44 +1 16:49:45 +1 16:49:51 RESOLUTION: ref. LC-2328, resolve yes, exception to the rule in 4.2.3 was removed. 16:50:11 Next is LC-2329 http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20091006/2328?cid=2329 16:50:52 FD: he saying we blur the semantics of the 200 response 16:51:23 ... what we could do is say that you should use something other than 406 16:51:41 Sean: We're not really breaking any HTTP rules here are we? 16:51:55 I suspect his objection is that the procedure to determine that the content is equivalent to a response with an HTTP 406 Status is not undetermined and not specifiable. 16:52:57 FD: We could link to the subsequent sections which contain details of when the 200 response should not be touched 16:54:10 ... the bullet points in 4.2.9 - if they're included then you can interpret that the browser doesn't support it 16:55:01 s/doesn't support it/browser isn't supported/ 16:55:28 Jo: My feeling is that... 16:55:48 ... subject to and notwithstanding... 16:56:11 ...taking into account various salient points and the full context... 16:56:33 .. and with due consideration to all relevant aspects ... 16:56:36 ... er 16:56:40 ... um 16:56:50 Can we proceed with alacrity please? 16:57:49 It is not us that is blurring the distinction. It's the content providers who are using 200 to say "your browser is not supported" 16:58:20 ... so we are responding to a dsitinction that is already blurred rather than blurring it 16:58:31 s/It is not us that/Jo: It is not us that/ 16:58:42 FD: So do you have some proposed text? 16:59:22 PROPSOED RESOLUTION: In respect of LC-2328, resolve no, we take your point, but pragmatically speaking the distinction is blurred by Web site owners 16:59:32 Do we want to state that servers SHOULD NOT use a 200 response to indicate that the browser or the user agent characteristics are unsupported? 16:59:48 we already say that, EdC 16:59:51 Retract this. 16:59:52 +1 to the resolution 17:00:02 +1 17:00:03 EdC, out of scope but referred to in the appendices 17:00:19 +1 17:00:20 +1 17:00:22 RESOLUTION: In respect of LC-2328, resolve no, we take your point, but pragmatically speaking the distinction is blurred by Web site owners 17:00:55 FD: We're done with LC comments AFAICS 17:00:56 sound oif champagne corks popping 17:00:58 WAIT !! what about that 406 issue? 17:01:07 FD; But I have more to say.... 17:01:12 s/;/:/ 17:01:53 Jo: I would like us to write a formal position on 406 and I'm happy to do it so let's deal with it 17:03:41 PROPOSED RESOLUTION: In respect of the 406 issue, having taken everything that I have been made aware of into consdieration, and after due reflection, my view is that not using 406 on the basis of consultion a DDR is not technically determining that the conclusion has been drawn from the accept headers specifically, as stated in sthe specification of the 406 status, is silly 17:04:32 What is a "consultion a DDR"? 17:04:32 FD: Je pense d'accord 17:04:57 s/pense/pense que je suis/ 17:05:44 FD: I just want record that we think we're using 406 correctly and that no one is saying otherwise 17:06:15 I remind that 403 can be used in a general case. 17:07:08 We can just add this to the relevant section of the appendix. 17:07:31 PROPOSED RESOLUTION: In respect of the 406 issue, HTTP says that 406 means "The resource identified by the request is only capable of generating response entities which have content characteristics not acceptable according to the accept headers sent in the request." To use a different code on the basis that incompatibility has been estaqblished by some means other than the accept headers... 17:07:31 ...seems silly and pedantic to me. 17:08:01 +1 17:08:10 +1 17:08:23 RESOLUTION: In respect of the 406 issue, HTTP says that 406 means "The resource identified by the request is only capable of generating response entities which have content characteristics not acceptable according to the accept headers sent in the request." To use a different code on the basis that incompatibility has been estaqblished by some means other than the accept headers... 17:09:14 On to LC-2319 http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20091006/2319?cid=2319 17:09:39 FD: we are already going to cache-control: no transform trumps all 17:09:48 s/going to/going to say/ 17:10:32 rrsagent, draft minutes 17:10:32 I have made the request to generate http://www.w3.org/2009/12/10-bpwg-minutes.html phila 17:10:48 PROPOSED RESOLUTION: In re LC-2319, resolve yes and modify the text to say Other than the fields that RFC 2616 says must be modified ... 17:11:05 +1 17:12:12 I would prefer "other than the modifications required by RFC2616, ..." I am not sure, but the method or body might be modified as well as the fields. 17:12:48 PROPOSED RESOLUTION: In re LC-2319, resolve yes and modify the text to say Other than the modifications required by RFC 2616 17:12:55 +1 17:13:02 +1 17:13:05 +1 17:13:24 +1 17:13:26 +1 17:13:27 RESOLUTION: In re LC-2319, resolve yes and modify the text to say Other than the modifications required by RFC 2616 17:13:53 LC-2322 http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20091006/2319?cid=2322 17:15:12 Jo: I regard it as obvious from the context that we're talking about mobile 17:15:36 FD: yes but it needs clarification. It's right to put 'process' between quotes as it is vague 17:17:13 FD: Clarification - he, MNOt, is right to put 'process' in quotes 17:17:20 PROPOSED RESOLUTION: in re LC-2322 - add to 4.2.7, in parentheses, If the user agent is determined as being "handheld" 17:19:29 +1 17:19:34 +1 17:19:49 +1 17:21:10 +1 17:21:13 +1 17:21:20 RESOLUTION: in re LC-2322 - add to 4.2.7, in parentheses, If the user agent is determined as being "handheld" 17:21:47 Comment from Thomas LC-2268 http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20091006/2268?cid=2268 17:22:19 FD: I don't think it's a real problem 17:22:22 Jo: +1 17:22:52 Jo: How about we change the 2nd bullet of 4.2.9 17:24:24 PROPOSED RESOLUTION: Change "the user agent has features (such as linearization or zoom) that allow it to present the content unaltered;" to "the user agent has features (such as linearization or zoom, is a desktop device using a mobile network for access) that allow it to present the content unaltered;" 17:24:35 +1 17:24:43 +1 17:25:23 +1 17:25:34 +1 17:25:45 "desktop device using a mobile network for access" what if I am using a mobile browser for testing on a desktop? 17:25:45 PROPOSED RESOLUTION: Change "the user agent has features (such as linearization or zoom) that allow it to present the content unaltered;" to "the user agent has features (such as linearization or zoom, is a desktop device using a mobile network for access) that allow it to present the content without the need for alteration by the proxy;" 17:26:01 +1 17:26:08 +1 17:26:09 "including but not limited to!" 17:26:20 +1 17:26:21 RESOLUTION: Change "the user agent has features (such as linearization or zoom) that allow it to present the content unaltered;" to "the user agent has features (such as linearization or zoom, is a desktop device using a mobile network for access) that allow it to present the content without the need for alteration by the proxy;" 17:26:29 +1 17:26:30 PROPOSED RESOLUTION: ref LC-2268, resolve yes, and point to the updated bullet in 4.2.9 17:26:35 +1 17:26:38 +1 17:26:40 +1 17:26:42 +1 17:26:47 RESOLUTION: ref LC-2268, resolve yes, and point to the updated bullet in 4.2.9 17:27:13 LC-2267 http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20091006/2268?cid=2267 17:27:23 FD: First part of the reply could be 'thank you' 17:28:43 Jo and Francois discuss options 17:29:45 Jo: Tlr is essentially asking us to add a note to say "don't underestimate how hard this is" 17:31:00 ... I think we say we don't want to do this as we' d be stepping into the internal processes used by proxies 17:31:04 RRSAgent, draft minutes 17:31:04 I have made the request to generate http://www.w3.org/2009/12/10-bpwg-minutes.html francois 17:32:15 PROPOSED RESOLUTION: ref LC-2267, resolve no, the document does not specify the internal operation of transforming proxies so we find it hard to think of anything useful to say 17:32:19 +1 17:32:21 +1 17:32:29 +1 17:32:30 +1 17:32:40 RESOLUTION: ref LC-2267, resolve no, the document does not specify the internal operation of transforming proxies so we find it hard to think of anything useful to say 17:34:38 What is the current issue? 17:35:47 PROPOSED RESOLUTION: ref LC-2323, resolve partial, we have added text to clarify some guidelines and do not think this is the final word on the subject, though we think it is a valuable contribution on the subject. 17:36:00 +1 17:36:12 +1 17:36:17 +1 17:36:21 RESOLUTION: ref LC-2323, resolve partial, we have added text to clarify some guidelines and do not think this is the final word on the subject, though we think it is a valuable contribution on the subject. 17:37:36 PROPOSED RESOLUTION: ref LC-2289, resolve no, as it is not the intention of the document to address legal, moral or liability issues. 17:37:49 +1 17:37:50 +1 17:37:55 +1 17:38:02 RESOLUTION: ref LC-2289, resolve no, as it is not the intention of the document to address legal, moral or liability issues. 17:39:21 PROPOSED RESOLUTION: The WG reluctantly accepts that the changes agreed today constitute Substantive Modification, and hence requires to enter Last call a further time 17:39:34 +1 17:39:40 +1 17:39:52 +1 17:40:01 ACTION: Jo to enact changes resolved today with minimal possible casuisitry 17:40:01 Created ACTION-1028 - Enact changes resolved today with minimal possible casuisitry [on Jo Rabin - due 2009-12-17]. 17:40:07 +1 with lachramousity 17:40:15 RESOLUTION: The WG reluctantly accepts that the changes agreed today constitute Substantive Modification, and hence requires to enter Last call a further time 17:40:38 ACTION: fd to draft responses to reviewers based on resolutions taken during the F2F 17:40:38 Created ACTION-1029 - Draft responses to reviewers based on resolutions taken during the F2F [on François Daoust - due 2009-12-17]. 17:40:59 I suspect lacrimosity 17:41:11 From latin lacrima -- tear. 17:41:21 Issue: Jo may not be able to devote very much time to this document so if modifications are needed beyond what has been discussed today a further editor is needed 17:41:21 Created ISSUE-301 - Jo may not be able to devote very much time to this document so if modifications are needed beyond what has been discussed today a further editor is needed ; please complete additional details at http://www.w3.org/2005/MWI/BPWG/Group/track/issues/301/edit . 17:42:21 q+ 17:42:27 ack ed 17:42:58 EdC: what is there now to do? 17:43:10 DKA: We wait for Jo to complete the changes 17:43:48 DKA: I think the only CT issue for tomorrow may be logistics, publishing moratorium, timing etc 17:44:14 Jo: I'm wonderign when I'm going to be able to make these changes. Not tonight, probably not next week. 17:44:33 DKA: Before Friday 18th? 17:44:48 Jo: Is decidedly noncomittal 17:48:18 FD: Publishing over Christmas doesn't affect timing that much since you can't include the moratorium in the minimum LC period. 17:48:29 Beer is required all round. 17:48:33 Meeting adjourned 17:48:37 s/can't/probably should not/ 17:48:41 rrsagent, generate minutes 17:48:41 I have made the request to generate http://www.w3.org/2009/12/10-bpwg-minutes.html phila 17:48:56 -EdC 17:49:28 zakim, drop vodafone 17:49:28 Vodafone is being disconnected 17:49:29 MWI_BPWG(F2F)4:30AM has ended 17:49:30 Attendees were +41.31.972.aaaa, Vodafone, EdC 17:49:40 phila has left #bpwg