20:01:27 RRSAgent has joined #waf 20:01:27 logging to http://www.w3.org/2008/01/16-waf-irc 20:01:28 ok, tlr; the call is being made 20:01:30 +[Mozilla] 20:02:04 zakim, call thomas-781 20:02:04 ok, tlr; the call is being made 20:02:06 +Anne_van_Kesteren 20:02:08 +Thomas 20:02:09 + +1.781.993.aaaa 20:02:18 zakim, aaaa is ArtB 20:02:18 +ArtB; got it 20:02:25 Zakim, Anne is me 20:02:25 +anne; got it 20:02:27 dorchard has joined #waf 20:02:37 Zakim, who is here? 20:02:37 On the phone I see [Mozilla], anne, ArtB, Thomas 20:02:38 On IRC I see dorchard, RRSAgent, Zakim, ArtB, tlr, Lachy, Mike^mail, heycam, shepazu, anne, Hixie, trackbot-ng, mikko 20:02:42 sicking has joined #waf 20:02:43 +DOrchard 20:02:49 Zakim, call Doug-work 20:02:49 ok, shepazu; the call is being made 20:02:51 +Doug 20:03:08 Zakim, who is on call 20:03:08 I don't understand 'who is on call', sicking 20:03:28 Agenda: http://lists.w3.org/Archives/Member/member-appformats/2008Jan/0018.html 20:03:38 Zakim, callers 20:03:38 I don't understand 'callers', sicking 20:03:50 Meeting: WAF WG Voice Conf on Access Control Spec 20:03:52 +??P11 20:03:55 Date: 16 January 2008 20:04:00 Zakim, ??P1 is me 20:04:00 +Mike^mail; got it 20:04:13 Zakim, mozilla is me 20:04:13 +sicking; got it 20:04:36 Present: Art, Anne, Thomas, Jonas, Doug, Mike, David 20:04:45 Regrets: Arve, Caludio 20:04:51 Zakim, noise? 20:04:51 I don't understand your question, anne. 20:05:08 Zakim, who is making noise? 20:05:18 anne, listening for 10 seconds I heard sound from the following: ArtB (79%), Thomas (5%) 20:05:26 zakim, I am thomas 20:05:26 ok, tlr, I now associate you with Thomas 20:05:27 zakim, mute me 20:05:27 Thomas should now be muted 20:05:40 -ArtB 20:05:55 zakim, unmute me 20:05:55 Thomas should no longer be muted 20:06:01 Zakim, who is making noise? 20:06:05 +ArtB 20:06:11 anne, listening for 10 seconds I heard sound from the following: Thomas (25%) 20:06:16 zakim, mute me 20:06:18 Thomas should now be muted 20:06:30 Zakim, who is making noise? 20:06:32 Scribe: Art 20:06:37 ScribeNick: ArtB 20:06:40 Chair: Art 20:06:41 anne, listening for 10 seconds I heard sound from the following: ArtB (19%) 20:07:02 Zakim, mute me 20:07:02 anne should now be muted 20:07:05 Topic: Confidentiality of Minutes 20:07:36 AB: propose minutes be made availible to the public immediately 20:07:39 JS: OK with me 20:07:51 AB: any objections? 20:07:54 +1 to public right away 20:07:57 [none heard] 20:08:33 q+ to ask for an agenda item 20:08:38 RESOLUTION: minutes will be public immediately 20:09:03 zakim, unmute me 20:09:03 Thomas should no longer be muted 20:09:06 AB: what about approval procedure 20:09:09 I like having minutes being made public immediately and giving a week for somebody to object before final approval 20:09:14 DS: could be approved immediately 20:09:28 TR: could do the approval at the beginning of the next meeting 20:09:54 zakim, mute me 20:09:54 Thomas should now be muted 20:10:21 AB: propose a 1-week approval period and if no objections the minutes will be approved 20:10:28 AB: any objections? 20:10:30 [none] 20:11:03 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 20:11:19 Topic: Requirements and Use Cases 20:13:07 Zakim, unmute me 20:13:07 anne should no longer be muted 20:13:42 Agenda item added at 10 minutes prior to end of call: Intro to Access Control rewrite proposal 20:14:08 AB: any comments on the plan for requirements and UCs? 20:14:21 AvK: what is the idea regarding the doc e.g. WG Note? 20:14:39 JS: I think a Note is a good idea 20:14:50 ... we need to set a deadline for completing the reqs 20:15:02 DO: seems right to me [Note] 20:15:33 ... support doing this as a note 20:15:53 ... some WGs have gone down the REC path but its significant overhead 20:16:55 DS: we could use a wiki as an intermediate step 20:17:10 AB: propose we create a WG Note 20:17:14 AB: any objections? 20:17:18 [none] 20:17:36 RESOLUTION: we shall create a WG Note for the UCs, Reqs, etc. 20:17:44 Zakim, who is making noise? 20:17:54 anne, listening for 10 seconds I heard sound from the following: ArtB (84%) 20:18:15 AB: what about a wiki? 20:18:27 JS: is one readily available for us to use? 20:18:42 ... and what does DO prefer? 20:19:02 DO: I'm indifferent; can use a wiki or the file I've started 20:19:05 [MikeSmith needs to drop off for another call. may be back..] 20:19:14 -Mike^mail 20:19:23 ... small set of Editors does help with continuity 20:19:39 ... can be hard with wikis 20:19:58 zakim, who is muted? 20:19:58 I see Thomas muted 20:19:58 ... but does help when lots of people are contributing 20:20:55 AB: who plans to contribute? 20:21:24 JS: I still plan to submit my input; can do it as an email or add to the wiki 20:21:37 DO: make an executive decision Art 20:21:47 AB: my preference is a wiki 20:21:55 AB: any objections to doing so? 20:21:58 [None] 20:22:05 i disagree 20:22:10 for some reason i can't talk 20:22:30 my suggestion would be to add it in an appendix to the main specification 20:22:34 DO: until we get a wiki set up can we continue as we started? 20:22:42 -anne 20:23:00 Zakim, passcode? 20:23:00 the conference code is 9231 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), anne 20:23:27 +anne 20:23:36 zakim, unmute me 20:23:36 Thomas should no longer be muted 20:23:51 AB: can our member-only wiki be made Public, at least for this part? 20:24:25 TR: should be relatively easy to set up but it is painful to add list of writers 20:25:14 Zakim, mute anne 20:25:14 anne should now be muted 20:25:17 TR: let's take this offline 20:25:20 DS: agree 20:25:28 AB: good point; I agree 20:25:31 DO: have serious concerns if wiki can't be public 20:25:38 sorry anne, you were causing echo 20:25:41 AB: let's drop this process-related discussion 20:25:43 zakim, mute me 20:25:43 Thomas should now be muted 20:25:49 -anne 20:25:57 sicking, yeah, this isn't working 20:26:07 apparently my objections on IRC are also ignored 20:27:01 zakim, who is on the phone? 20:27:01 On the phone I see sicking, Thomas (muted), DOrchard, Doug, ArtB 20:27:27 anne, please point out what objections you are referring to. 20:27:33 AB: Anne, we did not make a decision on the wiki 20:27:52 RRSAgent, pointer? 20:27:52 See http://www.w3.org/2008/01/16-waf-irc#T20-27-52 20:28:01 RRSAgent, make logs public 20:28:05 Topic: Requirements in David's document 20:28:32 AB: regarding 3.2, Hixie and Jonas both proposed we delete this requirement 20:28:35 http://www.w3.org/2008/01/16-waf-irc.html#T20-22-05 20:28:41 AB: any objections to deleting 3.2? 20:29:02 [None] 20:31:17 AB: how do we handle the existing reqs and new reqs? 20:31:23 +anne 20:31:24 Zakim, mute me 20:31:25 anne should now be muted 20:31:36 DO: people should make proposals for edits and new requirements 20:32:05 ... I am reluctant to add things without some general support 20:32:15 ... If a few people agree then we can add them 20:32:25 JS: agree we need it to be lightweight process 20:34:08 AB: I think the priority is to document the requirements for the existing model 20:34:27 JS: not clear what are the VB requirements 20:35:51 AB: I have an action to chase that down 20:36:22 JS: I ask because it could mean we could drop the XML PI if we no longer had their requirement for such support 20:37:56 AB: not sure how to make sure people submit comments 20:38:09 JS: could set a deadline 20:38:36 DS: what about the plans for FF implementation of the AC spec 20:38:56 DO: We could set a deadline of a few weeks if there are few comments over the next week or so. 20:39:03 is really important to me for XBL2, fwiw 20:39:30 and i think it's critical that we allow people to make data available cross-site without playing with server configuration 20:39:55 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 20:40:03 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 20:40:29 DS: it's relevant to understand Mozilla's timeframe 20:41:03 DS: DO, do you think we need major re-design? 20:41:22 DO: I think there are some still important open issues 20:41:41 ... e.g. is the PI support needed, etc. 20:41:53 ... think we need to nail down the requirements 20:42:56 DS: some people believe the spec is solid and that time is critical 20:43:10 ... and that we need to move forward quickly 20:44:05 ... 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 20:44:37 ... Need to get it into the hands of developers 20:44:55 q+ to wonder about implementation priority 20:45:13 zakim, who is muted? 20:45:13 I see Thomas, anne muted 20:46:20 DO: I think we need to be careful about a vendor putting constraints on the work just becuase they have done an implementation 20:46:36 anne, does Opera have any specific plans? 20:47:02 ... think we still need to prioritize the reqs and UCs 20:47:06 -anne 20:47:26 q+ 20:47:31 that was just a side question on irc 20:47:46 tlr, we don't talk about future products 20:48:06 the only way we can make sure that implementations don't constrain the spec is to not delay the spec 20:48:21 the more we delay, the more likely it is that implementations will constrain it 20:48:36 DS: think a key diff here is that this functionality has been needed for at least a couple of years 20:48:55 ... I don't think it's good [for the Web] to delay the spec 20:49:36 +anne 20:49:37 ... Everyday developers have been asking for this functionality 20:49:53 zakim, mute anne 20:49:53 anne should now be muted 20:50:01 anne, you are unmuted if art acks you 20:50:04 DO: I agree with DS' last point; I don't think we want a bunch of different hacks addressing this same issue 20:50:06 and you can unmute yourself with "ack anne" 20:50:16 q+ 20:50:35 JS: I did think the spec was stable that's why I started my implemenation 20:52:19 q- 20:52:42 q? 20:52:59 art: we early on tried to keep the use cases constrained; now getting bashed for not extending them 20:53:25 JS: in the current context, 1-2 months is a really long time 20:53:50 ... in another mont or so it will be too late for me to make changes or even to retract 20:54:06 shepazu has joined #waf 20:55:04 DS: so if we are in LC by the end of Feb would that work with Mozilla's timeframe would we be OK? 20:55:11 JS: mid-Feb would be much better 20:55:19 This seems very risky to me from an impl perspective. 20:55:25 ... but I think we just need to adjust some details 20:55:56 JS: I realize this is an unstable spec and the WG is free to make any changes it needs 20:57:27 AB: I'm OK with establishing a deadline for the requirements work 20:57:43 +1 to deadline on requirements work 20:57:43 ... like one week to review the existing set of reqs Dave captured 20:57:56 isn't it about a year after the deadline for the requirements work? 20:58:20 i mean, sure, it's sad that the requirements weren't captured formally, but shouldn't it be too late to change them now? 20:59:11 ack me 20:59:31 AB: what about giving two weeks for reqs work 21:00:01 JS: I think we need to document the implicit requirements 21:00:13 sorry, syntax is *not* minor changes 21:00:28 AvK: the spec really hasn't changed in over one year 21:00:34 please! 21:00:59 zakim, unmute me 21:00:59 Thomas should no longer be muted 21:01:03 q+ 21:01:28 AvK: by this I mean the spec as Hixie had written it; the AC has been updated to reflect Hixie's version 21:01:45 TR: there have been changes to the syntax and semantics 21:02:12 Zakim, mute me 21:02:12 anne should now be muted 21:02:16 ... think it would be more effective to get agreement on the reqs 21:02:37 what happens if we don't get agreement on the reqs? 21:02:45 ... that is documenting the implicit requirements 21:02:56 DO: The document of Feb 15th 2007 does not have the authorization request, support for different methods. 21:02:56 JS: I agree with TR 21:03:05 DO: I also agree with TR 21:03:09 DO: so I think that the document has changed a lot int he past year. 21:03:13 shepazu, I wasn't replying to you 21:04:10 AB: so what can we do in the next two weeks? 21:04:19 DO: we can try to get closure in 2 weeks 21:04:30 JS: we should aim to be done in two weeks 21:04:53 AB: get a sense of who is willing to really help document the implicit requirements? 21:04:54 art: want to get a sense who is willing to help document implicit reqs 21:04:58 AB: Anne? 21:05:10 zakim, unmute anne 21:05:10 anne should no longer be muted 21:05:19 anne: sure 21:05:21 AvK: sure 21:05:32 ... have already started 21:05:38 AB: Jonas? 21:05:40 JS: yes 21:05:44 AB: Thomas? 21:05:54 TLR: yes 21:06:07 you can use it against us later :) 21:06:10 AB: David? 21:06:12 q+ 21:06:17 DO: yes 21:06:22 Zakim, mute me 21:06:22 anne should now be muted 21:06:23 Zakim, mute anne 21:06:24 anne was already muted, sicking 21:06:25 ... including Editorial work 21:06:40 apologies 21:07:18 AB: Hixie - can you contribute to documenting the implicit requirements? 21:07:18 DO: I just wanted to mention that reading consensus of the WG could be hard 21:07:19 tr: is hixie going to contribute xbl2 reqs? 21:07:23 js: I can probably cover that 21:07:57 i think documenting requirements at this stage is an extremely bad idea 21:08:09 since it can only lead to one thing, and that's people disagreeing with the requirements 21:08:14 which can itself only lead to further delays 21:08:22 this should have been in CR last year 21:08:30 (and that already happened, see JonF on public-appformats) 21:08:45 unless there are specific technical complaints, i think we should publish LC right now 21:09:02 and that anything else is pandering to committee-driven design 21:09:02 AB: everyone please contribute to the implicit requirements discussions ASAP and let's try to be "done" in two weeks. 21:09:50 Topic: JSONRequest 21:10:21 /dev/null ? 21:10:52 AB: we talked about JSONRequest last week but with no resolution 21:11:01 ... for example is it in scope or not 21:11:31 ... Would like to know if there is consensus on JSONRequest. 21:11:51 q+ 21:12:18 q- 21:12:21 ... Should it be reflected in our first LC document? 21:12:57 TR: it has a completely different security model than XHR 21:13:02 Hixie, I don't think that a commitee doing design is a bad thing. That's why we have committees. 21:13:07 ... I don't think it is a fit for this spec 21:13:16 ... Recommend we keep it out. 21:13:22 JS: I agree with TR. 21:14:04 JSONRequest doesn't meet the implicit requirements. Why are we discussing this again? 21:14:05 ... I think it adds complexity and overhead. 21:14:19 JS: I intend to submit a requirement that rules out JSONRequest 21:14:37 DO: can there be negative requirements? 21:14:42 JSONRequest doesn't do cookies/authentication, it doesn't do other formats than JSON, etc. 21:14:44 DS: interesting 21:14:48 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. 21:15:02 DO: is absence of a requirement good enough or do we need negative requirements 21:15:42 -anne 21:15:49 q+ 21:16:32 JS: I think JSONRequest is out of scope 21:16:59 DO: I am a bystander on this one 21:17:35 js: (a) do we want to adapt the JSONRequest security model; (b) do we want to use access-control for JSONRequest 21:17:45 JS: I think there are two separate questions when it comes to JSONRequest 21:18:06 JS: 1. Should access-control use the JSONRequest security model 21:18:30 TR: wrt JSON, the client tells the server (by way of content type) that it is sending a request 21:18:38 JS: 2. Should we expact access-control such that JSONRequest can use the access-control security model 21:18:48 ... the server says the req will fail when the service cannot deal with JSON 21:19:03 Hixie, this is the W3C which has committees. They get to decide things. That's why organizations pay to join. 21:19:38 AvK: (1) no (2) don't need JSONRequest 21:19:43 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 21:19:49 TR: the one requirement we should document is: whether or not we expect cross-site requests to carry "ambient" auth information 21:19:56 JS: for 2 I think that is out of scope for this version of the spec 21:20:41 use case level: do we want to be able to deal with access-protected resources? 21:20:57 yes 21:21:09 AB: propose that JSONRequest is not in scope 21:21:09 dorchard: sure, and it is imperative that the editor take into account all feedback 21:21:22 dorchard: and if you have requirements that met, you should convey them to the editor 21:21:42 dorchard: who i am sure will take them into account and deal with them (especially if they don't contradict other people's requirements) 21:21:50 Hixie, but then you say when I give feedback and offer an alternative, that I'm "messing with the editors work" 21:21:51 JS: that's not quite right 21:21:55 dorchard: however, that's a far cry from committee-driven design 21:22:22 dorchard: i'm talking about normative requirements here, not how the spec is written, which is basically irrelevant at the end of the day 21:23:00 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 21:24:32 DO: I would add a non-requirement section 21:24:38 +1 21:24:46 ... add supporting JSONRequest to that section 21:25:24 AB: propose we add a non-requirements section and add JSONRequest to that section and that we close ISSUE #18. 21:25:32 AB: any objections? 21:25:36 [None] 21:25:48 RESOULTION: we add a non-requirements section and add JSONRequest to that section and that we close ISSUE #18 21:26:15 Topic: Access Control Re-write Proposal 21:26:17 http://dev.w3.org/2006/waf/access-control/Overview-Declarative-20080116.html 21:27:01 DO: Stuart Williams and I found the current prose a little confusing 21:27:13 ... we re-wrote it in pseudo-code 21:27:50 ... this approach is top-down 21:29:02 ... made a few other changes too (e.g. BNF) 21:29:25 ... Processing Model: added Stuart's overview input 21:30:11 ... The new algorithms are leveraged from the XACML spec 21:31:34 ... Access Item also redone in pseudo-code 21:31:42 q+ 21:31:59 ... We think the current style is diff to read and we think this is simpler to understand. 21:32:20 ... We want frank comments even if not flattering 21:32:38 ... If only part is adopted that's good too 21:32:47 ... If nothing is adopted that's OK too 21:33:13 ... There may be some holes/mistakes 21:33:25 ... But think about the overall style and think about: 21:33:34 ... 1. Is it easier to understand 21:33:36 q+ 21:33:40 My personal view it that it's way harder to read and understand. 21:33:46 ... 2. Is it easier to implement? 21:34:00 TR: agree with doing it top-down 21:34:11 ... I disagree with pseudo-code 21:34:49 And pseudo-code definitely can't replace the current normative text. 21:34:50 ... the XACML is based on several operators and different states and some of those states do not apply (and adds more complexity) 21:36:02 ... need to keep it simple 21:36:17 JS: I don't really care which style we use 21:36:20 Hixie has joined #waf 21:36:26 ... just don't want to ever regress 21:36:51 no disagreement with that, either 21:36:58 ... need a full replacement before we change anything 21:37:09 RRSAgent, pointer? 21:37:09 See http://www.w3.org/2008/01/16-waf-irc#T21-37-09 21:37:22 DO: you don't want new text to be lower quality than existing text 21:37:46 ... don't want to spend more effort on this if there isn't good support 21:38:06 zakim, who's on the phone? 21:38:06 On the phone I see sicking, Thomas, DOrchard, Doug, ArtB 21:39:11 AB: what about a meeting next week? 21:39:16 DO: think it would be good 21:39:25 DS: only if there has been substantial progress 21:39:41 TR: my schedule is free so far 21:39:56 can you hear me? 21:39:58 no 21:40:02 ack sicking 21:40:03 Zakim, unmute me 21:40:03 sicking was not muted, sicking 21:40:04 q- 21:40:13 we don't hear you 21:40:18 i'll type here 21:40:33 JS: I agree with DS 21:40:50 ... would rather not spend time unless we have useful things to discuss regarding reqs 21:40:51 AB: I think there is critical mass for a call next week 21:41:01 I agree with Jonas and Doug 21:41:23 AB: there is an action for everyone to submit comments on David and Sturart's proposal before next week's meeting. 21:41:51 JS: thanks guys 21:41:53 I feel that a lot what we discussed could've been done over e-mail 21:41:55 -DOrchard 21:41:55 AB: meeting adjorend 21:41:58 -Thomas 21:42:02 -sicking 21:42:05 rrsagent, make minutes public 21:42:05 I'm logging. I don't understand 'make minutes public', ArtB. Try /msg RRSAgent help 21:42:06 -Doug 21:42:15 rrsagent, make logs public 21:42:22 rrsagent, make minutes 21:42:22 I have made the request to generate http://www.w3.org/2008/01/16-waf-minutes.html ArtB 21:42:32 -ArtB 21:42:34 IA_WAF()3:00PM has ended 21:42:36 Attendees were Anne_van_Kesteren, Thomas, +1.781.993.aaaa, ArtB, anne, DOrchard, Doug, Mike^mail, sicking 22:42:44 Lachy has joined #waf 23:02:03