Date: 16 January 2008

<scribe> Scribe: Art

<scribe> ScribeNick: ArtB

Confidentiality of Minutes

AB: propose minutes be made availible to the public immediately

JS: OK with me

AB: any objections?

<tlr> +1 to public right away

[none heard]

RESOLUTION: minutes will be public immediately

AB: what about approval procedure

<dorchard> I like having minutes being made public immediately and giving a week for somebody to object before final approval

DS: could be approved immediately

TR: could do the approval at the beginning of the next meeting

AB: propose a 1-week approval period and if no objections the minutes will be approved
... any objections?

[none]

RESOLUTION: after the minutes are sent to the public mail list participants will have 1-week to raise objections; otherwise mins will be considered approved

Requirements and Use Cases

<dorchard> Agenda item added at 10 minutes prior to end of call: Intro to Access Control rewrite proposal

AB: any comments on the plan for requirements and UCs?

AvK: what is the idea regarding the doc e.g. WG Note?

JS: I think a Note is a good idea
... we need to set a deadline for completing the reqs

DO: seems right to me [Note]
... support doing this as a note
... some WGs have gone down the REC path but its significant overhead

DS: we could use a wiki as an intermediate step

AB: propose we create a WG Note
... any objections?

[none]

RESOLUTION: we shall create a WG Note for the UCs, Reqs, etc.

AB: what about a wiki?

JS: is one readily available for us to use?
... and what does DO prefer?

DO: I'm indifferent; can use a wiki or the file I've started

<MikeSmith> [MikeSmith needs to drop off for another call. may be back..]

DO: small set of Editors does help with continuity
... can be hard with wikis
... but does help when lots of people are contributing

AB: who plans to contribute?

JS: I still plan to submit my input; can do it as an email or add to the wiki

DO: make an executive decision Art

AB: my preference is a wiki
... any objections to doing so?

[None]

<anne> i disagree

<anne> for some reason i can't talk

<anne> my suggestion would be to add it in an appendix to the main specification

DO: until we get a wiki set up can we continue as we started?

AB: can our member-only wiki be made Public, at least for this part?

TR: should be relatively easy to set up but it is painful to add list of writers
... let's take this offline

DS: agree

AB: good point; I agree

<tlr> DO: have serious concerns if wiki can't be public

<sicking> sorry anne, you were causing echo

AB: let's drop this process-related discussion

<anne> sicking, yeah, this isn't working

<anne> apparently my objections on IRC are also ignored

<tlr> anne, please point out what objections you are referring to.

AB: Anne, we did not make a decision on the wiki

Requirements in David's document

AB: regarding 3.2, Hixie and Jonas both proposed we delete this requirement

<anne> http://www.w3.org/2008/01/16-waf-irc.html#T20-22-05

AB: any objections to deleting 3.2?

[None]

AB: how do we handle the existing reqs and new reqs?

DO: people should make proposals for edits and new requirements
... I am reluctant to add things without some general support
... If a few people agree then we can add them

JS: agree we need it to be lightweight process

AB: I think the priority is to document the requirements for the existing model

JS: not clear what are the VB requirements

AB: I have an action to chase that down

JS: I ask because it could mean we could drop the XML PI if we no longer had their requirement for such support

AB: not sure how to make sure people submit comments

JS: could set a deadline

DS: what about the plans for FF implementation of the AC spec

<dorchard> DO: We could set a deadline of a few weeks if there are few comments over the next week or so.

<Hixie> <?access-control?> is really important to me for XBL2, fwiw

<Hixie> and i think it's critical that we allow people to make data available cross-site without playing with server configuration

<Hixie> i assure you that not all servers give you low-level access, e.g. many google services would never let you add an http header

JS: some people are arguing we need to make a decision now; if the spec then has major changes we will have to withdraw the impl

DS: it's relevant to understand Mozilla's timeframe
... DO, do you think we need major re-design?

DO: I think there are some still important open issues
... e.g. is the PI support needed, etc.
... think we need to nail down the requirements

DS: some people believe the spec is solid and that time is critical
... and that we need to move forward quickly
... My concerns: 1) it's gravely flawed and will be released anyway; 2) it doesn't cause any probs but was held back because of debate
... Need to get it into the hands of developers

DO: I think we need to be careful about a vendor putting constraints on the work just becuase they have done an implementation

<tlr> anne, does Opera have any specific plans?

DO: think we still need to prioritize the reqs and UCs

<tlr> that was just a side question on irc

<anne> tlr, we don't talk about future products

<Hixie> the only way we can make sure that implementations don't constrain the spec is to not delay the spec

<Hixie> the more we delay, the more likely it is that implementations will constrain it

DS: think a key diff here is that this functionality has been needed for at least a couple of years
... I don't think it's good [for the Web] to delay the spec
... Everyday developers have been asking for this functionality

<tlr> anne, you are unmuted if art acks you

DO: I agree with DS' last point; I don't think we want a bunch of different hacks addressing this same issue

<tlr> and you can unmute yourself with "ack anne"

JS: I did think the spec was stable that's why I started my implemenation

<tlr> art: we early on tried to keep the use cases constrained; now getting bashed for not extending them

JS: in the current context, 1-2 months is a really long time
... in another mont or so it will be too late for me to make changes or even to retract

DS: so if we are in LC by the end of Feb would that work with Mozilla's timeframe would we be OK?

JS: mid-Feb would be much better

<dorchard> This seems very risky to me from an impl perspective.

JS: but I think we just need to adjust some details
... I realize this is an unstable spec and the WG is free to make any changes it needs

AB: I'm OK with establishing a deadline for the requirements work

<tlr> +1 to deadline on requirements work

AB: like one week to review the existing set of reqs Dave captured

<Hixie> isn't it about a year after the deadline for the requirements work?

<Hixie> i mean, sure, it's sad that the requirements weren't captured formally, but shouldn't it be too late to change them now?

AB: what about giving two weeks for reqs work

JS: I think we need to document the implicit requirements

<tlr> sorry, syntax is *not* minor changes

AvK: the spec really hasn't changed in over one year

<tlr> please!

AvK: by this I mean the spec as Hixie had written it; the AC has been updated to reflect Hixie's version

TR: there have been changes to the syntax and semantics
... think it would be more effective to get agreement on the reqs

<Hixie> what happens if we don't get agreement on the reqs?

TR: that is documenting the implicit requirements

<dorchard> DO: The document of Feb 15th 2007 does not have the authorization request, support for different methods.

JS: I agree with TR

DO: I also agree with TR

<dorchard> DO: so I think that the document has changed a lot int he past year.

<anne> shepazu, I wasn't replying to you

AB: so what can we do in the next two weeks?

DO: we can try to get closure in 2 weeks

JS: we should aim to be done in two weeks

AB: get a sense of who is willing to really help document the implicit requirements?

<tlr> art: want to get a sense who is willing to help document implicit reqs

AB: Anne?

<tlr> anne: sure

AvK: sure
... have already started

AB: Jonas?

JS: yes

AB: Thomas?

TLR: yes

<tlr> you can use it against us later :)

AB: David?

DO: yes
... including Editorial work

<tlr> apologies

AB: Hixie - can you contribute to documenting the implicit requirements?

<dorchard> DO: I just wanted to mention that reading consensus of the WG could be hard

<tlr> tr: is hixie going to contribute xbl2 reqs?

<tlr> js: I can probably cover that

<Hixie> i think documenting requirements at this stage is an extremely bad idea

<Hixie> since it can only lead to one thing, and that's people disagreeing with the requirements

<Hixie> which can itself only lead to further delays

<Hixie> this should have been in CR last year

<anne> (and that already happened, see JonF on public-appformats)

<Hixie> unless there are specific technical complaints, i think we should publish LC right now

<Hixie> and that anything else is pandering to committee-driven design

AB: everyone please contribute to the implicit requirements discussions ASAP and let's try to be "done" in two weeks.

JSONRequest

<anne> /dev/null ?

AB: we talked about JSONRequest last week but with no resolution
... for example is it in scope or not
... Would like to know if there is consensus on JSONRequest.
... Should it be reflected in our first LC document?

TR: it has a completely different security model than XHR

<dorchard> Hixie, I don't think that a commitee doing design is a bad thing. That's why we have committees.

TR: I don't think it is a fit for this spec
... Recommend we keep it out.

JS: I agree with TR.

<anne> JSONRequest doesn't meet the implicit requirements. Why are we discussing this again?

JS: I think it adds complexity and overhead.
... I intend to submit a requirement that rules out JSONRequest

DO: can there be negative requirements?

<anne> JSONRequest doesn't do cookies/authentication, it doesn't do other formats than JSON, etc.

DS: interesting

<Hixie> dorchard: i fundamentally disagree with that position and would put HTML, CSS, XForms, XHTML, and a broad range of other specs as evidence supporting my opinion.

DO: is absence of a requirement good enough or do we need negative requirements

JS: I think JSONRequest is out of scope

DO: I am a bystander on this one

<tlr> js: (a) do we want to adapt the JSONRequest security model; (b) do we want to use access-control for JSONRequest

<sicking> JS: I think there are two separate questions when it comes to JSONRequest

<sicking> JS: 1. Should access-control use the JSONRequest security model

TR: wrt JSON, the client tells the server (by way of content type) that it is sending a request

<sicking> JS: 2. Should we expact access-control such that JSONRequest can use the access-control security model

TR: the server says the req will fail when the service cannot deal with JSON

<dorchard> Hixie, this is the W3C which has committees. They get to decide things. That's why organizations pay to join.

<anne> AvK: (1) no (2) don't need JSONRequest

<sicking> JS: for 1 I feel that that would complicate the use of access-control too much since it would require that everything be put in a standardized JSONRequest envelope. It should be trivial to construct requirements that makes this obviously not work

TR: the one requirement we should document is: whether or not we expect cross-site requests to carry "ambient" auth information

<sicking> JS: for 2 I think that is out of scope for this version of the spec

<tlr> use case level: do we want to be able to deal with access-protected resources?

<anne> yes

AB: propose that JSONRequest is not in scope

<Hixie> dorchard: sure, and it is imperative that the editor take into account all feedback

<Hixie> dorchard: and if you have requirements that met, you should convey them to the editor

<Hixie> dorchard: who i am sure will take them into account and deal with them (especially if they don't contradict other people's requirements)

<dorchard> Hixie, but then you say when I give feedback and offer an alternative, that I'm "messing with the editors work"

JS: that's not quite right

<Hixie> dorchard: however, that's a far cry from committee-driven design

<Hixie> dorchard: i'm talking about normative requirements here, not how the spec is written, which is basically irrelevant at the end of the day

<sicking> JS: I think we should say that supporting JSONRequest is out of scope. I.e. we do not need to expand access-control such that JSONRequest is able to use it in this version of the ac spec

DO: I would add a non-requirement section

<tlr> +1

DO: add supporting JSONRequest to that section

AB: propose we add a non-requirements section and add JSONRequest to that section and that we close ISSUE #18.
... any objections?

[None]

RESOULTION: we add a non-requirements section and add JSONRequest to that section and that we close ISSUE #18

Access Control Re-write Proposal

<dorchard> http://dev.w3.org/2006/waf/access-control/Overview-Declarative-20080116.html

DO: Stuart Williams and I found the current prose a little confusing
... we re-wrote it in pseudo-code
... this approach is top-down
... made a few other changes too (e.g. BNF)
... Processing Model: added Stuart's overview input
... The new algorithms are leveraged from the XACML spec
... Access Item also redone in pseudo-code
... We think the current style is diff to read and we think this is simpler to understand.
... We want frank comments even if not flattering
... If only part is adopted that's good too
... If nothing is adopted that's OK too
... There may be some holes/mistakes
... But think about the overall style and think about:
... 1. Is it easier to understand

<anne> My personal view it that it's way harder to read and understand.

DO: 2. Is it easier to implement?

TR: agree with doing it top-down
... I disagree with pseudo-code

<anne> And pseudo-code definitely can't replace the current normative text.

TR: the XACML is based on several operators and different states and some of those states do not apply (and adds more complexity)
... need to keep it simple

JS: I don't really care which style we use
... just don't want to ever regress

<tlr> no disagreement with that, either

JS: need a full replacement before we change anything

DO: you don't want new text to be lower quality than existing text
... don't want to spend more effort on this if there isn't good support

AB: what about a meeting next week?

DO: think it would be good

DS: only if there has been substantial progress

TR: my schedule is free so far

<sicking> can you hear me?

<tlr> no

<tlr> we don't hear you

<sicking> i'll type here

<sicking> JS: I agree with DS

<sicking> ... would rather not spend time unless we have useful things to discuss regarding reqs

AB: I think there is critical mass for a call next week

<anne> I agree with Jonas and Doug

AB: there is an action for everyone to submit comments on David and Sturart's proposal before next week's meeting.

<sicking> JS: thanks guys

<anne> I feel that a lot what we discussed could've been done over e-mail

AB: meeting adjorend

This is scribe.perl Revision: 1.130  of Date: 2008/01/16 19:30:10  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found Scribe: Art
Found ScribeNick: ArtB
Present: Art Anne Thomas Jonas Doug Mike David
Regrets: Arve Caludio
Agenda: http://lists.w3.org/Archives/Member/member-appformats/2008Jan/0018.html
Found Date: 16 Jan 2008
Guessing minutes URL: http://www.w3.org/2008/01/16-waf-minutes.html
People with action items: