14:59:52 RRSAgent has joined #bpwg 14:59:52 logging to http://www.w3.org/2008/12/09-bpwg-irc 14:59:54 RRSAgent, make logs public 14:59:54 Zakim has joined #bpwg 14:59:56 Zakim, this will be BPWG 14:59:56 ok, trackbot; I see MWI_BPWG(CTTF)10:00AM scheduled to start in 1 minute 14:59:57 Meeting: Mobile Web Best Practices Working Group Teleconference 14:59:57 Date: 09 December 2008 15:00:16 Agenda: http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Dec/0029.html 15:00:19 Chair: francois 15:01:04 Regrets: rob, tom 15:04:11 jo has joined #bpwg 15:04:30 EdC has joined #bpwg 15:04:44 zakim, code? 15:04:48 the conference code is 2283 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), jo 15:05:03 MWI_BPWG(CTTF)10:00AM has now started 15:05:11 +Francois 15:05:37 + +41.31.972.aaaa 15:06:39 + +03531522aabb 15:06:45 zakim, aaaa is EdC 15:06:45 +EdC; got it 15:06:56 zakim, aabb is me 15:06:56 +jo; got it 15:08:11 AndreaT has joined #bpwg 15:12:32 + +44.793.201.aacc 15:13:44 AndreaT has left #bpwg 15:13:52 - +44.793.201.aacc 15:14:41 + +44.793.201.aadd 15:15:09 +q 15:15:20 ack EdC 15:18:02 q+ to say that I plan to work on a new draft over christmas, and that the draft after that should be the new LC draft 15:18:03 any dependencies on other work? e.g. mobileOK, Best practices, etc...? 15:18:13 - +44.793.201.aadd 15:18:39 ack jo 15:18:39 jo, you wanted to say that I plan to work on a new draft over christmas, and that the draft after that should be the new LC draft 15:18:40 ack me 15:19:33 +q 15:19:46 ack EdC 15:20:52 Scribe: francois 15:21:01 Topic: Pagination definition 15:21:09 -> http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Dec/0028.html thread 15:21:26 PROPOSED RESOLUTION: ref. definition of pagination, adopt Eduardo's proposed text in http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Dec/0028.html 15:22:40 +20 15:22:40 +1 15:23:31 PROPOSED RESOLUTION: ref. definition of pagination, adopt Eduardo's proposed text in http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Dec/0028.html, replacing "fragments" by "documents" 15:23:37 +1 15:23:39 RESOLUTION: ref. definition of pagination, adopt Eduardo's proposed text in http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Dec/0028.html, replacing "fragments" by "documents" 15:24:33 + +44.793.201.aaee 15:24:55 SeanP has joined #bpwg 15:26:24 + +1.630.414.aaff 15:26:35 Zakim, aaff is me 15:26:35 +SeanP; got it 15:26:53 Topic: Validation against formal published grammar 15:27:13 -> http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Nov/0037.html thread 15:28:31 fd: strong positions in favor of a guideline along the lines of "The altered content MUST be well-formed" 15:28:37 ... not too strong positions against it. 15:28:49 for xml-based content. 15:28:59 ... What are your thoughts about it? 15:29:36 jo: not very compelling in my view. I think that the guideline "The altered SHOULD validate to an appropriate formal grammar" is strong enough. 15:30:12 ... Even if we don't know about any example today, it is conceivable that there may be cases where this is not such a good idea. I'm a bit nervous about putting a MUST here. 15:30:29 rob: is this covered in the best practices somewhere? 15:31:22 jo: I don't think so. We do talk about validation against formal grammars, but there is no mention of well-formedness anywhere. 15:31:28 q+ 15:31:32 ack SeanP 15:31:38 ... not even in mobileOK. 15:31:43 EdC: mobileOK is much stronger. 15:32:05 jo: Indeed. It's a MUST validate against published grammar which encompasses well-formedness. 15:32:37 +q 15:32:47 SeanP: I don't feel so strongly one way or the other. If a CT-proxy generates content that is not well-formed but that works on the end device, then that may be not such a big deal. 15:32:53 q+ to wonder about validation? 15:33:08 ... I don't see that much benefit to have this in there. 15:33:50 ack e 15:33:51 EdC: the point is I have been at the receiving end of transcoding services, and broken content is a great problem to start with. 15:34:36 ... I think you Francois pointed out the MAMA findings that shows that more than 95% of Web content does not validate, so by saying SHOULD we do not say a lot. 15:34:43 ack jo 15:34:43 jo, you wanted to wonder about validation? 15:35:54 jo: I am wondering if any case discussing validation is not out of scope, because it's the way CT-proxies perform transformation. We're spending too much time. Either we should delete the guidelines altogether, either we should take into account Eduardo's proposal. 15:36:27 Rob: don't mind so strongly either. 15:37:09 PROPOSED RESOLUTION: Adopt the wording validate ... and if XML MUST be well formed. 15:37:26 0 15:37:30 0 15:37:30 +1 15:37:37 0 15:38:06 it matches the proposal of Rotan... 15:38:25 [no objection from rob] 15:38:26 RESOLUTION: Adopt the wording validate ... and if XML MUST be well formed. 15:38:44 Topic: Alteration of header fields 15:39:38 -> http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Nov/0019.html Thread 15:39:40 - +44.793.201.aaee 15:41:08 + +44.793.201.aagg 15:41:14 -> http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Dec/0016.html Thread 15:42:28 fd: current idea is to define capability header fields 15:42:42 ... User-Agent, Accept-* fields 15:42:55 ... and to construct a precise algorithm out of it 15:43:18 jo: I think we'll have a problem with IETF in that it is profiling HTTP. 15:43:29 ... not quite sure about the benefits 15:43:30 benefit of accuracy explained in the rationale... 15:44:13 fd: accuracy would be the main benefit. 15:44:28 q+ 15:44:34 jo: I think it's too detailed to be in the round of the text. Don't mind to put it in an explanatory appendix 15:44:39 ack SeanP 15:46:23 SeanP: I agree we should change the text in 4.1.5. Current text says "do not change headers other than User-Agent and blah", which could confuse readers, since other headers such as the Via header may need to be changed by the proxy. 15:46:48 ... so we could add "other headers may be changed according to the HTTP RFC" 15:46:57 Proxies should not change headers other than User Agent and Accept(-*) headers and must not delete headers. It must be possible for the server to reconstruct the original UA originated headers (see 4.1.5.5 Original Headers). 15:46:59 Other than to comply with transparent HTTP operation, proxies should not modify any request headers unless: 15:47:00 1. 15:47:36 Isn't it what stands in the proposal? "except as specified in sections... and except as prescribed by RFC2616 and other 15:47:36 published standards in force, a proxy..." 15:47:39 i/Proxies/Current Text: 15:49:31 fd: one proposal could be to prefix that with Eduardo's proposal: 15:49:51 "Except as specified in sections 4.1.6, 4.1.6.1, 4.2.4 of the present document, and except as prescribed by RFC2616, proxies should not change headers [blah]" 15:50:59 +q 15:52:03 fd: trying to summarize. The problem is that we cannot prescribe things for fear of profiling HTTP. 15:52:37 EdC: how can we say that it MUST be possible to reconstitute the original values if we don't prescribe things precisely? 15:52:40 ack EdC 15:53:07 Other than to comply with transparent HTTP operation, proxies should not modify any request headers unless: 15:54:06 EdC: Suppose the headers get modified by a first CT-proxy, then go through a second one 15:54:16 fd: multiple transcoding proxies are out of scope. 15:54:32 EdC: Well, that's the easy way out... 15:54:36 fd: indeed. 15:54:59 +q 15:56:28 jo: What Eduardo is suggesting is that the first proxy can modify and further proxies cannot. Further proxies may want to put back the original headers and that is acceptable in my view. 15:56:47 EdC: that's not really the case. 15:57:13 ... modified headers must be modified in a predictable way. 15:57:29 q+ 15:57:49 jo: cannot we say that the origin server must be able to reconstruct the original headers? 15:58:22 ack EdC 15:58:58 PROPOSED RESOLUTION: Modify the current text to say: It must be possible for the origin server to reconstruct the original UA originated headers (see 4.1.5.5 Original Headers) directly from corresponding X-Device headers. 15:59:20 PROPOSED RESOLUTION: Modify the current text to say: It must be possible for the origin server to reconstruct the original UA originated headers (see 4.1.5.5 Original Headers) directly from corresponding X-Device header values. 15:59:24 EdC: the point is that the origin server should be able to reconstruct http headers directly. 15:59:35 ack SeanP 16:00:46 SeanP: I think current text bottoms down to the second proxy cannot change the headers. 16:01:24 +1 16:02:07 ...by copying directly the corresponding X-device header field values. 16:02:29 PROPOSED RESOLUTION: Modify the current text to say: It must be possible for the origin server to reconstruct the original UA originated headers (see 4.1.5.5 Original Headers) directly from corresponding X-Device header field values. 16:02:44 +1 16:02:48 +1 16:03:26 PROPOSED RESOLUTION: Modify the current text to say: It must be possible for the origin server to reconstruct the original UA originated headers (see 4.1.5.5 Original Headers) by copying directly from corresponding X-Device header field values. 16:03:50 +1 16:04:02 +1 16:04:13 [+1 from rob on the phone] 16:04:32 +1 16:04:32 RESOLUTION: Modify the current text to say: It must be possible for the origin server to reconstruct the original UA originated headers (see 4.1.5.5 Original Headers) by copying directly from corresponding X-Device header field values. 16:04:58 - +44.793.201.aagg 16:06:40 +q 16:07:38 ack e 16:08:05 fd: Wonder about the purpose of the guideline: Proxies SHOULD NOT change headers" 16:08:07 PROPOSED RESOLUTION: Spell out the exact headers 4.1.5.5 16:08:33 jo: limits the scope of work to reconstruct the original values 16:08:34 PROPOSED RESOLUTION: Spell out the exact headers 4.1.5 16:08:44 +1 16:08:54 +1 16:08:57 PROPOSED RESOLUTION: Spell out the exact headers 4.1.5 (i.e. the exact accept-*) 16:09:03 +1 16:09:04 +1 16:09:07 and user-agent... 16:09:08 +1 16:09:22 RESOLUTION: Spell out the exact headers 4.1.5 (i.e. the exact accept-*) 16:09:33 ACTION-843 16:09:34 ACTION-843? 16:09:34 ACTION-843 -- Jo Rabin to see if he can come up with wording on this section that might accommodate everyone -- due 2008-09-16 -- PENDINGREVIEW 16:09:34 http://www.w3.org/2005/MWI/BPWG/Group/track/actions/843 16:09:38 -jo 16:09:43 Close ACTION-843 16:09:43 ACTION-843 See if he can come up with wording on this section that might accommodate everyone closed 16:10:05 -Francois 16:10:08 -EdC 16:10:16 -SeanP 16:10:18 MWI_BPWG(CTTF)10:00AM has ended 16:10:20 Attendees were Francois, +41.31.972.aaaa, +03531522aabb, EdC, jo, +44.793.201.aacc, +44.793.201.aadd, +44.793.201.aaee, +1.630.414.aaff, SeanP, +44.793.201.aagg 16:10:26 RRSAgent, draft minutes 16:10:26 I have made the request to generate http://www.w3.org/2008/12/09-bpwg-minutes.html francois