08:05:09 <RRSAgent> RRSAgent has joined #wam
08:05:09 <RRSAgent> logging to http://www.w3.org/2009/02/25-wam-irc
08:05:22 <ArtB> RRSAgent, make log Public
08:05:32 <ArtB> ScribeNick: ArtB
08:05:35 <ArtB> Scribe: Art
08:05:37 <ArtB> Chair: Art
08:05:43 <ArtB> Meeting: Widgets F2F Meeting
08:05:49 <ArtB> Date: 25 Feb 2009
08:06:37 <ArtB> Agenda: http://www.w3.org/2008/webapps/wiki/WidgetsParisAgenda
08:07:30 <ArtB> RRSAgent, make minutes
08:07:30 <RRSAgent> I have made the request to generate http://www.w3.org/2009/02/25-wam-minutes.html ArtB
08:07:50 <Benoit> Benoit has joined #wam
08:09:34 <ArtB> Present: Art, Andy, Claudio, Ivan, Fabrice, Rainer, Mark, David, Arve, Benoit, Marcos
08:12:38 <ArtB> Present+ Mike(IRC)
08:12:39 <abraun> abraun has joined #wam
08:12:50 <arve> arve has joined #wam
08:14:01 <ArtB> Topic: <content> tags?
08:14:08 <ArtB> AB: what is the status Ivan?
08:14:41 <ArtB> Ivan: I considere that closed in that the modes can be used to address my use cases
08:17:43 <ArtB> Topic: Focus & widgets management; by Marcin
08:17:52 <mpriestl> mpriestl has joined #wam
08:17:58 <ArtB> AB: not clear if this info was more FYI or formal comments for the LCWD
08:18:18 <ArtB> Arve: I think this is more informational i.e. this is how Access addresess window modes
08:18:41 <ArtB> MC: right; the QVGA proposal for example isn't something we want to do
08:19:22 <ArtB> Arve: the methods in his email are mostly covered in our A&E spec
08:19:46 <ArtB> AB: do we need to follow-up?
08:19:59 <ArtB> Arve: there are no questions there
08:20:31 <ArtB> ... if he feels strongly about his model being reflected in our model, he should make specific proposals for the Editor
08:20:43 <ArtB> AB: I think that is a reasonable proposal
08:21:31 <ArtB> ACTION: Marcos respond to Marcin and ask him to make specific proposals if he has any
08:21:32 <trackbot> Created ACTION-302 - Respond to Marcin and ask him to make specific proposals if he has any [on Marcos Caceres - due 2009-03-04].
08:21:50 <ArtB> Topic: Window Modes
08:22:14 <ArtB> MP: want to discuss what goes into the P&C based on our consensus from yesterday
08:22:34 <ArtB> AB: yesterday's minutes are: http://www.w3.org/2009/02/24-wam-minutes.html
08:22:54 <ArtB> Arve: not sure we will know until the new specs are available to review
08:25:22 <fabrice> fabrice has joined #wam
08:26:01 <ArtB> RRSAgent, make minutes
08:26:01 <RRSAgent> I have made the request to generate http://www.w3.org/2009/02/25-wam-minutes.html ArtB
08:26:08 <Benoit> q+
08:28:00 <ArtB> MP: re width and height property; in some cases you may want to use a different values depending on the mode
08:28:54 <ArtB> MP: what goes in the modes spec?
08:29:04 <ArtB> MC: just the definitions of the 4 modes
08:30:34 <ArtB> [ Arve sketches a "live" proposal of the syntax ... ]
08:33:28 <claudio> claudio has joined #wam
08:33:55 <ArtB> [ Marcos to drop in IRC this proposal ... ]
08:33:57 <Marcos> Marcos has joined #wam
08:34:00 <Marcos> <viewport 
08:34:00 <Marcos> 	mode          = "one of the modes"
08:34:00 <Marcos> 	width          = "csspx"
08:34:01 <Marcos> 	height         = "csspx"
08:34:04 <Marcos> 	min-height  = "csspx"
08:34:05 <Marcos> 	min-width   = "csspx"
08:34:07 <Marcos> 	max-height = "csspx"
08:34:09 <Marcos> 	max-width  = "csspx"
08:34:11 <Marcos> 	resize	      = "true|false"
08:34:18 <Marcos> ...
08:34:26 <Marcos> />
08:34:46 <ArtB> MP: the definitions of the modes spec will then define what these mean?
08:34:50 <ArtB> Arve: yes, that's the idea
08:36:05 <ArtB> BS: how does one define a widget that works for both mobile and desktop?
08:36:11 <ArtB> Arve: would define two veiwports
08:36:29 <Billy> Billy has joined #wam
08:37:00 <ArtB> MP: but some modes don't use height and width
08:37:20 <ArtB> Arve: then for some modes they wouldn't be needed
08:37:28 <ArtB> AB: or ignored if present
08:37:42 <ArtB> BS: what about orientation of the device?
08:37:52 <ArtB> Arve: that's handled by CSS
08:38:28 <ArtB> Present+ Josh(IRC)
08:38:49 <ArtB> Present+ Billy
08:39:08 <MikeSmith> MikeSmith has joined #wam
08:39:24 <ArtB> Arve: if a widget doesn't fit in a viewport e.g. on a mobile, the UA could provide zoom
08:40:26 <timeless> so, a WUA is required to provide zoom?
08:40:34 <arve> timeless: no
08:42:06 <ArtB> Arve: we go with CSS pixels in the spec
08:42:26 <ArtB> ... with the expectation that eventually UAs will likely do some zooming
08:45:08 <ArtB> AB: Mark, are you asking for some details about what goes in the P&C spec and the other two new specs proposed?
08:45:34 <ArtB> MP: I understand what goes into the two new proposed specs but not clear about what goes in P&C
08:46:05 <ArtB> Present+ Mohammed
08:49:16 <ajbraun> ajbraun has joined #wam
08:50:11 <ArtB> ACTION: Marcos report back to the WG ASAP regarding your ability to be the Editor of the two new specs proposed and discussed on Feb 24
08:50:11 <trackbot> Created ACTION-303 - Report back to the WG ASAP regarding your ability to be the Editor of the two new specs proposed and discussed on Feb 24 [on Marcos Caceres - due 2009-03-04].
08:51:04 <ArtB> MC: I wonder if some of the attributes proposed above can be handled by CSS
08:51:18 <ArtB> Arve: what if an imple doesn't support CSS
08:53:27 <ArtB> AB: I think we've hit the point of dimminishing returns on this
08:53:41 <ArtB> MC: give us a week and we'll put forward a proposal
08:54:17 <ArtB> Topic: Settings a View Mode; Benoit
08:54:34 <Marcos> http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0248.html
08:56:00 <ArtB> BS: in my email I enumerate various modes we need
08:56:15 <ArtB> ... Settings is one mode we need but we haven't discussed
08:56:57 <ArtB> ... think the developer would want a consistent and convenient way to define/modify settings
08:57:17 <ArtB> MC: I'm warming to this idea a little
08:57:28 <ArtB> ... e.g. could right-click and get to this info
08:57:38 <ArtB> Arve: I disagree vehemently
08:57:58 <ArtB> ... this is ultimately about being able to display some specified content in a specific way
08:58:34 <ArtB> ... your solution implies pointing at a completely diff document or firing some event or allowing the WUA to genearte a UA based on a scheme with some prefs
08:58:52 <ArtB> BS: If I build a widget want a config view for it
08:59:03 <ArtB> Arve: how is that diff than any other state?
08:59:19 <ArtB> ... how is settings different than refresh, for example
09:00:56 <ArtB> [ MC demos Dashboard and the "I" key used to get to the widget's settings ... ]
09:01:45 <ArtB> s/Settings a View Mode/Proposal for a "Settings" View Mode/
09:03:33 <ArtB> MC: can imagine using some of the new CSS3 Modules e.g. Transforms (2d, 3d), Transitions, etc. 
09:04:31 <ArtB> DR: something like Fring service isn't useful until it is configured
09:04:41 <ArtB> Arve; well that's a broken service
09:05:22 <ArtB> DR: my point is there is a use case for using a widget's settings without first instantiating the widget
09:05:45 <ArtB> Arve: this seems more about a widget being able to handle online or offline
09:06:56 <ArtB> AB: I'm not seeing a lot of support for this
09:07:44 <ArtB> ... One way fwd - after the two new specs are out and P&C spec updated to reflect the new specs, then Benoit can submit a proposal if his use case can't be addressed
09:07:52 <ArtB> BS: yes, that's OK with me
09:08:19 <ArtB> ... I did want to discuss this mode and we've done that
09:12:05 <ArtB> AB: any other topics related to Window Modes?
09:12:07 <ArtB> [ None ]
09:12:58 <ArtB> Topic: <access element>
09:14:34 <ArtB> AB: what's the best place to start?
09:14:49 <ArtB> MP: we should start with MC's latest e-mail
09:15:42 <ArtB> AB: here is MP's 2nd proposal: http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0505.html
09:16:41 <ArtB> AB: MC then responded on Feb 22 with: http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0517.html
09:17:15 <ArtB> MP: the semantics of the network attribute is not clear
09:17:55 <ArtB> MP: want author to be able to enumerate the white-listed hosts
09:18:14 <ArtB> ... However, there are some use cases where that list will not be know in advance e.g. a RSS reader
09:18:46 <ArtB> ... We need an "escape" mechanism for these use cases
09:20:46 <ArtB> s/<access element>/<access> Element/
09:21:08 <ArtB> [ We review strawman proposal by Arve ... ]
09:21:16 <arve>   element security optional
09:21:16 <arve>     element access multiple
09:21:16 <arve>       element "protocol" multiple
09:21:16 <arve>         cdata
09:21:16 <arve>       element "host" multiple
09:21:18 <arve>         cdata
09:21:20 <arve>       element "port" multiple
09:21:21 <arve>         cdata
09:21:23 <arve>       element "path" multiple
09:21:25 <arve>         cdata
09:21:28 <arve>     element "content"
09:21:29 <arve>       attribute "plugin" value = "yes|no"
09:22:46 <ArtB> Arve: the idea is a widget would be restricted to those access methods that are explicit in the config file
09:23:23 <ArtB> MP: BONDI has done some related work but using a URI with pattern matching
09:23:49 <ArtB> ... VF would like to move that functionality from BONDI spec to W3C spec
09:24:03 <anne> arve, btw, why not just have <origin>
09:24:31 <Marcos> what do you mean by it?
09:24:32 <anne> arve, every other spec on the planet is moving towards that, since you have the host,port,scheme tuple you might as well tag along
09:24:34 <Marcos> anne
09:24:37 <arve> anne: mind joining the call and explaining it?
09:24:54 <anne> (it's just syntax so I don't think worth it)
09:24:57 <Marcos> <widget> <origin uri="http://microsoft.com">  ?
09:25:02 <anne> that's worth it*
09:25:32 <anne> <security> <origin>http://example.org:81/</origin> rather than putting scheme, host and port into separate elements
09:26:03 <timeless> the strawman looks like it's likely to fail
09:26:10 <drogersuk> drogersuk has joined #wam
09:26:30 <arve> anne: got URI schemes for ssh, telnet, xmpp, raw sockets, udp?
09:26:33 <ArtB> Arve: with widgets, there isn't really an origin
09:26:50 <timeless> arve: there is a bad one for ssh and telnet
09:27:10 <ArtB> MC: that's one reason we need a different URI scheme for widgets
09:27:13 <Marcos> anne, can I take over microsoft? 
09:27:20 <Marcos> see my example above?
09:27:35 <arve> protocol: https ; host: google.com, yahoo.com, ask.com; path: search/
09:28:13 <ArtB> MC: need to also specify subdomains
09:28:32 <Marcos> MC: FWIW, this is like an inverse of CORS
09:29:18 <ArtB> MP: having multiple hosts associated with a single scheme and path is problematic
09:30:32 <arve> Reverse the two strings given for the request host and the host specified for the directive (directive host). Do a case-insensitive character by character comparison of the strings. If a mismatch is found before the end of the directive host string is reached, and the last two characters in the directive host string are not the character sequence '.*', consider the request host to not be a match. If there are characters left to parse in the request host, and the last
09:30:33 <arve>  characters of the directive host were the wildcard sequence '.*' consider the host a match.
09:30:54 <ArtB> Arve: I'm not totally opposed to a URI scheme
09:31:09 <ArtB> MC: what proposal is that?
09:31:17 <ArtB> Arve: the one from Anne above
09:31:36 <cgi-irc> cgi-irc has joined #wam
09:31:43 <ArtB> ... with a few modification
09:32:07 <arve> element uri multiple
09:32:26 <Marcos> Anne, do you still have any funky syntax in CORS for selecting subdomains (i.e., *.example.com) ?
09:32:36 <arve> .   attribute src 
09:33:16 <ArtB> [ Arve begins a new strawman proposal ... ]
09:33:29 <arve> <network><access><uri src="http://www.google.com/"/></access></network>
09:34:38 <ArtB> Arve: need wildcards on path and subdomains
09:35:10 <anne> Marcos, no, just origins
09:35:12 <arve> *.google.com
09:35:33 <arve> google.com
09:35:36 <Marcos> so, nothing like what arve has above
09:35:43 <Marcos> right anne
09:35:47 <Marcos> you gave up on that
09:36:11 <anne> is there a document that outlines what this security proposal is proposed to solve?
09:36:18 <ArtB> MP: BONDI allows wildcards in subdomains and paths
09:36:33 <Marcos> Anne, it's for cross domain request. 
09:36:45 <Marcos> as perfomed when no origin is available
09:36:59 <arve> <path>/cats</path>
09:36:59 <arve> thus, the widget can access all of 
09:37:16 <arve>  /cats/siamese.html 
09:37:16 <arve>  /cats/ 
09:37:16 <arve>  /catsoup
09:37:35 <anne> Marcos, does it affect e.g. <iframe>?
09:37:35 <Marcos> (HTML5 "origin" of a widget will be a widget specific URI (e.g., widget://bla;1231-123
09:37:45 <anne> Marcos, because in that case <path> restrictions are pointless
09:38:10 <anne> Marcos, why is there even restrictions on cross domain requests and not just a http(s) boolean?
09:39:05 <Marcos> we are proposing <domain uri="*"/> meaning allow all domains (and supported URI schemes) and <domain uri="uri"/> 
09:39:29 <ArtB> MP: how would this deal with subdomain?
09:39:35 <ArtB> MC: they would have to be added
09:40:39 <Marcos> Anne, because we think that authors should declare which domains they need to access
09:41:03 <Marcos> and we don't want to restrict this to http
09:41:32 <ivandm> ivandm has joined #wam
09:41:46 <anne> Marcos, but why do you think authors need to do that?
09:42:03 <anne> Marcos, also, what APIs do you have that go beyond HTTP(S)?
09:44:44 <ArtB> AB: let's try to regroup and determine where we have agreement and document those issues with no agreement
09:44:50 <Marcos> Anne, Q1. they probably don't. Q2. none :)
09:44:53 <ArtB> MP: subdomains is still open
09:45:20 <ArtB> ... it would be good if we could synch with BONDI and their deadline is March 9
09:45:33 <ArtB> ... want to get alignment if at all possible
09:45:51 <ArtB> MC: so what exactly is the usage?
09:45:55 <ArtB> ... how does it interact with sec policy?
09:46:22 <ArtB> Arve: don't want widgets to be a vessel for attacking remote web sites
09:46:33 <Marcos> Anne... please see minutes now re q1
09:46:34 <anne> Marcos, great solution to a non-problem then, lol
09:46:38 <ArtB> ... thus may want to restrict some sites
09:47:24 <ArtB> MP: want author to practice least privs principle
09:47:56 <ArtB> ... want other parties e.g. user, widget distributor, etc. to be able to examine the host list 
09:48:18 <ArtB> ... I can then look at widget before I sign it
09:48:26 <Marcos> Anne, so that's Q1 above
09:48:46 <Marcos> so there is use cases
09:49:03 <ArtB> Arve: want to limit a set of subdomain possibly
09:49:44 <arve> ssh://foo.net/
09:49:49 <ArtB> MC: the very first version of the spec had something like this
09:50:56 <ArtB> AB: so where are we?
09:51:29 <ArtB> MC: I think we should use URIs
09:51:35 <ArtB> ... learn from CORS experience
09:52:11 <ArtB> MP: we could limit the schemes for v1
09:52:32 <ArtB> MC: we an leave it to the WUA to handle what ever schemes it can
09:52:44 <ArtB> s/we an leave/we can leave/
09:53:15 <arve> Use-case restrictions URI lead to:
09:53:29 <arve> what if I want unrestricted access to http, but restricted access for xmpp
09:54:33 <ArtB> AB: I think we're going to continue to go around in circles if we don't have some agreed requirements
09:56:07 <ArtB> MP: how long will it take to get agreement?
09:56:30 <ArtB> MC: depends on how rich we want to get
09:56:44 <Marcos> s/rich/fancy pants
09:57:39 <ArtB> AB: sounds like there is an action for MC and Arve to submit a concrete proposal
09:57:51 <ArtB> Arve: we did send a proposal once
09:57:57 <ArtB> ... but it needs some updating
09:58:57 <ArtB> [ Arve searches the mail list archive for his previous proposal ... ]
09:59:41 <arve> http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0332.html
10:02:34 <tlr> tlr has joined #wam
10:03:24 <ArtB> RH: also can have a web server on a SIM card
10:04:28 <ArtB> ACTION: Marcos will make a hybrid proposal and send it the mail list
10:04:29 <trackbot> Created ACTION-304 - Will make a hybrid proposal and send it the mail list [on Marcos Caceres - due 2009-03-04].
10:05:26 <ArtB> MC: do we need the access element?
10:05:46 <ArtB> Arve: prefer encapsulating it in a network element
10:06:07 <timeless> so, i think the tupppling in arve's proposal is likely to result in messes
10:06:18 <timeless> but other than that, i'm not sure what to say
10:06:38 <timeless> and i think someone already raised the issue of tuppling messes in the context of allow access to all https but limited http
10:12:09 <ArtB> [ Marcos adds Note to the Reader to P&C spec about <access> being a WIP ; checks-in new version ]
10:20:24 <anne> anne has left #wam
10:37:25 <ArtB> Topic: BONDI Update by David Rogers
10:37:48 <ArtB> DR: first the so-called Turin Rules
10:38:54 <Benoit> Benoit has joined #wam
10:42:24 <ArtB> ScribeNick: Marcos
10:43:21 <Marcos> David: all contributions will be under RF, if not, they are not submitted to the w3c.
10:44:02 <Marcos> David: contributions that cannot be traced to an author or origin, will not be submitted (it must be possible to trace it back to being RF)
10:44:19 <Marcos> David: we have made sure that members are clear on RF requirements. 
10:44:45 <Marcos> David: OMTP members must make it clear where there are IPR claims.... 
10:45:06 <Marcos> David describes the "OMTP - BONDI IPR PRINCIPLES"
10:45:39 <Marcos> David: if you have any legal questions, please contact the w3c legal team
10:45:51 <Marcos> David: update on Bondi
10:46:37 <ArtB> ScribeNick: ArtB
10:47:03 <ArtB> DR: OMTP release 1.0 RefImpl
10:47:09 <ArtB> ... based on Windows Mobile
10:47:45 <ArtB> ... by RI in this context we mean an example of the implementation of our specs
10:47:57 <ArtB> ... The RI is helping to drive the specs
10:48:04 <ArtB> ... using an interative model
10:48:12 <ArtB> .. We have "code fests"
10:48:27 <ArtB> AB: who has contributed code?
10:48:46 <ArtB> DR: Aplix, BONDI staff
10:49:12 <ArtB> ... some operators have also contributed
10:49:48 <ArtB> MC: the author is embedded in every source file
10:49:56 <ArtB> AB: what  is the licensing?
10:50:20 <ArtB> ... and does every file have an identical license?
10:50:34 <ArtB> DR: I'll come back to the licensing
10:50:55 <ArtB> DR: Opera joined OMTP
10:51:09 <ArtB> ... and LiMo Foundation has endorsed BONDI specs
10:51:52 <ArtB> AB: what does that really mean in terms of devices shipping BONDI implementations?
10:52:43 <ArtB> MP: LiMo devices that implement web runtimes should implement BONDI specs
10:53:28 <ArtB> AB: is there an expectation LiMo will take the RI code?
10:53:43 <ArtB> MC: no; its a Windows implementation
10:54:03 <arve> http://www.opera.com/press/releases/2009/02/16/
10:54:09 <ArtB> Arve: Opera has been a member of LiMo since Feb 16
10:55:11 <ArtB> MP: there is some overlap of members between LiMo and OMTP
10:56:16 <ArtB> DR: at MWC some operators clearly endorsed BONDI e.g. AT&T
10:56:41 <ArtB> MC: what is the exact relationship between W3C widget specs and BONDI widget specs
10:57:10 <ArtB> DR: we think W3C is the right place to create widget specs
10:57:37 <ArtB> MC: are BONDI specs Royalty-Free?
10:57:42 <ArtB> MP: I don't know
10:58:07 <ArtB> DR: let me come back to the licensing question
10:59:10 <ArtB> AB: still not clear to me about the relationship between W3C widget specs and BONDI widget specs
10:59:25 <ArtB> MP: one thing we are focusing on is policy
10:59:48 <ArtB> MC: I've heard BONDI has resolved all of the open issues W3C has in its specs
11:00:00 <ArtB> ... I've also heard you have good uptake
11:01:34 <ArtB> Arve: my concern is regarding device APIs and security models
11:03:00 <ArtB> MP: BONDI has defined a set of device APIs
11:03:14 <ArtB> ... we use <feature> from P&C to hook into those APIs
11:04:01 <ArtB> DR: later today I will post to public-webapps pointers to our Candidate specs
11:05:05 <ArtB> AB: which version of the P&C spec has been implemented in the RI?
11:05:12 <ArtB> MP: not sure
11:05:15 <claudio> claudio has joined #wam
11:06:48 <ArtB> AB: did BONDI create a Widgets P&C spec?
11:06:51 <ArtB> DR: no
11:07:08 <ArtB> AB: did BONDI create a Widgets DigSig spec?
11:07:12 <ArtB> DR: no
11:07:31 <ArtB> DR: we reference P&C and DigSig now; but do not currently reference A&E
11:08:19 <ArtB> AB: you have created some deltas of the P&C spec right?
11:08:44 <ArtB> MP: yes. For example we added a new element because P&C's <access> does not meet our requirements
11:08:51 <abraun> abraun has joined #wam
11:09:18 <ArtB> DR: I think a delta doc makes sense
11:10:21 <ArtB> Arve: on March 9 BONDI will ship 1.0, right?
11:10:26 <ArtB> DR: yes
11:10:49 <ArtB> Arve: doesn't that tie W3C's hand?
11:11:05 <ArtB> DR: no. We want to get the specs synched.
11:12:15 <ArtB> AB: what happens starting on March 10? Will BONDI members start shipping implementations of the RI?
11:12:50 <ArtB> MP: on March 10, VF will begin asking vendors to implement the BONDI specs
11:14:09 <ArtB> MC: but this is going to lead to fragmentation
11:14:44 <ArtB> ... these implemenations will not be the same as implemenations based on the eventual Recommendation of W3C's widgets specs
11:15:15 <abraun> abraun has joined #wam
11:15:21 <ArtB> MP: OMTP is only interested in mobile use cases
11:15:52 <ArtB> ... thus we don't necessarily care about additional use cases that go beyond mobile
11:17:23 <ArtB> MC: so it appears then that to meet your requirements it will lead to more fragmentation
11:18:00 <ArtB> DR: we've done a lot of work related to security
11:19:06 <ArtB> CV: we are participating in both orgs
11:19:41 <ArtB> .... the W3C's mobile web initiative hasn't really been that successful
11:20:05 <ArtB> ... and some players in the market are taking advantage of this
11:20:32 <ArtB> ... Want the W3C to create the infrastructure
11:21:16 <ArtB> MC: I don't understand why the W3C should continue its work
11:21:58 <ArtB> MP: I don't there is any desire to create overlapping specs
11:22:13 <ArtB> s/don't there/dont' think there/
11:23:03 <ArtB> ... BONDI can't wait forever for W3C to complete their work
11:24:16 <ArtB> AB: ultimately it is a business decision regarding whether one should ship an implementation of the W3C's widgets specs + BONDI specs as of March 10
11:24:26 <ArtB> ... people understand the risks
11:24:56 <ArtB> Arve: I think it is short-sighted to only look at this from the mobile perspective
11:25:42 <ArtB> DR: OMTP intends to continue active participation in W3C
11:25:55 <ArtB> ... we want to put our device APIs into the W3C
11:26:38 <ArtB> AB: is it then the case that on March 10, you expect BONDI to start implementing your device APIs and to start shipping such implemenations?
11:26:56 <ArtB> DR: not sure March 10 is the right date but yes, that is my expectation
11:28:20 <ArtB> Arve: I would like to see OMTP/BONDI commit resources for Editing API specs like File I/O
11:28:47 <ArtB> ... requirements first of course; but follow up with spec contributions too
11:30:59 <ArtB> ... It sounds like this is going to lead some fragmentation in the mobile space
11:33:28 <ArtB> MC: so now that we've continued discussion I'm seeing more of an "embrace and extend" model
11:34:59 <ArtB> DR: re licensing - Apache 2.0
11:35:11 <ArtB> ... that is for the BONDI RI
11:37:31 <ArtB> Topic: New Work related to the Device API and Security Workshop
11:37:44 <ArtB> AB: WS report http://www.w3.org/2008/security-ws/report
11:38:39 <ArtB> AB: the report identifies 6 potential work areas and assigns priorities to each
11:40:12 <ArtB> AB: what is BONDI's position re work split for the 4 High priority items?
11:40:51 <ArtB> AB: which of the 6 items are in scope for BONDI?
11:41:53 <ArtB> MP: depends on what you mean by in scope
11:42:14 <ArtB> AB: which areas are actively in spec work?
11:42:38 <ArtB> DR: Concrete APIs
11:43:05 <ArtB> ... Policy Description
11:43:40 <ArtB> ... Policy Management is of interest
11:44:24 <ArtB> AB: what do you expect to push into the W3C?
11:44:38 <ArtB> MP: that not a useful question because we don't use that list
11:44:52 <ArtB> MDR: we expect to submit some APIs
11:45:04 <ArtB> s/MDR:/DR:/
11:45:15 <ArtB> ... and of course policy description
11:45:37 <ArtB> AB: and what is your pref for where that work is done?
11:45:44 <ArtB> DR: Web Apps WG
11:46:45 <ArtB> AB: as Chair, I think it will be hard to add so much new work to WebApps
11:47:47 <ArtB> DR: Thomas would like to form a new WG re the policy work items
11:48:05 <tlr> "would like" sounds exaggerated.  It looks like a likely path forward.
11:48:27 <tlr> no interest in forcing things on you folks... ;)
11:49:55 <ArtB> AB: when will BONDI be ready to submit the Device API specs to the W3C?
11:50:06 <ArtB> DR: I'm not sure but will find out
11:51:52 <ArtB> AB: perhaps you should send an email to http://lists.w3.org/Archives/Public/public-device-apis/ and state BONDIs interest, plans, roadmap, etc
11:57:03 <timelE61i> timelE61i has joined #wam
11:57:36 <tlr> +1 to sending that e-mail
12:52:15 <Marcos> Marcos has joined #wam
12:53:37 <fjh> fjh has joined #wam
12:54:19 <ArtB> RRSAgent, make minutes
12:54:19 <RRSAgent> I have made the request to generate http://www.w3.org/2009/02/25-wam-minutes.html ArtB
12:56:32 <ArtB> ArtB has joined #wam
12:56:45 <Zakim> Zakim has joined #wam
12:56:47 <drogersuk> The other two points that I wanted to mention before the BONDI discussion is closed are: 1) we'd like to be able to offer the reference implementation as an implementation of the W3C spec at some point
12:56:51 <ArtB> RRSAgent, make minutes
12:56:51 <RRSAgent> I have made the request to generate http://www.w3.org/2009/02/25-wam-minutes.html ArtB
12:57:32 <fjh> zakim, who is here?
12:57:32 <Zakim> sorry, fjh, I don't know what conference this is
12:57:33 <Zakim> On IRC I see ArtB, fjh, Marcos, timelE61i, abraun, tlr, drogersuk, mpriestl, arve, RRSAgent, heycam, shepazu, trackbot, timeless, timelyx
12:57:43 <ArtB> zakim, this is widgets
12:57:43 <Zakim> ok, ArtB; that matches IA_WebApps(Widgets F2F)3:30AM
12:57:52 <drogersuk> 2) We'll be doing some work on testing and compliance - the BONDI work here will be a superset of everything but could be reused P&C and other specs
12:57:58 <fjh> zakim, who is here?
12:57:58 <Zakim> On the phone I see +45.29.aaaa, [IPcaller]
12:57:59 <Zakim> On IRC I see ArtB, fjh, Marcos, timelE61i, abraun, tlr, drogersuk, mpriestl, arve, RRSAgent, heycam, shepazu, trackbot, timeless, timelyx
12:58:39 <fjh> zakim, [IPcaller] is fjh
12:58:39 <Zakim> +fjh; got it
12:58:44 <fjh> zakim, mute me
12:58:44 <Zakim> fjh should now be muted
12:59:07 <ArtB> Topic: Widgets Digital Signatures
12:59:53 <fjh> latest editorial draft
12:59:55 <fjh> http://dev.w3.org/2006/waf/widgets-digsig/
13:00:47 <fjh> review
13:00:48 <fjh> http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0548.html
13:01:01 <fjh> http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0547.html
13:01:17 <tlr> zakim, call thomas-781
13:01:17 <Zakim> ok, tlr; the call is being made
13:01:19 <Zakim> +Thomas
13:01:31 <tlr> zakim, I am thomas
13:01:31 <Zakim> ok, tlr, I now associate you with Thomas
13:01:33 <tlr> zakim, mute me
13:01:33 <Zakim> Thomas should now be muted
13:02:29 <tlr> yes
13:02:46 <fjh> zakim, unmute me
13:02:46 <Zakim> fjh should no longer be muted
13:03:15 <ArtB> RRSAgent, make minutes
13:03:15 <RRSAgent> I have made the request to generate http://www.w3.org/2009/02/25-wam-minutes.html ArtB
13:03:24 <fjh> zakim, mute me
13:03:24 <Zakim> fjh should now be muted
13:03:29 <ArtB> AB: agenda http://www.w3.org/2008/webapps/wiki/WidgetsParisAgenda#Digital_Signature_spec
13:04:01 <fjh> updated editors draft http://dev.w3.org/2006/waf/widgets-digsig/
13:04:44 <fjh> q+
13:04:49 <fjh> zakim, unmute me
13:04:49 <Zakim> fjh should no longer be muted
13:05:51 <tlr> zakim, unmute me
13:05:51 <Zakim> Thomas should no longer be muted
13:06:09 <fjh> zakim, what is the code?
13:06:09 <Zakim> the conference code is 9231 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), fjh
13:06:21 <tlr> zakim, mute me
13:06:21 <Zakim> Thomas should now be muted
13:06:45 <tlr> wtf?
13:06:53 <Zakim> +Frederick_Hirsch
13:07:01 <Zakim> -fjh
13:07:09 <tlr> s/wtf?//
13:07:25 <ArtB> FH: I suggest I walk thru my recent changes
13:07:27 <ArtB> AB: good
13:07:35 <ArtB> FH: some restructuring
13:07:40 <ArtB> ... added namesaces
13:07:45 <ArtB> ... added some definitions
13:08:42 <ArtB> ... big change is Author and Distributor signatures
13:08:44 <ArtB> ... updates should not be treated differently in this spec
13:08:52 <ArtB> ... still need to work on algorithms
13:09:07 <ArtB> ... XML Sig v1.1 should go to FPWD this week
13:09:30 <ArtB> ... some work on the proc model 
13:09:58 <ivandm> ivandm has joined #wam
13:10:03 <tlr> zakim, unmute me
13:10:03 <Zakim> Thomas should no longer be muted
13:10:49 <mpriestl> I have a few small comments but overall I think this is an excellent update of the document - many thanks Frederick!
13:10:59 <ArtB> FH: recommend we go thru TLR's comments first
13:11:10 <ArtB> AB: let's do that
13:11:35 <tlr> http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0547.html
13:12:11 <ArtB> TR: I'll skip editorial comments
13:12:31 <fjh> zakim, mute me
13:12:31 <Zakim> sorry, fjh, I do not know which phone connection belongs to you
13:12:42 <fjh> zakim, who is here?
13:12:42 <Zakim> On the phone I see +45.29.aaaa, Thomas, Frederick_Hirsch
13:12:43 <Zakim> On IRC I see ivandm, Zakim, ArtB, fjh, Marcos, timelE61i, abraun, tlr, drogersuk, mpriestl, arve, RRSAgent, heycam, shepazu, trackbot, timeless, timelyx
13:12:52 <fjh> zakim, Frederick_HIrsch is fjh
13:12:52 <Zakim> +fjh; got it
13:12:56 <fjh> zakim, mute me
13:12:57 <Zakim> fjh should now be muted
13:13:00 <fjh> q+
13:13:01 <ArtB> ScribeNick: drogersuk
13:13:11 <claudio> claudio has joined #wam
13:13:28 <fjh> zakim, unmute me
13:13:28 <Zakim> fjh should no longer be muted
13:13:29 <drogersuk> I would like to consider separate filname conventions
13:13:39 <drogersuk> for distributor and authors
13:13:49 <fjh> Widget Signature Name:
13:13:49 <fjh> The reserved file name "author-signature.xml"
13:13:59 <mpriestl> q+
13:14:04 <fjh> "signature" [0-9]* ".xml"
13:14:29 <drogersuk> <discussion on filename conventions>
13:14:45 <mpriestl> q-
13:14:55 <fjh> ack fjh
13:14:55 <drogersuk> FJH clarified a point that TLR raised - it was already included in the spec
13:15:11 <fjh> zakim, mute me
13:15:11 <Zakim> fjh should now be muted
13:16:03 <drogersuk> MC Thomas you have addressed my concerns, could you summarise why it is bad to have <role> attribute for signature in signature.xml?
13:16:19 <fjh> single signature per file, should state that explicitly
13:16:24 <drogersuk> TLR There is a basic design decision that there is a single signature per file
13:17:01 <mpriestl> q+
13:17:06 <drogersuk> TLR You don't want to look at two signatures at the same time
13:17:28 <drogersuk> MC We don't want to use filenames as an extensibility mechanism, but I can live with this
13:17:48 <fjh> right now we use file name convention instead of a manifest
13:18:05 <tlr> fjh, +1, that's precisely the problem
13:18:06 <tlr> q+
13:18:13 <drogersuk> MC you are optimising prematurely
13:18:26 <fjh> of course a manifest could be signed, addressing the signature insertion and deletion risk as well
13:18:33 <drogersuk> MP There are cases where you may want to be able to find the author signature without processing everything
13:18:48 <fjh> q+
13:18:58 <mpriestl> q-
13:19:05 <fjh> ack fjh
13:19:42 <drogersuk> MC I accept the proposed solution
13:20:01 <fjh> zakim, mute me
13:20:01 <Zakim> fjh should now be muted
13:20:25 <drogersuk> TLR I do not like using the filename in this way. We have different classes of resources inside the widget package
13:20:35 <drogersuk> ...same problem as content type discovery
13:20:52 <drogersuk> ..clearly our solution is not best, a manifest is the best way
13:21:06 <tlr> ... and I'm happy to defer this part of the discussion to a later time
13:21:15 <drogersuk> MC I proposed a manifest solution a couple of days ago
13:21:19 <drogersuk> ...it would be optional
13:21:26 <drogersuk> ...assigned around the content types
13:21:32 <mpriestl> q+
13:21:39 <drogersuk> ...per file declaration of what the content type is a maybe the role
13:21:47 <tlr> q-
13:22:06 <drogersuk> MP can the manifest discussion go on the mailing list?
13:22:39 <tlr> +1 to Mark
13:22:43 <drogersuk> MP I'm happy to review that, we're in no way stuck on using filenames, if there is a valid reason for manifest, let's discuss it asap
13:22:49 <mpriestl> q-
13:23:12 <drogersuk> TLR in the processing model, we say the distributor signature must countersign the author signature. We validate that
13:23:17 <ArtB> [ discussing TLR's comment "The processing model in 6.2 does not currently enforce the MUST NOT  on distributor signatures countersigning each other.  I'm having a  hunch that that might get abused by malevolent distributors in order  to interfere with each other; I therefore suggest that distributorr  signatures that countersign each other are a reason for validation  failure." ]
13:23:26 <drogersuk> we do not validate a distiributor signing another distributor
13:23:47 <drogersuk> ...I propose that this is invalid to break this case
13:23:51 <drogersuk> MP: I agree
13:23:54 <drogersuk> MC +1
13:23:56 <fjh> +1
13:24:06 <drogersuk> DR: +1
13:24:37 <drogersuk> AB: We have consensus here on that point
13:25:18 <drogersuk> TLR: editorial on ID-based reference
13:25:22 <fjh> zakim, unmute me
13:25:22 <Zakim> fjh should no longer be muted
13:25:24 <fjh> q+
13:25:26 <drogersuk> MP: agreed
13:25:50 <drogersuk> FJH: I'll update the draft. I could use some help from Thomas
13:26:06 <drogersuk> TLR: I'd be happy to review, but won't commit on sending a proposal
13:26:14 <fjh> zakim, mute me
13:26:14 <Zakim> fjh should now be muted
13:26:16 <ArtB> [ TLR's comment "In 4.4, we currently perform a dance around X.509 version numbers.   Thinking this through more thoroughly, it worries me that this came  up, for the following reason:  You need an X.509 v3 extension to  express the basic constraints on a certificate.  Without the basic  constraints extension, it is impossible to distinguish a CA  certificate from an end entity certificate.  Which in turn suggests  that somebody might have inadvertently generated 
13:26:18 <drogersuk> AB: The group here are happy for you to update the draft
13:27:21 <drogersuk> TLR: I propose certificates must be v3 to sign widgets
13:27:33 <fjh> zakim, unmute me
13:27:33 <Zakim> fjh should no longer be muted
13:27:40 <drogersuk> MP: I need to check internally - but provisionally this looks ok
13:27:50 <drogersuk> MC: I'll do the same internally at Opera
13:28:06 <drogersuk> FJH: It seems to be right for me
13:28:14 <tlr> RFC 5280 sets a default for v3 certificates that do not have the extension, and that's important.
13:28:22 <drogersuk> MC: It is messy supporting the three different standards
13:28:42 <drogersuk> TLR: It is important to reference RFC-5280
13:29:52 <drogersuk> AB: If we don't get any concerns in the next two weeks then we'll accetp v3
13:30:12 <drogersuk> FJH: Let's update to v3 now, then we can revert if issues
13:30:20 <drogersuk> AB: We have agreement on that
13:30:37 <fabrice> fabrice has joined #wam
13:30:57 <ArtB> [ TLR's comment "The current draft has a relatively complex set of interacting  signatures, but does not timestamp these at all.  I'd *really* like us  to mandate a timestamp property on each of the signatures, and demand  during validation that the timestamp MUST be in the past.  To give  just one example, assume a distributor's signing process is found to  be broken, but it's not practical to exchange the signature key.   Being able to weed out all signatures ma
13:32:19 <fjh> q+
13:32:24 <drogersuk> TLR outlined the point
13:32:41 <drogersuk> MP: Vodafone will most likely object to the validation failing if the timestamp is in the future
13:33:01 <drogersuk> MP: correction in the past
13:33:22 <drogersuk> MP: People don't set their date and time in the phone
13:33:31 <drogersuk> MP: This is a problem currently with java
13:33:59 <drogersuk> MP: Unless we demand that we have network time or accurate time on devices we will not be able to live with this
13:34:15 <drogersuk> MP: Defining it in our specification is dangerous for that reason
13:34:30 <drogersuk> MP: What type of timestamp? By the signer?
13:34:35 <drogersuk> TLR: Yes
13:34:52 <drogersuk> MP: The timestamp is a statement of when the author 'says' they signed it
13:35:10 <drogersuk> MP: Author's will set timestamps to make sure they get installed
13:35:31 <drogersuk> correction:authors
13:35:50 <fjh> q?
13:35:56 <drogersuk> MP: Do you see a use case for an expires and a timestamp?
13:36:14 <drogersuk> TLR: I agree about the phones point
13:36:34 <drogersuk> TLR: This is a good argument against the MUST
13:36:52 <drogersuk> TLR: Having expiration is useful as well
13:37:05 <drogersuk> TLR: The two cover separate parts of the problem
13:37:15 <fjh> current signature properties draft
13:37:16 <fjh> http://www.w3.org/2008/xmlsec/Drafts/xmldsig-properties/Overview.html
13:37:19 <drogersuk> ... expiration limits the impact in the future
13:37:37 <drogersuk> ...the timestamp helps you with which sequence signatures happened
13:37:44 <drogersuk> ..perhaps before some event
13:38:10 <Benoit> Benoit has joined #wam
13:38:25 <drogersuk> ...when the package was signed can be critically important <DR: this is for forensics purposes>
13:38:54 <drogersuk> ..and incident handling / reaction
13:39:28 <tlr> q+ to note that SHOULD with wall-clock is fine if we don't enforce upon validation
13:39:30 <Marcos> +q
13:39:44 <Marcos> -q
13:39:49 <mpriestl> Q+
13:40:11 <drogersuk> <TLR ran over the points again>
13:40:20 <Marcos> +q should <timestamp> be added to XML Dig Sig 1.1 instead of widgets dig sig?
13:40:43 <mpriestl> q+
13:40:45 <Marcos> +q to should <timestamp> be added to XML Dig Sig 1.1 instead of widgets dig sig?
13:41:34 <fjh> zakim, mute me
13:41:34 <Zakim> fjh should now be muted
13:41:47 <fjh> good question marcos
13:42:13 <tlr> ack t
13:42:13 <Zakim> Thomas, you wanted to note that SHOULD with wall-clock is fine if we don't enforce upon validation
13:42:21 <fjh> q-
13:43:06 <drogersuk> MP: I support Frederick's suggestion which was to recommend the use of timestamp and expires as best practices rather than mandating them
13:43:22 <drogersuk> ...a recommendation is good enough here
13:43:57 <fjh> q+
13:44:02 <drogersuk> MC: This timestamp element sounds pretty general. Shouldn't this go in the XML DigSig Spec? Having said that I agree with Mark's comments
13:44:03 <Zakim> +Josh_Soref
13:44:07 <tlr> I think it's fine for this to go into the signature properties document, with a "SHOULD use" in the widget signature spec.
13:44:25 <ArtB> Present+ Josh
13:44:26 <fjh> zakim, unmute me
13:44:26 <Zakim> fjh should no longer be muted
13:44:49 <drogersuk> FJH: There is some merit in what Marcos just said
13:45:01 <drogersuk> FJH: You might want to comment on that Thomas
13:45:18 <drogersuk> ...let's discuss that
13:45:23 <fjh> zakim, mute me
13:45:23 <Zakim> fjh should now be muted
13:45:59 <fjh> zakim, unmute me
13:45:59 <Zakim> fjh should no longer be muted
13:46:01 <Marcos> +q
13:46:03 <drogersuk> TLR: I don't have any deep thoughts on new timestamps... I'm fine with having a should
13:46:11 <fjh> q+
13:46:29 <drogersuk> TLR: It becomes unlikely that best practices get implemented
13:47:11 <drogersuk> MC: We want to avoid using new elements where possible
13:47:32 <drogersuk> ..our preference is to profile 1.1
13:47:47 <Marcos> s/we/Opera
13:47:49 <fjh> zakim, mute me
13:47:49 <Zakim> fjh should now be muted
13:48:19 <drogersuk> MP: I would support roughly what marcos said. We should reference the properties
13:48:22 <fjh> q+
13:48:29 <fjh> zakim, unmute me
13:48:29 <Zakim> fjh should no longer be muted
13:48:31 <drogersuk> ...role, expires and timestamp
13:48:45 <ArtB> ACTION: Frederick check XMl Sig 1.1 re role, expires, etc. properties
13:48:46 <trackbot> Created ACTION-305 - Check XMl Sig 1.1 re role, expires, etc. properties [on Frederick Hirsch - due 2009-03-04].
13:48:47 <drogersuk> ...but I would defer to the XML DigSig group
13:48:51 <drogersuk> FJH: I agree with Mark
13:49:35 <fjh> zakim, mute me
13:49:35 <Zakim> fjh should now be muted
13:49:40 <drogersuk> FJH: TLR if could you write down that use case it would really help
13:50:30 <fjh> +1 to additional hash agl
13:50:33 <drogersuk> AB: That closes the discussion then. TLR would you like to discuss hash algorithms and revocation?
13:50:36 <fjh> zakim, unute me
13:50:36 <Zakim> I don't understand 'unute me', fjh
13:50:42 <fjh> zakim, unmute me
13:50:42 <Zakim> fjh should no longer be muted
13:50:59 <drogersuk> AB: Let's discuss both. Firstly hash algorithm
13:51:03 <mpriestl> mpriestl has joined #wam
13:51:06 <ArtB> [ TLR's comment "I wonder whether we should be keeping an additional hash algorithm  in reserve, too. (That's a question that needs to go back to the XML  Security WG.)" ]
13:51:13 <drogersuk> FJH: I agree we need a second hash algorithm
13:51:45 <drogersuk> TLR: Not having a second hash algorithm that is outside the SHA family is an issue
13:52:42 <tlr> I suspect consensus about hash algorithms is easier than on the PK ones.
13:52:51 <drogersuk> FJH: We require some time and thought to get to where we want to be
13:53:54 <drogersuk> MP: On algorithms, on the digest algorithm I agree with TLR
13:54:22 <fjh> zakim, mute me
13:54:22 <Zakim> fjh should now be muted
13:54:57 <drogersuk> ..we have to be aware that in 5.2 Digest Algorithms, we support additional methods
13:55:41 <fjh> zakim,  unmute me
13:55:41 <Zakim> fjh should no longer be muted
13:56:05 <drogersuk> FJH: The validation needs to better match the generation requirements, I will look at that
13:56:48 <ArtB> [ TLR's comment "I'm worried that we don't say anything about revocation of  signatures.  I'd like to revisit why this is the case, and whether  there's anything we can do about it." ]
13:56:59 <fjh> suggest, we should not profile but should mention best practice of certificate  
13:57:00 <fjh> validtion and revocation checking
13:57:21 <fjh> q+
13:57:30 <Marcos> -q
13:58:07 <drogersuk> TLR: <discusses complexities of revocation>
13:58:37 <fjh> identify signature versus certifcate revocation
13:59:16 <tlr> can live with
13:59:40 <drogersuk> MP: Some of the stuff is policy dependent so is probably correctly left out of the specification
14:00:25 <drogersuk> FJH: I agree with Mark. I think we decided not to do a complete profile of the XML DigSig spec within this spec
14:00:27 <tlr> q+
14:01:01 <drogersuk> TLR: I can live with what Mark and Frederick said about revocation
14:01:08 <fjh> zakim, mute me
14:01:08 <Zakim> fjh should now be muted
14:01:29 <drogersuk> ..if we have a unique identifier for each signature, then we can store metadata about specific signatures
14:01:46 <fjh> so signature identifier could be another signature property?
14:01:54 <drogersuk> ..there may be several signatures over time from the same signer
14:02:03 <ArtB> RRSAgent, make minutes
14:02:03 <RRSAgent> I have made the request to generate http://www.w3.org/2009/02/25-wam-minutes.html ArtB
14:02:16 <fjh> zakim, unmute me
14:02:16 <Zakim> fjh should no longer be muted
14:02:19 <fjh> q+
14:03:17 <tlr> yew
14:03:20 <tlr> s/yew/yes/
14:04:40 <drogersuk> AB: Mandatory algorithms
14:04:51 <drogersuk> FJH: I'd like to mention something first
14:06:02 <drogersuk> ...I changed requirement 6.1 5c from MUST to MAY
14:06:34 <drogersuk> ...the ds:KeyInfo element MAY be included
14:06:44 <drogersuk> MP: I have one question related to this
14:07:22 <drogersuk> MP: we're relying on certificates - I'll go back and check this
14:07:25 <fabrice> fabrice has joined #wam
14:08:42 <drogersuk> MP: I think what you've changed is correct, but I just want to check it
14:08:48 <fjh> If a ds:KeyInfo element is present then it MUST conform to the [XMLDSIG11] specification. If present then any certificate chain SHOULD be validated and any CRL or OCSP information may be used as appropriate [RFC5280]..
14:09:35 <drogersuk> FJH: I just wanted to highlight this
14:09:49 <fjh> also
14:10:09 <fjh> The ds:KeyInfo element MAY be included and MAY include certificate, CRL and/or OCSP information. If so, it MUST be compliant with the [XMLDSIG11] specification. If certificates are used they MUST conform to the mandatory certificate format.
14:10:21 <drogersuk> AB: OK so let's go to mandatory algorithms
14:10:22 <fjh> sections on generation and validation
14:10:33 <drogersuk> AB: First Mark's point
14:10:45 <fjh> zakim, mute me
14:10:45 <Zakim> fjh should now be muted
14:10:57 <tlr> +1 to mark on that point
14:11:02 <drogersuk> MP: I'd like to thankyou for the restructuring work, it has moved this on a huge amount, thankyou
14:11:23 <drogersuk> MP: I have some small editorials I will send via email
14:11:34 <fjh> http://dev.w3.org/2006/waf/widgets-digsig/#signature-valiation
14:11:35 <drogersuk> ...one point here: section 6.2
14:11:50 <fjh> +1 re install statement
14:12:00 <fjh> I mean +1 mark
14:12:04 <Benoit> Benoit has joined #wam
14:12:13 <fjh> zakim, unmute me
14:12:13 <Zakim> fjh should no longer be muted
14:12:32 <tlr> "not install" is probably the wrong category, yes
14:12:50 <drogersuk> MP outlined issues on installations on different platforms
14:12:56 <tlr> q+
14:12:56 <fjh> proposal - If Widget Signature Validation fails for any reason the application must be informed of the failure and possibly the reason for failure.
14:13:51 <drogersuk> FJH: I agree with these points you are making
14:14:01 <drogersuk> MP: I agree with your approach FJH
14:14:27 <fjh> zakim, mute me
14:14:27 <Zakim> fjh should now be muted
14:14:37 <drogersuk> MP: In multiple digital signatures with one passing and one failing, there are different things to do, but that is getting into policy
14:14:37 <Marcos> MC: me too
14:14:40 <fjh> zakim, unmute me
14:14:40 <Zakim> fjh should no longer be muted
14:15:22 <tlr> q?
14:15:27 <tlr> ack m
14:15:28 <tlr> ack f
14:15:32 <tlr> ack t
14:16:06 <fjh> zakim, mute me
14:16:06 <Zakim> fjh should now be muted
14:16:33 <ivandm> ivandm has joined #wam
14:16:38 <drogersuk> TLR: A signature verifier could just return a boolean the way it is currently written
14:16:54 <drogersuk> ..there is no understanding of what trust anchors there are
14:17:01 <drogersuk> ..I would like to see it covered
14:17:08 <drogersuk> ..there must be a policy in place
14:17:12 <fjh> q+
14:17:16 <fjh> ack f
14:17:30 <fjh> zakim, mute me
14:17:30 <Zakim> fjh should now be muted
14:17:33 <drogersuk> FJH: I can try and do some wording, I think you're right Thomas
14:17:46 <drogersuk> MP: I agree it could be drawn out more, happy to help on this
14:18:18 <tlr> action: thomas to say something about trust anchors in the beginning of 6.2
14:18:18 <trackbot> Created ACTION-306 - Say something about trust anchors in the beginning of 6.2 [on Thomas Roessler - due 2009-03-04].
14:18:20 <fjh> no
14:18:45 <drogersuk> AB: Work split and step 4 and step 5...
14:19:11 <drogersuk> MC: I removed anything about handling responses and deferred it to widgets digsig spec
14:19:28 <ArtB> [ Step #4 is: http://dev.w3.org/2006/waf/widgets/#step-4--locate-digital-signatures-for-th ]
14:20:11 <fjh> q+
14:21:01 <fjh> ack f
14:21:13 <drogersuk> MC: where do we put author signature?
14:21:21 <mpriestl> fjh, I don't think we need any 
14:21:24 <drogersuk> MP: It doesn't really matter
14:21:35 <drogersuk> TLR: Policy issue
14:21:42 <tlr> s/TLR/fjh/
14:22:20 <fjh> zakim, mute me
14:22:20 <Zakim> fjh should now be muted
14:22:20 <drogersuk> MP: no need change anything in widget digsig
14:22:39 <drogersuk> MP: Find all signatures in package, then process in accordance with
14:22:43 <fjh> zakim, unmute me
14:22:43 <Zakim> fjh should no longer be muted
14:22:47 <drogersuk> ..widget digsig
14:22:54 <fjh> zakim, mute me
14:22:54 <Zakim> fjh should now be muted
14:23:02 <drogersuk> AB: step 4 and 5 have been simplified
14:23:31 <drogersuk> MP: the last sentence in step 5 says a UA must process...
14:23:57 <drogersuk> ...it should be possible for the UA to jump out of the list if it has enough information to make a policy decision
14:24:03 <fjh> http://dev.w3.org/2006/waf/widgets/#step-4--locate-digital-signatures-for-th
14:24:20 <drogersuk> MP: I might only be interested in the Nokia signature
14:24:37 <fjh> note need to change section 4 for author signatures
14:24:39 <drogersuk> MP: It makes sense to process in order, then skip out
14:24:39 <fjh> http://dev.w3.org/2006/waf/widgets/#digital-signatures
14:24:57 <timeless> q+
14:25:14 <drogersuk> MP: slight rewording plus a MAY on the author signature
14:25:49 <Marcos> MC: I added "Search at the root of the widget for any file whose file name field case insensitively matches author-signature.xml. If found, add this file entry to the signatures list."
14:25:54 <drogersuk> JS: My concern is that there is a revoked signature there
14:26:01 <drogersuk> JS: I'd like people to consider it
14:26:14 <drogersuk> ..even if they are interested in something else
14:26:22 <mpriestl> q+
14:27:19 <timeless> q-
14:27:44 <drogersuk> MP: You can define reasons for revocation if you want and there are different things you may want to do.
14:28:18 <drogersuk> MP: In some cases you may want to consider the status of more than one signature. We wouldn't stop you doing that - the UA and the policy determines when this happens
14:29:03 <timeless> soudns ok
14:29:27 <fjh> zakim, unmute me
14:29:27 <Zakim> fjh should no longer be muted
14:29:33 <fjh> q+
14:30:06 <drogersuk> FJH: Are we planning to address policy at some point?
14:30:20 <drogersuk> ..we need a note in the packaging spec
14:30:44 <drogersuk> MP: The processing is dependent on your policy and we don't define what that is
14:31:15 <fjh> need to add statement that processing depends on policy
14:31:27 <drogersuk> DR: This comes back to our discussion on new work items - for example security policy type issues
14:31:43 <drogersuk> AB: So right now we don't have a draft charter for that working group yet
14:31:52 <tlr> yes
14:31:59 <drogersuk> FJH: Which is why we need to outline the concerns now before that group is there
14:32:02 <Marcos> MC: As an aside, in the PC spec, I added the following text "Search at the root of the widget for any file whose file name field case insensitively matches the naming convention for the author's digital signature (i.e., author-signature.xml). If found, add the matching file entry to the end of the signatures list."
14:32:37 <drogersuk> MC: the processing part in step 4
14:32:47 <fjh> zakim, mute me
14:32:47 <Zakim> fjh should now be muted
14:33:22 <drogersuk> MP: This is sort of what we need, let's take it offline though
14:33:55 <drogersuk> RH: If we have the author at the end of the list, we can't step out of the processing
14:34:19 <ArtB> RRSAgent, make minutes
14:34:19 <RRSAgent> I have made the request to generate http://www.w3.org/2009/02/25-wam-minutes.html ArtB
14:34:49 <drogersuk> MC clarified how you could do this
14:34:54 <fjh> no
14:35:30 <drogersuk> AB: Let's cover issue #81
14:35:55 <drogersuk> AB: OK, schedule firast
14:35:56 <drogersuk> first
14:36:23 <fjh> q+
14:36:33 <drogersuk> MP: We've addressed most of the comments
14:37:28 <drogersuk> MP: I think we're ready once the updates are complete, we're ready to go to the next WD. Next stage would be LCWD
14:38:04 <fjh> zakim, unmute me
14:38:04 <Zakim> fjh should no longer be muted
14:38:07 <drogersuk> MP: Fundamentals have not changed and I think we're all agreed on and it would be great to get to last call
14:38:39 <drogersuk> FJH: I need to make some changes and include the comments, I'd like to reference the FCWD from XML DigSig this week
14:38:58 <drogersuk> FJH: Other than that, then I don't see why not
14:39:13 <tlr> q+
14:39:22 <drogersuk> FJH: Properties stuff would mean doc would need delaying
14:40:27 <drogersuk> TLR: We have some different options - perhaps we could put an editors note in the widget signatures document saying what will be included
14:40:53 <drogersuk> FJH: This could solve the properties issue
14:41:34 <tlr> it's not pretty, but it's probably easiest
14:41:40 <drogersuk> AB: We have agreement on that route
14:42:14 <drogersuk> AB: 4-5 weeks from now we could have a LCWD
14:44:23 <drogersuk> TLR: Let's take this offline
14:45:22 <Benoit> I understand 19th march for the last WD --- 16 april for LC --- 14 may RC
14:46:15 <tlr> +1 to taking this offline
14:47:11 <fjh> +1 to taking this offline
14:47:18 <drogersuk> AB: Last thing on the list is mandatory algorithms
14:47:40 <drogersuk> TLR: Think about EC and DSA
14:47:54 <drogersuk> ..no consensus in the security group yet
14:48:32 <drogersuk> MP: We would prefer the spec to be finished rather than have drawn out discussions
14:48:50 <fjh> zakim, mute me
14:48:50 <Zakim> fjh should now be muted
14:48:51 <drogersuk> ..there are unclear IPR issues around ECDSA
14:49:05 <drogersuk> ...we haven't been able to check on that
14:49:26 <drogersuk> ...the reasons for rejecting DSASHA-256 are not very strong from the XML SG
14:49:44 <tlr> q+ to add information on the FIPS
14:49:50 <fjh> zakim, unmute me
14:49:50 <Zakim> fjh should no longer be muted
14:50:25 <drogersuk> TLR: The FIPS standard is done, it is waiting for the US Secretary of Commerce to sign it... however there is no Secretary of Commerce appointed yet
14:51:28 <drogersuk> FJH: Need to know who can live with EC or DSA
14:51:35 <MD> MD has joined #wam
14:51:42 <fjh> zakim, mute me
14:51:42 <Zakim> fjh should now be muted
14:51:48 <drogersuk> DR: Suggest raising as an action
14:52:14 <drogersuk> DR: I can circulate for feedback in OMTP
14:52:57 <drogersuk> Arve: There is not much real world use of EC
14:53:17 <drogersuk> ...I would like to understand if and why it is necessary now and not at some later stage
14:53:30 <drogersuk> MC: We want to future proof as much as possible
14:53:40 <ArtB> ACTION: Marcos determine Opera's position on elliptic curve re Widgets DigSig spec 
14:53:40 <trackbot> Created ACTION-307 - Determine Opera's position on elliptic curve re Widgets DigSig spec  [on Marcos Caceres - due 2009-03-04].
14:54:11 <ArtB> ACTION: David determine Opera's position on elliptic curve re Widgets DigSig spec 
14:54:11 <trackbot> Sorry, amibiguous username (more than one match) - David
14:54:11 <trackbot> Try using a different identifier, such as family name or username (eg. dorchard, drogers)
14:54:49 <tlr> ACTION: rogers to determine OMTP's position on EC re Widgets DigSig spec
14:54:49 <trackbot> Created ACTION-308 - Determine OMTP's position on EC re Widgets DigSig spec [on David Rogers - due 2009-03-04].
14:54:58 <tlr> zakim, mute arve
14:54:58 <Zakim> sorry, tlr, I do not know which phone connection belongs to arve
14:55:02 <tlr> zakim, who is on the phone?
14:55:02 <Zakim> On the phone I see +45.29.aaaa, Thomas, fjh (muted), Josh_Soref
14:55:06 <fjh> zakim, unmute me
14:55:06 <Zakim> fjh should no longer be muted
14:55:34 <ArtB> ACTION: Rogers determine OMTP's position on elliptic curve re Widgets DigSig spec 
14:55:34 <trackbot> Created ACTION-309 - Determine OMTP's position on elliptic curve re Widgets DigSig spec  [on David Rogers - due 2009-03-04].
14:55:53 <tlr> ACTION-308: duplicate of ACTION-309
14:55:53 <trackbot> ACTION-308 Determine OMTP's position on EC re Widgets DigSig spec notes added
14:55:55 <tlr> ACTION-308 closed
14:55:55 <trackbot> ACTION-308 Determine OMTP's position on EC re Widgets DigSig spec closed
14:56:30 <drogersuk> FJH: I'd like to understand where we are with this
14:56:56 <drogersuk> TLR: We need the feedback on the document that is being published tomorrow
14:57:25 <fjh> Please review XML Siganature 1.1 working draft, algorithms and give feedback!
14:58:46 <drogersuk> AB: Thanks for joining guys and particularly Frederick for updating the spec
14:58:54 <drogersuk> FJH: Thanks to everyone for their comments
14:58:59 <Zakim> -Josh_Soref
14:59:00 <Zakim> -fjh
14:59:02 <Zakim> -Thomas
14:59:43 <Zakim> - +45.29.aaaa
14:59:44 <Zakim> IA_WebApps(Widgets F2F)3:30AM has ended
14:59:45 <Zakim> Attendees were +45.29.aaaa, fjh, Thomas, Josh_Soref
14:59:50 <abraun> abraun has joined #wam
15:18:12 <ArtB> ArtB has joined #wam
15:18:34 <ArtB> RRSAgent, make Minutes
15:18:34 <RRSAgent> I have made the request to generate http://www.w3.org/2009/02/25-wam-minutes.html ArtB
15:18:40 <ArtB> ScribeNick: ArtB
15:20:58 <ajbraun> ajbraun has joined #wam
15:22:30 <ArtB> Topic: Media type declarations; MIME; etc. 
15:25:45 <ArtB> AB: looking at the agenda, Marcos
15:26:16 <ArtB> ... Is the <type> element still something we need to discuss or drop?
15:26:18 <ArtB> MC: drop it
15:26:27 <claudio> claudio has joined #wam
15:26:42 <ArtB> ... we want to talk about the <media> element proposal
15:26:57 <ArtB> ... http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0491.html
15:27:51 <ArtB> ... Larry Masinter submitted some comments
15:28:44 <ArtB> ... LM: http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0459.html
15:30:44 <ArtB> ... No, LM's response is: http://lists.w3.org/Archives/Public/public-pkg-uri-scheme/2009Feb/0003.html
15:31:52 <ArtB> [ Marcos displays a strawman proposal of the <manifest> element ... ]
15:32:34 <Marcos> <manifest xmlns="">
15:32:34 <Marcos>    <media path="" type=""/>
15:32:34 <Marcos>    <media ext="space delimited list" type=""/>
15:32:34 <Marcos> </manifest>
15:33:06 <ArtB> Arve: are path and extension mutually exclusive for a given element?
15:33:50 <Marcos> <media path="styles/" ext="php" type="text/css" />
15:34:16 <Marcos> <media path="styles/mystyle"  type="text/css" />
15:34:26 <arve> [ foo.css, bar, baz ]
15:34:27 <Marcos> <media path="styles/" ext="php" type="text/css;charset=utf8" />
15:34:47 <arve> [bar, baz] = text/html, foo.css = text/css
15:35:36 <Marcos> <media path="styles/" type="text/css" /> <media path="styles/foo.css" type="text/css" />
15:36:14 <ArtB> RRSAgent, make minutes
15:36:14 <RRSAgent> I have made the request to generate http://www.w3.org/2009/02/25-wam-minutes.html ArtB
15:36:40 <Marcos> <media path="foo/" ext="php" type="text/css" /> <media path="foo/bar/" type="" />
15:37:00 <Marcos> where type="" = unknown, so sniff
15:37:43 <ArtB> AB: any comments about this proposal?
15:37:48 <ArtB> Arve: looks pretty solid
15:38:08 <Marcos> <media path="styles/" type="text/css" /> <media path="styles/" type="text/html" />, where the second overrides the first
15:38:57 <ArtB> AB: so the precedence is what?
15:39:06 <ArtB> MC: last one is the winner
15:39:10 <arve> /home/user/foo/
15:39:12 <arve> foo
15:40:01 <Marcos> how would this work with xml:base
15:40:03 <Marcos> ?
15:40:59 <ArtB> AB: does this proposal address the issues LM raised?
15:41:28 <ArtB> MC: some of them
15:41:37 <ArtB> ... it encorporates some of his concerns
15:43:21 <arve> I quite like type="application/uberml+xml;charset=UTF-7"
15:43:21 <ArtB> MC: he agreed we don't need to include every file in the ZIP
15:43:38 <ArtB> ... for example, we could just target one folder
15:44:40 <ArtB> MC: who wins in the conflict of manifest versus config file
15:44:48 <ArtB> ... I like config file wins
15:45:39 <Benoit_> Benoit_ has joined #wam
15:48:12 <ArtB> MC: this proposal does not conflict with HTML5's cache manifest
15:48:20 <ArtB> ... that is completely different use case
15:48:24 <ArtB> AB: good
15:49:17 <ArtB> AB: what is the processing model?
15:49:45 <ArtB> MC: I will define it in a separate new spec - it will not be in the P&C spec
15:49:58 <ArtB> AB: when will it be used
15:50:33 <ArtB> MC: one use case is when a user wants to save a widget and the WUS can slurp up all of the files for a widget
15:50:52 <ArtB> s/WUS can/WUA can/
15:52:28 <ArtB> AB: is Opera convinced we need this for v1.0?
15:52:40 <ArtB> MC: no, not necessarily. 2.0 could be OK
15:53:35 <ArtB> ... It has been requested by several people including TLR, LM and Adam Barth
15:53:44 <ArtB> Arve: I'm not convinced we need it
15:54:14 <ArtB> ... sure Save As Widgets is neat but not sure we need a spec to cover the use case
15:56:09 <ArtB> AB: what's the relationship between this proposal and the issue Adam Barth raised?
15:56:24 <ArtB> ... i.e. http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0264.html
15:56:55 <ArtB> MC: Adam proposed something like this so indeed my proposal addresses his concerns
15:57:29 <ArtB> AB: has Adam responded to this proposal?
15:57:32 <ArtB> MC: no, not yet
15:58:43 <ArtB> AB: do you anticipate proponents of this functionality pushing for this element to be added to P&C spec?
15:58:45 <ArtB> MC: not sure
15:59:53 <ArtB> AB: so here is where I think we are with this:
16:00:32 <ArtB> ... A number of people have suggested we need to address this issue e.g. file extension to MIME type mapping
16:00:39 <ArtB> ... we are in general agreement
16:00:51 <ArtB> ... But we don't think it needs to be specified in the P&C spec
16:01:15 <ArtB> ... We are willing to define this functionality in a separate spec 
16:02:04 <ArtB> ... And probably not in the Widget spec series
16:03:07 <ArtB> DR: think the P&C spec needs to specify a UI format e.g. HTML
16:03:26 <ArtB> MC: the P&C spec is agnostic - it just specifies the config file and the package format
16:04:16 <ArtB> Arve: the reality is most of the implemenations will be compatible with each other and implement a superset of P&C + DigSig + A&E + ...
16:05:31 <ArtB> MC: P&C does not define a "Widget User Agent" just a UA that can process the config file and ZIP format
16:06:01 <ArtB> DR: we want any widget that will run anywhere
16:06:43 <ArtB> ... think we're going to get that widgets that can't be run e.g. only contains a DLL
16:07:56 <ArtB> DR: we want the W3C to define Widget User Agent
16:08:07 <ArtB> Arve: the W3C hasn't defined what a Web page is
16:09:00 <ArtB> MC: to be accurate, we should replace the <widget> element with <package> element
16:11:53 <ArtB> AB: we should go back to the FPWD as that title is probably more accurate than the current one
16:12:47 <ArtB> Arve: my expectation is that a WUA will be able to handle HTML
16:13:22 <ArtB> ... but I don't think that should be mandatory
16:13:55 <ArtB> MC: the original title was "Web Applications Packaging Format"!
16:14:16 <ArtB> CV: I don't think we can replace Widgets at this point
16:16:15 <chaals> chaals has joined #wam
16:16:53 <ArtB> MC: In hindsight I think we should not have switched to the name Widget
16:18:48 <ArtB> ... I can put the old WUA dependency information into an Informative appendix if people think that would be useful
16:20:57 <ArtB> AB: we aren't seriously considering changing the title of the P&C spec, right?
16:20:59 <ArtB> MC: no
16:21:02 <ArtB> Arve: no
16:21:17 <ArtB> DR: still then, where is Widget User Agent defined
16:21:40 <ArtB> AB: I'm mostly indifferent but it does not belong in the P&C spec
16:22:35 <ArtB> DR: so how do we solve this problem?
16:22:44 <drogersuk> we are at serious risk of market fragmentation
16:23:03 <ArtB> MC: one approach as I mentioned is to add an informative note to the P&C spec
16:24:39 <ArtB> AB: why doesn't OMTP define WUA as it see fit?
16:24:47 <ArtB> DR: that leads to fragmenation
16:25:53 <ArtB> MC: we can recommend specific MIME types but we can't mandate them
16:26:05 <ArtB> s/it see fit/it sees fit/
16:26:55 <ArtB> ... for example the widget i.e. package could contain Flash
16:27:57 <ArtB> MC: are you willing to write text that covers your concern?
16:29:27 <drogersuk> ACTION:rogers OMTP to take Marcos' original text and modify to add the concerns over MIME types
16:30:57 <ArtB> MC: note HTML5 doesn't define any dependencies
16:31:08 <ArtB> ... although they are implied
16:33:29 <ArtB> RRSAgent, make minutes
16:33:29 <RRSAgent> I have made the request to generate http://www.w3.org/2009/02/25-wam-minutes.html ArtB
16:36:44 <ArtB> Topic: #  <feature> default; raised by Kai Hendry 
16:36:53 <ArtB> AB: what's the status of this?
16:37:03 <ArtB> MC: I've already addressed this
16:37:21 <ArtB> ... feature is required at runtime unless explicitly set to optional
16:39:05 <ArtB> ACTION: Marcos make sure the <feature> comment by Kai has been addressed
16:39:05 <trackbot> Created ACTION-310 - Make sure the <feature> comment by Kai has been addressed [on Marcos Caceres - due 2009-03-04].
16:40:13 <ArtB> ACTION: Rogers OMTP to take Marcos' original text and modify to add the concerns over MIME types
16:40:13 <trackbot> Created ACTION-311 - OMTP to take Marcos' original text and modify to add the concerns over MIME types [on David Rogers - due 2009-03-04].
16:41:01 <ArtB> Topic: <icon> element ISSUE: what if it's a vector and no size is given?
16:41:11 <ArtB> AB: Marcos, what's the status of this?
16:41:24 <ArtB> ... http://dev.w3.org/2006/waf/widgets/#the-icon-element
16:41:57 <ArtB> MC: Doug gave me some proposed text and I've added it to the ED
16:42:24 <ArtB> Arve: is this really needed in the spec?
16:42:39 <ArtB> ... Seems like its specifying visual behavior of the UA
16:43:25 <ArtB> MC: during the 2nd LC we must do a better job of removing anything that is extaneous to the config file and package format
16:44:06 <ArtB> AB: from the P&C perspective, I don't think this needs to be specified
16:44:37 <ArtB> Topic: <preference> element proposal; by Art Barstow 
16:44:44 <ArtB> AB: what's the status Marcos?
16:44:51 <ArtB> MC: I've already specified this
16:45:05 <ArtB> ... see the latest ED
16:45:26 <ArtB> Arve: I don't agree with MUST in this case
16:46:11 <ArtB> ... I can think of some cases were MUST is too strong
16:47:00 <ArtB> [ MC makes a change in the ED to address Arve's comment ]
16:47:54 <ArtB> Arve: how will read-only be handled by the UA implementing the preferences array as defined in the A&E spec?
16:48:17 <ArtB> MC: that array should be read-only
16:48:24 <ArtB> Arve: I'm not sure about that
16:50:41 <ArtB> Ivan: what are the use cases?
16:51:05 <Marcos> for var in preferences {}
16:51:08 <ArtB> Arve: a widget like a RSS reader could have a list of URIs
16:51:53 <arve> for (var key in widget.preferences){ /* ... */ }
16:53:43 <ArtB> Ivan: seems like we don't need two mechanisms here
16:53:51 <ArtB> ... How do you get the keys?
16:54:05 <ArtB> MC: we will probably need a keys attribute
16:54:32 <ArtB> ... we don't want to build a dependency on HTML5
16:55:02 <ArtB> ... we probably also need methods to clear the array
16:56:18 <ArtB> Arve: what if prefs returned generic objects rather than a DOMString?
16:56:24 <ArtB> ... not sure we want to go that way
16:57:50 <Zakim> Zakim has left #wam
16:57:50 <ArtB> Ivan: I made a proposal on the mail list
16:57:52 <ArtB> ... http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0455.html
17:01:01 <ArtB> [ Discussion of Ivan's proposal in the above e-mail ]
17:03:26 <ArtB> [ Marcos adds some related text to Req #28 e.g. some methods needed to support richer Preferences ... ]
17:05:58 <ArtB> AB: Meeting Adjourned
17:06:11 <ArtB> RRSAgent, make minutes
17:06:11 <RRSAgent> I have made the request to generate http://www.w3.org/2009/02/25-wam-minutes.html ArtB
17:06:55 <ivandm> ivandm has joined #wam
17:08:31 <ArtB> RRSAgent, bye
17:08:31 <RRSAgent> I see 12 open action items saved in http://www.w3.org/2009/02/25-wam-actions.rdf :
17:08:31 <RRSAgent> ACTION: Marcos respond to Marcin and ask him to make specific proposals if he has any [1]
17:08:31 <RRSAgent>   recorded in http://www.w3.org/2009/02/25-wam-irc#T08-21-31
17:08:31 <RRSAgent> ACTION: Marcos report back to the WG ASAP regarding your ability to be the Editor of the two new specs proposed and discussed on Feb 24 [2]
17:08:31 <RRSAgent>   recorded in http://www.w3.org/2009/02/25-wam-irc#T08-50-11
17:08:31 <RRSAgent> ACTION: Marcos will make a hybrid proposal and send it the mail list [3]
17:08:31 <RRSAgent>   recorded in http://www.w3.org/2009/02/25-wam-irc#T10-04-28
17:08:31 <RRSAgent> ACTION: Frederick check XMl Sig 1.1 re role, expires, etc. properties [4]
17:08:31 <RRSAgent>   recorded in http://www.w3.org/2009/02/25-wam-irc#T13-48-45
17:08:31 <RRSAgent> ACTION: thomas to say something about trust anchors in the beginning of 6.2 [5]
17:08:31 <RRSAgent>   recorded in http://www.w3.org/2009/02/25-wam-irc#T14-18-18
17:08:31 <RRSAgent> ACTION: Marcos determine Opera's position on elliptic curve re Widgets DigSig spec  [6]
17:08:31 <RRSAgent>   recorded in http://www.w3.org/2009/02/25-wam-irc#T14-53-40
17:08:31 <RRSAgent> ACTION: David determine Opera's position on elliptic curve re Widgets DigSig spec  [7]
17:08:31 <RRSAgent>   recorded in http://www.w3.org/2009/02/25-wam-irc#T14-54-11
17:08:31 <RRSAgent> ACTION: rogers to determine OMTP's position on EC re Widgets DigSig spec [8]
17:08:31 <RRSAgent>   recorded in http://www.w3.org/2009/02/25-wam-irc#T14-54-49
17:08:31 <RRSAgent> ACTION: Rogers determine OMTP's position on elliptic curve re Widgets DigSig spec  [9]
17:08:31 <RRSAgent>   recorded in http://www.w3.org/2009/02/25-wam-irc#T14-55-34
17:08:31 <RRSAgent> ACTION: rogers OMTP to take Marcos' original text and modify to add the concerns over MIME types [10]
17:08:31 <RRSAgent>   recorded in http://www.w3.org/2009/02/25-wam-irc#T16-29-27
17:08:31 <RRSAgent> ACTION: Marcos make sure the <feature> comment by Kai has been addressed [11]
17:08:31 <RRSAgent>   recorded in http://www.w3.org/2009/02/25-wam-irc#T16-39-05
17:08:31 <RRSAgent> ACTION: Rogers OMTP to take Marcos' original text and modify to add the concerns over MIME types [12]
17:08:31 <RRSAgent>   recorded in http://www.w3.org/2009/02/25-wam-irc#T16-40-13