14:01:42 RRSAgent has joined #wam 14:01:42 logging to http://www.w3.org/2009/11/19-wam-irc 14:01:49 RRSAgent, make log Public 14:01:52 MikeSmith has joined #wam 14:01:53 Scribe: Art 14:01:57 ScribeNick: ArtB 14:02:00 Chair: Art 14:02:07 Date: 19 November 2009 14:02:21 Meeting: Widgets Voice Conf 14:02:54 zakim, who is on the phone? 14:02:54 On the phone I see +49.208.4.aaaa, +47.23.69.aabb, +1.207.868.aacc, darobin (muted), +1.781.993.aadd 14:03:01 zakim, aabb is me 14:03:01 +arve; got it 14:03:02 Agenda: http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0763.html 14:03:14 zakim, who's here? 14:03:14 On the phone I see +49.208.4.aaaa, arve, +1.207.868.aacc, darobin (muted), +1.781.993.aadd 14:03:14 zakim, aaaa is me 14:03:15 I can't hear anything either 14:03:17 On IRC I see MikeSmith, RRSAgent, Zakim, drogersuk, fh, marcin, darobin, Steven, Benoit, tlr, arve, ArtB, Marcos, shepazu, trackbot, timely 14:03:17 neither do I 14:03:19 +marcin; got it 14:03:25 that's better 14:03:33 present+ David_Rogers 14:03:47 now, I'm at least hearing ArtB talk 14:04:02 Present: Art, Arve, Robin, David, Marcin, Steve 14:04:04 + +1.479.524.aaee 14:04:13 s/Steve/Steven/ 14:04:15 Present+ Marcos 14:04:18 zakim, aaee is marcos 14:04:18 +marcos; got it 14:04:30 zakim, +1.479.524.aaee is me 14:04:30 sorry, Marcos, I do not recognize a party named '+1.479.524.aaee' 14:04:39 Regrets: Frederick 14:04:48 Zakim, 1.479.524.aaee is me 14:04:48 sorry, Marcos, I do not recognize a party named '1.479.524.aaee' 14:05:06 +[IPcaller] 14:05:07 zakim, drop steven 14:05:08 sorry, Steven, I do not see a party named 'steven' 14:05:12 zakim, [IPcaller] is fh 14:05:12 +fh; got it 14:05:16 zakim, dial steven-617 14:05:17 ok, Steven; the call is being made 14:05:17 Present+ Frederick 14:05:21 Regrets: 14:06:00 Doug and I keep ending up on the same call, but no one else 14:06:07 Marcos, :) 14:06:29 Marcin, quickly check out the email I just sent you 14:06:30 zakim, what call is this? 14:06:30 I don't understand your question, Steven. 14:06:33 Steven, Doug - we're all here on 9231 14:06:38 zakim, dial steven-617 14:06:38 ok, Steven; the call is being made 14:07:15 Doug and steven on a separate call again 14:07:21 zakim, code? 14:07:21 the conference code is 9231 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), Steven 14:07:26 Topic: Agenda review 14:07:52 AB: draft agenda is http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0763.html 14:07:54 + +1.408.216.aaff 14:08:09 Present+ Suresh 14:08:13 +Steven 14:08:16 + +1.452.9.aagg 14:08:34 Present+ Benoit 14:08:51 AB: any change requests on the agenda? 14:08:52 +Doug_Schepers 14:08:59 Present+ Doug 14:09:18 Marcos, long email :). I think option 3 should win, but I need to check what parameters we may have. I will respond shortly. 14:09:30 AB: any change requests on agenda? 14:09:33 [ None ] 14:09:35 zakim, mute me 14:09:35 Steven should now be muted 14:10:01 MC: can we add Marcin's regarding P&C? 14:10:03 AB: yes 14:10:13 Topic: Announcements: 14:10:19 AB: No Voice Conf on 26 November; next one will be 3 December 14:10:28 AB: Reminder: last day to request publications for 2009 is Friday 18 December 14:10:44 AB: WebApps has been asked to submit comments re OASIS' Packaging spec for ODF for Office Apps spec; see ( http://www.w3.org/mid/4B016692.2090408@w3.org ) for details 14:11:12 Suresh has joined #wam 14:11:12 AB: Doug, anything to add? 14:11:22 DS: they are using ZIP too 14:11:47 AB: if there are comments, send them to the OASIS list 14:11:55 DS: if need clarification on list, let me know 14:11:56 Present+ Suresh Chitturi 14:12:42 AB: any other annoucements? 14:12:44 [ None ] 14:12:46 Topic: P&C spec: LCWD#3 comment period ends 19 November 14:13:13 DS: I am on the ODF Tech Committee 14:13:18 ... my main reason is SVG 14:13:30 ack me 14:13:32 ... but I can be a pipe for other ODF comments 14:13:46 SP: I will also join the ODF TC but not as a W3C rep 14:13:56 zakim, mute me 14:13:56 Steven should now be muted 14:13:59 AB: November 19 is the last day to submit comments re P&C LC#3 ( http://www.w3.org/TR/2009/WD-widgets-20091029/ ). 14:14:09 AB: the comment tracking document is ( http://www.w3.org/2006/02/lc-comments-tracker/42538/WD-widgets-20091029/ ). Marcos, that document must be up to date before the Director's call. 14:14:28 AB: the Director's call is tentatively set for Nov 23 14:14:40 AB: Marcos, which comments still lack a WG response? My count is 5 total: 2 from Marcin ( http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0711.html and http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0750.html ), 1 from Ericsson ( http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0567.html ), 1 from Scott Wilson ( http://lists.w3.org/Archives/Public/public-w 14:14:42 ebapps/2009OctDec/0808.html ) and 1 from Benoit ( http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0469.html ) . 14:14:58 AB: let's make sure we are all on the same page re these comments 14:15:47 AB: what's the plan to populate the CT doc? 14:15:52 MC: I'll start tomorrow 14:16:38 ... Benoit's is open 14:16:50 ACTION: benoit close the loop on your P&C comment 14:16:50 Created ACTION-458 - Close the loop on your P&C comment [on Benoit Suzanne - due 2009-11-26]. 14:17:26 AB: it appears Ola is OK with your response Marcos? 14:17:28 MC: yes 14:17:45 AB: we need closure on Scott's comment 14:18:04 ACTION: wilson close the loop on the author element discussion 14:18:04 Sorry, amibiguous username (more than one match) - wilson 14:18:04 Try using a different identifier, such as family name or username (eg. awilson2, swilson3, ChrisWilson) 14:18:15 http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0808.htm 14:18:35 AB: Scott proposes support for multipe authors? 14:18:42 MC: no, he was just asking how to do that 14:18:50 ... I don't think it was a spec comment 14:19:09 ACTION: marcos seek clarification with Scott Wilson re his intent for multiple authors 14:19:09 Created ACTION-459 - Seek clarification with Scott Wilson re his intent for multiple authors [on Marcos Caceres - due 2009-11-26]. 14:19:56 AB: re Marcin, his comment #1 was bug fixes and editorial, right? 14:19:58 MC: yes 14:20:00 MH: yes 14:20:07 AB: then we have closure on that 14:20:33 AB: what about MH comment #2? 14:20:47 MC: param ambiguity at the end of a mime type decl 14:20:59 ... e.g. charset 14:21:20 ... can also use to declare mime type 14:21:26 ... not sure which one wins 14:22:12 AB: will this require a new LC to fix? 14:22:25 MC: it should not 14:22:45 ... break any impls 14:22:51 q+ 14:23:06 ... I've clarified the behavior 14:23:14 MH: I don't think we need another LC 14:23:19 ... I do think it is a bug 14:23:33 ... I think we can resolve this over email shortly 14:23:49 ... think the registration is also a bit buggy 14:24:01 q- 14:24:09 1. kill the parameter bit - using the ABNF you suggest below. 14:24:09 2. say that it is allowed, but left up to the implementation. 14:24:09 3. say that parameter is allowed, but if it includes an encoding 14:24:09 parameter, then @encoding beats it (or the other way around). 14:24:12 AB: does anyone have any additional comments on MH's comments? 14:24:39 type = "text/html;charset=Windows-1252" 14:24:39 encoding = "ISO-8859-1" /> 14:25:32 AB: is the WG being asked to choose one of these opts? 14:25:42 RB: I think #3 is the most logical 14:25:52 MC: yes, I agree with #3 14:25:54 +1 for 3, but I - as author - would be kind of crazy putting two different values there :). Maybe I would like to crack the WUA? 14:26:02 AB: any other opinions? 14:26:26 AB: I think we need some time to review the proposals 14:26:38 ... not sure we can agree on this call 14:26:45 Arve: agree we need some time 14:26:55 ... what are the security implications of these opts? 14:27:20 MH: think we should continue on email 14:27:39 RB: don't think we are adding new security concerns (that are already there) 14:27:48 ... I don't think this is a big issue 14:27:53 ... want to decide now 14:28:30 AB: I heard MC, MH and RB voice support for #3 14:28:46 Arve: if I have to choose now, I'd say #3 14:29:09 DS: no opinion 14:30:13 AB: is #3 a bug fix or a substantive change 14:30:27 ... I'm hearing that MH, MC, and RB say it is a bug fix 14:30:31 ... is that correct? 14:30:35 yes 14:30:42 MC: yes 14:30:44 RB: yes 14:30:46 MH: yes 14:30:51 DS: would it change impls? 14:31:00 MC: no, don't think so 14:31:31 DS: based on MC's description, this would be a class #2 change thus would not require going back to LC 14:31:53 AB: draft proposal to accept proposal #3 above 14:31:57 AB: any objections? 14:32:01 [ None ] 14:32:30 RESOLUTION: group agrees to proposal #3 in MC's response to MH's comment #2 email re P&C LC#3 14:32:51 AB: are there any other LC#3 comments? 14:33:05 MC: there is something else in MH's email 14:33:33 ... re references to media type RFCs 14:34:33 MH: W3C 2046 should be used for regis 14:34:45 ... but 2046 says use 2048 14:35:22 s/W3C 2046/W3C media type reg says use RFC 2046/ 14:35:39 ... I think this is a W3C and IETF process issue 14:36:03 MC: let's see what IETF says about our registration 14:36:46 AB: are there any other comments from MH we need to discuss today? 14:37:10 MC: our use of SNIFF spec is questioned by MH 14:37:19 ... I think we are using it OK 14:37:25 ... but need to hear from Marcin 14:37:41 AB: Marcin, can we live with what is in the spec now? 14:37:43 MH: yes 14:37:53 ... SNIFF spec is still a WIP 14:38:15 MC: my proposal is to work with Adam Barth to make sure we are aligned with SNIFF 14:38:30 ... on the P&C side, I don't think the proc model will change 14:38:35 MH: yes, I agree 14:38:45 ... we may need to ask Adam to make some changes/additions 14:39:36 AB: any other issues from Marcin? 14:39:49 MC: no 14:39:51 MH: no 14:40:16 AB: you two, MC and MH, please get closure on your emails so we have public record of agreement 14:40:29 MC: I've already changed to the spec 14:40:30 http://dev.w3.org/2006/waf/widgets/ 14:41:01 AB: anything else re LC#3 comments? 14:41:19 ... the deadline is today 14:41:41 Topic: P&C spec: CfC to publish CR#2 14:41:49 AB: on November 23 we have a call scheduled with the Director but that will be postponed if comments/issues are still open. 14:42:09 AB: I think we the best we can do now is to record a resolution to publish CR but with a proviso 14:42:21 AB: Proposed Resolution: the group agrees to publish CR#2 of the P&C spec provided no substantive and unresolved issues are raised on Nov 19 14:42:46 AB: any comments? 14:43:15 MC: we've addressed all comments submitted 14:43:28 ... we have made no substantive changes since LC#3 was published 14:43:36 ... think we are ready to go to CR 14:43:48 RB: I agree with Marcos 14:44:11 AB: anyone else have comments on CR#2 readiness? 14:44:21 AB: any objections to the proposed resolution above? 14:44:25 [ None ] 14:44:32 RESOLUTION: the group agrees to publish CR#2 of the P&C spec provided no substantive and unresolved issues are raised on Nov 19 14:44:54 Topic: WARP spec: Patent exclusions by Apple ; PAG & Next steps .. 14:45:02 AB: last week Apple excluded two of the patent applications from the W3C's Royalty-Free Licensing Requirements for the WARP spec ( http://www.w3.org/2004/01/pp-impl/p73 ) 14:45:09 -darobin 14:45:20 AB: this presumably means a new PAG will be created 14:45:42 AB: Doug and/or Steven, do you have any information to share? 14:46:00 +[IPcaller] 14:46:17 darobin has joined #wam 14:46:18 SP: PLH will talk to Rigo today; want to start the PAG in about 1-weeks time 14:46:26 AB: wow; that would be excellent 14:46:36 RB: indeed 14:47:15 DR: these are patent applications, not patents 14:47:34 ... anyone can go to USPTO and present prior art 14:47:59 DS: does anyone know if there is precedence for excluding patent apps 14:48:12 AB: I am not aware of that, in the context of patent apps 14:48:29 DS: wondering if one could take someone to court for infringing on a patent app 14:49:01 ACTION: doug I will follow-up with the IE we had for the Updates PAG 14:49:01 Created ACTION-460 - I will follow-up with the IE we had for the Updates PAG [on Doug Schepers - due 2009-11-26]. 14:50:00 AB: Rigo reported to me "Participants in the Webapps WG are free to contact the USPTO to oppose the application if they are aware of prior art." 14:50:10 Benoit_ has joined #wam 14:50:33 AB: as we already know, we may continue to work on the WARP spec i.e. work do not need to pause nor stop our work on WARP 14:50:57 RB: I think we should insist on continuing 14:51:20 DS: re USPTO, does it have to be prior art or can "obvious" be included 14:51:27 DR: need to ask Rigo 14:51:48 AB: thanks DS and SP for your info 14:51:49 zakim, mute me 14:51:49 Steven should now be muted 14:51:52 Topic: WARP spec: comments 14:52:02 AB: several discussion re WARP are continuing on the mail list: Robin ( http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0745.html ) and Bryan ( http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0757.html ). 14:52:26 AB: and yesterday, RIM started a new thread ( http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0774.html ). Implementing that proposal could affect the P&C such that a new LC would need to be published. 14:52:43 fjh has joined #wam 14:53:01 AB: my short summary re WARP is the main tension is if the intentionally simplistic model as reflected in the latest ED ( http://dev.w3.org/2006/waf/widgets-access/ ) is sufficient or do we accept some set of the additional features/proposals e.g. UPnP addresses, RIM's proposal, Bryan's proposal, etc. 14:53:36 AB: an additional consideration is, given related patents in this area, is it wise to increase the scope and hence attack surface for "non-friendly" patents. 14:54:24 q+ 14:54:36 q+ to propose a general approach 14:55:20 MH: re UPnP, I think it needs to be addressed 14:55:30 ... it would be bad to exclude the UPnP use cases 14:56:11 ... if we don't address these UCs, the spec is dead for UPnP usage 14:57:26 ... the WARP spec could say local net traffic is out of scope; doesn't say it is excluded though 14:57:55 ack me 14:57:55 darobin, you wanted to propose a general approach 14:58:00 q- 14:58:13 AB: MH says UPnP needs to be supported 14:58:19 ... what do others think? 14:58:37 RB: I think the door for new features is already closed 14:58:50 ... a lot of people like JIL are waiting for it 14:58:57 ... I propose no new features for WARP 14:59:16 ... we can make some changes e.g. some refinements 14:59:39 q+ 14:59:41 ... If there is a need for additional features, they can be done in a branched spec e.g. WARP 2.0 14:59:44 q+ 15:00:10 SC: being a newcomer, I'm not sure about the scope 15:00:24 ... we think it is vauable to have our proposed feature in the standard 15:00:34 ... don't feel too strongly about 1.0 vs 2.0 15:00:44 ... we should try to address the high priority features 15:01:06 RB: I'm fine with the new features, just want them in 2.0 15:01:31 SC: what is the impact on the features being added 15:01:44 ... will it really add a bunch of time versus starting with a new 2.0 spec 15:02:00 ... concerned about the review cycles 15:02:10 RB: can get a 2.0 spec started rather quickly 15:02:22 SC: I think what I proposed is useful 15:02:52 RB: would you be willing to edit 2.0 spec if group agrees? 15:02:56 SC: I'd consider it 15:03:25 ... If we want new features, then we need to assign an Editor? 15:03:28 RB: yes 15:03:37 AB: yes, that is the case 15:04:09 MH: re UPnP, I proposed a special value of local 15:04:24 ... I also proposed that local nets are out of the scope 15:04:34 +q 15:04:48 ... I don't think there any objections to my local networks proposal 15:05:01 - +1.207.868.aacc 15:05:28 ... think the BBC use case should be in 1.0 15:05:41 what about the current incarnation _prevents_ uPnP from working? 15:05:47 RB: I think it should be in a separate spec 15:06:05 q+ 15:06:11 MC: the main use case is using HTTP to get stuff from the web 15:06:45 q+ to say that we'd already discussed putting UPnP in a new document 15:06:50 q- 15:06:54 ... My proposal is we create a new Doc like "widget access for UPnP" 15:06:58 +1 to WARP4U 15:07:02 ... and we do something like that for other protocols 15:07:04 If we are talking about just a few weeks or so and see good use cases, I would encourage inluding the new features in 1.0 15:07:08 Arve: I agree with MC 15:07:16 ... UPnP belongs in a separate spec 15:07:42 ... there a other things to consider re UPnP in the context of widgets 15:07:52 ... think UPnP needs its own spec 15:08:21 AB: MH, are you interested in driving a UPnP + WARP spec? 15:08:40 MH: maybe; but think WARP should explicitly say UPnP is out of scope 15:08:51 Arve: but there's a bunch of stuff out of scope 15:10:09 q+ 15:10:13 AB: we could add a ref to a WARP4U spec 15:10:15 q- 15:10:19 q- 15:10:20 Arve: but that would require a re-Charter 15:10:43 AB: I had not thought about the Charter implications; good point; 15:10:52 ... that is something we need to consider 15:11:00 [Clarification: we need to consider whether re-chartering is necessary, I'm not saying it is so] 15:11:30 s/but that would require a re-Charter/would that require a re-charter?/ 15:11:43 SC: if there is a way to proceed without changing the Charter and referencing Editor's Drafts even if informative, seems like a good way forward 15:11:53 RB: I don't think it would imply a re-charter 15:11:56 MC: me neither 15:12:03 s/MC/MH/ 15:12:04 ... want to make sure though that we can get things out quickly 15:12:27 DS: what is the time scale for WARP v2? 15:12:38 RB: as soon as an ED is ready 15:12:49 q+ 15:13:22 AB: first need to know if anyone is willing to commit to driving a WARP4U spec 15:13:32 DS: we will re-Charter in June 15:13:51 ... but may need to re-Charter earlier 15:14:04 ... and at that time, could add the UPnP+WARP then 15:14:13 ... but the work could proceed before the Charter 15:14:47 Benoit_ has joined #wam 15:16:00 AB: lots of poeple agreed in the summer that we are feature complete 15:16:00 AB: the market is adopting our specs already 15:16:00 AB: we agree that that new features are important but should be added to a new docuemnt 15:16:00 AB: To have new features 15:16:01 AB: in order for us to go down the path of a new spec, we need an editor 15:17:11 SC: what is the next pub plan for WARP? 15:17:16 RB: LC#2 15:17:19 SC: can we have a summary? 15:17:19 SC: I might be able to commit 15:17:20 SC: I have a question. Right now it's an editor's draft? 15:17:20 DB: it's in last call 15:17:20 SC: it it progressing to CR 15:17:21 AB: yes, that's correct 15:18:15 SC: I'm willing to take an approach where we create new Drafts for new Features 15:18:44 and having informative references from the WARP 1.0 15:19:42 MH: I already proposed text to handle local traffic 15:19:58 ... I could put that in a new ED 15:20:46 ... and then ED I create WARP4U 15:21:04 ... could then in WARP spec, refer to WARP4U 15:21:41 RB: ok, we could do that i.e. add an Informative Ref to WARP4U if/when it exists 15:22:26 MH: that's not acceptable 15:22:55 ... want to have an explicit statement that UPnP is not in scope for WARP and it is defined in WARP4U 15:23:40 ... I can create an ED of WARP4U 15:23:47 ... let's discuss over e-mail 15:24:08 RB: need to discuss Bryan's email 15:25:03 RB: we should discuss Bryan's suggestion that by default instead of excluding everything we should allow the same sutff that browsers do, e.g. images from anywhere 15:25:33 RB: if we do what browsers do, we don't need WARP at all 15:25:45 ... but I don't think that's what people want 15:26:18 MC: we do need it for cross-origin access because a widget doesn't have an orgin like a browser's web page 15:26:38 ... HTML5 defines behavior if have HTTP origin but is silent on Widget origin 15:26:47 RB: that would require a bunch of mapping 15:26:57 MC: right; that's why we have the WARP spec 15:27:41 RB: need to be careful with white-lists 15:27:44 WARP = whitelist, 15:28:13 MC: need to align with Web security model 15:28:27 AB: have recent changes been made? 15:28:33 RB: not since the call for review 15:28:55 RB: propose we reject Bryan's proposal and move to LC#2 15:29:08 AB: any comments on Robin's proposal? 15:29:24 q+ 15:29:25 RB: if someone wants to implement BS' model, they could define it in a new spec 15:29:54 SC: do we need a resolution on how to handle new features via new specs? 15:30:20 ... I get the sense new features aren't acceptable 15:30:41 ... Given this, should we capture the process for new features e.g. as a resolution? 15:30:50 RB: I'm OK with that 15:31:04 ... but would be concerned about adding Informative Refs to the new drafts 15:31:22 SC: right, Informative for now but eventually could become Normative 15:31:41 SC: would like a resolution 15:32:06 AB: draft resolution: new features for WARP will be handled via new documents 15:32:18 q+ 15:32:19 +1 15:32:28 -Steven 15:32:47 -1 for this text, refinement is needed 15:32:53 new features for WARP will be handled via new documents 15:33:00 SC: want to add something about references 15:33:17 zakim, who is making noise? 15:33:27 Marcos, listening for 10 seconds I heard sound from the following: marcin (17%), darobin (33%), marcos (30%) 15:33:29 New features for WARP will be handled via new documents and informatively referenced from WARP 1.0 15:33:49 AB: any objections to SC's modified resolution? 15:34:07 RB: yes, want to say "Informatively Referenced when the docs are published" 15:34:25 AB: IOW, FPWD is an entrance block 15:34:47 AB: SC, is that qualification acceptable? 15:34:50 this delays the other specs allowing WARP to block the other texts 15:35:07 therefore the scope of WARP must be precisely defined 15:35:11 SC: so EDs cannot be referenced? 15:35:17 RB: they shouldn't be 15:35:23 DS: that's not true 15:35:33 RB: well, I think they shouldn't be 15:35:45 SC: I want to address the LC comments and keep the work going 15:36:22 q+ 15:36:29 -q 15:36:38 RB: I can live with Informative refs to EDs if the group agrees to move those specs fwd 15:37:22 it is still not clear what the relation is between WARP and the other texts 15:37:53 AB: the maturity level for Informative refs is quite low, correct Doug? 15:37:55 DS: yes 15:38:53 AB: proposed resolution: New features for WARP will be handled via new documents and informatively referenced from WARP 1.0 15:39:12