Widgets Voice Conference

07 May 2009


See also: IRC log


Art, Jere, Thomas, Andy, Mike, Marcos, Robin, Arve
Josh, David




<scribe> ScribeNick: ArtB

<scribe> Scribe: Art

Date: 7 May 2009

trackbot, associate this channel with #webapps

<trackbot> Associating this channel with #webapps...

Review and tweak agenda

AB: I submitted the Draft Agenda on May 6 (http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0499.html). One change is discussing Marcos' P&C ToDo List (http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0500.html) during the "3.e." agenda item. Any other change requests?

[ None ]


AB: earlier today I announced a Call for Editor(s) to help with the P&C spec but we'll get to that later. Any other announcements?

P&C spec: Proposal to add "required" attribute to <access>

AB: last week Bryan proposed (http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/att-0444/00-part) adding two new requirements to the <access> element. Their was agreement the "optional" attribute would be deferred until the next version but there was no consensus on the "required" attribute. Given this spec is already in LC, my inclination is move "required" attribute to the v2 list. Comments?

MC: I agree with defering required attr to v2

RB: I thought we agreed to add it so I did but I'm also OK with dropping it

AB: what would be the burden of the UA if it was included?

MC: the UA wouldn't necessarily do anything with it
... the URI may not be available

AB: I propose the "required" attribute be moved to the v2 feature list
... any objections?

[ None ]

RESOLUTION: the "required" attribute will be moved to the v2 feature list

<scribe> ACTION: barstow add the required attribute to the v2 feature list [recorded in http://www.w3.org/2009/05/07-wam-minutes.html#action01]

<trackbot> Created ACTION-340 - Add the required attribute to the v2 feature list [on Arthur Barstow - due 2009-05-14].

P&C spec: <access> element comments by Thomas

AB: last week Thomas submitted several comments regarding the access element (http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0470.html). Earlier today Robin replied to Thomas (http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0504.html). Let's start with Robin ...

RB: TLR made 5 points
... #1 asks for clarification and I've done that in the draft
... #2: I kept the name and added a subdomain attr
... #3: I'm not exactly sure what TLR is needed
... #4 is defined in the spec
... #5: I explained the wildcard use

TR: I will elaborate in another email
... there are some details we need to think about
... To what extent it is likely someone will want to link to an inline image/iframe
... Want a widget to do same things a web page can do but nothing more
... Permiting XHR leads to a larger risk surface
... If there is a significant piece of widgetry that uses inline content e.g. images, scripts, etc. and do not use XHR then it might be worthwhile to separate XHR from the inline requests in the access element
... Do people have insight if that distinticint exists with authors todayh

RB: in terms of separateing the two, default is inline use
... need to think about security complexities of different contexts

<tlr> tlr: if you have an access tag, then you're mixing content already. That means you need to think about the mix of security context anyway. Note that this is most important in the case of frames.

MC: I don't have any firm ideas on this at this point

TR: are we trying to close down things a web browser has anyway
... or are we saying we want another surface

MC: we want a separate sec model for widgets
... not sure about the implications of using the browser's sec model

TR: not sure we want to define a diff sec model
... what do you want to protect; what is the cost of deviating from the browser model
... don't want to go that route without compelling reasons

MC: since we don't have an origin à la web origin, we need to define our own model

TR: could say the signature protects everything
... can think about access element as it defines the exceptions to the browser sec model

MC: I think that makes sense

TR: we need more input, especially from security experts

MC: this would be better for authors too e.g. developers creating iphone apps, etc.

<darobin> ack

RB: think we may be mixing conversations
... config doc enables a variety of sec models
... could say inline is OK and for everything else must go thru access
... access element defines the metadata for sec model

TR: I have concerns about that view

Arve: I have a concerns about the view RB presented

TR: don't think the access element should defer to a future spec

MC: I agree

RB: I think we should separate discusion of access element from security policy

TR: I don't think they are related

Arve: I agree with TR

AB: how do we move the P+C spec forward if we need a detailed sec model spec?

TR: could say origin is ignored and can't access network resources
... could say a widget is a web page and inherits HTML5 sec model
... this means could have inline content
... access element could specify exceptions to the same origin policy
... there are pros for both of these models

Arve: so you want it to be an opt in of the sec model?

TR: yes

Arve: not sure how that aligns with operator models and handset models
... not sure the HTML5 model is acceptable to handset vendors

TR: we are defining a sec model without reqs for it

MC: we have a synthetic origin

TR: need an origin a server can handle

Arve: not sure why a packaging format needs a detailed sec model

AB: what's next steps here?

TR: I will respond to Robin's email
... I will also state where I think we are
... Want Arve to state his reqs for sec model

Arve: I can't do that today but it will have to wait a few days

TR: I will miss next week's call

AB: please follow-up on the mail list

P&C spec: I18N issue: case-sensitivity of locale subdirectories

AB: on April 29 Robin made a proposal (http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0404.html) for addressing case-sensitivity for localize subdirectory names. There appears to be consensus that option "b" is preferred. Any comments?

<tlr> TR: regrets for 14 and 21 May (argh); happy to do call out of normal schedule

JK: I sent comments on this today
... would be good if RB and MC would read those comments
... will need to do case comparisions anyway

MC: OK; I'll followup
... I think the proposal was to use ASCII order

JK: using ASCII may not be a good idea

AB: so no consensus yet on that issue

P&C spec: status of L10N model agreements

AB: Marcos, what is the status of you integrating the L10N model agreements into the ED?

MC: I've started to integrate the comments.

AB: when do you expect to complete that work?

MC: maybe by mid next week
... it effects diff parts of the spec

P&C spec: proposal to close Issue #80 (Runtime localization model for widgets)

AB: given the agreements we reached during the April 30 call regarding Marcos' L10N model, I think we can now close Issue #80 (http://www.w3.org/2008/webapps/track/issues/8) "Runtime localization model for widgts". Comments?

MC: ok with me

JK: agree

AB: any other comments?

RESOLUTION: Issue #80 is now closed given the agreements from the 30 April call

P&C ToDo List aka how to get P&C to LCWD#2

AB: yesterday Marcos submitted a detailed list of open items for the P&C spec (http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0500.html). Thanks for creating this list Marcos! I don't want to necessarily do a deep dive for any of these but for each would like to understand a) its priority; and b) who will commit to doing the work.
... I see at least four different priorities that could be assigned: 1) Must be addressed before LCWD #2 is published; 2) can be addressed after LCWD #2 is published but before the CR is published; 3) can be addressed during Candidate; 4) can be moved to the v2 feature list. Let's see if we can get quick agreement on the priorities as well as a firm commitment from someone to complete the work.
... #1 - priority #1
... and who?
... #1: prio #1 and Marcos
... anyone can help?

MC: I'll take it

JK: I can help; MC, just let me know

AB: #2:
... prio #2?

RB: not sure; it impacts the processing
... I'm willing to take this

AB: ok, then #2 is prio #1 and RB will take the lead
... #3 and #4

MC: I think RB was going to take these

RB: I can take #3 and #4

AB: great; anyone else that can help?

[ No vols ]

#5: prio #1 ; Robin is taking the lead already

scribe: everyone contribute to related discussions

RB: I'm happy to edit which ever way the group resolves

AB: #6 is part of the L10N model right?

MC: yes
... perhaps JK can help

JK: yes, I can help; is there a tentative defn now?

MC: yes, a 1-line defn
... needs to be expanded

#7: prio #3; can be done during CR phase; Art already agreed to do this

AB: #8: comments?
... there has been some offlist discussion to remove these two attrs

MC: we are unsure now
... they are optional
... they need to be clearly defined in the Window Modes spec
... they make no sense e.g. in full screen mode
... but text needs to be tightened up

AB: so prio #1 for w/h?

MC: yes

AB: #9: window modes
... is this critical for LCWD #2?

MC: yes; the change isn't big; I will take this

AB: #10; this is also related to the L10N model, right?

MC: given last week's agreement, we don't need xml:base
... not clear if we need it or not

AB: is it in there now?

MC: yes

RB: what's in there now is wrong and should be dropped

JK: agree

RESOLUTION: Marcos will remove all refs to xml:base from P+C spec

AB: #11; not sure on the prio of this
... not clear this is critical for v1

MC: it is already specified
... and we have a use case
... Anne said we don't need it

AB: so I propose we leave it in
... any objections to that?

RESOLUTION: we will keep the content element attributes related to encoding and type

AB: #12 - param parsing model

MC: this is high prio and simple cut-and-paste

AB: can you do that MC or do you need help?

MC: I can take it

AB: #13, #14, and #15 are steps 2, 3, and 5

MC: #13 is a 1-liner
... #14 and #15 are L10N

AB: given that, will you take those?

MC: yes

AB: do you need help?

MC: need someone to review after I'm done
... #16 is in the same bucket
... it is related to #1

JK: I am willing to review; just let me know
... I can also help write; just let me know

MC: Jere, can you take finding the base folder and widget locale?

JK: this aligns with item #6
... I'll work on this and get something to MC next week

MC: I should have something by Monday

AB: #17 and #18 - these are prio #2 or #3
... any disagreements on 17 and 18?

[ None ]

AB: if we want the LCWD#2 comment period to end before the June 9-11 f2f meeting then for a 4-week review period we must publish on May 11 and for a 3-week review period we must publish on May 18.

MC: re LC, want to know who we can get to review

AB: besides the "normal suspects"?

MC: could we premtively contact people
... so people could start pre-allocating time

A&E spec: Action 232 - Check the API spec for compliance with the Web IDL spec

AB: Arve and I briefly discussed Action #232 (http://www.w3.org/2008/webapps/track/actions/232) today in IRC (logger not working). His take is that this is not required for LCWD thus I want to drop it from the agenda. Any short comments/feedback?
... defer discssion

A&E spec: Action 290 - Review changes to HTML5 that may affect API and Events spec and propose a way forward

AB: Arve, what is the status of Action #290 (http://www.w3.org/2008/webapps/track/actions/290)?
... without Arve here, need to defer this

A&E spec: Red Block issue in section 5.14 "ISSUE: do we need to do some kind of URI normalization to check for equivalency?"

AB: we will defer discussion on this too

JK: the corresponding RFCs define the baseline
... the answer is Yes by RFCXXXX

TR: are we talking about full URI refs?

JK: the A+E spec defines valid uri

AB: without Arve, I'd like to defer discussion

TR: OK: I'll make a note to follow this

Widgets URI spec: Widget instances and widget invocations

AB: last week Robin submitted a proposal (http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0445.html) re widget instances and widget invocations. There was some followup
... but no consensus
... RB, what's the next step on this?

<tlr> concerning 5.14, I'm comfortable with (a) restricting to URIs (not IRIs) here, and (b) byte-wise comparison of these

RB: I can make a new set of proposals; I don't have a strong opinion

MC: this is an interesting discussion

<JereK> tlr, why not character-wise comparison?

<tlr> because for URIs (not IRIs) that's the same

<tlr> in other wrods, I meant character-wise

<JereK> understood :-)

MC: not sure how much behavior we want to specify

AB: what advice are we giving Robin?

MC: do we want copies of prefs, do we want to clone, ...

<JereK> unless you had UTF-8 encoded URIs?

MC: there are lots of issues

RB: this stuff doesn't belong in URI spec

MC: agree and doesn't belong in P+C either

RB: T-Mobile has some ideas about lifecycle for widgets
... would be good to see their input
... I'll talk to them

AB: that would be good
... I also agree these issues don't belong in URI spec nor P+C spec
... what's the next step with the URI spec?

RB: still need to complete some Edits
... when do we want to publish this?

AB: we can talk about this

RB: I think P+C is a higher prio

AB: agree

RB: perhaps we should wait until after P+C is published

AB: my pref is to wait; want to get P+C and A+E to LC before we publish URI spec

RB: OK. I'll focus on P+C and A+E

AB: good priorities

Widgets URI spec: Action 338 - "edit access element to take into account OMTP feedback and Bryan's"

AB: Robin is Action #338 (http://www.w3.org/2008/webapps/track/actions/338) completed?

RB: this is completed
... and MC has added it to the spec

AB: great
... Meeting Adjourned

Summary of Action Items

[NEW] ACTION: barstow add the required attribute to the v2 feature list [recorded in http://www.w3.org/2009/05/07-wam-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2009/05/07 14:28:40 $

Scribe.perl diagnostic output

[Delete this section before finalizing the 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/think security/think about security/
Succeeded: s/ala/à la/
Found ScribeNick: ArtB
Found Scribe: Art
Present: Art Jere Thomas Andy Mike Marcos Robin Arve
Regrets: Josh David
Agenda: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0499.html
Found Date: 07 May 2009
Guessing minutes URL: http://www.w3.org/2009/05/07-wam-minutes.html
People with action items: barstow

[End of scribe.perl diagnostic output]