[widgets] Minutes from 25 February 2009 Widgets F2F Meeting

The minutes from the February 25 Widgets f2f meeting are available at  
the following and copied below:

   <http://www.w3.org/2009/02/25-wam-minutes.html>

WG Members - if you have any comments, corrections, etc., please send  
them to the public-webapps mail list before 5 March 2009 (the next  
Widgets voice conference); otherwise these minutes will be considered  
Approved.

-Regards, Art Barstow

    [1]W3C

       [1] http://www.w3.org/

                                - DRAFT -

                           Widgets F2F Meeting

25 Feb 2009

    [2]Agenda

       [2] http://www.w3.org/2008/webapps/wiki/WidgetsParisAgenda

    See also: [3]IRC log

       [3] http://www.w3.org/2009/02/25-wam-irc

Attendees

    Present
           Art, Andy, Claudio, Ivan, Fabrice, Rainer, Mark, David, Arve,
           Benoit, Marcos, Mike(IRC), Josh(IRC), Billy, Mohammed, Josh

    Regrets
    Chair
           Art

    Scribe
           Art

Contents

      * [4]Topics
          1. [5]<content> tags?
          2. [6]Focus & widgets management; by Marcin
          3. [7]Window Modes
          4. [8]Proposal for a "Settings" View Mode; Benoit
          5. [9]<access> Element
          6. [10]BONDI Update by David Rogers
          7. [11]New Work related to the Device API and Security
             Workshop
          8. [12]Widgets Digital Signatures
          9. [13]Media type declarations; MIME; etc.
         10. [14]# <feature> default; raised by Kai Hendry
         11. [15]<icon> element ISSUE: what if it's a vector and no size
             is given?
         12. [16]<preference> element proposal; by Art Barstow
      * [17]Summary of Action Items
      _________________________________________________________



    <ArtB> ScribeNick: ArtB

    <scribe> Scribe: Art

    Date: 25 Feb 2009

<content> tags?

    AB: what is the status Ivan?

    Ivan: I considere that closed in that the modes can be used to
    address my use cases

Focus & widgets management; by Marcin

    AB: not clear if this info was more FYI or formal comments for the
    LCWD

    Arve: I think this is more informational i.e. this is how Access
    addresess window modes

    MC: right; the QVGA proposal for example isn't something we want to
    do

    Arve: the methods in his email are mostly covered in our A&E spec

    AB: do we need to follow-up?

    Arve: there are no questions there
    ... if he feels strongly about his model being reflected in our
    model, he should make specific proposals for the Editor

    AB: I think that is a reasonable proposal

    <scribe> ACTION: Marcos respond to Marcin and ask him to make
    specific proposals if he has any [recorded in
    [18]http://www.w3.org/2009/02/25-wam-minutes.html#action01]

    <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].

Window Modes

    MP: want to discuss what goes into the P&C based on our consensus
    from yesterday

    AB: yesterday's minutes are:
    [19]http://www.w3.org/2009/02/24-wam-minutes.html

      [19] http://www.w3.org/2009/02/24-wam-minutes.html

    Arve: not sure we will know until the new specs are available to
    review

    MP: re width and height property; in some cases you may want to use
    a different values depending on the mode
    ... what goes in the modes spec?

    MC: just the definitions of the 4 modes

    [ Arve sketches a "live" proposal of the syntax ... ]

    [ Marcos to drop in IRC this proposal ... ]

    <Marcos> <viewport

    <Marcos> mode = "one of the modes"

    <Marcos> width = "csspx"

    <Marcos> height = "csspx"

    <Marcos> min-height = "csspx"

    <Marcos> min-width = "csspx"

    <Marcos> max-height = "csspx"

    <Marcos> max-width = "csspx"

    <Marcos> resize = "true|false"

    <Marcos> ...

    <Marcos> />

    MP: the definitions of the modes spec will then define what these
    mean?

    Arve: yes, that's the idea

    BS: how does one define a widget that works for both mobile and
    desktop?

    Arve: would define two veiwports

    MP: but some modes don't use height and width

    Arve: then for some modes they wouldn't be needed

    AB: or ignored if present

    BS: what about orientation of the device?

    Arve: that's handled by CSS
    ... if a widget doesn't fit in a viewport e.g. on a mobile, the UA
    could provide zoom

    <timeless> so, a WUA is required to provide zoom?

    <arve> timeless: no

    Arve: we go with CSS pixels in the spec
    ... with the expectation that eventually UAs will likely do some
    zooming

    AB: Mark, are you asking for some details about what goes in the P&C
    spec and the other two new specs proposed?

    MP: I understand what goes into the two new proposed specs but not
    clear about what goes in P&C

    <scribe> 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 [recorded in
    [20]http://www.w3.org/2009/02/25-wam-minutes.html#action02]

    <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].

    MC: I wonder if some of the attributes proposed above can be handled
    by CSS

    Arve: what if an imple doesn't support CSS

    AB: I think we've hit the point of dimminishing returns on this

    MC: give us a week and we'll put forward a proposal

Proposal for a "Settings" View Mode; Benoit

    <Marcos>
    [21]http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/02
    48.html

      [21] http://lists.w3.org/Archives/Public/public-webapps/ 
2009JanMar/0248.html

    BS: in my email I enumerate various modes we need
    ... Settings is one mode we need but we haven't discussed
    ... think the developer would want a consistent and convenient way
    to define/modify settings

    MC: I'm warming to this idea a little
    ... e.g. could right-click and get to this info

    Arve: I disagree vehemently
    ... this is ultimately about being able to display some specified
    content in a specific way
    ... 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

    BS: If I build a widget want a config view for it

    Arve: how is that diff than any other state?
    ... how is settings different than refresh, for example

    [ MC demos Dashboard and the "I" key used to get to the widget's
    settings ... ]

    MC: can imagine using some of the new CSS3 Modules e.g. Transforms
    (2d, 3d), Transitions, etc.

    DR: something like Fring service isn't useful until it is configured

    Arve; well that's a broken service

    DR: my point is there is a use case for using a widget's settings
    without first instantiating the widget

    Arve: this seems more about a widget being able to handle online or
    offline

    AB: I'm not seeing a lot of support for this
    ... 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

    BS: yes, that's OK with me
    ... I did want to discuss this mode and we've done that

    AB: any other topics related to Window Modes?

    [ None ]

<access> Element

    AB: what's the best place to start?

    MP: we should start with MC's latest e-mail

    AB: here is MP's 2nd proposal:
    [22]http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/05
    05.html
    ... MC then responded on Feb 22 with:
    [23]http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/05
    17.html

      [22] http://lists.w3.org/Archives/Public/public-webapps/ 
2009JanMar/0505.html
      [23] http://lists.w3.org/Archives/Public/public-webapps/ 
2009JanMar/0517.html

    MP: the semantics of the network attribute is not clear
    ... want author to be able to enumerate the white-listed hosts
    ... However, there are some use cases where that list will not be
    know in advance e.g. a RSS reader
    ... We need an "escape" mechanism for these use cases

    [ We review strawman proposal by Arve ... ]

    <arve> element security optional

    <arve> element access multiple

    <arve> element "protocol" multiple

    <arve> cdata

    <arve> element "host" multiple

    <arve> cdata

    <arve> element "port" multiple

    <arve> cdata

    <arve> element "path" multiple

    <arve> cdata

    <arve> element "content"

    <arve> attribute "plugin" value = "yes|no"

    Arve: the idea is a widget would be restricted to those access
    methods that are explicit in the config file

    MP: BONDI has done some related work but using a URI with pattern
    matching
    ... VF would like to move that functionality from BONDI spec to W3C
    spec

    <anne> arve, btw, why not just have <origin>

    <Marcos> what do you mean by it?

    <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

    <Marcos> anne

    <arve> anne: mind joining the call and explaining it?

    <anne> (it's just syntax so I don't think worth it)

    <Marcos> <widget> <origin uri="[24]http://microsoft.com"> ?

      [24] http://microsoft.com/

    <anne> that's worth it*

    <anne> <security> <origin>[25]http://example.org:81/</origin> rather
    than putting scheme, host and port into separate elements

      [25] http://example.org:81/%3C/origin%3E

    <timeless> the strawman looks like it's likely to fail

    <arve> anne: got URI schemes for ssh, telnet, xmpp, raw sockets,
    udp?

    Arve: with widgets, there isn't really an origin

    <timeless> arve: there is a bad one for ssh and telnet

    MC: that's one reason we need a different URI scheme for widgets

    <Marcos> anne, can I take over microsoft?

    <Marcos> see my example above?

    <arve> protocol: https ; host: google.com, yahoo.com, ask.com; path:
    search/

    MC: need to also specify subdomains

    <Marcos> MC: FWIW, this is like an inverse of CORS

    MP: having multiple hosts associated with a single scheme and path
    is problematic

    <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

    <arve> characters of the directive host were the wildcard sequence
    '.*' consider the host a match.

    Arve: I'm not totally opposed to a URI scheme

    MC: what proposal is that?

    Arve: the one from Anne above
    ... with a few modification

    <arve> element uri multiple

    <Marcos> Anne, do you still have any funky syntax in CORS for
    selecting subdomains (i.e., *.example.com) ?

    <arve> . attribute src

    [ Arve begins a new strawman proposal ... ]

    <arve> <network><access><uri
    src="[26]http://www.google.com/"/></access></network>

      [26] http://www.google.com/

    Arve: need wildcards on path and subdomains

    <anne> Marcos, no, just origins

    <arve> *.google.com

    <arve> google.com

    <Marcos> so, nothing like what arve has above

    <Marcos> right anne

    <Marcos> you gave up on that

    <anne> is there a document that outlines what this security proposal
    is proposed to solve?

    MP: BONDI allows wildcards in subdomains and paths

    <Marcos> Anne, it's for cross domain request.

    <Marcos> as perfomed when no origin is available

    <arve> <path>/cats</path>

    <arve> thus, the widget can access all of

    <arve> /cats/siamese.html

    <arve> /cats/

    <arve> /catsoup

    <anne> Marcos, does it affect e.g. <iframe>?

    <Marcos> (HTML5 "origin" of a widget will be a widget specific URI
    (e.g., widget://bla;1231-123

    <anne> Marcos, because in that case <path> restrictions are
    pointless

    <anne> Marcos, why is there even restrictions on cross domain
    requests and not just a http(s) boolean?

    <Marcos> we are proposing <domain uri="*"/> meaning allow all
    domains (and supported URI schemes) and <domain uri="uri"/>

    MP: how would this deal with subdomain?

    MC: they would have to be added

    <Marcos> Anne, because we think that authors should declare which
    domains they need to access

    <Marcos> and we don't want to restrict this to http

    <anne> Marcos, but why do you think authors need to do that?

    <anne> Marcos, also, what APIs do you have that go beyond HTTP(S)?

    AB: let's try to regroup and determine where we have agreement and
    document those issues with no agreement

    <Marcos> Anne, Q1. they probably don't. Q2. none :)

    MP: subdomains is still open
    ... it would be good if we could synch with BONDI and their deadline
    is March 9
    ... want to get alignment if at all possible

    MC: so what exactly is the usage?
    ... how does it interact with sec policy?

    Arve: don't want widgets to be a vessel for attacking remote web
    sites

    <Marcos> Anne... please see minutes now re q1

    <anne> Marcos, great solution to a non-problem then, lol

    Arve: thus may want to restrict some sites

    MP: want author to practice least privs principle
    ... want other parties e.g. user, widget distributor, etc. to be
    able to examine the host list
    ... I can then look at widget before I sign it

    <Marcos> Anne, so that's Q1 above

    <Marcos> so there is use cases

    Arve: want to limit a set of subdomain possibly

    <arve> ssh://foo.net/

    MC: the very first version of the spec had something like this

    AB: so where are we?

    MC: I think we should use URIs
    ... learn from CORS experience

    MP: we could limit the schemes for v1

    MC: we can leave it to the WUA to handle what ever schemes it can

    <arve> Use-case restrictions URI lead to:

    <arve> what if I want unrestricted access to http, but restricted
    access for xmpp

    AB: I think we're going to continue to go around in circles if we
    don't have some agreed requirements

    MP: how long will it take to get agreement?

    MC: depends on how fancy pants we want to get

    AB: sounds like there is an action for MC and Arve to submit a
    concrete proposal

    Arve: we did send a proposal once
    ... but it needs some updating

    [ Arve searches the mail list archive for his previous proposal ...
    ]

    <arve>
    [27]http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/03
    32.html

      [27] http://lists.w3.org/Archives/Public/public-webapps/ 
2008JulSep/0332.html

    RH: also can have a web server on a SIM card

    <scribe> ACTION: Marcos will make a hybrid proposal and send it the
    mail list [recorded in
    [28]http://www.w3.org/2009/02/25-wam-minutes.html#action03]

    <trackbot> Created ACTION-304 - Will make a hybrid proposal and send
    it the mail list [on Marcos Caceres - due 2009-03-04].

    MC: do we need the access element?

    Arve: prefer encapsulating it in a network element

    <timeless> so, i think the tupppling in arve's proposal is likely to
    result in messes

    <timeless> but other than that, i'm not sure what to say

    <timeless> and i think someone already raised the issue of tuppling
    messes in the context of allow access to all https but limited http

    [ Marcos adds Note to the Reader to P&C spec about <access> being a
    WIP ; checks-in new version ]

BONDI Update by David Rogers

    DR: first the so-called Turin Rules

    <scribe> ScribeNick: Marcos

    David: all contributions will be under RF, if not, they are not
    submitted to the w3c.
    ... 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)
    ... we have made sure that members are clear on RF requirements.
    ... OMTP members must make it clear where there are IPR claims....

    David describes the "OMTP - BONDI IPR PRINCIPLES"

    David: if you have any legal questions, please contact the w3c legal
    team
    ... update on Bondi

    <ArtB> ScribeNick: ArtB

    DR: OMTP release 1.0 RefImpl
    ... based on Windows Mobile
    ... by RI in this context we mean an example of the implementation
    of our specs
    ... The RI is helping to drive the specs
    ... using an interative model
    ... We have "code fests"

    AB: who has contributed code?

    DR: Aplix, BONDI staff
    ... some operators have also contributed

    MC: the author is embedded in every source file

    AB: what is the licensing?
    ... and does every file have an identical license?

    DR: I'll come back to the licensing
    ... Opera joined OMTP
    ... and LiMo Foundation has endorsed BONDI specs

    AB: what does that really mean in terms of devices shipping BONDI
    implementations?

    MP: LiMo devices that implement web runtimes should implement BONDI
    specs

    AB: is there an expectation LiMo will take the RI code?

    MC: no; its a Windows implementation

    <arve> [29]http://www.opera.com/press/releases/2009/02/16/

      [29] http://www.opera.com/press/releases/2009/02/16/

    Arve: Opera has been a member of LiMo since Feb 16

    MP: there is some overlap of members between LiMo and OMTP

    DR: at MWC some operators clearly endorsed BONDI e.g. AT&T

    MC: what is the exact relationship between W3C widget specs and
    BONDI widget specs

    DR: we think W3C is the right place to create widget specs

    MC: are BONDI specs Royalty-Free?

    MP: I don't know

    DR: let me come back to the licensing question

    AB: still not clear to me about the relationship between W3C widget
    specs and BONDI widget specs

    MP: one thing we are focusing on is policy

    MC: I've heard BONDI has resolved all of the open issues W3C has in
    its specs
    ... I've also heard you have good uptake

    Arve: my concern is regarding device APIs and security models

    MP: BONDI has defined a set of device APIs
    ... we use <feature> from P&C to hook into those APIs

    DR: later today I will post to public-webapps pointers to our
    Candidate specs

    AB: which version of the P&C spec has been implemented in the RI?

    MP: not sure

    AB: did BONDI create a Widgets P&C spec?

    DR: no

    AB: did BONDI create a Widgets DigSig spec?

    DR: no
    ... we reference P&C and DigSig now; but do not currently reference
    A&E

    AB: you have created some deltas of the P&C spec right?

    MP: yes. For example we added a new element because P&C's <access>
    does not meet our requirements

    DR: I think a delta doc makes sense

    Arve: on March 9 BONDI will ship 1.0, right?

    DR: yes

    Arve: doesn't that tie W3C's hand?

    DR: no. We want to get the specs synched.

    AB: what happens starting on March 10? Will BONDI members start
    shipping implementations of the RI?

    MP: on March 10, VF will begin asking vendors to implement the BONDI
    specs

    MC: but this is going to lead to fragmentation
    ... these implemenations will not be the same as implemenations
    based on the eventual Recommendation of W3C's widgets specs

    MP: OMTP is only interested in mobile use cases
    ... thus we don't necessarily care about additional use cases that
    go beyond mobile

    MC: so it appears then that to meet your requirements it will lead
    to more fragmentation

    DR: we've done a lot of work related to security

    CV: we are participating in both orgs
    ... the W3C's mobile web initiative hasn't really been that
    successful
    ... and some players in the market are taking advantage of this
    ... Want the W3C to create the infrastructure

    MC: I don't understand why the W3C should continue its work

    MP: I dont' think there is any desire to create overlapping specs
    ... BONDI can't wait forever for W3C to complete their work

    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
    ... people understand the risks

    Arve: I think it is short-sighted to only look at this from the
    mobile perspective

    DR: OMTP intends to continue active participation in W3C
    ... we want to put our device APIs into the W3C

    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?

    DR: not sure March 10 is the right date but yes, that is my
    expectation

    Arve: I would like to see OMTP/BONDI commit resources for Editing
    API specs like File I/O
    ... requirements first of course; but follow up with spec
    contributions too
    ... It sounds like this is going to lead some fragmentation in the
    mobile space

    MC: so now that we've continued discussion I'm seeing more of an
    "embrace and extend" model

    DR: re licensing - Apache 2.0
    ... that is for the BONDI RI

New Work related to the Device API and Security Workshop

    AB: WS report [30]http://www.w3.org/2008/security-ws/report
    ... the report identifies 6 potential work areas and assigns
    priorities to each
    ... what is BONDI's position re work split for the 4 High priority
    items?
    ... which of the 6 items are in scope for BONDI?

      [30] http://www.w3.org/2008/security-ws/report

    MP: depends on what you mean by in scope

    AB: which areas are actively in spec work?

    DR: Concrete APIs
    ... Policy Description
    ... Policy Management is of interest

    AB: what do you expect to push into the W3C?

    MP: that not a useful question because we don't use that list

    DR: we expect to submit some APIs
    ... and of course policy description

    AB: and what is your pref for where that work is done?

    DR: Web Apps WG

    AB: as Chair, I think it will be hard to add so much new work to
    WebApps

    DR: Thomas would like to form a new WG re the policy work items

    <tlr> "would like" sounds exaggerated. It looks like a likely path
    forward.

    <tlr> no interest in forcing things on you folks... ;)

    AB: when will BONDI be ready to submit the Device API specs to the
    W3C?

    DR: I'm not sure but will find out

    AB: perhaps you should send an email to
    [31]http://lists.w3.org/Archives/Public/public-device-apis/ and
    state BONDIs interest, plans, roadmap, etc

      [31] http://lists.w3.org/Archives/Public/public-device-apis/

    <tlr> +1 to sending that e-mail

    <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

    <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

Widgets Digital Signatures

    <fjh> latest editorial draft

    <fjh> [32]http://dev.w3.org/2006/waf/widgets-digsig/

      [32] http://dev.w3.org/2006/waf/widgets-digsig/

    <fjh> review

    <fjh>
    [33]http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/05
    48.html

      [33] http://lists.w3.org/Archives/Public/public-webapps/ 
2009JanMar/0548.html

    <fjh>
    [34]http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/05
    47.html

      [34] http://lists.w3.org/Archives/Public/public-webapps/ 
2009JanMar/0547.html

    <tlr> yes

    AB: agenda
    [35]http://www.w3.org/2008/webapps/wiki/WidgetsParisAgenda#Digital_S
    ignature_spec

      [35] http://www.w3.org/2008/webapps/wiki/ 
WidgetsParisAgenda#Digital_Signature_spec

    <fjh> updated editors draft
    [36]http://dev.w3.org/2006/waf/widgets-digsig/

      [36] http://dev.w3.org/2006/waf/widgets-digsig/

    FH: I suggest I walk thru my recent changes

    AB: good

    FH: some restructuring
    ... added namesaces
    ... added some definitions
    ... big change is Author and Distributor signatures
    ... updates should not be treated differently in this spec
    ... still need to work on algorithms
    ... XML Sig v1.1 should go to FPWD this week
    ... some work on the proc model

    <mpriestl> I have a few small comments but overall I think this is
    an excellent update of the document - many thanks Frederick!

    FH: recommend we go thru TLR's comments first

    AB: let's do that

    <tlr>
    [37]http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/05
    47.html

      [37] http://lists.w3.org/Archives/Public/public-webapps/ 
2009JanMar/0547.html

    TR: I'll skip editorial comments

    <scribe> ScribeNick: drogersuk

    I would like to consider separate filname conventions

    for distributor and authors

    <fjh> Widget Signature Name:

    <fjh> The reserved file name "author-signature.xml"

    <fjh> "signature" [0-9]* ".xml"

    <discussion on filename conventions>

    FJH clarified a point that TLR raised - it was already included in
    the spec

    MC Thomas you have addressed my concerns, could you summarise why it
    is bad to have <role> attribute for signature in signature.xml?

    <fjh> single signature per file, should state that explicitly

    TLR There is a basic design decision that there is a single
    signature per file

    TLR You don't want to look at two signatures at the same time

    MC We don't want to use filenames as an extensibility mechanism, but
    I can live with this

    <fjh> right now we use file name convention instead of a manifest

    <tlr> fjh, +1, that's precisely the problem

    MC you are optimising prematurely

    <fjh> of course a manifest could be signed, addressing the signature
    insertion and deletion risk as well

    MP There are cases where you may want to be able to find the author
    signature without processing everything

    MC I accept the proposed solution

    TLR I do not like using the filename in this way. We have different
    classes of resources inside the widget package

    scribe: same problem as content type discovery
    ... clearly our solution is not best, a manifest is the best way

    <tlr> ... and I'm happy to defer this part of the discussion to a
    later time

    MC I proposed a manifest solution a couple of days ago

    scribe: it would be optional
    ... assigned around the content types
    ... per file declaration of what the content type is a maybe the
    role

    MP can the manifest discussion go on the mailing list?

    <tlr> +1 to Mark

    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

    TLR in the processing model, we say the distributor signature must
    countersign the author signature. We validate that

    <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." ]

    we do not validate a distiributor signing another distributor

    scribe: I propose that this is invalid to break this case

    MP: I agree

    MC +1

    <fjh> +1

    DR: +1

    AB: We have consensus here on that point

    TLR: editorial on ID-based reference

    MP: agreed

    FJH: I'll update the draft. I could use some help from Thomas

    TLR: I'd be happy to review, but won't commit on sending a proposal

    <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

    AB: The group here are happy for you to update the draft

    TLR: I propose certificates must be v3 to sign widgets

    MP: I need to check internally - but provisionally this looks ok

    MC: I'll do the same internally at Opera

    FJH: It seems to be right for me

    <tlr> RFC 5280 sets a default for v3 certificates that do not have
    the extension, and that's important.

    MC: It is messy supporting the three different standards

    TLR: It is important to reference RFC-5280

    AB: If we don't get any concerns in the next two weeks then we'll
    accetp v3

    FJH: Let's update to v3 now, then we can revert if issues

    AB: We have agreement on that

    <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

    TLR outlined the point

    MP: Vodafone will most likely object to the validation failing if
    the timestamp is in the future
    ... correction in the past
    ... People don't set their date and time in the phone
    ... This is a problem currently with java
    ... Unless we demand that we have network time or accurate time on
    devices we will not be able to live with this
    ... Defining it in our specification is dangerous for that reason
    ... What type of timestamp? By the signer?

    TLR: Yes

    MP: The timestamp is a statement of when the author 'says' they
    signed it
    ... Author's will set timestamps to make sure they get installed

    correction: authors

    MP: Do you see a use case for an expires and a timestamp?

    TLR: I agree about the phones point
    ... This is a good argument against the MUST
    ... Having expiration is useful as well
    ... The two cover separate parts of the problem

    <fjh> current signature properties draft

    <fjh>
    [38]http://www.w3.org/2008/xmlsec/Drafts/xmldsig-properties/Overview
    .html

      [38] http://www.w3.org/2008/xmlsec/Drafts/xmldsig-properties/ 
Overview.html

    TLR: expiration limits the impact in the future
    ... the timestamp helps you with which sequence signatures happened
    ... perhaps before some event
    ... when the package was signed can be critically important <DR:
    this is for forensics purposes>
    ... and incident handling / reaction

    <Marcos> +q

    <Marcos> -q

    <TLR ran over the points again>

    <Marcos> +q should <timestamp> be added to XML Dig Sig 1.1 instead
    of widgets dig sig?

    <Marcos> +q to should <timestamp> be added to XML Dig Sig 1.1
    instead of widgets dig sig?

    <fjh> good question marcos

    <Zakim> Thomas, you wanted to note that SHOULD with wall-clock is
    fine if Opera don't enforce upon validation

    MP: I support Frederick's suggestion which was to recommend the use
    of timestamp and expires as best practices rather than mandating
    them
    ... a recommendation is good enough here

    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

    <tlr> I think it's fine for this to go into the signature properties
    document, with a "SHOULD use" in the widget signature spec.

    FJH: There is some merit in what Marcos just said
    ... You might want to comment on that Thomas
    ... let's discuss that

    <Marcos> +q

    TLR: I don't have any deep thoughts on new timestamps... I'm fine
    with having a should
    ... It becomes unlikely that best practices get implemented

    MC: We want to avoid using new elements where possible
    ... our preference is to profile 1.1

    MP: I would support roughly what marcos said. We should reference
    the properties
    ... role, expires and timestamp

    <ArtB> ACTION: Frederick check XMl Sig 1.1 re role, expires, etc.
    properties [recorded in
    [39]http://www.w3.org/2009/02/25-wam-minutes.html#action04]

    <trackbot> Created ACTION-305 - Check XMl Sig 1.1 re role, expires,
    etc. properties [on Frederick Hirsch - due 2009-03-04].

    MP: but I would defer to the XML DigSig group

    FJH: I agree with Mark
    ... TLR if could you write down that use case it would really help

    <fjh> +1 to additional hash agl

    AB: That closes the discussion then. TLR would you like to discuss
    hash algorithms and revocation?
    ... Let's discuss both. Firstly hash algorithm

    <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.)" ]

    FJH: I agree we need a second hash algorithm

    TLR: Not having a second hash algorithm that is outside the SHA
    family is an issue

    <tlr> I suspect consensus about hash algorithms is easier than on
    the PK ones.

    FJH: We require some time and thought to get to where we want to be

    MP: On algorithms, on the digest algorithm I agree with TLR
    ... we have to be aware that in 5.2 Digest Algorithms, we support
    additional methods

    FJH: The validation needs to better match the generation
    requirements, I will look at that

    <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." ]

    <fjh> suggest, we should not profile but should mention best
    practice of certificate

    <fjh> validtion and revocation checking

    <Marcos> -q

    TLR: <discusses complexities of revocation>

    <fjh> identify signature versus certifcate revocation

    <tlr> can live with

    MP: Some of the stuff is policy dependent so is probably correctly
    left out of the specification

    FJH: I agree with Mark. I think we decided not to do a complete
    profile of the XML DigSig spec within this spec

    TLR: I can live with what Mark and Frederick said about revocation
    ... if we have a unique identifier for each signature, then we can
    store metadata about specific signatures

    <fjh> so signature identifier could be another signature property?

    TLR: there may be several signatures over time from the same signer

    <tlr> yes

    AB: Mandatory algorithms

    FJH: I'd like to mention something first
    ... I changed requirement 6.1 5c from MUST to MAY
    ... the ds:KeyInfo element MAY be included

    MP: I have one question related to this
    ... we're relying on certificates - I'll go back and check this
    ... I think what you've changed is correct, but I just want to check
    it

    <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]..

    FJH: I just wanted to highlight this

    <fjh> also

    <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.

    AB: OK so let's go to mandatory algorithms

    <fjh> sections on generation and validation

    AB: First Mark's point

    <tlr> +1 to mark on that point

    MP: I'd like to thankyou for the restructuring work, it has moved
    this on a huge amount, thankyou
    ... I have some small editorials I will send via email

    <fjh>
    [40]http://dev.w3.org/2006/waf/widgets-digsig/#signature-valiation

      [40] http://dev.w3.org/2006/waf/widgets-digsig/#signature- 
valiation

    MP: one point here: section 6.2

    <fjh> +1 re install statement

    <fjh> I mean +1 mark

    <tlr> "not install" is probably the wrong category, yes

    MP outlined issues on installations on different platforms

    <fjh> proposal - If Widget Signature Validation fails for any reason
    the application must be informed of the failure and possibly the
    reason for failure.

    FJH: I agree with these points you are making

    MP: I agree with your approach FJH
    ... In multiple digital signatures with one passing and one failing,
    there are different things to do, but that is getting into policy

    <Marcos> MC: me too

    TLR: A signature verifier could just return a boolean the way it is
    currently written
    ... there is no understanding of what trust anchors there are
    ... I would like to see it covered
    ... there must be a policy in place

    FJH: I can try and do some wording, I think you're right Thomas

    MP: I agree it could be drawn out more, happy to help on this

    <tlr> ACTION: thomas to say something about trust anchors in the
    beginning of 6.2 [recorded in
    [41]http://www.w3.org/2009/02/25-wam-minutes.html#action05]

    <trackbot> Created ACTION-306 - Say something about trust anchors in
    the beginning of 6.2 [on Thomas Roessler - due 2009-03-04].

    <fjh> no

    AB: Work split and step 4 and step 5...

    MC: I removed anything about handling responses and deferred it to
    widgets digsig spec

    <ArtB> [ Step #4 is:
    [42]http://dev.w3.org/2006/waf/widgets/#step-4--locate-digital-signa
    tures-for-th ]

      [42] http://dev.w3.org/2006/waf/widgets/#step-4--locate-digital- 
signatures-for-th

    MC: where do we put author signature?

    <mpriestl> fjh, I don't think we need any

    MP: It doesn't really matter

    fjh: Policy issue

    MP: no need change anything in widget digsig
    ... Find all signatures in package, then process in accordance with
    ... widget digsig

    AB: step 4 and 5 have been simplified

    MP: the last sentence in step 5 says a UA must process...
    ... it should be possible for the UA to jump out of the list if it
    has enough information to make a policy decision

    <fjh>
    [43]http://dev.w3.org/2006/waf/widgets/#step-4--locate-digital-signa
    tures-for-th

      [43] http://dev.w3.org/2006/waf/widgets/#step-4--locate-digital- 
signatures-for-th

    MP: I might only be interested in the Nokia signature

    <fjh> note need to change section 4 for author signatures

    MP: It makes sense to process in order, then skip out

    <fjh> [44]http://dev.w3.org/2006/waf/widgets/#digital-signatures

      [44] http://dev.w3.org/2006/waf/widgets/#digital-signatures

    MP: slight rewording plus a MAY on the author signature

    <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."

    JS: My concern is that there is a revoked signature there
    ... I'd like people to consider it
    ... even if they are interested in something else

    MP: You can define reasons for revocation if you want and there are
    different things you may want to do.
    ... 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

    <timeless> soudns ok

    FJH: Are we planning to address policy at some point?
    ... we need a note in the packaging spec

    MP: The processing is dependent on your policy and we don't define
    what that is

    <fjh> need to add statement that processing depends on policy

    DR: This comes back to our discussion on new work items - for
    example security policy type issues

    AB: So right now we don't have a draft charter for that working
    group yet

    <tlr> yes

    FJH: Which is why we need to outline the concerns now before that
    group is there

    <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."

    MC: the processing part in step 4

    MP: This is sort of what we need, let's take it offline though

    RH: If we have the author at the end of the list, we can't step out
    of the processing

    MC clarified how you could do this

    <fjh> no

    AB: Let's cover issue #81
    ... OK, schedule firast

    first

    MP: We've addressed most of the comments
    ... I think we're ready once the updates are complete, we're ready
    to go to the next WD. Next stage would be LCWD
    ... Fundamentals have not changed and I think we're all agreed on
    and it would be great to get to last call

    FJH: I need to make some changes and include the comments, I'd like
    to reference the FCWD from XML DigSig this week
    ... Other than that, then I don't see why not
    ... Properties stuff would mean doc would need delaying

    TLR: We have some different options - perhaps we could put an
    editors note in the widget signatures document saying what will be
    included

    FJH: This could solve the properties issue

    <tlr> it's not pretty, but it's probably easiest

    AB: We have agreement on that route
    ... 4-5 weeks from now we could have a LCWD

    TLR: Let's take this offline

    <Benoit> I understand 19th march for the last WD --- 16 april for LC
    --- 14 may RC

    <tlr> +1 to taking this offline

    <fjh> +1 to taking this offline

    AB: Last thing on the list is mandatory algorithms

    TLR: Think about EC and DSA
    ... no consensus in the security group yet

    MP: We would prefer the spec to be finished rather than have drawn
    out discussions
    ... there are unclear IPR issues around ECDSA
    ... we haven't been able to check on that
    ... the reasons for rejecting DSASHA-256 are not very strong from
    the XML SG

    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

    FJH: Need to know who can live with EC or DSA

    DR: Suggest raising as an action
    ... I can circulate for feedback in OMTP

    Arve: There is not much real world use of EC
    ... I would like to understand if and why it is necessary now and
    not at some later stage

    MC: We want to future proof as much as possible

    <ArtB> ACTION: Marcos determine Opera's position on elliptic curve
    re Widgets DigSig spec [recorded in
    [45]http://www.w3.org/2009/02/25-wam-minutes.html#action06]

    <trackbot> Created ACTION-307 - Determine Opera's position on
    elliptic curve re Widgets DigSig spec [on Marcos Caceres - due
    2009-03-04].

    <ArtB> ACTION: David determine Opera's position on elliptic curve re
    Widgets DigSig spec [recorded in
    [46]http://www.w3.org/2009/02/25-wam-minutes.html#action07]

    <trackbot> Sorry, amibiguous username (more than one match) - David

    <trackbot> Try using a different identifier, such as family name or
    username (eg. dorchard, drogers)

    <tlr> ACTION: rogers to determine OMTP's position on EC re Widgets
    DigSig spec [recorded in
    [47]http://www.w3.org/2009/02/25-wam-minutes.html#action08]

    <trackbot> Created ACTION-308 - Determine OMTP's position on EC re
    Widgets DigSig spec [on David Rogers - due 2009-03-04].

    <ArtB> ACTION: Rogers determine OMTP's position on elliptic curve re
    Widgets DigSig spec [recorded in
    [48]http://www.w3.org/2009/02/25-wam-minutes.html#action09]

    <trackbot> Created ACTION-309 - Determine OMTP's position on
    elliptic curve re Widgets DigSig spec [on David Rogers - due
    2009-03-04].

    <tlr> ACTION-308: duplicate of ACTION-309

    <trackbot> ACTION-308 Determine OMTP's position on EC re Widgets
    DigSig spec notes added

    <tlr> ACTION-308 closed

    <trackbot> ACTION-308 Determine OMTP's position on EC re Widgets
    DigSig spec closed

    FJH: I'd like to understand where we are with this

    TLR: We need the feedback on the document that is being published
    tomorrow

    <fjh> Please review XML Siganature 1.1 working draft, algorithms and
    give feedback!

    AB: Thanks for joining guys and particularly Frederick for updating
    the spec

    FJH: Thanks to everyone for their comments

    <ArtB> ScribeNick: ArtB

Media type declarations; MIME; etc.

    AB: looking at the agenda, Marcos
    ... Is the <type> element still something we need to discuss or
    drop?

    MC: drop it
    ... we want to talk about the <media> element proposal
    ...
    [49]http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/04
    91.html
    ... Larry Masinter submitted some comments
    ... LM:
    [50]http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/04
    59.html
    ... No, LM's response is:
    [51]http://lists.w3.org/Archives/Public/public-pkg-uri-scheme/2009Fe
    b/0003.html

      [49] http://lists.w3.org/Archives/Public/public-webapps/ 
2009JanMar/0491.html
      [50] http://lists.w3.org/Archives/Public/public-webapps/ 
2009JanMar/0459.html
      [51] http://lists.w3.org/Archives/Public/public-pkg-uri-scheme/ 
2009Feb/0003.html

    [ Marcos displays a strawman proposal of the <manifest> element ...
    ]

    <Marcos> <manifest xmlns="">

    <Marcos> <media path="" type=""/>

    <Marcos> <media ext="space delimited list" type=""/>

    <Marcos> </manifest>

    Arve: are path and extension mutually exclusive for a given element?

    <Marcos> <media path="styles/" ext="php" type="text/css" />

    <Marcos> <media path="styles/mystyle" type="text/css" />

    <arve> [ foo.css, bar, baz ]

    <Marcos> <media path="styles/" ext="php"
    type="text/css;charset=utf8" />

    <arve> [bar, baz] = text/html, foo.css = text/css

    <Marcos> <media path="styles/" type="text/css" /> <media
    path="styles/foo.css" type="text/css" />

    <Marcos> <media path="foo/" ext="php" type="text/css" /> <media
    path="foo/bar/" type="" />

    <Marcos> where type="" = unknown, so sniff

    AB: any comments about this proposal?

    Arve: looks pretty solid

    <Marcos> <media path="styles/" type="text/css" /> <media
    path="styles/" type="text/html" />, where the second overrides the
    first

    AB: so the precedence is what?

    MC: last one is the winner

    <arve> /home/user/foo/

    <arve> foo

    <Marcos> how would this work with xml:base

    <Marcos> ?

    AB: does this proposal address the issues LM raised?

    MC: some of them
    ... it encorporates some of his concerns

    <arve> I quite like type="application/uberml+xml;charset=UTF-7"

    MC: he agreed we don't need to include every file in the ZIP
    ... for example, we could just target one folder
    ... who wins in the conflict of manifest versus config file
    ... I like config file wins
    ... this proposal does not conflict with HTML5's cache manifest
    ... that is completely different use case

    AB: good
    ... what is the processing model?

    MC: I will define it in a separate new spec - it will not be in the
    P&C spec

    AB: when will it be used

    MC: one use case is when a user wants to save a widget and the WUA
    can slurp up all of the files for a widget

    AB: is Opera convinced we need this for v1.0?

    MC: no, not necessarily. 2.0 could be OK
    ... It has been requested by several people including TLR, LM and
    Adam Barth

    Arve: I'm not convinced we need it
    ... sure Save As Widgets is neat but not sure we need a spec to
    cover the use case

    AB: what's the relationship between this proposal and the issue Adam
    Barth raised?
    ... i.e.
    [52]http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/02
    64.html

      [52] http://lists.w3.org/Archives/Public/public-webapps/ 
2009JanMar/0264.html

    MC: Adam proposed something like this so indeed my proposal
    addresses his concerns

    AB: has Adam responded to this proposal?

    MC: no, not yet

    AB: do you anticipate proponents of this functionality pushing for
    this element to be added to P&C spec?

    MC: not sure

    AB: so here is where I think we are with this:
    ... A number of people have suggested we need to address this issue
    e.g. file extension to MIME type mapping
    ... we are in general agreement
    ... But we don't think it needs to be specified in the P&C spec
    ... We are willing to define this functionality in a separate spec
    ... And probably not in the Widget spec series

    DR: think the P&C spec needs to specify a UI format e.g. HTML

    MC: the P&C spec is agnostic - it just specifies the config file and
    the package format

    Arve: the reality is most of the implemenations will be compatible
    with each other and implement a superset of P&C + DigSig + A&E + ...

    MC: P&C does not define a "Widget User Agent" just a UA that can
    process the config file and ZIP format

    DR: we want any widget that will run anywhere
    ... think we're going to get that widgets that can't be run e.g.
    only contains a DLL
    ... we want the W3C to define Widget User Agent

    Arve: the W3C hasn't defined what a Web page is

    MC: to be accurate, we should replace the <widget> element with
    <package> element

    AB: we should go back to the FPWD as that title is probably more
    accurate than the current one

    Arve: my expectation is that a WUA will be able to handle HTML
    ... but I don't think that should be mandatory

    MC: the original title was "Web Applications Packaging Format"!

    CV: I don't think we can replace Widgets at this point

    MC: In hindsight I think we should not have switched to the name
    Widget
    ... I can put the old WUA dependency information into an Informative
    appendix if people think that would be useful

    AB: we aren't seriously considering changing the title of the P&C
    spec, right?

    MC: no

    Arve: no

    DR: still then, where is Widget User Agent defined

    AB: I'm mostly indifferent but it does not belong in the P&C spec

    DR: so how do we solve this problem?

    <drogersuk> we are at serious risk of market fragmentation

    MC: one approach as I mentioned is to add an informative note to the
    P&C spec

    AB: why doesn't OMTP define WUA as it sees fit?

    DR: that leads to fragmenation

    MC: we can recommend specific MIME types but we can't mandate them
    ... for example the widget i.e. package could contain Flash
    ... are you willing to write text that covers your concern?

    <drogersuk> ACTION:rogers OMTP to take Marcos' original text and
    modify to add the concerns over MIME types [recorded in
    [53]http://www.w3.org/2009/02/25-wam-minutes.html#action10]

    MC: note HTML5 doesn't define any dependencies
    ... although they are implied

# <feature> default; raised by Kai Hendry

    AB: what's the status of this?

    MC: I've already addressed this
    ... feature is required at runtime unless explicitly set to optional

    <scribe> ACTION: Marcos make sure the <feature> comment by Kai has
    been addressed [recorded in
    [54]http://www.w3.org/2009/02/25-wam-minutes.html#action11]

    <trackbot> Created ACTION-310 - Make sure the <feature> comment by
    Kai has been addressed [on Marcos Caceres - due 2009-03-04].

    <scribe> ACTION: Rogers OMTP to take Marcos' original text and
    modify to add the concerns over MIME types [recorded in
    [55]http://www.w3.org/2009/02/25-wam-minutes.html#action12]

    <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].

<icon> element ISSUE: what if it's a vector and no size is given?

    AB: Marcos, what's the status of this?
    ... [56]http://dev.w3.org/2006/waf/widgets/#the-icon-element

      [56] http://dev.w3.org/2006/waf/widgets/#the-icon-element

    MC: Doug gave me some proposed text and I've added it to the ED

    Arve: is this really needed in the spec?
    ... Seems like its specifying visual behavior of the UA

    MC: during the 2nd LC we must do a better job of removing anything
    that is extaneous to the config file and package format

    AB: from the P&C perspective, I don't think this needs to be
    specified

<preference> element proposal; by Art Barstow

    AB: what's the status Marcos?

    MC: I've already specified this
    ... see the latest ED

    Arve: I don't agree with MUST in this case
    ... I can think of some cases were MUST is too strong

    [ MC makes a change in the ED to address Arve's comment ]

    Arve: how will read-only be handled by the UA implementing the
    preferences array as defined in the A&E spec?

    MC: that array should be read-only

    Arve: I'm not sure about that

    Ivan: what are the use cases?

    <Marcos> for var in preferences {}

    Arve: a widget like a RSS reader could have a list of URIs

    <arve> for (var key in widget.preferences){ /* ... */ }

    Ivan: seems like we don't need two mechanisms here
    ... How do you get the keys?

    MC: we will probably need a keys attribute
    ... we don't want to build a dependency on HTML5
    ... we probably also need methods to clear the array

    Arve: what if prefs returned generic objects rather than a
    DOMString?
    ... not sure we want to go that way

    Ivan: I made a proposal on the mail list
    ...
    [57]http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/04
    55.html

      [57] http://lists.w3.org/Archives/Public/public-webapps/ 
2009JanMar/0455.html

    [ Discussion of Ivan's proposal in the above e-mail ]

    [ Marcos adds some related text to Req #28 e.g. some methods needed
    to support richer Preferences ... ]

    AB: Meeting Adjourned

Summary of Action Items

    [NEW] ACTION: David determine Opera's position on elliptic curve re
    Widgets DigSig spec [recorded in
    [58]http://www.w3.org/2009/02/25-wam-minutes.html#action07]
    [NEW] ACTION: Frederick check XMl Sig 1.1 re role, expires, etc.
    properties [recorded in
    [59]http://www.w3.org/2009/02/25-wam-minutes.html#action04]
    [NEW] ACTION: Marcos determine Opera's position on elliptic curve re
    Widgets DigSig spec [recorded in
    [60]http://www.w3.org/2009/02/25-wam-minutes.html#action06]
    [NEW] ACTION: Marcos make sure the <feature> comment by Kai has been
    addressed [recorded in
    [61]http://www.w3.org/2009/02/25-wam-minutes.html#action11]
    [NEW] 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 [recorded in
    [62]http://www.w3.org/2009/02/25-wam-minutes.html#action02]
    [NEW] ACTION: Marcos respond to Marcin and ask him to make specific
    proposals if he has any [recorded in
    [63]http://www.w3.org/2009/02/25-wam-minutes.html#action01]
    [NEW] ACTION: Marcos will make a hybrid proposal and send it the
    mail list [recorded in
    [64]http://www.w3.org/2009/02/25-wam-minutes.html#action03]
    [NEW] ACTION: Rogers determine OMTP's position on elliptic curve re
    Widgets DigSig spec [recorded in
    [65]http://www.w3.org/2009/02/25-wam-minutes.html#action09]
    [NEW] ACTION: rogers OMTP to take Marcos' original text and modify
    to add the concerns over MIME types [recorded in
    [66]http://www.w3.org/2009/02/25-wam-minutes.html#action10]
    [NEW] ACTION: Rogers OMTP to take Marcos' original text and modify
    to add the concerns over MIME types [recorded in
    [67]http://www.w3.org/2009/02/25-wam-minutes.html#action12]
    [NEW] ACTION: rogers to determine OMTP's position on EC re Widgets
    DigSig spec [recorded in
    [68]http://www.w3.org/2009/02/25-wam-minutes.html#action08]
    [NEW] ACTION: thomas to say something about trust anchors in the
    beginning of 6.2 [recorded in
    [69]http://www.w3.org/2009/02/25-wam-minutes.html#action05]

    [End of minutes]

Received on Thursday, 26 February 2009 16:23:04 UTC