W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

[widgets] Draft Minutes from 16 April 2009 Widgets Voice Conference

From: Arthur Barstow <art.barstow@nokia.com>
Date: Thu, 16 Apr 2009 10:43:50 -0400
Message-Id: <AE1FA074-01BF-4213-AF21-1AD134D701C0@nokia.com>
To: public-webapps <public-webapps@w3.org>
The draft minutes from the April 16 Widgets voice conference are  
available at the following and copied below:


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

-Regards, Art Barstow


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

                                - DRAFT -

                        Widgets Voice Conference

16 Apr 2009


       [2] http://lists.w3.org/Archives/Public/public-webapps/ 

    See also: [3]IRC log

       [3] http://www.w3.org/2009/04/16-wam-irc


           Art, Josh, Marcos, Arve, Frederick, Jere, Mike, Thomas, Mark




      * [4]Topics
          1. [5]who's here?
          2. [6]Review and tweak agenda
          3. [7]Announcements
          4. [8]DigSig: Feedback sought on ECDSA Curves:
          5. [9]DigSig: ISSUE-83 - Instantiated widget should not be
             able to read digital signature
          6. [10]P&C spec: Simple approach for <access>
          7. [11]P&C spec: I18N proposal from Marcos
          8. [12]A&E spec: preferences attribute and the Storage
          9. [13]Plan to get inputs and closure on the Red Block issues
         10. [14]Window Modes spec: status and plans
         11. [15]AOB
      * [16]Summary of Action Items

    <scribe> ScribeNick: ArtB

    <scribe> Scribe: Art

    Date: 16 April 2009

    <arve> Is anyone else on the line? I tried saying "Hi" but can't
    hear anyone

who's here?

    <MikeSmith> ArtB: can you please do "Zakim, call Mike-Mobile" again
    in about 10 minutes?

    AB: anyone heard from Robin lately? It would be good if he was here

Review and tweak agenda

    AB: agenda submitted on 14 April
    181.html). One change I propose is to drop PAG status since Rigo's
    related email
    0000.html) covers the status, AFAIK.
    ... any issues with dropping that agenda item?

      [17] http://lists.w3.org/Archives/Public/public-webapps/ 
      [18] http://lists.w3.org/Archives/Member/member-widgets-pag/ 


    AB: any other change requests for the agenda?



    JS: I'd like to talk about a widget implementation I saw recently

    AB: how about AOB?

    JS: OK

    Arve: I want to add show and hide proposal to A+E section

    AB: OK, we will cover that proposal then

    MP: I need to leave after one hour

    FH: I need to leave then too

DigSig: Feedback sought on ECDSA Curves:

    AB: On April 8 Frederick asked the group for feedback regarding the
    various ECDSA Curves
    094.html). Frederick, please give us a short intro and then explain
    what you want from us and the deadline for feedback.

      [19] http://lists.w3.org/Archives/Public/public-webapps/ 

    FH: I sent a note that talked about some of the specific EC curves
    ... I rephrased the question to the group
    ... Please get some feedback and let us know
    ... I think the timing is more critical to the WebApps WG then to
    XML Sec WG since WebApps wants to go to LC sooner
    ... any other timing questions?


      [20] http://lists.w3.org/Archives/Public/public-webapps/ 

    FH: please review the above message and respond within two weeks

    <fjh> This message clarifies and sonstrains the request for
    information regarding the elliptic curve, notes that it reduces the

    AB: who expects to provide information on the EC curves?

    MP: VF will provide feedback
    ... I think FH's new email does help clarify the EC curve issue
    ... Not sure about the IPR related to this though

    FH: I can't make any authoritative statements; I'm just passing
    along info from US govt
    ... TR was saying the intent of my email was to narrow the scope

    <tlr> tlr; the question is narrowing the scope of what's asked,
    based on a perception that responses might be different for some
    specific curves than they would be for a general requirement

    MP: I can give some prelim feedback
    ... the main issue for us is IPR
    ... we are going to do some checking to see if the IPR is a major
    issue for us because it will involve our legal team

    FH: thanks Mark; that would be helpful

DigSig: ISSUE-83 - Instantiated widget should not be able to read
digital signature

    AB: we've discussed this on e-mail and in meetings. Want to spend a
    little bit of time on it today with the hope of getting consensus on
    how to close it. If we start to rat-hole, I will cut off discussion.
    As I've said on the mail list
    162.html), I don't think this issue should be addressed in a
    normative/prescriptive way. What do others think? (See

      [21] http://lists.w3.org/Archives/Public/public-webapps/ 
      [22] http://www.w3.org/2008/webapps/track/issues/83)

    MC: I think the ball is in Mark's court; some members are not
    convinced this is an issue
    ... I think we need to get a sense from MP about the level of

    MP: we think we identified a risk and the fix is relatively easy
    ... we don't think the use cases against it are compelling
    ... I'm not sure we have consensus on what the issue is

    AB: I think the issue is clear

    FH: I could use a reminder

    MP: we allow mult sigs in a package
    ... the sigs do not sign each other
    ... can have a package with some files that are not signed
    ... could lead to abuse

    FH: so there is a covert channel
    ... I agree it is a risk
    ... but I'm concerned about an arbitrary rule that precludes all sig
    files from being accessed
    ... think some policy re access is a better way to go
    ... rather than a single rule that says no, this is not ever allowed

    MP: I don't understand the use case
    ... but I do agree displaying some info to the user could be useful
    ... I don't think the widget itself should be allowed to access the
    widget package contents
    ... If we go in the policy direction, need text on Object element
    restrictions too

    [ FH makes a proposal that I did not minute ...]

    <fjh> proposal is that ds:Object element be required to be signed,
    hence part of signature verified and validated

    TR: I'm not sure I see a strong use case for accessing the signature
    ... unless we create some type of API
    ... think there may be a larger covert opportunity e.g. HTML iframes
    ... behavior user sees can be controled by things that are not

    MP: I agree with TR's points

    <fjh> should this be a security consideration in the specification
    with note that implementation should take care regarding access
    control to information?

    MP: think we just need a couple of lines in the spec to close the

    <fjh> proposal - add security consideration about covert channels
    and providing access to information, access control decision by

    AB: which spec?

    MP: P+C spec

    Arve: re covert channel issue
    ... I think restricting access to sig files is going overboard
    ... would rather propose that we treat the signature as invalid if
    it has non-conformant data

    FH: I'm concerned we are trying to be too prescriptive in the spec
    rather leaving this as an impl detail re the access policy
    ... I agree we need a Security Considerations section in P+C and we
    could add this issue there
    ... not sure it's a good design to restrict implementations

    <fjh> proposing that implementations address issue via access

    AB: clearly we don't have consensus here
    ... Marcos, will you please re-submit your complete proposal?

    MC: yes

    AB: FH, will you please submit your proposal?

    FH: yes

P&C spec: Simple approach for <access>

    AB: On March 26 Robin made a proposal for the <access> element. I
    don't believe there has been any follow-up yet this is a relatively
    major issue with respect to P&C going to LC#2. Robin, please give us
    a short intro and status on your proposal
    ... anyone know the whereabout of Robin?
    ... he wasn't here on April 2 either

      [23] http://lists.w3.org/Archives/Public/public-webapps/ 

    <scribe> ACTION: barstow Ask Robin to flesh-out his <access> element
    proposal [recorded in

    <trackbot> Created ACTION-332 - Ask Robin to flesh-out his <access>
    element proposal [on Arthur Barstow - due 2009-04-23].

    AB: any comments on Robin's proposal?

    MC: it is aligned with the way I think we should go

    AB: anyone else?

    TR: I want to briefly speak to Robin's proposal
    ... have we thought about how this would be used at install time?
    ... want to understand the use of the policy
    ... Any comments on that?

    MP: we think this info will be used at diff points
    ... for example at distribution time
    ... decisions could be made by user e.g. at install time
    ... could also use this info at runtime

    TR: also need some text about the use beyond just access control
    ... e.g. DNS control too

    AB: TR, would you please respond to Robin's proposal with your
    ... they are good things we need to consider

    TR: yes; I'll do that

P&C spec: I18N proposal from Marcos

    AB: Marcos has been working on a I18N model that will presumably
    address all of the related open issues for the P&C spec. This is
    another one of the major issues that must be closed before we
    publish LC#2. Marcos, please give us a short intro and then I'll
    open up for others' comments. Proposal is in CVS

      [25] http://dev.w3.org/cvsweb/2006/waf/widgets/i18n.html).

    MC: my doc presents several options for localizing a widget
    ... we have about 16 different options
    ... some result in invalid widgets
    ... also addresses the xml:base issue we've discussed

    AB: is the proposal complete?

    MC: I consider it still a rough proposal but it is mostly done

    AB: I believe only Jere has responded so far

    MC: yes; I also submitted it to the I18N Core WG
    ... we may want to publish it as a WG Note

    JK: have you received any feedback to the I18N Core WG

    MC: no, I have sent it to the whole WG yet, just Addisson

    JK: my comments are base on an older version
    ... I gave some feedback on the options

    <Marcos> [26]http://dev.w3.org/2006/waf/widgets/i18n.html

      [26] http://dev.w3.org/2006/waf/widgets/i18n.html

    JK: perhaps we should try to reduce the number of options so it
    isn't overwhelming to the reader

    MC: in section 9 there is a matrix that summarizes the options

    AB: so a reader could stop at the table in section 9?

    MC: yes, that's basically true

    JK: it's great you did this work Marcos; it is essential we get it
    ... I urge everyone to read the proposal and make sure we get it
    right the first time
    ... I don't think we want some type of incremental approach

    AB: when will the doc be ready for a broad review?

    MC: by the end of today

    <scribe> ACTION: Marcos send a Request for Comments re I18N proposal
    to I18N Core WG and WebApps WG on April 16 with a 1-week review
    period [recorded in

    <trackbot> Created ACTION-333 - Send a Request for Comments re I18N
    proposal to I18N Core WG and WebApps WG on April 16 with a 1-week
    review period [on Marcos Caceres - due 2009-04-23].

    JK: I think we can reduce the options today
    ... please see my comments

    <timeless> i can't make that deadline

    JK: if something can be removed from the list, we should do so
    before we ask for broad review

    JS: I will be on vacation starting today and cannot get comments in
    by April 23

    AB: the action for everyone is to read this document and submit
    comments by April 23
    ... thanks Marcos for this good work!
    ... I note that I support a WG Note after we have WG consensus on
    the content

A&E spec: preferences attribute and the Storage interface;

    AB: Marcos started a thread on April 6
    040.html) that included a proposed change to the preferences
    attribute. Several commentors disagreed with the proposal. If I
    understand the status correctly, Marcos' intent was to notify the
    group we may want to consider only prescribing HTML5's Storage
    support for HTML5 UAs only but he is OK with leaving the text as is
    (in the 26 March ED, [29]http://dev.w3.org/2006

      [28] http://lists.w3.org/Archives/Public/public-webapps/ 
      [29] http://dev.w3.org/2006

    MC: yes, the above summary is correct

    AB: RESOLUTION: the preferences attribute as specified in the 26
    March 2009 ED is OK
    ... any objections

    [ None ]

    RESOLUTION: the preferences attribute as specified in the 26 March
    2009 ED is OK

Plan to get inputs and closure on the Red Block issues

    AB: Arve agreed to create a proposal (see Action #235
    [30]http://www.w3.org/2008/webapps/track/actions/325) to address the
    Red Block issues. I don't believe that proposal has materialized.
    Arve, what is the status?
    ... some resolutions from April 2 are not in the ED

      [30] http://www.w3.org/2008/webapps/track/actions/325)


      [31] http://dev.w3.org/2006/waf/widgets-api/Overview.src.html

    Arve: let's look at the version MC just put into IRC

    AB: yes, that's fine with me

    Arve: I'll hightlight the changes
    ... Section on Resolving DOM nodes removed

    AB: yes, we agree to do that before

    Arve: Window interface

    MC: we need to say how the Widget interface will be implemented on
    the Window interface

    Arve: without actually mentioning the Window object

    MC: we have also removed refs to XHR spec

    Arve: we also removed the Icon interface
    ... the previous text didn't make sense on some platforms
    ... for example in a desktop scenario there could be several icons
    ... also because of this, removed the icon attribute

    AB: so, this version addresses all of the Red Block issues that were
    in the March 26 ED?

    Arve: yes

    AB: ok, so we can close action 325
    ... Arve, will you please do two things:
    ... 1. build the doc and check it in
    ... 2. annouce the doc on public-webapps

    <arve> 1 is already done

    Arve: so what's next?

    AB: good question; what do people think?

    [ No comments ]

    Arve: the next step is to fill in Ack section
    ... then publish a new WD to see if there are any major issues
    ... then push toward LC ASAP

    AB: that sounds like a good plan to me

    Arve: I do not want any scope creep
    ... may want to wait for feedback for removing hide and open methods
    ... but they can be defined via extension mechanism

    AB: yes agree on scope creep

    <timeless> fwiw

    <timeless> i'm opposed to using 'onclick' in new apis

    AB: we can publish a new WD ASAP or publish the next version as a LC

    <timeless> (showNotification())

    MC: no, not ready for LC

    JK: may need an API or two related to localization
    ... for example Dashboard has some Localization APIs for getting
    localized strings

    MC: we thought about that model but rejected it
    ... don't think it is a good model to follow
    ... can load scripts dynamically and then easily emulate Dashboard

    Arve: don't want to follow Dashboard model; it raises more concerns
    then it solves

    AB: I prefer to publish a new WD ASAP and then open the discussion
    for comments including this localization API
    ... RESOLUTION: we publish a new WD of A+E ASAP
    ... any objections to this proposal?

    RESOLUTION: we publish a new WD of A+E ASAP

Window Modes spec: status and plans

    AB: I believe the plan of record is for Robin to be the Editor of
    this spec. The only related document in CVS is "Widgets 1.0: Media
    Query Extensions"
    ([32]http://dev.w3.org/cvsweb/2006/waf/widgets-wm/). I have three
    initial questions: 1) is this MQ Extension spec the one that will
    normatively define the Window Modes; 2) what is the status of the
    window mode specification; 3) what, if any, dependencies do P&C and
    A&E have on the formal definition of window modes?
    ... did Robin agree to be editor of Window Modes spec?

      [32] http://dev.w3.org/cvsweb/2006/waf/widgets-wm/).

    MC: I don't know

    <scribe> ACTION: barstow deterimine if Robin agreed to be editor of
    the Window Modes spec [recorded in

    <trackbot> Created ACTION-334 - Deterimine if Robin agreed to be
    editor of the Window Modes spec [on Arthur Barstow - due

    MC: yes

    AB: is the normative defn of Window Modes a separate doc than this
    MQ Extensions doc?
    ... what about question #3 above re depedencies P+C and A+E have on
    Window Mode definition?

    Arve: width and height in A+E may have a dependency

    MC: I don't see any dependencies P+C will have on Window Modes spec

    AB: good answer!
    ... anything else on Window Modes

    Arve: what if Robin cannot agree to be Editor of Window Modes?

    AB: good question

    Arve: without it we are likely to have some interop problems

    AB: I will work with Mike to try to find a resource if Robin can't


    AB: I don't have anything

    JS: I saw a widget UA
    ... demo to a large audience
    ... if the widget is HTML then it can be styled by CSS
    ... there are two classes: author wants widget to have its own look
    and feel; others will want the widget to just fit in with rest of
    the platform
    ... need some way to say "I want this widget to be skinned to fit
    into the platform"
    ... but also some way to say "I want to do my own skinning"
    ... can also expect an author to be able to say "I don't want

    MC: I share a lot of those concerns
    ... it is hard to know if a widget platform will "take over" a
    widget Look and Feel
    ... we do have the app chrome that is part of window mode

    JS: it's not about chrome really, its other parts of the UI
    ... stuff like padding between buttons
    ... it isn't specified by HTML5

    Arve: I'm not sure we want to go too far in this direction

    AB: meeting adjourned

    RSSAgent, make minutes

Summary of Action Items

    [NEW] ACTION: barstow Ask Robin to flesh-out his <access> element
    proposal [recorded in
    [NEW] ACTION: barstow deterimine if Robin agreed to be editor of the
    Window Modes spec [recorded in
    [NEW] ACTION: Marcos send a Request for Comments re I18N proposal to
    I18N Core WG and WebApps WG on April 16 with a 1-week review period
    [recorded in

    [End of minutes]
Received on Thursday, 16 April 2009 14:46:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:53 UTC