<sicking> i'm already dialed in

<arve> I'm calling in in a minute

Date: 9 January 2008

<scribe> Scribe: Art

<scribe> ScribeNick: ArtB

Requirements and Use Cases

<anne-mac> AB: XBL, XSLT, VoiceXML <data> element, XMLHttpRequest, etc.

<anne-mac> AB: DO has been working on a requirements document based on Hixie's input to the mailing list last week

DO: I just created a short start but I can help going forward
... can live with the existing doc going fwd or put the info in the existing doc

<tlr> http://lists.w3.org/Archives/Public/www-archive/2008Jan/att-0010/AccessControl-Requirements-20070108.html

JS: req 3.2 is vague to me too

<tlr> +1

JS: perhaps it should be removed

DO: we should get Hixie to expand on it

<anne-mac> I think it means that the server should always be able to refrain from responding to a request

DO: the reqs should help with the design decisions

<anne-mac> I think you can't assign action items to persons who are not in the meeting

<anne-mac> Though maybe that's just how DanC works

<scribe> ACTION: Hickson elaborate on requirement 3.2 [recorded in http://www.w3.org/2008/01/09-waf-minutes.html#action01]

<trackbot-ng> Created ACTION-149 - Elaborate on requirement 3.2 [on Ian Hickson - due 2008-01-16].

DO: think 3.2 needs more elaboration re the client doing the enforcement

TR: req does not define User Scenarios
... also need to expand on the Goals much better
... the protection goals need to be clear
... Clarifying the Goals and Scenarios is needed before 3.2 can be well understood.

DO: I didn't put any UC stuff in the doc because there wasn't anything available when I created my 1st draft
... I now see some work has been done on UCs

JS: agree we need some Usage Scenarios
... I am particularly interested in input from Hixie because I understand Google is interested in using this

<anne-mac> hmm, the blacklist came from Mozilla sicking...

JS: Also should help with the white list and black list question

DO: one view is everything in the spec should be motivated by the UCs
... but it raises the question about how large the set of UCs should be
... What does the WG want?

AB: I think the priority is to document the 3 scenarios we have talked about

<scribe> ACTION: Sicking submit a Usage Scenario input [recorded in http://www.w3.org/2008/01/09-waf-minutes.html#action02]

<trackbot-ng> Created ACTION-150 - Submit a Usage Scenario input [on Jonas Sicking - due 2008-01-16].

DO: then perhaps we should begin with the initial 3 cases

JS: I'm thinking about some UCs that are not part of the original 3

<scribe> ACTION: Barstow get some UC info from the VB community [recorded in http://www.w3.org/2008/01/09-waf-minutes.html#action03]

<trackbot-ng> Created ACTION-151 - Get some UC info from the VB community [on Arthur Barstow - due 2008-01-16].

<scribe> ACTION: Orchard add in the UC stuff that Art pointed to [recorded in http://www.w3.org/2008/01/09-waf-minutes.html#action04]

<trackbot-ng> Created ACTION-152 - Add in the UC stuff that Art pointed to [on David Orchard - due 2008-01-16].

DS: having detailed UCs and Reqs will help flesh out the security concerns and we will need that to move the doc forward

JS: I think we have addressed all of the security-related concerns that have been raised
... but I agree clear UCs and Reqs will help us articulate the security model

<anne-mac> Yeah, as far as I can tell no new security issues have been raised since we designed this. We have changed the design slightly to make it nicer, but that's it. The security has been sound pretty much from the start.

TLR: requirement 3.3 - some people don't agree with this requirement
... req 3.4 - I agree with the Ed Note; not clear what this is and we need clarification

JS: perhaps 3.4 is better described as a UC rather than a requirement

TLR: I tend to agree
... as currently written its too fuzzy
... req 3.6 - also needs some clarification about what is meant by admin
... req 3.7 and 3.8 - I think these should be CSRF and not XSS
... also need to define the baseline for these reqs
... need to understand the real protection goal and needs more discussion

<anne-mac> It seems better to share this information on the mailing list than on a telconference tlr

<anne-mac> This doesn't give anybody time to study the issue and make an informed comment on it

TLR: req 3.9 - the model must be able to deal with caching as deployed today
... must be very careful with HTTP caching

RESOLUTION: minutes from this VC will be Public

<tlr> For the record, thanks to Dave Orchard for helping with the editorial work!

JS: regarding 3.4, we need to formulate the goal somehow

<scribe> ACTION: Hickson submit a clarification and elaboration of req 3.4 to the mail list [recorded in http://www.w3.org/2008/01/09-waf-minutes.html#action05]

<trackbot-ng> Created ACTION-153 - Submit a clarification and elaboration of req 3.4 to the mail list [on Ian Hickson - due 2008-01-16].

<anne-mac> Not just XSLT and XBL. Also an XML resource which you can then fetch cross-site with XMLHttpRequest

JS: agree req 3.4 is too vague to the point of not being useful as currently documented

<anne-mac> +1, that seems way more useful

DO: going forward with the requirements, seems like we should ask for suggested alternative re-wording

AB: do we want to open up an invitation to a bunch of new UCs and/or Reqs?

JS: NO, I do not want that.
... I've started to implement the current WD
... If the spec is going to change a lot I will need to pull my impl out of FFv3
... I do not want to go back to square 1 regarding Reqs

AvK: yes, I agree with JS; I do not want to go back to square 1

DO: understand but if there are fundamental questions e.g. location of the PEP
... we may have a problem

AvK: I think we have already addressed the questions being raised

JS: if we get input that says the spec is bad/wrong then yes we need to address that input but I haven't seen that yet

TR: but we are getting the same questions over again
... we first need clear UCs, principles and Reqs

<tlr> the request for use cases and requirements is not a new one.

DO: I can document what the WG wants me to
... I can volunteer for at least a little while

AB: we don't have an option regarding requirements - the Process Doc mandates we identify the requiremetns the spec fullfills to take the spec to Last Call

<tlr> sorry

<arve> that would've been caroline baron, no?

<tlr> by caller ID, yes, and I don't think she'd join this call.

<tlr> which is what I found confusing

<anne-mac> it's easier for me to attend now, but I rather discuss things through e-mail

next Voice Conf

AvK: this time is OK but I prefer e-mail

DO: I think we should plan to have a call next week

TR: does not prefer one hour earlier

<tlr> no!

<anne-mac> 8PM European time collides with food

<tlr> 8pm European time collides with food, indeed, 9pm European time is better

<tlr> Generally I prefer afternoons, but this time next week is ok. Indeed.

JS: one hour earlier is problematic

<tlr> sicking, the reference re tunneling and arbitrary firewall traversals is http://www.doxpara.com/

JS: the current time is good

<tlr> Look for his latest slide deck.

JSONRequest

<tlr> ISSUE-18?

<trackbot-ng> ISSUE-18 -- Is JSONRequest an acceptable alternative to the current model? -- RAISED

<trackbot-ng> http://www.w3.org/2005/06/tracker/waf/issues/18

<tlr> ISSUE-20?

<trackbot-ng> ISSUE-20 -- Client and Server model -- RAISED

<trackbot-ng> http://www.w3.org/2005/06/tracker/waf/issues/20

<anne-mac> yeah... wtf

JS: I've posted a lot of responses to this question
... I don't think we can adopt it and address our UCs
... don't think it can be expanded to transfer anything but JSONRequests

DO: Jonas just enumerated a bunch of constraints that need to documented in our reqs
... We should also be able to use good clear reqs to substantiate questions like "why not use JSONRequest?"

JS: I will try to address your concern via my requirements input

TR: there are lots of issues regarding JSONRequests
... one is, where should it be specified
... another is should there be an XHR derivative do something like it
... another is whether or not JSONRequest is a Use Case for the AC4CSR
... what decisions are we after?

<tlr> art: JSONRequest seems to be coming up as a new, additional use case.

<tlr> ... very recently ...

<tlr> ... as chair, I ask group whether we should add anything? ...

<tlr> ... or should we say "sorry, out of scope" to Doug and others?

<tlr> Doug = Doug Crockford

JS: I'm not comfortable expanding the spec to include JSONReq
... I think it would require some fairly dramatic changes to the JSONReq spec
... would they even consider this?
... The way it works today it will not fit our requirements.

AvK: I agree with JS

DS: if we had clear UCs and Reqs then the issue about JSONReq would be easier and more objective to answer

TR: I agree with DS on a general level
... I tend to agree with JS that bringing AC and JSONReqest specs together is problematic

<arve> tlr, that's wrong

TR: I don't think we should go down that path.

<arve> :-)

JS: one issue that has been raised is that both AC4CSR and JSONRequest are both short-term solutions, kinda' hackish so I wonder what the long-term plan should be.
... But I don't want to delay AC4CSR for some long-term spec.
... which could take a long, long time to produce.

TR: I think what JS is saying is that we may need some type of Workshop to grapple with the broader architectural issues

DO: I'm struggling with the scope of this work
... getting the UCs and Reqs documented will certainly help
... How did this WG start this work to begin with?
... There never was any AC review of this work.
... Perhaps there is a need for the short-term work and longer-term work.

AB: before we did any work we had a Team Review and I presented the work to the W3C
... AC in May '06

TR: remember the work started in the VB WG and was a WG Note.

<dorchard> However, I don't think that the AC had a chance to say "please do the long term solution" or "please don't do the long term solution".

<anne-mac> access-control was found by Hixie and used for XXX (cross-site extensions for XMLHttpRequest)

<anne-mac> it wasn't really through XBL2

TR: WAF noted a need for something similar regarding XBL2
... the Web API WG also stated a need for a similar mechanismm for XHR

<dorchard> I'm open to the group doing the long-term solution, and even a bit worried that the short-term might preclude long-term.

TR: It only made sense to create one spec/model rather than 3

<dorchard> Though I don't know what the long-term would look like at a high-level.

<anne-mac> I wonder what long-term solutions people are thinking about? That stuff magically works?

DS: security concerns are showing up in many places

<tlr> incidentally, I don't disagree with what Doug's saying there.

DS: I think we need to do something sooner rather thann later

<anne-mac> I sort of think we're way past long-term solutions unless we replace the Web with something new but I'm willing to be proven wrong

<anne-mac> (for some value of "long-term")

AvK: will the requirements and UC stuff delay LC?

<tlr> for the record, there might be disagreement that this is ready for LC

AvK: I think it is ready for LC

JS: not so sure; want to talk about the methods some more

AvK: I'm OK with using OPTIONS provided Apache issues can be addressed

<shepazu> DS: security concerns in W3C have typically had 2 responses... 1) we can't do it because of security; or 2) let's ignore security and do it anyway... neither is acceptable; we need a short-term as well as a long-term solution, if only because to set the scope for larger work, and to give some minimal functionality to Web app developers

AvK: need real evidence

TR: I think we may get some different views from the HTTP community

<dorchard> I have concerns about GET as well.

AvK: Hixie has addressed these issues
... Bjoerne has raised an issue

TR: what about a Proxy cache and two diff clients request the same resource?

<dorchard> My concern comes from the aliasing web architecture issue, that is one URI for 2 different resources.

<tlr> dorchard, I hadn't thought about that one.

<anne-mac> conneg?

AB: Meeting adjourned

This is scribe.perl Revision: 1.128  of Date: 2007/02/23 21:38:13  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/no new issues/no new security issues/
Succeeded: s/prefer/does not prefer/
Succeeded: s/AC spec/there be an XHR derivative/
Found Scribe: Art
Found ScribeNick: ArtB
Default Present: +1.781.993.aaaa, ArtB, Sicking, Thomas, Dave_Orchard, Doug_Schepers, +47.24.16.aabb, anne-mac, DOrchard, Benoit
Present: Art Arve David Thomas Benoit Doug Anne Jonas
Agenda: http://lists.w3.org/Archives/Member/member-appformats/2008Jan/0001.html

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 9 Jan 2008
Guessing minutes URL: http://www.w3.org/2008/01/09-waf-minutes.html
People with action items: barstow hickson orchard sicking