IRC log of bpwg on 2008-11-25

Timestamps are in UTC.

14:54:53 [RRSAgent]: RRSAgent has joined #bpwg
14:54:53 [RRSAgent]: logging to http://www.w3.org/2008/11/25-bpwg-irc
14:54:55 [trackbot]: RRSAgent, make logs public
14:54:55 [Zakim]: Zakim has joined #bpwg
14:54:57 [trackbot]: Zakim, this will be BPWG
14:54:57 [Zakim]: ok, trackbot; I see MWI_BPWG(CTTF)10:00AM scheduled to start in 6 minutes
14:54:58 [trackbot]: Meeting: Mobile Web Best Practices Working Group Teleconference
14:54:58 [trackbot]: Date: 25 November 2008
14:56:44 [francois]: Chair: francois
14:56:49 [francois]: Regrets: rob
14:58:04 [tomhume]: francois: I was planning to offer to scribe, are you about to run me through what's required briefly before we start?
14:58:59 [Zakim]: MWI_BPWG(CTTF)10:00AM has now started
14:59:06 [Zakim]: +??P7
14:59:11 [tomhume]: zakim, ??P7 is me
14:59:11 [Zakim]: +tomhume; got it
15:00:54 [Zakim]: +Bryan_Sullivan
15:00:58 [Zakim]: -tomhume
15:01:02 [Zakim]: +tomhume
15:01:22 [Zakim]: +Eduardo
15:01:31 [Bryan]: Bryan has joined #bpwg
15:02:04 [Zakim]: + +95169aaaa
15:02:10 [francois]: zakim, aaaa is me
15:02:10 [Zakim]: +francois; got it
15:02:59 [SeanP]: SeanP has joined #bpwg
15:03:24 [francois]: Scribenick: tomhume
15:03:29 [francois]: Scribe: Tom
15:03:47 [francois]: Agenda: http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Nov/0077.html
15:03:54 [Zakim]: +SeanP
15:04:40 [EdC]: EdC has joined #bpwg
15:04:44 [jo]: jo has joined #bpwg
15:06:28 [EdC]: test. do you receive this? EdC
15:07:03 [Zakim]: + +7.899.72.aabb
15:07:55 [francois]: zakim, aabb is Andrew
15:07:55 [Zakim]: +Andrew; got it
15:08:55 [andrews]: andrews has joined #bpwg
15:09:30 [francois]: zakim, who makes noise?
15:09:30 [Zakim]: I don't understand your question, francois.
15:09:34 [francois]: zakim, who is making noise?
15:09:45 [Zakim]: francois, listening for 10 seconds I heard sound from the following: tomhume (29%)
15:10:14 [tomhume]: Topic: User experience
15:10:31 [jo]: zakim, code?
15:10:31 [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:10:53 [tomhume]: francois: following discussion on-list, Eduardo proposed an algorithm to define "improving the user experience", which is tough to define
15:11:16 [tomhume]: francois: to me this is out of scope as we've decided not to describe the internal operations of proxies
15:11:24 [Zakim]: + +03531522aacc
15:11:33 [jo]: zakim, aacc is me
15:11:33 [Zakim]: +jo; got it
15:12:19 [tomhume]: eduardo: agree to leave the algorithm out of scope
15:12:30 [tomhume]: Topic: W3C mobile addressing standards
15:12:37 [francois]: ISSUE-284?
15:12:38 [trackbot]: ISSUE-284 -- W3C mobile addressing standards -- RAISED
15:12:38 [trackbot]: http://www.w3.org/2005/MWI/BPWG/Group/track/issues/284
15:13:27 [tomhume]: francois: jo raised this issue after the Verizon statement, where they claimed to follow the CT guidelines but advised URI patterns which CT lists as examples
15:14:12 [tomhume]: francois: the interpretation was also that desktop user-agents should be substituted by default. This is contrary to the guidelines we're writing.
15:14:38 [francois]: PROPOSED RESOLUTION: Add some text in 4.1.5 to state that inferring that a desktop User-Agent is needed in the absence of any indication (e.g. URI patterns) is contrary to the guidelines
15:14:47 [SeanP]: q+
15:14:54 [francois]: ack SeanP
15:15:17 [tomhume]: SeanP: Verizon are working on changing this document.
15:17:29 [tomhume]: jo: we're starting to put things in because we've seen them in the wild, which is risky
15:17:47 [francois]: +1
15:17:57 [jo]: +1
15:18:00 [tomhume]: +1
15:18:02 [EdC]: +1
15:18:19 [tomhume]: RESOLUTION: Add some text in 4.1.5 to state that inferring that a desktop User-Agent is needed in the absence of any indication (e.g. URI patterns) is contrary to the guidelines
15:18:45 [tomhume]: Topic: Capability negotiation on the client side
15:19:20 [tomhume]: jo: would like a resolution on the subject of reinforcing the text in the Heuristics appendix to say "these are just heuristics"
15:19:44 [tomhume]: francois: feels the guidelines are clear, but could be emphasised some more
15:20:06 [jo]: PROPOSED RESOLUTION: Beef up text on Heuristics to say that they are *not* endorsed and are not even recommended as good practice
15:20:14 [andrews]: +1
15:20:15 [tomhume]: +1
15:20:27 [francois]: +1
15:21:02 [tomhume]: Eduardo(?): wonders why they're not recommended as best practice
15:21:15 [tomhume]: jo: if we say "it's good practice to use these" we're endorsing them.
15:21:21 [francois]: s/(?)//
15:21:59 [tomhume]: jo: we're saying "this is not advice of best practice, just an observation of what people do"
15:22:57 [tomhume]: jo: Verizon said "these are the W3C endorsed mobile addressing patterns", but we don't endorse them.
15:23:30 [tomhume]: jo: I wouldn't want us to say "it's good practice to use x.domainname or domainname/x", but it's worth our saying "if you're building a CT proxy, these are the things people typically look out for"
15:23:46 [tomhume]: jo: it's unsound to recommend people parse site entry points in any way, it's worth noting that people do do that.
15:24:26 [SeanP]: q+
15:24:32 [Bryan]: q+
15:25:08 [tomhume]: jo: you should send unaltered headers in the first instance
15:25:30 [tomhume]: jo: the pattern of the name should inform you re your decision to do this
15:26:06 [tomhume]: Eduardo: wasn't the Verizon thing taking the counterposition of the guidelines?
15:26:37 [francois]: ack SeanP
15:27:08 [tomhume]: SeanP: I'd like to amend the proposed resolution to say they're not endorsed, but also say "you can't deduce that a site isn't mobile by looking at these patterns"
15:27:32 [francois]: ack Bryan
15:28:19 [tomhume]: Bryan: you can't reliably deduce... but the issue of using specific url/domain-naming conventions is that it's a practice that isn't considered "best practice" but has support.
15:28:20 [EdC]: q+
15:28:52 [tomhume]: ... unless it's driven by W3C/IETF recommendation, we're in danger of creating technology. e.g. some older browsers used WSP instead of HTTP, and it was dropped after a lot of pain
15:29:05 [francois]: ack EdC
15:29:08 [tomhume]: ... we should avoid similar situations by implying that this is a proposed technology approach
15:29:40 [tomhume]: Eduardo: saying that some of these practices aren't good practices will have to be checked. e.g. .mobi domain *is* good practice to recognise a mobile site
15:30:31 [tomhume]: francois: jo, could you suggest some text on the mailing list?
15:30:45 [jo]: ACTION: Jo to propose beefed up text on heuristics in respect of practice vs good practice
15:30:46 [trackbot]: Created ACTION-886 - Propose beefed up text on heuristics in respect of practice vs good practice [on Jo Rabin - due 2008-12-02].
15:31:40 [jo]: q+
15:31:53 [Bryan]: q+
15:32:08 [francois]: ack jo
15:32:12 [tomhume]: francois: we mentioned POWDER as a possibility to let servers communicate with CT proxies. From the clients POV we don't have such a reference, CC/PP could be used a bit more in future. We could refer to this in "scope for future work".
15:32:37 [tomhume]: jo: CC/PP should be retired in a dignified fashion
15:32:39 [francois]: ack Bryan
15:32:42 [JonathanJ]: JonathanJ has joined #bpwg
15:33:24 [tomhume]: bryan: we should look forward to new technology to solve this problem. The OMA (?) group is defining an ontology for device capabilities. Should see something coming to the market in the next year or two.
15:34:21 [tomhume]: bryan: (that's the OMA mobile client environment MCE group)
15:34:29 [jo]: s/(?)/Mobile Client Environment MCE
15:34:34 [francois]: PROPOSED RESOLUTION: do not reference CC/PP in Scope for Future Work as a possible future way to communicate between a mobile device and a CT-proxy because it probably won't be used as such.
15:34:52 [jo]: +1
15:34:52 [EdC]: +1
15:34:54 [francois]: +1
15:35:00 [SeanP]: +1
15:35:02 [tomhume]: RESOLUTION: do not reference CC/PP in Scope for Future Work as a possible future way to communicate between a mobile device and a CT-proxy because it probably won't be used as such.
15:35:23 [tomhume]: Topic: "Dry" statements for Alteration of Response and LC-2053 on Classes of Devices (4.2.8.1)
15:35:54 [tomhume]: francois: conclusion of the discussion from the mailing list was that all normative statements must be testable. We must avoid wishful thinking or unclear statements.
15:36:16 [tomhume]: francois: two statements in particular aren't testable, both in 4.2.8.1
15:36:21 [francois]: ->http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/081107#sec-alteration-of-response section 4.2.8.1
15:37:14 [tomhume]: francois: we have 2 statements saying a proxy must do its best not to break content, and only adapt to make things better for user agents
15:37:18 [EdC]: +q
15:37:50 [tomhume]: francois: how can we reword this along the lines of the Best Practice we have on exploiting device capabilities, or do we need something else?
15:38:02 [francois]: ack EdC
15:38:36 [tomhume]: Eduardo: The first paragraph in 4.2.8.1 is questionable on 2 grounds: it's not testable, and it introduces a restriction in setting the scope for what kind of transformations are allowed
15:38:47 [Bryan]: q+
15:39:01 [tomhume]: ... there are transformations to match the capabilities of the network, not just the handset (e.g. to encode/decode content). This statement prohibits that kind of application.
15:39:17 [tomhume]: francois: doesn't think we want to be this rigid
15:39:55 [francois]: ack Bryan
15:39:55 [tomhume]: Eduardo: there is a document about MWBP, if there should be something stated it should be to that document (perhaps w/chapter references), not as a normative statement but as an indication
15:39:56 [jo]: q+ to agree with the point that these are poor as they stand, and to suggest that someone drafts some proposed text for these bits
15:40:53 [tomhume]: bryan: this is similar to earlier statements we had re the scope of the document. When this doc restricts what a CT proxy can do, it should be explicit that this is only within the scope of what a CT proxy is intended for (translating for purposes of usability), and not for e.g. reducing load of network, which should be outside the scope of these guidelines.
15:41:11 [tomhume]: ... these statements are OK but shouldn't imply a restriction on the same system that's doing CT for other purposes.
15:41:12 [francois]: ack jo
15:41:12 [Zakim]: jo, you wanted to agree with the point that these are poor as they stand, and to suggest that someone drafts some proposed text for these bits
15:41:28 [SeanP]: q+
15:41:56 [tomhume]: jo: happy to adopt that text, but think reformatting images *is* within scope for this doc.
15:41:59 [francois]: ack SeanP
15:42:00 [EdC]: +q
15:42:30 [tomhume]: SeanP: agree this should be non-normative, but not sure referring to BP is much better. "Exploit device capabilities" isn't any more testable than what we have here.
15:42:48 [tomhume]: jo: how about striking these sections altogether?
15:43:07 [francois]: ack EdC
15:43:17 [tomhume]: jo: this is leaning towards talking about proxy internals. proxy vendors should be free to make a lousy product.
15:44:01 [tomhume]: eduardo: introduction of guidelines talk about improving user experience. There could be an indication in an appendix to BP as an information reference.
15:45:21 [francois]: PROPOSED RESOLUTION: Strike first paragraph in section 4.2.8.1 on transformations carried out by CT proxies as it refers to what CT-proxies do (stated in the introduction) and does not have any normative meaning.
15:45:59 [Bryan]: +1
15:46:02 [tomhume]: jo: we've had comment that the bits that matter here (points 1/2/3) get lost in the body
15:46:05 [francois]: +1
15:46:10 [SeanP]: +1
15:46:11 [tomhume]: +1
15:46:12 [jo]: +1
15:46:32 [tomhume]: RESOLUTION: Strike first paragraph in section 4.2.8.1 on transformations carried out by CT proxies as it refers to what CT-proxies do (stated in the introduction) and does not have any normative meaning.
15:46:33 [EdC]: +1
15:46:41 [andrews]: +1
15:46:50 [tomhume]: francois: appendix already contains reference to BP
15:47:03 [EdC]: +q
15:47:28 [francois]: ack EdC
15:48:11 [jo]: ACTION: Jo to put a reference somewhere to the Best Practice about exploiting device capabilities
15:48:11 [trackbot]: Created ACTION-887 - Put a reference somewhere to the Best Practice about exploiting device capabilities [on Jo Rabin - due 2008-12-02].
15:48:25 [jo]: ACTION: Jo to be lucky :-)
15:48:25 [trackbot]: Created ACTION-888 - Be lucky :-) [on Jo Rabin - due 2008-12-02].
15:49:27 [tomhume]: francois: eduardo, you'd like it to apply to 4.2.8 in the list of heuristics
15:49:45 [tomhume]: francois: one of the heuristics would be that the proxy would examine the user-agent
15:50:18 [tomhume]: francois: this goes with features like zoom capability
15:50:19 [francois]: "the user agent has linearization or zoom capabilities or other features which allow it to present the content unaltered"
15:51:16 [tomhume]: eduardo: it's actually not general enough. you might have desktop-capable user agents on a mobile device without linearization, but that's still able to access content from a web server. So you can keep that bullet-point, but there are other properties of user agents which you have to take into account to deal properly with the decision to transform.
15:51:34 [tomhume]: jo: what do we need over and above the phrase "other features"?
15:52:47 [jo]: PROPOSED RESOLUTION: Reword "the user agent has linearization or zoom capabilities or other features which allow it to present the content unaltered" "the user agent has features such as linearization or zoom that allow it to present the content unaltered"
15:53:43 [jo]: PROPOSED RESOLUTION: Reword "the user agent has linearization or zoom capabilities or other features which allow it to present the content unaltered" as "the user agent has features (such as linearization or zoom) that allow it to present the content unaltered"
15:54:20 [tomhume]: francois: perhaps "the user agent as identified by some evidence in the http request"?
15:54:37 [tomhume]: eduardo: didn't someone say evidence is a terminology in some other group?
15:54:44 [tomhume]: francois: used by the DDR Simple API
15:55:29 [tomhume]: jo: we don't care how the user agent is determined
15:55:49 [tomhume]: RESOLUTION: Reword "the user agent has linearization or zoom capabilities or other features which allow it to present the content unaltered" as "the user agent has features (such as linearization or zoom) that allow it to present the content unaltered"
15:55:58 [francois]: Close ACTION-880
15:55:58 [trackbot]: ACTION-880 Review LC-2053 and clarify to group closed
15:56:26 [tomhume]: Topic: LC-2023 - note instead of alteration of the list (4.2.8.1)
15:56:46 [tomhume]: francois: in 4.2.8.1 Jo inserted a note instead of what had been agreed. Are we fine with the note?
15:57:11 [tomhume]: jo: the note should be moved to the top of the section
15:57:36 [jo]: PROPOSED RESOLUTION: Move the note under 4.2.8.1 to the start of the section
15:57:51 [francois]: +1
15:57:59 [tomhume]: RESOLUTION: Move the note under 4.2.8.1 to the start of the section
15:58:01 [francois]: ACTION-881?
15:58:01 [trackbot]: ACTION-881 -- Jo Rabin to enact resolution on 4.2.8.1 ref adding character-encoding to the list of format, layout, dimensions etc. -- due 2008-11-17 -- PENDINGREVIEW
15:58:01 [trackbot]: http://www.w3.org/2005/MWI/BPWG/Group/track/actions/881
15:58:11 [francois]: Close ACTION-881
15:58:11 [trackbot]: ACTION-881 Enact resolution on 4.2.8.1 ref adding character-encoding to the list of format, layout, dimensions etc. closed
15:58:20 [tomhume]: Topic: Validation against formal published grammar (4.2.8.1)
15:59:10 [tomhume]: francois: for the time being, it says SHOULD validate. Discussion on the mailing list is that we could split this into 2 guidelines: content MUST be well formed (if it's XML), the second being that it SHOULD validate to a formal grammar.
15:59:20 [EdC]: are there other formal notions of well-formedness than just for XML?
15:59:23 [francois]: PROPOSED RESOLUTION: ref. Validation against formal published grammar, two guidelines "The altered content MUST be well-formed (if it's XML-based)" and "The altered content SHOULD validate to an appropriate published formal grammar"
15:59:30 [tomhume]: francois: if we split into 2 guidelines, will it be misunderstood?
15:59:35 [jo]: q+ to say that it is probably clearer as it is
15:59:40 [francois]: ack jo
15:59:40 [Zakim]: jo, you wanted to say that it is probably clearer as it is
15:59:58 [tomhume]: jo: it already echoes the language of the BP doc, I'd rather leave as is
16:00:59 [tomhume]: jo: the doc says it SHOULD validate according to a published formal grammar. If there's no published formal grammar for the content type, this can't be complied with (hence this being a SHOULD) and there are reasons not to comply with formal grammars even when you can (hence SHOULD)
16:01:17 [tomhume]: jo: ponders what virtue there is to well-formedness
16:01:48 [tomhume]: eduardo: if we ask for well-formedness we're stating a minimum
16:02:07 [EdC]: +q
16:02:08 [tomhume]: jo: it should still only be a SHOULD; there are cases where well-formedness works less well than non-well-formed on some devices
16:02:14 [francois]: ack EdC
16:02:36 [tomhume]: eduardo: is there an example where non-well-formedness is an example? we couldn't see one.
16:02:54 [SeanP]: q+
16:02:59 [tomhume]: eduardo: there are examples where you want to restrict the whole set of well-formed documents to a smaller set, because of browsers being particular. But these are still well-formed documents.
16:03:10 [francois]: ack SeanP
16:03:46 [tomhume]: SeanP: if we put in a statement about well-formedness, what does it buy us here? Proxies aren't going to create non-well-formed if browsers can't handle them ("don't put in bugs") so why do we need this?
16:03:49 [EdC]: +q
16:03:54 [francois]: ack EdC
16:04:20 [tomhume]: eduardo: if best practice is not to put in bugs, well-formedness is the way not to put in bugs.
16:05:18 [tomhume]: francois: I share Sean and Jo's POV, that there isn't enough added value to say "content must be well formed" given that there could be an example where this isn't required. What value does having two statements instead of one add?
16:05:45 [jo]: -1 to well formed
16:05:55 [EdC]: +1 to wf
16:05:59 [francois]: 0 to well formed
16:06:01 [Bryan]: -1
16:06:03 [tomhume]: 0
16:06:07 [andrews]: 0
16:06:14 [SeanP]: -1 to well formed, but I don't care that much
16:06:42 [tomhume]: francois: let's think about this and return to it next week
16:07:20 [Zakim]: -Bryan_Sullivan
16:07:21 [Zakim]: -jo
16:07:23 [Zakim]: -SeanP
16:07:25 [Zakim]: -Eduardo
16:07:26 [Zakim]: -Andrew
16:07:26 [Zakim]: -tomhume
16:07:27 [Zakim]: -francois
16:07:27 [Zakim]: MWI_BPWG(CTTF)10:00AM has ended
16:07:28 [Zakim]: Attendees were tomhume, Bryan_Sullivan, Eduardo, +95169aaaa, francois, SeanP, +7.899.72.aabb, Andrew, +03531522aacc, jo
16:09:46 [francois]: RRSAgent, draft minutes
16:09:46 [RRSAgent]: I have made the request to generate http://www.w3.org/2008/11/25-bpwg-minutes.html francois
16:43:56 [JonathanJ]: JonathanJ has joined #bpwg
17:03:14 [francois]: RRSAgent, bye
17:03:14 [RRSAgent]: I see 3 open action items saved in http://www.w3.org/2008/11/25-bpwg-actions.rdf :
17:03:14 [RRSAgent]: ACTION: Jo to propose beefed up text on heuristics in respect of practice vs good practice [1]
17:03:14 [RRSAgent]: recorded in http://www.w3.org/2008/11/25-bpwg-irc#T15-30-45
17:03:14 [RRSAgent]: ACTION: Jo to put a reference somewhere to the Best Practice about exploiting device capabilities [2]
17:03:14 [RRSAgent]: recorded in http://www.w3.org/2008/11/25-bpwg-irc#T15-48-11
17:03:14 [RRSAgent]: ACTION: Jo to be lucky :-) [3]
17:03:14 [RRSAgent]: recorded in http://www.w3.org/2008/11/25-bpwg-irc#T15-48-25
17:03:19 [francois]: Zakim, bye
17:03:19 [Zakim]: Zakim has left #bpwg