The draft minutes from the April 16 Widgets voice conference are
available at the following and copied below:
<http://www.w3.org/2009/04/16-wam-minutes.html>
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
Approved.
-Regards, Art Barstow
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Widgets Voice Conference
16 Apr 2009
[2]Agenda
[2] http://lists.w3.org/Archives/Public/public-webapps/
2009AprJun/0181.html
See also: [3]IRC log
[3] http://www.w3.org/2009/04/16-wam-irc
Attendees
Present
Art, Josh, Marcos, Arve, Frederick, Jere, Mike, Thomas, Mark
Regrets
Chair
Art
Scribe
Art
Contents
* [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
interface;
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
([17]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0
181.html). One change I propose is to drop PAG status since Rigo's
related email
([18]http://lists.w3.org/Archives/Member/member-widgets-pag/2009Apr/
0000.html) covers the status, AFAIK.
... any issues with dropping that agenda item?
[17] http://lists.w3.org/Archives/Public/public-webapps/
2009AprJun/0181.html).
[18] http://lists.w3.org/Archives/Member/member-widgets-pag/
2009Apr/0000.html)
[None]
AB: any other change requests for the agenda?
[None]
Announcements
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
([19]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0
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/
2009AprJun/0094.html).
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?
<fjh>
[20]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/00
94.html
[20] http://lists.w3.org/Archives/Public/public-webapps/
2009AprJun/0094.html
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
number.
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
([21]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0
162.html), I don't think this issue should be addressed in a
normative/prescriptive way. What do others think? (See
[22]http://www.w3.org/2008/webapps/track/issues/83)
[21] http://lists.w3.org/Archives/Public/public-webapps/
2009AprJun/0162.html)
[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
severity
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
signed
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
hole
<fjh> proposal - add security consideration about covert channels
and providing access to information, access control decision by
implementation
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
control
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
([23]http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0
943.html).
... anyone know the whereabout of Robin?
... he wasn't here on April 2 either
[23] http://lists.w3.org/Archives/Public/public-webapps/
2009JanMar/0943.html).
<scribe> ACTION: barstow Ask Robin to flesh-out his <access> element
proposal [recorded in
[24]http://www.w3.org/2009/04/16-wam-minutes.html#action01]
<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
comments
... 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).
[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
right
... 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
[27]http://www.w3.org/2009/04/16-wam-minutes.html#action02]
<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
([28]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0
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/
2009AprJun/0040.html)
[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)
<Marcos>
[31]http://dev.w3.org/2006/waf/widgets-api/Overview.src.html
[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
methods
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
[33]http://www.w3.org/2009/04/16-wam-minutes.html#action03]
<trackbot> Created ACTION-334 - Deterimine if Robin agreed to be
editor of the Window Modes spec [on Arthur Barstow - due
2009-04-23].
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
help
AOB
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
scrollbars"
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
[34]http://www.w3.org/2009/04/16-wam-minutes.html#action01]
[NEW] ACTION: barstow deterimine if Robin agreed to be editor of the
Window Modes spec [recorded in
[35]http://www.w3.org/2009/04/16-wam-minutes.html#action03]
[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
[36]http://www.w3.org/2009/04/16-wam-minutes.html#action02]
[End of minutes]
