IRC log of bpwg on 2009-01-13

Timestamps are in UTC.

14:28:06 [RRSAgent]: RRSAgent has joined #bpwg
14:28:06 [RRSAgent]: logging to http://www.w3.org/2009/01/13-bpwg-irc
14:28:08 [trackbot]: RRSAgent, make logs public
14:28:08 [Zakim]: Zakim has joined #bpwg
14:28:10 [trackbot]: Zakim, this will be BPWG
14:28:10 [Zakim]: ok, trackbot; I see MWI_BPWG()9:30AM scheduled to start in 2 minutes
14:28:11 [trackbot]: Meeting: Mobile Web Best Practices Working Group Teleconference
14:28:11 [trackbot]: Date: 13 January 2009
14:28:17 [francois]: Chair: jo
14:28:25 [francois]: Regrets: DKA, SeanP, DavidStorey, abel, nacho
14:29:11 [jo]: zakim, code?
14:29:11 [Zakim]: the conference code is 2794 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), jo
14:29:46 [Zakim]: MWI_BPWG()9:30AM has now started
14:29:53 [Zakim]: + +2
14:29:58 [tomhume]: zakim, +2 is me
14:29:58 [Zakim]: +tomhume; got it
14:30:07 [jo]: /me +2???
14:30:10 [Zakim]: +matthias_samwald
14:30:16 [francois]: zakim, mute me
14:30:16 [Zakim]: sorry, francois, I do not know which phone connection belongs to you
14:30:33 [Zakim]: +Jeff
14:30:40 [francois]: zakim, matthias_samwalt is really francois
14:30:40 [Zakim]: sorry, francois, I do not recognize a party named 'matthias_samwalt'
14:30:48 [francois]: zakim, matthias_samwald is really francois
14:30:48 [Zakim]: +francois; got it
14:31:01 [francois]: zakim, mute me
14:31:01 [Zakim]: francois should now be muted
14:31:08 [Zakim]: +jo
14:31:18 [EdC]: EdC has joined #bpwg
14:31:19 [francois]: zakim, unmute me
14:31:19 [Zakim]: francois should no longer be muted
14:31:49 [rob]: rob has joined #bpwg
14:31:52 [francois]: zakim, mute me
14:31:52 [Zakim]: francois should now be muted
14:32:00 [Zakim]: +Dom
14:32:21 [Zakim]: +rob
14:33:00 [dom]: zakim, mute me
14:33:00 [Zakim]: Dom should now be muted
14:33:41 [Zakim]: +Bryan_Sullivan
14:34:03 [Zakim]: +??P17
14:34:12 [yeliz]: zakim, ??P17 is yeliz
14:34:12 [Zakim]: +yeliz; got it
14:34:28 [yeliz]: zakim, mute yeliz
14:34:28 [Zakim]: yeliz should now be muted
14:34:39 [Zakim]: +EdC
14:34:55 [Bryan]: Bryan has joined #bpwg
14:35:23 [dom]: zakim, who's on the call?
14:35:23 [Zakim]: On the phone I see tomhume, francois (muted), Jeff, jo, Dom (muted), rob, Bryan_Sullivan, yeliz (muted), EdC
14:35:54 [jo]: Agenda: http://lists.w3.org/Archives/Public/public-bpwg/2009Jan/0005.html
14:36:20 [jo]: scribe: tom
14:36:28 [jo]: scribenick: tomhume
14:36:58 [francois]: zakim, unmute me
14:36:58 [Zakim]: francois should no longer be muted
14:36:58 [tomhume]: Topic: F2F Poll [1] as announced [2] by Francois
14:37:13 [tomhume]: francois: this should run for 1 week.
14:37:19 [francois]: zakim, mute me
14:37:19 [Zakim]: francois should now be muted
14:37:30 [miguel]: miguel has joined #bpwg
14:37:45 [achuter]: achuter has joined #bpwg
14:37:46 [tomhume]: jo: Please answer ASAP. London is in the lead, by a short head.
14:37:55 [francois]: -> http://www.w3.org/2002/09/wbs/37584/BPWG-Possible-F2F-March-2009/ questionnaire on next F2F's location
14:38:09 [tomhume]: jo: Dan has an action to find hosts for Boston etc.
14:38:14 [Zakim]: +miguel
14:38:21 [jo]: zakim, who is making noise?
14:38:31 [Zakim]: jo, listening for 10 seconds I heard sound from the following: jo (37%), Bryan_Sullivan (5%)
14:38:55 [yeliz]: zakim, unmute yeliz
14:38:55 [Zakim]: yeliz should no longer be muted
14:39:09 [jo]: zakim, who is on the call?
14:39:09 [Zakim]: On the phone I see tomhume, francois (muted), Jeff, jo, Dom (muted), rob, Bryan_Sullivan, yeliz, EdC, miguel
14:39:17 [Zakim]: + +003491121aabb
14:39:35 [francois]: zakim, aabb is achuter
14:39:35 [Zakim]: +achuter; got it
14:40:07 [tomhume]: Topic: Update on Mobile Accessibility
14:40:30 [tomhume]: alan: Sent a message to the list, but it didn't arrive.
14:41:15 [yeliz]: zakim, mute yeliz
14:41:15 [Zakim]: yeliz should now be muted
14:41:23 [jo]: /me WCAG 2.0, tomhume
14:41:31 [tomhume]: ... It was updated in October, I haven't done any work on it yet. WCAG became a W3C recommendation end December, but it's still pending some changes from Sean and Lisa in the Education & Outreach WG. Next week I'll do this, publish a new version which can be approved by the working group.
14:41:40 [tomhume]: ... No more work required by the group at the moment.
14:42:07 [jo]: s/me WCAG 2.0, tomhume//
14:42:15 [tomhume]: ... Before next weeks call (before Monday next week) I should be able to update it, so we can review Tuesday and the following Friday the EOWG can review and pass onto the WCAG.
14:42:28 [tomhume]: jo: We should give this group a week to review, so if you could get out by Monday that'd be great.
14:42:52 [tomhume]: Topic: CT Issues
14:43:12 [francois]: zakim, unmute me
14:43:13 [Zakim]: francois should no longer be muted
14:43:20 [achuter]: zakim, mute me
14:43:20 [Zakim]: achuter should now be muted
14:43:54 [tomhume]: francois: the main topic that remains re CTG are those in the agenda, plus a few details
14:44:29 [tomhume]: ... Mandating respect of explicit mobile heuristics, mandating meaning the CT proxy SHOULD NOT transcode responses where these heuristics are found
14:45:29 [tomhume]: ... There's discussion on the CT mailing list for the time being around this. I've not had time to go through Eduardo's last response. I suggest we postpone the discussion til next week, in Sean's absence
14:45:39 [tomhume]: jo: Plus we've not aired this discussion on the list.
14:45:40 [EdC]: +1 for postponing.
14:46:15 [tomhume]: q+ to note that there were some points of feedback due re transcoding of HTTPS content
14:46:48 [dom]: queue=
14:47:07 [jo]: ACTION: Francois to stimulate discussion on the SHOULD NOT question ref mobile heuristics
14:47:08 [trackbot]: Created ACTION-896 - Stimulate discussion on the SHOULD NOT question ref mobile heuristics [on François Daoust - due 2009-01-20].
14:47:20 [tomhume]: tomhume: we're also awaiting some feedback re safe means to transcode HTTPS content from the transcoder folks
14:47:42 [tomhume]: jo: This was an action on Sean, I think?
14:47:48 [francois]: ISSUE-285?
14:47:48 [trackbot]: ISSUE-285 -- Does BPWG feel it can write Best Practices on links rewriting in the CT guidelines? Or that it cannot be a best practice? -- OPEN
14:47:48 [trackbot]: http://www.w3.org/2005/MWI/BPWG/Group/track/issues/285
14:48:12 [tomhume]: francois: there are two things - issue-285 to get advice from the main body of the working group on best practices around security guidelines.
14:48:23 [tomhume]: ... and an action from Rob to start ???ing different guidelines being composed.
14:48:49 [jo]: Topic: HTTPS Link Rewriting
14:49:18 [Zakim]: -EdC
14:49:26 [Zakim]: -francois
14:49:46 [tomhume]: jo: for the benefit of the WG here, we reached a stalemate in discussion and Rob took an action to write some guidelines on "is there anything we can say is best practice around the idea of intercepting links that people have deliberately designated as secure". The task-force was evenly divided between (lost Jo there)
14:50:27 [Zakim]: + +0121707aacc
14:50:33 [jsmanrique]: jsmanrique has joined #bpwg
14:50:50 [jo]: s/(lost Jo there)/those that thought not and those that think saying something is essential
14:50:54 [dom]: zakim, aacc is bruce
14:50:54 [Zakim]: +bruce; got it
14:50:56 [dom]: zakim, code?
14:50:56 [Zakim]: the conference code is 2794 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), dom
14:51:20 [EdC]: I was suddenly diverted to another call, and now cannot join the number at +33 (busy tone).
14:51:27 [Zakim]: +??P7
14:51:33 [francois]: zakim, ??P7 is me
14:51:33 [Zakim]: +francois; got it
14:52:45 [tomhume]: jo: for HTTPS, we're waiting for a discussion on-list
14:52:55 [tomhume]: Topic: X-Device-* HTTP header fields
14:53:12 [Zakim]: + +04131972aadd
14:53:42 [jsmanrique]: jsmanrique has joined #bpwg
14:54:16 [tomhume]: francois: in the guidelines we emphasise that whenever a CT proxy changes one of the HTTP Header fields it must add an X-Device- and the name of the original field, so that the origin server can reconstruct the original HTTP request from these headers. The problem is with the registration of these fields: X- means experimental, by definition we cannot register this and new header fields must be registered with the IETF.
14:54:51 [Zakim]: -tomhume
14:55:17 [jo]: PROPOSED RESOLUTION: We will document this as X-TBD-* headers and explain that registration is being sought and that implementations should expect to see both with and without the X-
14:55:23 [Zakim]: +??P5
14:55:26 [yeliz]: zakim, mute yeliz
14:55:26 [Zakim]: yeliz was already muted, yeliz
14:55:33 [jeffs]: this seems no longer "experimental", so move to Provisional Header reg at IETF instead of X-Device-* makes sense to me, so it would have my +1
14:55:48 [Zakim]: -Jeff
14:56:09 [jo]: zakim, ??P5 is tomhume
14:56:09 [Zakim]: +tomhume; got it
14:56:12 [Zakim]: +martin_spain
14:56:47 [jo]: [francois notes that we may have objections to going to rec with X- and also that the Device- prefix is overloaded
14:57:24 [EdC]: Comment: some other standards have kept x-* fields (e.g. Uaprof), without registration. Registering different fields will require supporting both for the foreseeable future both in CT-proxies and application servers. Is there a KO criterion to go the way of registration?
14:57:27 [jo]: s/overloaded/overloaded]
14:58:17 [jo]: PROPOSED RESOLUTION: We will document this as X-TBD-* headers and explain that registration is being sought and that implementations should expect to see both with and without the X-
14:59:02 [tomhume]: tomhume has joined #BPWG
14:59:09 [francois]: [I don't think the "Device-" header is overloaded. The "Original-" header is, which was one of the possibilities to improve the header name in the first place.]
14:59:43 [tomhume]: jo: edC, I understand the point re keeping X- fields
14:59:54 [jsmanrique]: jsmanrique has joined #bpwg
14:59:55 [francois]: q+
15:00:02 [jo]: ack f
15:00:06 [tomhume]: ... my feeling is that we can get away with it by noting this as what we're seeing.
15:00:56 [achuter]: zakim, unmute me
15:00:56 [Zakim]: achuter should no longer be muted
15:00:58 [Bryan]: sorry, have to drop off for another call
15:01:04 [Zakim]: -Bryan_Sullivan
15:01:13 [achuter]: zakim, mute me
15:01:15 [Zakim]: achuter should now be muted
15:01:23 [francois]: [My point is if we are to change the name of the X- headers, then we should as well register proper names *without* the X- prefix!]
15:01:56 [tomhume]: jo: I don't think the point is whether we register an X- header, it's that we can't do this
15:02:17 [tomhume]: jo: the proposed resolution is we document as X- headers and proceed in parallel with registration. Any objections?
15:02:22 [francois]: q+
15:02:50 [tomhume]: francois: I think the proposed resolution should be to document this as X-Device-
15:03:06 [tomhume]: ... if you change the name there's no reason to keep the X-, we can register proper headers if we invent a new header.
15:03:17 [jo]: PROPOSED RESOLUTION: We will document this as X-Device-* headers and explain that registration is being sought and that implementations should expect to see both with and without the X-
15:03:25 [jo]: ack f
15:03:37 [jo]: +1
15:03:38 [EdC]: What is the ultimate relation between X-Device-* and the TBD-* ? Migration?
15:03:54 [tomhume]: jo: the TBD is no longer on the table
15:04:02 [rob]: +1
15:04:26 [francois]: +1
15:04:32 [EdC]: MUST implementations support both?
15:04:45 [EdC]: SHOULD or MUST?
15:04:53 [tomhume]: jo: they SHOULD
15:05:01 [jsmanrique]: jsmanrique has joined #bpwg
15:05:04 [EdC]: To be practical: what must the CT-proxies support?
15:05:04 [brucel]: brucel has joined #bpwg
15:06:05 [tomhume]: edC: if there are two header fields, then app servers must support both. What will the CT proxies have to do? MUST they support the registered header field once the registration passes? Can they just continue with the older experimental header fields?
15:06:31 [tomhume]: jo: we'll have a problem if there's a MUST surrounding a future event, this is probably a W3C (???)
15:06:46 [jo]: s/(???)/conformance question
15:06:51 [tomhume]: edC: there is a question of the migration path. Also, can it be that a proxy supports both at the same time?
15:07:32 [tomhume]: edC: Should it put the header into both? There's nothing to prevent it, but this is linked to the previous question.
15:07:46 [tomhume]: jo: it'd be good if we just had one. How long will it take to register these headers?
15:08:01 [EdC]: q+
15:08:22 [tomhume]: francois: it's easily done, we need to define the headers in the guidelines (which we're doing anyway) then send an email to the IETF.
15:08:40 [tomhume]: jo: so there'll be no dependency from the IETF delaying us?
15:09:18 [jo]: ack ed
15:09:19 [tomhume]: francois: there's a small risk of their not liking the name (but I don't think we need to worry about that). The registration doesn't take long and isn't hard to do.
15:09:56 [jsmanrique]: jsmanrique has joined #bpwg
15:10:13 [tomhume]: edC: There was a question that it'd be good if we just had 1 field. On the migration path: if after some time the TBD header fields come into force, CT proxies will need to send both to keep app servers working with old and new headers working... and you don't want to exclude one or the other.
15:11:08 [jo]: PROPOSED RESOLUTION: We will go ahead and register the DEVICE-* headers and review progress. We will document that Proxies MUST use these headers and note taht they SHOULD use the X-Device headers at least initially for backwards compatibility reasons
15:11:38 [tomhume]: q+
15:11:42 [jo]: ack t
15:12:04 [tomhume]: tomhume: will this mean that on publication of the CTG, every proxy is in conflict with them?
15:12:08 [tomhume]: jo: possibly true
15:12:36 [tomhume]: rob: I can't comment, I'm not sure how our proxy works.
15:12:37 [rob]: q+
15:12:44 [jo]: ack r
15:13:28 [EdC]: Record the resolution proposal and postpone it to when all other CT-proxy-representatives are present to comment?
15:13:49 [tomhume]: rob: being able to duplicate the header and having 2 is harder than just changing the header
15:14:03 [tomhume]: jo: This problem is partly introduced by the convention of X-
15:14:18 [tomhume]: rob: our preference is to change the header... but some applications may be looking for one value, others for another.
15:14:26 [tomhume]: ... Eduardo's problem still exists.
15:15:16 [tomhume]: jo: we can't standardise on current practices; we will face this problem.
15:15:25 [jo]: PROPOSED RESOLUTION: We will go ahead and register the DEVICE-* headers and review progress. We will document that Proxies MUST use these headers and note that they SHOULD use the X-Device headers at least initially for backwards compatibility reasons
15:15:35 [francois]: +1
15:15:41 [rob]: +1
15:15:46 [tomhume]: +1
15:15:52 [jo]: straw poll, -1 if you think we do not have enough info to proceed +1 to take the resolution
15:16:00 [jo]: +1
15:16:18 [tomhume]: +1 straw poll
15:16:19 [brucel]: abstention
15:16:43 [tomhume]: rob: resolution avoids issue of using both
15:16:48 [brucel]: abstention from resolution
15:16:48 [tomhume]: jo: effectively it says they SHOULD use both
15:16:56 [jsmanrique]: jsmanrique has joined #bpwg
15:17:17 [tomhume]: rob: this may last for years.
15:17:25 [tomhume]: jo: it will. I see no objections, are there any?
15:17:28 [jo]: PROPOSED RESOLUTION: We will go ahead and register the DEVICE-* headers and review progress. We will document that Proxies MUST use these headers and note that they SHOULD use the X-Device headers at least initially for backwards compatibility reasons
15:17:32 [jo]: objections?
15:17:40 [EdC]: -0.5
15:18:00 [tomhume]: jo: that counts. How would you like to fix this up?
15:18:40 [EdC]: Is there a criterion to phase out the X-device fields?
15:19:13 [EdC]: Are there W3C deprecation criteria or rules?
15:19:16 [tomhume]: jo: not that I know of. Anyone know enough about the use of X- convention, to determine what IETF think about this?
15:20:08 [tomhume]: jo: Eduardo, can you take an action to research what ??? X- ????
15:20:34 [jsmanrique]: jsmanrique has joined #bpwg
15:20:38 [jo]: ACTION: EdC to establish what best current practice is with regard the withrawal of use of X- once the non X- form is agreed
15:20:38 [trackbot]: Sorry, couldn't find user - EdC
15:20:42 [EdC]: ok.
15:20:53 [jo]: ACTION: casais to establish what best current practice is with regard the withrawal of use of X- once the non X- form is agreed
15:20:53 [trackbot]: Created ACTION-897 - Establish what best current practice is with regard the withrawal of use of X- once the non X- form is agreed [on Eduardo Casais - due 2009-01-20].
15:21:11 [tomhume]: jo: we'll come back to this later.
15:21:24 [tomhume]: Topic: re-consider our position regarding the use of Cache-Control extension mechanisms
15:22:17 [tomhume]: jo: we did look at this, there were some suggestions wrt extending Cache-control in the first drafts of the document. We decided unequivocally that any such changes would be a substantial change to HTTP, so these were dropped and moved to a discussion at the end of the document as "an area for further work". I feel relatively strongly that we should not reopen this point.
15:22:38 [tomhume]: q+
15:22:43 [jo]: ack t
15:24:01 [tomhume]: tomhume: this was an area of HTTP specifically written with future extensibility in mind, as opposed to a new header. I wasn't privy to original discussions and not sure what HTTP profiling is.
15:24:39 [tomhume]: jo: we have had pushback from IETF... and we're not chartered to do this. Whilst we do skirt narrowly around the border of "new technology", though this feels firmly in that area.
15:25:46 [tomhume]: Francois: I remember having done some research on that and we had extensive discussions in the past. The extensions don't solve the entire problem, so aren't a satisfactory enough solution and doesn't add much to the no-transform directive (it does fix cases where it can't be used safely, but doesn't do much more). For this reason on top of the ones Jo mentioned, I don't think it's a good idea to go down this path.
15:25:57 [jo]: PROPOSED RESOLUTION:We will not reconsider the question of extending the cache-control directive for CT usage
15:26:01 [jo]: +1
15:26:06 [francois]: +1
15:26:07 [rob]: +1
15:26:13 [EdC]: It is more: we have reconsidered and decided against it?
15:26:19 [EdC]: +1
15:26:30 [tomhume]: +1
15:26:43 [jo]: [yes, EdC we will not reconsider the previous negative on this, it remains negative]
15:26:49 [tomhume]: RESOLUTION:We will not reconsider the question of extending the cache-control directive for CT usage
15:27:18 [tomhume]: Topic: Included resources of a non transformed resource should not be transformed.
15:27:25 [EdC]: q+
15:28:10 [tomhume]: jo: there's no practical mechanism to put no-transform onto included resources, and it may be difficult to put this onto resources referenced from html
15:28:13 [jo]: ack edc
15:28:25 [tomhume]: edC: does everyone understand the proposal?
15:28:33 [tomhume]: q+ to wonder about resources not referenced from markup
15:28:49 [tomhume]: edC: this applies to stylesheets, images
15:30:37 [tomhume]: edC: the first one is a subtle point: cache-control isn't attached to a document, but to an HTTP request or response, so we're subtly tweaking a part of the HTTP stack. In essence the sub-parts of the document will provoke further HTTP requests and responses. But here we're making an aggregation and shifting the association of the cache-control directive to a set of documents. It's a subtle thing but if people are complaining about profiling HTTP they might compla
15:30:43 [tomhume]: jo: I (regretfully) agree
15:31:10 [francois]: [I agree too]
15:31:18 [tomhume]: jo: we may be extending the meaning of http in a way they don't like
15:32:00 [tomhume]: edC: we're effectively closing the door to an (unimportant?) use case. You might have a document you want left alone, with images converted. If you extend no-transform to apply to everything below you close the door to this.
15:33:07 [tomhume]: edC: I'm also afraid this kind of functionality will impose a very specific architecture for CT proxies. You have 2 choices: a proxy grabs the first HTTP request from the terminal, collects document, collects sub-parts, then decides to transform or not.
15:34:04 [tomhume]: ... or you just get the first HTTP request for markup, send it back (untransformed in this case) then the terminal sends another HTTP request at which point you have to be able to associate this with the earlier request. This means you have to implement sessioning, or change the way the proxy works and fall back on the first mechanism.
15:34:24 [rob]: q+
15:35:59 [jo]: ack t
15:35:59 [Zakim]: tomhume, you wanted to wonder about resources not referenced from markup
15:36:10 [jo]: ack r
15:36:14 [tomhume]: tomhume: images may not be referred from a page (e.g. wallpapers, screensavers); also requests might include sub-requests (HTML references SVG document references sub-document etc etc.)
15:36:41 [tomhume]: rob: a CT does have to have some concept of browsing sessions to work in the way they do. There may be simpler transformations which don't need sessions, but if you're going to adapt HTML (partic. with scripts) you do need a session concept.
15:36:52 [francois]: q+
15:36:53 [jo]: PROPOSED RESOLUTION: We will not say anything about transforming included resources [that was not your best ever idea Jo]
15:38:02 [tomhume]: francois; in the case of cache-control: no-transform, I agree with edC. In the case of explicit heuristics, here we have some semantics saying the main document is for mobile, therefore sub-documents can be assumed to be mobile too.
15:38:35 [tomhume]: ... if we mandate some heuristics we should caveat that it's not easy to link a request for an embedded resource to the request for the main document.
15:39:20 [tomhume]: jo: aren't we saying that for all the reasons listed here, it's not workable. To link it back in as a mandatory heuristic... ???
15:39:44 [jo]: c/???/would not be wise, surely
15:39:49 [Zakim]: -achuter
15:40:03 [jo]: s|c/???/would not be wise, surely||
15:40:11 [jo]: s/???/would not be wise, surely
15:40:22 [tomhume]: francois: I think it can be worked out in some cases. We can't say you must not transform in ?????
15:40:55 [jo]: PROPOSED RESOLUTION: We will not say anything about transforming included resources [that was not your best ever idea Jo]
15:40:57 [tomhume]: jo: we're in danger of having heuristics upon heuristics. I'd prefer we not mention this. Any strong objection to moving ahead w/resolution?
15:41:12 [francois]: +1
15:41:13 [EdC]: +1
15:41:16 [jo]: +1
15:41:16 [rob]: +1
15:41:19 [tomhume]: +1
15:41:23 [tomhume]: RESOLUTION: We will not say anything about transforming included resources [that was not your best ever idea Jo]
15:42:13 [tomhume]: Topic: Request for last call comments [4], from WebApps WG on Widgets 1.0: Packaging and Configuration
15:42:21 [tomhume]: jo: We've already sent them some comments
15:42:23 [tomhume]: bryan: yep
15:42:35 [jo]: -> http://lists.w3.org/Archives/Public/public-bpwg/2009Jan/0002.html Call for LC Comments from WebApps
15:42:45 [Zakim]: + +03491121aaee
15:42:50 [jo]: s/bryan/francois/
15:43:00 [achuter]: zakim, aaee is me
15:43:00 [Zakim]: +achuter; got it
15:43:05 [francois]: q+
15:43:18 [achuter]: zakim, mute me
15:43:18 [Zakim]: achuter should now be muted
15:43:24 [tomhume]: jo: anyone else moved to take on preparing this response, or shall we note this and note folks should respond individually?
15:43:55 [tomhume]: francois: we haven't reviewed (???)
15:44:32 [tomhume]: bruce: this was written by friends so I might not be impartial
15:45:12 [tomhume]: jo: the BPWG should we aware this is related to what we do. If anyone has a view they should raise it with the WG
15:45:30 [tomhume]: bruce: I could contact some people I think have been involved and ask them for a heads up of where there might be items of contention or interest?
15:45:59 [tomhume]: jo: there could be things in here that don't work well from a mobile perspective, we should point this out.
15:46:22 [tomhume]: bruce: I imagine it's based on the opera widget spec which we put fwd a while back... so should be mobile-friendly
15:46:36 [tomhume]: jo: notes Nokia involvement
15:47:11 [jo]: ACTION: Bruce to take lead on pointing out anything in the WebApps doc that we should be aware of and/or comment on
15:47:11 [trackbot]: Created ACTION-898 - Take lead on pointing out anything in the WebApps doc that we should be aware of and/or comment on [on Bruce Lawson - due 2009-01-20].
15:47:27 [tomhume]: jo: AOB?
15:47:58 [Zakim]: -achuter
15:47:59 [Zakim]: -yeliz
15:47:59 [Zakim]: -bruce
15:48:00 [Zakim]: -rob
15:48:01 [Zakim]: -tomhume
15:48:02 [Zakim]: -jo
15:48:02 [Zakim]: -Dom
15:48:03 [jsmanrique]: bye
15:48:11 [Zakim]: -miguel
15:48:13 [Zakim]: -martin_spain
15:48:16 [Zakim]: -francois
15:48:21 [Zakim]: - +04131972aadd
15:48:22 [brucel]: brucel has left #bpwg
15:48:23 [Zakim]: MWI_BPWG()9:30AM has ended
15:48:24 [Zakim]: Attendees were tomhume, Jeff, francois, jo, Dom, rob, Bryan_Sullivan, yeliz, EdC, miguel, +003491121aabb, achuter, +0121707aacc, bruce, +04131972aadd, martin_spain, +03491121aaee
15:48:53 [francois]: RRSAgent, draft minutes
15:48:53 [RRSAgent]: I have made the request to generate http://www.w3.org/2009/01/13-bpwg-minutes.html francois
16:33:18 [rob]: rob has left #bpwg
17:19:01 [francois]: RRSAgent, bye
17:19:01 [RRSAgent]: I see 4 open action items saved in http://www.w3.org/2009/01/13-bpwg-actions.rdf :
17:19:01 [RRSAgent]: ACTION: Francois to stimulate discussion on the SHOULD NOT question ref mobile heuristics [1]
17:19:01 [RRSAgent]: recorded in http://www.w3.org/2009/01/13-bpwg-irc#T14-47-07
17:19:01 [RRSAgent]: ACTION: EdC to establish what best current practice is with regard the withrawal of use of X- once the non X- form is agreed [2]
17:19:01 [RRSAgent]: recorded in http://www.w3.org/2009/01/13-bpwg-irc#T15-20-38
17:19:01 [RRSAgent]: ACTION: casais to establish what best current practice is with regard the withrawal of use of X- once the non X- form is agreed [3]
17:19:01 [RRSAgent]: recorded in http://www.w3.org/2009/01/13-bpwg-irc#T15-20-53
17:19:01 [RRSAgent]: ACTION: Bruce to take lead on pointing out anything in the WebApps doc that we should be aware of and/or comment on [4]
17:19:01 [RRSAgent]: recorded in http://www.w3.org/2009/01/13-bpwg-irc#T15-47-11
17:19:06 [francois]: Zakim, bye
17:19:06 [Zakim]: Zakim has left #bpwg