See also: IRC log
Date: 16 January 2008
<scribe> Scribe: Art
<scribe> ScribeNick: ArtB
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
<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
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.
<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
<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:[End of scribe.perl diagnostic output]