See also: IRC log
<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
<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
AB: agenda submitted on 14 April
(http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0181.html).
One change I propose is to drop PAG status since Rigo's related
email (http://lists.w3.org/Archives/Member/member-widgets-pag/2009Apr/0000.html)
covers the status, AFAIK.
... any issues with dropping that agenda item?
[None]
AB: any other change requests for the agenda?
[None]
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
AB: On April 8 Frederick asked the group for feedback regarding the various ECDSA Curves (http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0094.html). Frederick, please give us a short intro and then explain what you want from us and the deadline for feedback.
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> 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
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 (http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0162.html), I don't think this issue should be addressed in a normative/prescriptive way. What do others think? (See 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
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 (http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0943.html).
... anyone know the whereabout of Robin?
... he wasn't here on April 2 either
<scribe> ACTION: barstow Ask Robin to flesh-out his <access> element proposal [recorded in 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
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 (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> 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 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
AB: Marcos started a thread on April 6 (http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0040.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, 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
AB: Arve agreed to create a
proposal (see Action #235 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
<Marcos> 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
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"
(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?
MC: I don't know
<scribe> ACTION: barstow deterimine if Robin agreed to be editor of the Window Modes spec [recorded in 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
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
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/decision/consideration in the specification/ Succeeded: s/how we/have we/ Succeeded: s/Topic: P&C spec: I18N proposal from Marcos// Succeeded: s/remove refs/removed refs/ Succeeded: s/Arve: we/MC: we/ Found ScribeNick: ArtB Found Scribe: Art Present: Art Josh Marcos Arve Frederick Jere Mike Thomas Mark Agenda: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0181.html Found Date: 16 Apr 2009 Guessing minutes URL: http://www.w3.org/2009/04/16-wam-minutes.html People with action items: ask barstow marcos robin[End of scribe.perl diagnostic output]