13:59:07 RRSAgent has joined #bpwg 13:59:07 logging to http://www.w3.org/2008/04/22-bpwg-irc 13:59:09 RRSAgent, make logs public 13:59:09 Zakim has joined #bpwg 13:59:11 Zakim, this will be BPWG 13:59:11 ok, trackbot-ng; I see MWI_BPWG(CTTF)10:00AM scheduled to start in 1 minute 13:59:12 Meeting: Mobile Web Best Practices Working Group Teleconference 13:59:12 Date: 22 April 2008 13:59:14 Chair: francois 13:59:23 Agenda: http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Apr/0035.html 13:59:31 Regrets: kemp, bryan, rob 13:59:31 zakim, code? 13:59:31 the conference code is 2283 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), Magnus 14:00:02 MWI_BPWG(CTTF)10:00AM has now started 14:00:09 +francois 14:00:10 +Magnus 14:00:13 -francois 14:00:14 +francois 14:01:23 +hgerlach 14:01:26 +jo 14:01:34 Martin1 has joined #bpwg 14:01:46 + +7.776.13.aaaa 14:01:55 zakim, aaaa is me 14:01:55 +Martin1; got it 14:02:01 hgerlach has joined #bpwg 14:02:16 hi 14:03:05 scribe: jo 14:03:25 zakim, mute me 14:03:25 Martin1 should now be muted 14:03:27 ScribeNick: jo 14:03:35 Topic: Comments on FPWD 14:03:44 Topic: Comments on FPWD 14:03:59 -> http://lists.w3.org/Archives/Public/public-bpwg-comments/2008AprJun/0000.html comment received 14:04:01 fd: actually we only received one comment which is pretty good going 14:04:13 I just sent the document to our Vodafone OpCos. By when do you need their comments? 14:04:24 SeanP has joined #bpwg 14:04:26 ... raises an interesting point but I am not sure how to take them into account 14:04:52 q+ 14:04:54 andrews has joined #bpwg 14:04:56 ... basically it is about how a transforming proxy can make a valid page invalid 14:05:05 ... not sure how we can put this in 14:05:32 ... we could say that it should always generate a valid page? 14:05:36 ack m 14:05:37 ack Magnus 14:05:48 +andrews 14:06:01 magnus: the comment is that the proxy added javascript and thus made the page invalid 14:06:14 ... think it is pretty obvious that the proxy shouldn't make pages invalid 14:06:33 q+ (new Item) 14:06:34 ... builders should show adequate humiliy, it's easy to get this wrong 14:06:52 s/builders/proxy builders/ 14:06:57 ack (ne 14:07:02 ack i 14:07:04 s/humily/humbleness/ 14:07:14 s/humiliy/humbleness/ 14:07:40 +SeanP 14:09:25 fd: it's an obvious statement but how should we pharase it, who thinks we should not mention it? 14:09:34 s/pharase/phrase 14:09:51 ... does anyone think it is too obvious? 14:09:53 q+ 14:09:57 ack jo 14:09:59 ack me 14:11:00 jo: think its non-obvious and is definitely an omission from present draft 14:11:20 ... and that we should add something about generating valid markup (and images too, for that matter) 14:11:38 ... happy to take an action to propose some text in next draft 14:11:49 fd: probably should go in 4.4 ,,,, 14:12:20 action: jo to create text about transforming proxies generating valid documents and propose it in next draft 14:12:21 Created ACTION-738 - Create text about transforming proxies generating valid documents and propose it in next draft [on Jo Rabin - due 2008-04-29]. 14:12:31 Topic: Linearization/zoom/format support and CT 14:12:51 Topic: Discussion on Linearization and Zoom and All That Jazz 14:13:18 fd: in 4.1.2 there is some text ... [quotes] ... there was some discussion on the mailing list 14:13:20 -> http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Apr/0032.html thread on the topic 14:13:48 fd: first this applies to the response 14:13:58 ... so we should remove it from where it is 14:14:02 q+ 14:14:20 ... and move it to 4.4 Proxy response to user agent 14:14:44 ... jo and sean have different perspectives on this 14:14:47 ack jo 14:15:45 jo: there needs to be something under 4.1.2 reference not changing headers 14:16:02 fd: but we already say that headers should not be changed 14:16:12 ... unless the response would be rejected 14:16:19 ... so it doesn't add anything 14:16:39 ... you suggest that we add this as an additional point? 14:18:45 jo: I think it should go under "knowledge it has of user agent capabilities" as you suggest under Possiblity 1 c) 14:19:12 fd: OK, yes as an example of UA capabilities 14:19:35 q+ 14:19:39 ack SeanP 14:20:06 seanp: even on advanced browsers you may want to do some kind of transformation 14:20:33 ... depends on network, memory and so on, so you might want to do some segmentation 14:21:17 fd: still worth mentioning under 4.1.2 but maybe change the wording under 4.4 14:21:49 seanp: the way I would phrase it is that the capabilities of the browser should be taken into account but shouldn't be a restriction 14:22:13 fd: perhaps it is just another example of the type of heuristic that the proxy should apply 14:23:55 q+ 14:24:07 ack SeanP 14:24:38 jo: perhaps it could go there but I am worried that we end up being too wishy washy. what we are trying to avoid is having the server doinf adaptation, and transforming proxies transforming and ditto the browsers - this turns into a real mess. And we should say that this is to be avoided etc. 14:25:08 sean: yes, I agree but the case I was referring to was when the Server doesn't adapt then it may be worth the proxy doing things 14:26:02 PROPOSED RESOLUTION: to replace paragraph on "adavanced browsers" and CT, add it as an example to "any knowledge it has of user agent capabilities" in 4.1.2 and add it as a bullet point in the list of heuristics in 4.4 14:26:25 +1 14:26:26 +1 14:26:32 +1 14:26:34 -1 14:26:40 +1 14:26:41 +1 to francois's auto-+1 14:27:57 qheiko: don't agree because of the arbitrary choices of my local marketing department 14:28:06 s/qheiko/heiko/ 14:28:18 q+ to disagree strongly with heiko 14:28:35 +1 14:28:41 ack jo 14:28:41 jo, you wanted to disagree strongly with heiko 14:28:44 fd: if we add this to the list of heuristics then it is not as strong so matters less 14:29:19 -Magnus 14:30:30 jo: I think that whether your equipment is conformant to these guidelines or not is their choice, we can't make arbitrary choices in the sections based on the bits they may or may not choose to ignore 14:30:40 RESOLUTION: to replace paragraph on "adavanced browsers" and CT, add it as an example to "any knowledge it has of user agent capabilities" in 4.1.2 and add it as a bullet point in the list of heuristics in 4.4 14:30:53 s/adavanced/advanced/ 14:31:09 topic: Ajax Calls and CT Proxies 14:31:24 -> http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Mar/0028.html discussion on Ajax/XHR calls 14:31:57 fd: basically if you have an XHR in a page then there is no way for the CT proxy to know that this is an AJAX call 14:32:06 ... rather than just a page request 14:32:12 ... we did discuss this 14:32:49 ... it's just about choosing the right response content type - text/xml or text/plain 14:33:01 ... I wonder if we should write about it or forget about it 14:33:08 ... there isn't really a rpoblem in practice 14:33:20 s/rpoblem/problem/ 14:33:23 q+ 14:33:32 q+ to suggest that we put an example in the appendix 14:34:09 fd: we could add this to a list of heuristics 14:34:12 +1 14:34:13 ack hgerlach 14:34:32 ... saying that if you see scripts then be prepared for this 14:34:56 heiko: the application has to add no-cache so adding no-transform should not be a problem 14:35:01 ack jo 14:35:01 jo, you wanted to suggest that we put an example in the appendix 14:35:47 jo: think that we should discuss this and say the no-transform should be added in both the request and the response 14:35:58 fd: do you mean the request or just the response 14:36:08 ... not sure there is need to add it in the request 14:36:53 q+ 14:36:54 jo: think this is the classic use case for no-transform in the request 14:37:36 heiko: normally the Ajax client and data are owned by the same operator so they can add this easily 14:37:39 ack SeanP 14:37:45 ... either way round 14:38:19 seanp: martin said at the f2f if the page that contained the ajax request was transformed then you might want to transform the response 14:38:34 heiko: transformed ajax pages won't work, in my expectation 14:38:57 q+ 14:39:15 seanp: the point was that if the proxy knows enough to transform the page with the request then it will know enough to transform the request 14:39:25 q+ 14:39:37 zakim, unmute me 14:39:37 Martin1 should no longer be muted 14:39:38 ack Martin1 14:39:42 fd: if it knows enough then it is going to be smart enough to remove the no-transform it receives 14:39:46 ack Martin 14:40:32 sorry, I have to leave for the doc.- bye Heiko 14:40:48 martin: I agree that if you transform an Ajax page then it's unlikely to work, but there could be some minor optimizations that are worth doing and should not be prohibited 14:40:58 fd: wondering alound, um, er, 14:41:05 s/alound/aloud/ 14:41:22 ... if it is smart enough it could remove the no-transform from the request so ... 14:41:37 ... 14:42:02 q+ 14:42:14 ack hgerlach 14:42:47 heiko: got to go , just want to say there should be no-transform on the response to the AJAX request 14:42:57 -hgerlach 14:42:58 fd: agree that it should be rpesent in both 14:43:05 zakim, mute me 14:43:05 Martin1 should now be muted 14:43:07 s/rpesent/present/ 14:43:14 ack jo 14:43:55 q+ 14:44:06 jo: I find it worrying that you suggest that a transforming proxy MAY transform requests with no-transform on them 14:44:19 fd: hmmm, difficult to write it 14:44:58 ... some where in the doc we should add the text saying that XHR requests should have no-transform on (and consequently according to the rules it will alos be on the response) 14:45:36 jo: suggest that we put this in as one among other examples of how the whole thing is intended to be used 14:46:00 ... in a non-normative appendix, for example 14:46:29 ack SeanP 14:47:05 seanp: I was thinking along the lines of the ??? itself hasn't been and there is no no-transform on the request or the response 14:47:28 scribe is confused? 14:48:35 seanp: if it is no-transform ab initio, then it shouldn't be transformed, but just because it is Ajax doesn't mean it should not be transformed 14:48:45 ACTION: daoust to summarize (again) discussion on Ajax/XHR and propose some resolutions 14:48:48 Created ACTION-739 - Summarize (again) discussion on Ajax/XHR and propose some resolutions [on François Daoust - due 2008-04-29]. 14:49:23 Topic: Comments and Via Headers 14:49:29 fd: we are in 4.1.3 14:49:59 ... there is a statement that comments in Via headers may be removed 14:50:27 ... it seems that this was motivated my memory constraints and they don't exist in practice 14:50:46 ... doesn't mean that comments are always kept just means they are kept most of the time 14:51:03 ... don't think we should change anything 14:51:22 On the XHR issue, my comment was that if a page was transformed, then any XHR requests originating from that page may need to have their responses transformed, so these requests should probably not be marked no-transform. 14:51:27 According to the HTTP RFC (§14.45), Via headers comments "MAY be 14:51:27 removed by any recipient prior to forwarding the message". Noting that 14:51:27 the justification for removing such comments is memory-based, that most 14:51:27 modern proxies are able to handle that amount of information and that 14:51:27 comments are useful for CT, the BPWG recommends that Via headers 14:51:28 comments SHOULD NOT be removed. 14:51:29 ... and move the ednote to a note and point out that there is a slight difference to HTTP RFC 2616 14:51:51 ... per the text I just pasted 14:52:21 ... any objection or aything to add? 14:52:23 q? 14:52:30 s/ayth/anyth/ 14:52:57 ACTION: Jo to find a way of crafting FD's text above and weaving it skillfully into the flow of the text 14:52:57 Created ACTION-740 - Find a way of crafting FD's text above and weaving it skillfully into the flow of the text [on Jo Rabin - due 2008-04-29]. 14:53:21 Close ACTION-722 14:53:21 ACTION-722 Check why HTTP RFC states comments MAY be removed from a VIA header. closed 14:53:29 fd: close the action 14:53:40 Close ACTION-684 14:53:40 ACTION-684 Include a note that we think it is bad practice to strip the comment from downstream via header fields closed 14:54:02 ... and also there was one on jo too, so we can close that as it's all included in the new action 14:54:11 Topic: The format of the Via Header 14:54:45 fd: i'd prefer if we finished the guidelines without powder and sprinkle it on later 14:55:04 ... wondering what we can use in the meantime 14:55:33 ... could it be a namespace stating "I'm a CT Proxy?" 14:55:53 http://www.w3.org/2008/04/ct/ 14:56:05 q+ 14:56:12 ack jo 14:57:23 jo: what will a server do knowing that it is a CT proxy but not knowing anything about its facilities 14:57:32 fd: we could have one or two values 14:57:41 ... including statement of intent to transform 14:57:56 ... think it would be directly usable 14:58:34 ... later then the usage could be expanded, we could use it as a flag and this would actually already add value 14:58:51 +q 14:59:07 jo: so what is a server actually going to do differently 14:59:15 fd: it could refuse to serve the page 14:59:33 ... it's in the requirements, we wanted the server to know that there is a ct proxy 14:59:53 [OK I think there is no downside to this and suggest we do as FD suggests] 14:59:55 ack andrews 15:00:28 andrew: it's not just the server that would find this useful, it could be useful for diagnostics 15:00:46 fd: could be used for debugging 15:00:58 andrew: great strength of http is that it is human readable 15:01:09 ... v useful to have this information in there. 15:01:28 ... moot point as to when you consider yourself to be a transformation proxy 15:02:21 fd: there is also the proxy intention to transform that we want to communicate to the server 15:02:34 ... and I don't see any other way of doing this 15:02:57 ACTION: daoust to write a concrete proposal on use of via header 15:02:57 Created ACTION-741 - Write a concrete proposal on use of via header [on François Daoust - due 2008-04-29]. 15:03:36 ACTION: daoust to write some concrete proposal on the format of the HTTP Via comment to advertise the CT-proxy's presence (and possibly intention to transform) 15:03:37 Created ACTION-742 - Write some concrete proposal on the format of the HTTP Via comment to advertise the CT-proxy's presence (and possibly intention to transform) [on François Daoust - due 2008-04-29]. 15:04:16 fd: look at the other to do's at the end of the agenda 15:04:30 ... we have to get this done and I will try to stimulate discussion on these topics 15:04:40 [meeting ends] 15:04:45 -SeanP 15:04:48 -Martin1 15:04:49 -francois 15:04:58 zakim, drop me 15:05:08 Martin1 has left #bpwg 15:05:18 RRSAgent, draft minutes 15:05:18 I have made the request to generate http://www.w3.org/2008/04/22-bpwg-minutes.html francois 15:05:24 jo is being disconnected 15:05:25 -jo 15:05:36 zakim, who is on the phone? 15:05:37 On the phone I see andrews 15:05:39 -andrews 15:05:41 MWI_BPWG(CTTF)10:00AM has ended 15:05:43 Attendees were francois, Magnus, hgerlach, jo, +7.776.13.aaaa, Martin1, andrews, SeanP 15:05:44 zakim, drop andews 15:05:49 sorry, jo, I don't know what conference this is 15:06:08 zakim, list attendees 15:06:08 sorry, francois, I don't know what conference this is 15:06:12 RRSAgent, draft minutes 15:06:12 I have made the request to generate http://www.w3.org/2008/04/22-bpwg-minutes.html francois 15:09:37 zakim, bye 15:09:37 Zakim has left #bpwg 15:11:16 RRSAgent, bye 15:11:16 I see 5 open action items saved in http://www.w3.org/2008/04/22-bpwg-actions.rdf : 15:11:16 ACTION: jo to create text about transforming proxies generating valid documents and propose it in next draft [1] 15:11:16 recorded in http://www.w3.org/2008/04/22-bpwg-irc#T14-12-20 15:11:16 ACTION: daoust to summarize (again) discussion on Ajax/XHR and propose some resolutions [2] 15:11:16 recorded in http://www.w3.org/2008/04/22-bpwg-irc#T14-48-45 15:11:16 ACTION: Jo to find a way of crafting FD's text above and weaving it skillfully into the flow of the text [3] 15:11:16 recorded in http://www.w3.org/2008/04/22-bpwg-irc#T14-52-57 15:11:16 ACTION: daoust to write a concrete proposal on use of via header [4] 15:11:16 recorded in http://www.w3.org/2008/04/22-bpwg-irc#T15-02-57 15:11:16 ACTION: daoust to write some concrete proposal on the format of the HTTP Via comment to advertise the CT-proxy's presence (and possibly intention to transform) [5] 15:11:16 recorded in http://www.w3.org/2008/04/22-bpwg-irc#T15-03-36