See also: IRC log
Date: 29 May 2008
<scribe> Scribe: Art
<scribe> ScribeNick: ArtB
Regrests: Ben, Benoit
AB: any change requested?
[None]
AB: next week's meeting June 5 - start time will be ONE HOUR EARLIER!
AB: proposal from Marcos
http://lists.w3.org/Archives/Public/public-appformats/2008May/0124.html
... is this your proposal or did you work with Arve?
MC: this started as my input but
reflects comments from Arve, Mark Baker and JonF
... this proposal includes several mechanisms
AB: orthoganal or complementary mechanisms?
MC: some are complementary and
some are orthoganal
... there are four mechanism described in varying levels of
detail
CV: agree some mechanisms are
complementary but they seem to address different use
cases
... e.g. the 2nd mechanism gives some additional
flexibility
... it could be viewed as an extension to the 1st proposal
ABe: the 2nd mechanism (XML file) can be done via a push to the UA
MC: using the hash is kinda' of a cheap dig sig scheme thus another good thing about the XML format
AB: of these mechanisms, which is most commonly implemented today?
MC: #3 (local storage) is the
most common i.e. just download a new widget
... pretty much just leaves the details to the UA
... and hence doesn't require much standardization
ABe: these proposals are still a
bit short on details
... think we need to explore the alternatives some more
MC: agree; I've started to expand
the examples
... I will also include the various usage scenarios
AB: that would be excellent; we can then analyze the various strengths and weakness of the different models
<marcos> <update url="http:/a.com/myWidget.wgt" etag="36f4d2e876c5c51:b74"/>
MC: this model requires author to
include an update element with a URI attribute
... the etag attr would be optional
... if etag is present can compare it with what is installed;
if different, assume a new widget exists
AB: we discussed that mechanism last year, right?
MC: yes, Mark Baker suggested the
etag
... if etag is missing, the UA asks the user if they want to
update the widget
... this model uses HTTP caching mechanism
ABe: not sure what happens if the
widget was obtained via some non-http protocol e.g.
Bluetooth
... think there is a trust issue with this model e.g. where did
the widget really come from
MC: right, a Widget could be copied from one site and installed somewhere else
ABe: I'm concerned about
tampering of un-signed widgets
... the update URI could have been altered by some means
... or the etag could be tampered
MC: yes, but I don't think we want to prescribe encryption
ABe: but the update document could be signed
MC: can also require httpS
... 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)
ABe: the main thing we must do is to clearly identify the security considerations
ABe: an advantage of this model
is the update format can be signed
... I think we need to flesh-out both of these models
MC: I think we should document both models
AB: would the server need to do anything special in this model?
MC: no it would not
... the update format could be done by hand given it is quite
simple
AB: is this model being used today?
MC: yes it is being used by
numerous systems (iTunes, Debian, ...)
... this is certainly more common than model #1
AB: what is the user interaction model for the XML format?
MC: one mechanism is the UA just
tells the user a new version is available
... another interaction model is a user explicitly checks a
"check for updates" sheet
ABe: I don't think we want to
normatively specify the user interaction model
... especially since the update could be done auto-magically
[withouth any user interaction at all]
MC: agree
AB: agree too
CV: the spec should enable
different user interaction models
... want to leave both user interaction models open
MC: we will not recommend any user interaction model
CV: data exchange from device to
server is important for operators
... the update process could be used to do advertising
MC: yes but such a widget would become un-popular
MC: the UA compares the current widget id with the new widget
AB: will you Marcos submit details for this model too?
MC: yes there are some additional details to flesh out
MC: author provides an update
element in the config doc
... at runtime the script in the engine calls the update()
method
... this causes the UA to ask the server for a new Widget
... basically, this would trigger model #1 or model #2
AB: will this one also be further explored?
MC: yes; in particular will need to add it to the API spec
ABe: yes, this will need to be detailed in the API spec
MS: the comment period has
ended
... Doug has responded to all comments
... He has updated the charter to reflect the comments
... The deliverables list has been updated
... Most of the AC commentors are OK with the Team's
responses
... we expected comments about too many deliverables but we
didn't get such feedback
... the only exception is Geo-location
... 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
... Access Control will remain in the WebApps WG
AB: thanks Mike
... our Charter ends May 31
MS: yes, we will need another short extension
AB: thanks to Mike and Doug for all of the time and effort they've put into getting this done!
<MikeSmith> for the record, Doug did almost all of the work on the charter and disposition comments (not me)
AB: the majority of preferences
expressed in Dublin were to have the next f2f in early
September
... I'm happy to say Claudio can accomdate that
... next f2f meeting will be Sept 9-11 in Turin
Italy
<scribe> ACTION: barstow announce Sept 9-11 to the WG [recorded in http://www.w3.org/2008/05/29-waf-minutes.html#action01]
<trackbot-ng> Created ACTION-179 - Announce Sept 9-11 to the WG [on Arthur Barstow - due 2008-06-05].
<scribe> ACTION: barstow review TPAC meeting schedule and forward to the WG [recorded in http://www.w3.org/2008/05/29-waf-minutes.html#action02]
<trackbot-ng> Created ACTION-180 - Review TPAC meeting schedule and forward to the WG [on Arthur Barstow - due 2008-06-05].
AB: Meeting Adjourned
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/MC: we expected/MS: we expected/ Found Scribe: Art Found ScribeNick: ArtB Present: Art Claudio Marcos Arve Mike Regrets: Ben Benoit Agenda: http://lists.w3.org/Archives/Member/member-appformats/2008May/0011.html Found Date: 29 May 2008 Guessing minutes URL: http://www.w3.org/2008/05/29-waf-minutes.html People with action items: 9-11 announce barstow sept[End of scribe.perl diagnostic output]