See also: IRC log
<scribe> ScribeNick: ArtB
<scribe> Scribe: Art
Date: 7 May 2009
trackbot, associate this channel with #webapps
<trackbot> Associating this channel with #webapps...
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?
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].
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
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
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
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
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
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
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
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
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
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
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]