See also: IRC log
<scribe> ScribeNick: ArtB
<scribe> Scribe: Art
Date: 28 May 2009
AB: draft agenda posted May 27 (http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0622.html). Any change requests?
[ None ]
AB: I have two short announcements: 1) f2f agenda has been updated (http://www.w3.org/2008/webapps/wiki/WidgetsLondonJune2009#Agenda_Items); 2) P&C LCWD#2 published today (http://www.w3.org/TR/2009/WD-widgets-20090528/). Comment period ends June 19. The comment period will not be extended. Comments will be accepted after June 19 but will not be included in the LC's Disposition of Comments document.
<scribe> ACTION: barstow discuss London f2f meeting time for Widgets DigSig [recorded in http://www.w3.org/2009/05/28-wam-minutes.html#action01]
<trackbot> Created ACTION-346 - Discuss London f2f meeting time for Widgets DigSig [on Arthur Barstow - due 2009-06-04].
AB: any other annoucements?
DR: today OMTP will release Approve v1.0 BONDI
AB: on May 21 I issued a Call for
regarding UCs and Reqs for the WAR spec (http://dev.w3.org/2006/waf/widgets-access/).
So far the only response was from Scott Wilson (http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0581.html).
... I think it is important to clearly articulate the primary Use Case (or Use Cases) and the main requirements. Without such information we subject ourselves to lots of questions about what motivates the prescribed model. The WAR spec explicitly identifies two relevant requirements in the Reqs Doc (http://www.w3.org/TR/widgets-reqs/#default-security-policy).
... let's start with Scott's input (http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0581.html). Comments?
<drogersuk> @tlr - oh dear ;-)
AB: Marcos, have you looked at Scott's comments?
MC: no, not yet
Arve: I think Scott's input is in
line with what we have in mind
... so I'm OK with what he wrote but some may not be directly in scope for the WAR spec
... e.g. some may be addressed by the Widget UA itself
... but the requiement itself is OK
RB: yes, agree it is a good
... but may need some work
TR: the rationale has a lot of
solutions so may want to remove some of the mechanism
... think Adam asked some good questions
... we need to address those issues
... by having some reqs
... don't want reqs to have detailed mechanisms
... need to articulate widgets versus the broader web model
AB: sounds like we don't have all of the requirements defined
BS: I can submit some requirements before the f2f meeting
TR: my suggestion is that Robin
begin a draft of reqs and send it to me and Arve
... and then once we have agreement we can send to the list
BS: is the call for UCs complete?
Arve: no, I think we've just started
BS: I can provide some UCs if people want them
<scribe> ACTION: berjon submit requirements for WAR spec to public-webapps [recorded in http://www.w3.org/2009/05/28-wam-minutes.html#action02]
<trackbot> Created ACTION-347 - Submit requirements for WAR spec to public-webapps [on Robin Berjon - due 2009-06-04].
AB: are you saying you already submitted some UC info to public-webapps?
BS: I did send some feedback re the access element and proposed some attributes
<scribe> ACTION: sullivan submit Use Case input before the London f2f meeting [recorded in http://www.w3.org/2009/05/28-wam-minutes.html#action03]
<trackbot> Created ACTION-348 - Submit Use Case input before the London f2f meeting [on Bryan Sullivan - due 2009-06-04].
TR: need UC for net access from
... need to differentiate widget versus web page
BS: I think both have issues with
unrestricted access to the web
... can describe the diff between the two via use cases
Arve: widgets are applications
that simply use web technologies
... but they are no different than desktop apps
... at least that is how I think about it
AB: Arve, Marcos - are there some explicit or implicit requirements from Opera's Widgets Security Model document (http://lists.w3.org/Archives/Public/public-appformats/2008Apr/att-0096/w3c-security.html) we should use?
AB: the WAR spec's Security Model
is a bit thin and includes a Warning about their not being
consensus on the model. There was also a renewal of an older
thread by Josh (http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0600.html)
that lead to a discussion about origin (http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0608.html)
and other things e.g. unique identifiers.
... not sure if we should dig into the threads or talk more about how to make progress.
... what do the Editors need from the rest of us?
Arve: don't think we can make progress until we have an agreed definition of "ORIGIN"
AB: agree with that
RB: yes; plus we need to get agreed reqs
AB: agree with that too
RB: I think we need to nail dow the reqs first
AB: OK, then let's stop the
discussion on WAR today until the actions are completed
... any last comments about the WAR spec?
TR: can we change the name to PEACE?
AB: the A&E spec still has some Red Block issues (http://dev.w3.org/2006/waf/widgets-api/). During the 14 May call we briefly discussed these issues (http://www.w3.org/2009/05/14-wam-minutes.html#item07). What is the status of this spec?
<tlr> only if we get Tolstoy to edit it
MC: I started editing this today;
not much new to report
... hope to spend more time on it soon
... can't give a specific date when LC will be ready
... Storage needs some work
Arve: yes, Storage needs some
... Adam Barth mentioned that yesterday
... need to get Storage and origin sorted out
AB: you two are on it?
Arve: we must first get an agreed defintion of Origin
<tlr> I wonder what happened to this thread: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0301.html
Arve: if we don't use HTML5
Origin, what do we do?
... don't think we want to write our own
RB: writing our own doesn't sound good
Arve: Thomas was suggesting
HTML5's definition of Origin may not be good enough
... via a discussion with Anne in IRC
<tlr> tr: discussion yesterday was about an issue with postMessage
<tlr> tr: solutions: (A) fix postMessage (B) don't use synthetic origins in widget (C) both
AB: not sure how we can move the origin discussion toward closure
<tlr> tr: what's the new piece vs the thread in April?
<tlr> ab: want to understand what Adam's concern is
<tlr> tr: ah, ok. I think it's the same as in April
AB: we still don't have a ED of the Window Modes spec although we have an ED of the Media Query Extensions spec (http://dev.w3.org/2006/waf/widgets-wm/Overview.src.html). What's the priority for the WM spec and the short-term plan?
<tlr> ab: want to check
Arve: it has some impact on the
... if we can't finish WM spec soon, it will affect A+E spec
... we could remove window mode stuff from the A+E spec
AB: do we have an Editor for the WM spec?
RB: I can take it if no one else will
AB: is anyone willing to step up and help Robin?
MC: yes, I can help Robin
AB: is one task moving stuff from MQE spec to the WM spec?
<arve> specifically: viewMode
<arve> 5.13 The onmodechange Callback
Arve: could remove viewMode from A+E
<arve> 5.10 The width Attribute
<arve> 5.11 The height Attribute
AB: so are the opts: 1) increase prio of WM or 2) remove wm stuff from A+E?
Arve: well, one question is if the group is willing to ref incomplete docs
BS: wm-related reqs are very
... if those parts are moved out of A+E, the target spec must also move forward
AB: any other discussion points
for A+E today?
... one question I have is what is BONDI going to do about A+E?
... given its lack of maturity
DR: we will follow what WebApps
... we offered help some time ago
... but it was put on the shelf
... understand P+C was the main target of activity
[ can't hear BS ...]
DR: we currently don't ref any
version of A+E in BONDI
... but eventually we will align with it as it matures
BS: in the next phase of BONDI,
we will work on events
... and window modes is a key part of that
... must get alignment of A+E and WM specs
AB: Bryan, if you can help with WM spec, that would be good
BS: yes, I can create some input
AB: anything else on WM spec?
[ No ]
AB: several weeks ago Robin
created an ED for the Widget URIs spec (http://dev.w3.org/cvsweb/2006/waf/widgets-uri/).
This week, Jean-Claude Dufourd raised the frequently asked
question "do we really need this scheme?" (http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0610.html)
and that naturally resulted in a lively discussion.
... Additionally, Adam Barth started a new thread (http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0624.html) regarding using a public key rather than UUID as the authority; that suggestion was "seconded" by Aaron Broodman
... (http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0636.html) of the Chrome team) and it also touched on the "origin" issue (http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0629.html).
... Lastly, the latest ED contains a list of Issues.
... are there any specific issues we want to discuss today or should we continue discussions on the mail list?
Arve: not sure what we can
... we just don't have consensus
... we will continue to fight the TAG on this
RB: we need to get consensus first within the group
Arve: perhaps our requirements and UCs are not strong enough
RB: are you agreeing to gather UCs and Reqs?
Arve: want to know if other memebers of the group think our ucs and reqs are strong enough
RB: perhpas we need to simplify things for v1 and then defer some things for v2
Arve: if have an origin it will be exposed outside of widget somewhere
TR: need two strong reqs
... 1. do as little as possible and KISS
... 2. absolutize rel uris
... 3. need something on the RHS
... need to also think about adding authority section that identifies signer
... as suggested by Adam
... Not sure if that needs to be done for v1 vs. making sure that can be done for v2
... no relation for origin; solved by DAP WG
... Think we can define a simple model now and defer parts for v2
Arve: if we use a simple model
will we create interop problems for the implementors
... don't want something that is incompatible with the web
TR: the model I proposed is
fundamentally a sand-boxed iframe as far as the DOM is
... behavior is reasonable well-defined in the HTML5 spec
... agree it could have some bugs
... we cannot reuse the web's origin model for remote access requests
Arve: how do we enable the UC to embedd video within a widget?
TR: use same model as XHR or any inline element
Arve: video and audio will be
subject to CORS
... will have required pre-flight requests
TR: preflight not required for a
same origin request
... must distinguish between decisions made in the UA and decisions made on the wire
... the UA will seek authorization via preflight
Arve: we cannot make a decsion on the model until we have researched the consequences
AB: so where does this leave us TR and Arve?
TR: I hear Arve says there is a prob; not convinced we must solve it in v1
Arve: if we want to work with the real web we can't defer this to v2
TR: what is your proposal for solving the hard problem?
Arve: I don't have a proposal now
TR: when will you have a proposal?
Arve: I can't commit
RB: the table is open for proposal
Arve: I have worries but no proposal
RB: do you have specific examples of things that can go wrong?
Arve: video with synthetic origin
it could be impossible for content owner is being served to a
... also content owners may want to know where the content is used or embedded
... this discussion slops over with the WAR discussion
TR: there is a set of proposals
on the table
... I'm looking for a strawman
... I'm hearing there may be requirements
Arve: I'm saying there may be
... and consequences
TR: please put them on the table
AB: Arve, can you take an action to document your concerns?
Arve: I've raised the concerns
... I don't have the answers
... I think the minutes reflect the concerns I have
TR: given Opera has been working on CORS, perhaps you can investigate this
Arve: I will ask Anne
AB: I don't want to be in the same place next week
<tlr> +1 to Robin
TR: I think in the absence of any new proposals, we should specify the simplest proposal possible
<darobin> +1 to TR :)
RB: yes, I agree with TR and can edit the ED that way
AB: any other comments on Widget URIs spec?
[ No ]
<drogersuk> As mentioned earlier on the call, the Approved Release of BONDI 1.0 can be downloaded from http://bondi.omtp.org/. Please let me know if you have any comments or questions.
DR: I will post a link to BONDI release in IRC
AB: my recommendation is to send this information to the public-webapps mail list
DR: yes, I will do that
MC: does this reflect changes from the RC comments?
DR: yes, it does
AB: what level of testing has been done?
DR: it is a spec; what part are you talking about?
AB: e.g. the security policy
... is there a test suite for that?
DR: we have compliance matrix and
... for v1.1 we will have a compliance suite
AB: so this is a set of specifications without a test suite to show an implementation complies?
DR: there is a compliance document and that may help answer your question
AB: any other comments for David?
[ No ]
MC: which version of DigSig and P+C is BONDI referencing
DR: for P+C we ref the
... not sure about the DigSig spec
RB: I think it is the LC version
DR: yes, I think that's true
AB: Meeting Adjourned
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/I agree there is a prob/I hear Arve says there is a prob/ Succeeded: s/+1/+1 to Robin/ Found ScribeNick: ArtB Found Scribe: Art Default Present: +45.29.aaaa, David_Roger, Art_Barstow, Thomas, +188.8.131.52.aabb, darobin, Marcos/Arve, Mike, +1.920.840.aacc, Bryan_Sullivan, +1.919.536.aadd, +45.29.aaee Present: Benoit Thomas Marcos Arve Robin David Art Mike Marcin Bryan WARNING: Replacing previous Regrets list. (Old list: Josh, Frederick) Use 'Regrets+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Regrets+ AndyS Regrets: Josh Frederick AndyS Agenda: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0622.html Found Date: 28 May 2009 Guessing minutes URL: http://www.w3.org/2009/05/28-wam-minutes.html People with action items: barstow berjon for requirements spec submit sullivan war[End of scribe.perl diagnostic output]