11:01:07 <RRSAgent> RRSAgent has joined #waf
11:01:07 <RRSAgent> logging to http://www.w3.org/2008/05/29-waf-irc
11:02:04 <Zakim> +[IPcaller]
11:02:30 <marcos> zakim, IPcaller is me
11:02:30 <Zakim> +marcos; got it
11:03:26 <ArtB> Meeting: Widgets Voice Conference
11:03:39 <ArtB> Date: 29 May 2008
11:03:42 <ArtB> Chair: Art
11:03:45 <ArtB> Scribe: Art
11:03:50 <ArtB> ScribeNick: ArtB
11:04:00 <ArtB> Present: Art, Claudio, Marcos
11:04:07 <ArtB> Regrests: Ben, Benoit
11:04:26 <ArtB> Agenda: http://lists.w3.org/Archives/Member/member-appformats/2008May/0011.html
11:05:41 <Zakim> + +47.23.69.aabb
11:05:52 <ArtB> zakim, aabb is Arve
11:05:52 <Zakim> +Arve; got it
11:06:05 <ArtB> Present+ Arve
11:07:03 <ArtB> Regrets: Ben, Benoit
11:07:11 <ArtB> Topic: Review Agenda
11:07:21 <ArtB> AB: any change requested?
11:07:30 <ArtB> [None]
11:07:38 <ArtB> Topic: Announcements
11:08:02 <ArtB> AB: next week's meeting June 5 - start time will be ONE HOUR EARLIER!
11:08:34 <ArtB> Topic: Auto-updates
11:08:48 <ArtB> AB: proposal from Marcos http://lists.w3.org/Archives/Public/public-appformats/2008May/0124.html
11:09:19 <ArtB> AB: is this your proposal or did you work with Arve?
11:09:44 <ArtB> MC: this started as my input but reflects comments from Arve, Mark Baker and JonF
11:10:10 <ArtB> ... this proposal includes several mechanisms
11:10:35 <ArtB> AB: orthoganal or complementary mechanisms?
11:10:46 <ArtB> MC: some are complementary and some are orthoganal
11:11:35 <ArtB> ... there are four mechanism described in varying levels of detail
11:12:20 <ArtB> CV: agree some mechanisms are complementary but they seem to address different use cases
11:13:07 <ArtB> ... e.g. the 2nd mechanism gives some additional flexibility
11:13:19 <ArtB> ... it could be viewed as an extension to the 1st proposal
11:14:12 <ArtB> ABe: the 2nd mechanism (XML file) can be done via a push to the UA
11:14:52 <ArtB> MC: using the hash is kinda' of a cheap dig sig scheme thus another good thing about the XML format
11:15:23 <ArtB> AB: of these mechanisms, which is most commonly implemented today?
11:15:44 <ArtB> MC: #3 (local storage) is the most common i.e. just download a new widget
11:16:16 <ArtB> ... pretty much just leaves the details to the UA
11:16:37 <ArtB> ... and hence doesn't require much standardization
11:17:12 <MikeSmith> Zakim, code?
11:17:12 <Zakim> the conference code is 9231 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), MikeSmith
11:17:31 <ArtB> ABe: these proposals are still a bit short on details
11:17:33 <Zakim> +??P0
11:17:39 <MikeSmith> Zakim, ??P0 is me
11:17:39 <Zakim> +MikeSmith; got it
11:17:45 <ArtB> ... think we need to explore the alternatives some more
11:17:55 <ArtB> MC: agree; I've started to expand the examples
11:18:27 <ArtB> ... I will also include the various usage scenarios
11:19:06 <ArtB> AB: that would be excellent; we can then analyze the various strengths and weakness of the different models
11:19:51 <ArtB> Topic: Widget Resource on the Web
11:20:07 <marcos> <update url="http:/a.com/myWidget.wgt" etag="36f4d2e876c5c51:b74"/>
11:20:12 <ArtB> MC: this model requires author to include an update element with a URI attribute
11:20:22 <ArtB> ... the etag attr would be optional
11:20:50 <ArtB> ... if etag is present can compare it with what is installed; if different, assume a new widget exists
11:21:02 <MikeSmith> Zakim, mute me
11:21:02 <Zakim> MikeSmith should now be muted
11:21:10 <ArtB> AB: we discussed that mechanism last year, right?
11:21:33 <ArtB> MC: yes, Mark Baker suggested the etag
11:22:13 <ArtB> MC: if etag is missing, the UA asks the user if they want to update the widget
11:23:28 <ArtB> ... this model uses HTTP caching mechanism
11:25:16 <ArtB> ABe: not sure what happens if the widget was obtained via some non-http protocol e.g. Bluetooth
11:25:50 <ArtB> ... think there is a trust issue with this model e.g. where did the widget really come from
11:26:17 <ArtB> MC: right, a Widget could be copied from one site and installed somewhere else
11:26:33 <ArtB> ABe: I'm concerned about tampering of un-signed widgets
11:26:49 <ArtB> ... the update URI could have been altered by some means
11:27:11 <ArtB> ... or the etag could be tampered
11:27:49 <ArtB> MC: yes, but I don't think we want to prescribe encryption 
11:28:09 <ArtB> ABe: but the update document could be signed
11:28:24 <ArtB> MC: can also require httpS
11:29:36 <ArtB> MC: in the web today we see this issue being addressed by asking the user if they really want to install something (e.g. FF installed from a non-Mozilla site)
11:30:08 <ArtB> ABe: the main thing we must do is to clearly identify the security considerations
11:30:23 <ArtB> Topic: XML File
11:30:42 <ArtB> ABe: an advantage of this model is the update format can be signed
11:31:06 <ArtB> ABe: I think we need to flesh-out both of these models
11:31:18 <ArtB> MC: I think we should document both models
11:32:00 <ArtB> AB: would the server need to do anything special in this model?
11:32:08 <ArtB> MC: no it would not
11:32:22 <ArtB> ... the update format could be done by hand given it is quite simple
11:33:00 <ArtB> AB: is this model being used today?
11:33:20 <ArtB> MC: yes it is being used by numerous systems (iTunes, Debian, ...)
11:33:51 <ArtB> ... this is certainly more common than model #1
11:34:46 <ArtB> AB: what is the user interaction model for the XML format?
11:35:03 <ArtB> MC: one mechanism is the UA just tells the user a new version is available
11:35:29 <ArtB> ... another interaction model is a user explicitly checks a "check for updates" sheet
11:36:19 <ArtB> ABe: I don't think we want to normatively specify the user interaction model
11:36:44 <ArtB> ... especially since the update could be done auto-magically [withouth any user interaction at all]
11:36:59 <ArtB> MC: agree
11:37:15 <ArtB> AB: agree too
11:38:41 <ArtB> CV: the spec should enable different user interaction models
11:39:51 <ArtB> ... want to leave both user interaction models open
11:40:10 <ArtB> MC: we will not recommend any user interaction model
11:41:23 <ArtB> CV: data exchange from device to server is important for operators
11:42:19 <ArtB> ... the update process could be used to do advertising
11:42:37 <ArtB> MC: yes but such a widget would become un-popular
11:43:47 <ArtB> Topic: Local Storage model (sub-proposal #3)
11:44:32 <ArtB> MC: the UA compares the current widget id with the new widget
11:46:22 <ArtB> AB: will you Marcos submit details for this model too?
11:46:34 <ArtB> MC: yes there are some additional details to flesh out
11:47:09 <ArtB> Topic: API Call model (sub-proposal #4)
11:47:26 <ArtB> MC: author provides an update element in the config doc
11:47:41 <ArtB> ... at runtime the script in the engine calls the update() method
11:47:52 <ArtB> ... this causes the UA to ask the server for a new Widget
11:48:07 <ArtB> ... basically, this would trigger model #1 or model #2
11:48:42 <ArtB> AB: will this one also be further explored?
11:48:59 <ArtB> MC: yes; in particular will need to add it to the API spec
11:49:13 <ArtB> ABe: yes, this will need to be detailed in the API spec
11:51:05 <MikeSmith> Zakim, unmute me
11:51:05 <Zakim> MikeSmith should no longer be muted
11:51:41 <ArtB> Topic: WebApps WG Charter Update
11:51:49 <ArtB> Present+ Mike
11:52:04 <ArtB> MS: the comment period has ended
11:52:13 <ArtB> ... Doug has responded to all comments
11:52:26 <ArtB> ... He has updated the charter to reflect the comments
11:52:34 <ArtB> ... The deliverables list has been updated
11:53:06 <ArtB> ... Most of the AC commentors are OK with the Team's responses
11:53:41 <ArtB> MC: we expected comments about too many deliverables but we didn't get such feedback
11:53:58 <ArtB> ... the only exception is Geo-location 
11:54:34 <ArtB> ... we expect to do the Geo-location API in a separate WG but that's not yet a done deal because we first have to get AC review
11:55:13 <ArtB> s/MC: we expected/MS: we expected/
11:55:36 <ArtB> MS: Access Control will remain in the WebApps WG
11:56:07 <ArtB> AB: thanks Mike
11:56:13 <ArtB> ... our Charter ends May 31
11:56:22 <ArtB> MS: yes, we will need another short extension
11:57:39 <ArtB> AB: thanks to Mike and Doug for all of the time and effort they've put into getting this done!
11:57:56 <ArtB> Topic: Next F2F Meeting
11:58:26 <MikeSmith> for the record, Doug did almost all of the work on the charter and disposition comments (not me)
11:58:32 <ArtB> AB: the majority of preferences expressed in Dublin were to have the next f2f in early September
11:58:54 <ArtB> AB: I'm happy to say Claudio can accomdate that
11:59:10 <ArtB> AB: next f2f meeting will be Sept 9-11 in Turin Italy
12:02:25 <ArtB> ACTION: barstow announce Sept 9-11 to the WG
12:02:25 <trackbot-ng> Created ACTION-179 - Announce Sept 9-11 to the WG [on Arthur Barstow - due 2008-06-05].
12:03:07 <ArtB> ACTION: barstow review TPAC meeting schedule and forward to the WG
12:03:07 <trackbot-ng> Created ACTION-180 - Review TPAC meeting schedule and forward to the WG [on Arthur Barstow - due 2008-06-05].
12:03:25 <ArtB> AB: Meeting Adjourned
12:03:46 <Zakim> -marcos
12:03:47 <Zakim> -MikeSmith
12:03:48 <Zakim> - +39.011.228.aaaa
12:03:50 <Zakim> -Arve
12:03:52 <ArtB> rrsagent, make logs public
12:03:58 <ArtB> rrsagent, make minutes
12:03:58 <RRSAgent> I have made the request to generate http://www.w3.org/2008/05/29-waf-minutes.html ArtB
12:04:02 <Zakim> -Art_Barstow
12:04:03 <Zakim> IA_WAF(widgets)7:00AM has ended
12:04:08 <Zakim> Attendees were +39.011.228.aaaa, Art_Barstow, marcos, +47.23.69.aabb, Arve, MikeSmith
12:06:07 <ArtB> zakim, bye
12:06:07 <Zakim> Zakim has left #waf
12:06:20 <ArtB> rrsagent, bye
12:06:20 <RRSAgent> I see 2 open action items saved in http://www.w3.org/2008/05/29-waf-actions.rdf :
12:06:20 <RRSAgent> ACTION: barstow announce Sept 9-11 to the WG [1]
12:06:20 <RRSAgent>   recorded in http://www.w3.org/2008/05/29-waf-irc#T12-02-25
12:06:20 <RRSAgent> ACTION: barstow review TPAC meeting schedule and forward to the WG [2]
12:06:20 <RRSAgent>   recorded in http://www.w3.org/2008/05/29-waf-irc#T12-03-07