IRC log of bpwg on 2008-12-09

Timestamps are in UTC.

14:59:52 [RRSAgent]: RRSAgent has joined #bpwg
14:59:52 [RRSAgent]: logging to http://www.w3.org/2008/12/09-bpwg-irc
14:59:54 [trackbot]: RRSAgent, make logs public
14:59:54 [Zakim]: Zakim has joined #bpwg
14:59:56 [trackbot]: Zakim, this will be BPWG
14:59:56 [Zakim]: ok, trackbot; I see MWI_BPWG(CTTF)10:00AM scheduled to start in 1 minute
14:59:57 [trackbot]: Meeting: Mobile Web Best Practices Working Group Teleconference
14:59:57 [trackbot]: Date: 09 December 2008
15:00:16 [francois]: Agenda: http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Dec/0029.html
15:00:19 [francois]: Chair: francois
15:01:04 [francois]: Regrets: rob, tom
15:04:11 [jo]: jo has joined #bpwg
15:04:30 [EdC]: EdC has joined #bpwg
15:04:44 [jo]: zakim, code?
15:04:48 [Zakim]: 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 [Zakim]: MWI_BPWG(CTTF)10:00AM has now started
15:05:11 [Zakim]: +Francois
15:05:37 [Zakim]: + +41.31.972.aaaa
15:06:39 [Zakim]: + +03531522aabb
15:06:45 [francois]: zakim, aaaa is EdC
15:06:45 [Zakim]: +EdC; got it
15:06:56 [jo]: zakim, aabb is me
15:06:56 [Zakim]: +jo; got it
15:08:11 [AndreaT]: AndreaT has joined #bpwg
15:12:32 [Zakim]: + +44.793.201.aacc
15:13:44 [AndreaT]: AndreaT has left #bpwg
15:13:52 [Zakim]: - +44.793.201.aacc
15:14:41 [Zakim]: + +44.793.201.aadd
15:15:09 [EdC]: +q
15:15:20 [francois]: ack EdC
15:18:02 [jo]: 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 [EdC]: any dependencies on other work? e.g. mobileOK, Best practices, etc...?
15:18:13 [Zakim]: - +44.793.201.aadd
15:18:39 [francois]: ack jo
15:18:39 [Zakim]: 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 [jo]: ack me
15:19:33 [EdC]: +q
15:19:46 [francois]: ack EdC
15:20:52 [francois]: Scribe: francois
15:21:01 [francois]: Topic: Pagination definition
15:21:09 [francois]: -> http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Dec/0028.html thread
15:21:26 [francois]: 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 [jo]: +20
15:22:40 [francois]: +1
15:23:31 [francois]: 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 [EdC]: +1
15:23:39 [francois]: 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 [Zakim]: + +44.793.201.aaee
15:24:55 [SeanP]: SeanP has joined #bpwg
15:26:24 [Zakim]: + +1.630.414.aaff
15:26:35 [SeanP]: Zakim, aaff is me
15:26:35 [Zakim]: +SeanP; got it
15:26:53 [francois]: Topic: Validation against formal published grammar
15:27:13 [francois]: -> http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Nov/0037.html thread
15:28:31 [francois]: fd: strong positions in favor of a guideline along the lines of "The altered content MUST be well-formed"
15:28:37 [francois]: ... not too strong positions against it.
15:28:49 [EdC]: for xml-based content.
15:28:59 [francois]: ... What are your thoughts about it?
15:29:36 [francois]: 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 [francois]: ... 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 [francois]: rob: is this covered in the best practices somewhere?
15:31:22 [francois]: 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 [SeanP]: q+
15:31:32 [francois]: ack SeanP
15:31:38 [francois]: ... not even in mobileOK.
15:31:43 [francois]: EdC: mobileOK is much stronger.
15:32:05 [francois]: jo: Indeed. It's a MUST validate against published grammar which encompasses well-formedness.
15:32:37 [EdC]: +q
15:32:47 [francois]: 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 [jo]: q+ to wonder about validation?
15:33:08 [francois]: ... I don't see that much benefit to have this in there.
15:33:50 [jo]: ack e
15:33:51 [francois]: 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 [francois]: ... 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 [francois]: ack jo
15:34:43 [Zakim]: jo, you wanted to wonder about validation?
15:35:54 [francois]: 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 [francois]: Rob: don't mind so strongly either.
15:37:09 [jo]: PROPOSED RESOLUTION: Adopt the wording validate ... and if XML MUST be well formed.
15:37:26 [jo]: 0
15:37:30 [francois]: 0
15:37:30 [EdC]: +1
15:37:37 [SeanP]: 0
15:38:06 [EdC]: it matches the proposal of Rotan...
15:38:25 [francois]: [no objection from rob]
15:38:26 [francois]: RESOLUTION: Adopt the wording validate ... and if XML MUST be well formed.
15:38:44 [francois]: Topic: Alteration of header fields
15:39:38 [francois]: -> http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Nov/0019.html Thread
15:39:40 [Zakim]: - +44.793.201.aaee
15:41:08 [Zakim]: + +44.793.201.aagg
15:41:14 [francois]: -> http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Dec/0016.html Thread
15:42:28 [francois]: fd: current idea is to define capability header fields
15:42:42 [francois]: ... User-Agent, Accept-* fields
15:42:55 [francois]: ... and to construct a precise algorithm out of it
15:43:18 [francois]: jo: I think we'll have a problem with IETF in that it is profiling HTTP.
15:43:29 [francois]: ... not quite sure about the benefits
15:43:30 [EdC]: benefit of accuracy explained in the rationale...
15:44:13 [francois]: fd: accuracy would be the main benefit.
15:44:28 [SeanP]: q+
15:44:34 [francois]: 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 [francois]: ack SeanP
15:46:23 [francois]: 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 [francois]: ... so we could add "other headers may be changed according to the HTTP RFC"
15:46:57 [jo]: 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 [jo]: Other than to comply with transparent HTTP operation, proxies should not modify any request headers unless:
15:47:00 [jo]: 1.
15:47:36 [EdC]: Isn't it what stands in the proposal? "except as specified in sections... and except as prescribed by RFC2616 and other
15:47:36 [EdC]: published standards in force, a proxy..."
15:47:39 [jo]: i/Proxies/Current Text:
15:49:31 [francois]: fd: one proposal could be to prefix that with Eduardo's proposal:
15:49:51 [francois]: "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 [EdC]: +q
15:52:03 [francois]: fd: trying to summarize. The problem is that we cannot prescribe things for fear of profiling HTTP.
15:52:37 [francois]: 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 [francois]: ack EdC
15:53:07 [jo]: Other than to comply with transparent HTTP operation, proxies should not modify any request headers unless:
15:54:06 [francois]: EdC: Suppose the headers get modified by a first CT-proxy, then go through a second one
15:54:16 [francois]: fd: multiple transcoding proxies are out of scope.
15:54:32 [francois]: EdC: Well, that's the easy way out...
15:54:36 [francois]: fd: indeed.
15:54:59 [EdC]: +q
15:56:28 [francois]: 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 [francois]: EdC: that's not really the case.
15:57:13 [francois]: ... modified headers must be modified in a predictable way.
15:57:29 [SeanP]: q+
15:57:49 [francois]: jo: cannot we say that the origin server must be able to reconstruct the original headers?
15:58:22 [francois]: ack EdC
15:58:58 [jo]: 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 [jo]: 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 [francois]: EdC: the point is that the origin server should be able to reconstruct http headers directly.
15:59:35 [francois]: ack SeanP
16:00:46 [francois]: SeanP: I think current text bottoms down to the second proxy cannot change the headers.
16:01:24 [SeanP]: +1
16:02:07 [EdC]: ...by copying directly the corresponding X-device header field values.
16:02:29 [jo]: 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 [francois]: +1
16:02:48 [SeanP]: +1
16:03:26 [jo]: 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 [SeanP]: +1
16:04:02 [francois]: +1
16:04:13 [francois]: [+1 from rob on the phone]
16:04:32 [jo]: +1
16:04:32 [francois]: 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 [Zakim]: - +44.793.201.aagg
16:06:40 [EdC]: +q
16:07:38 [jo]: ack e
16:08:05 [francois]: fd: Wonder about the purpose of the guideline: Proxies SHOULD NOT change headers"
16:08:07 [jo]: PROPOSED RESOLUTION: Spell out the exact headers 4.1.5.5
16:08:33 [francois]: jo: limits the scope of work to reconstruct the original values
16:08:34 [jo]: PROPOSED RESOLUTION: Spell out the exact headers 4.1.5
16:08:44 [francois]: +1
16:08:54 [EdC]: +1
16:08:57 [jo]: PROPOSED RESOLUTION: Spell out the exact headers 4.1.5 (i.e. the exact accept-*)
16:09:03 [SeanP]: +1
16:09:04 [jo]: +1
16:09:07 [EdC]: and user-agent...
16:09:08 [francois]: +1
16:09:22 [francois]: RESOLUTION: Spell out the exact headers 4.1.5 (i.e. the exact accept-*)
16:09:33 [francois]: ACTION-843
16:09:34 [francois]: ACTION-843?
16:09:34 [trackbot]: 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 [trackbot]: http://www.w3.org/2005/MWI/BPWG/Group/track/actions/843
16:09:38 [Zakim]: -jo
16:09:43 [francois]: Close ACTION-843
16:09:43 [trackbot]: ACTION-843 See if he can come up with wording on this section that might accommodate everyone closed
16:10:05 [Zakim]: -Francois
16:10:08 [Zakim]: -EdC
16:10:16 [Zakim]: -SeanP
16:10:18 [Zakim]: MWI_BPWG(CTTF)10:00AM has ended
16:10:20 [Zakim]: 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 [francois]: RRSAgent, draft minutes
16:10:26 [RRSAgent]: I have made the request to generate http://www.w3.org/2008/12/09-bpwg-minutes.html francois