19:29:50 RRSAgent has joined #ws-ra 19:29:50 logging to http://www.w3.org/2009/10/27-ws-ra-irc 19:29:52 RRSAgent, make logs public 19:29:52 Zakim has joined #ws-ra 19:29:54 Zakim, this will be WSRA 19:29:54 ok, trackbot, I see WS_WSRA()3:30PM already started 19:29:55 Meeting: Web Services Resource Access Working Group Teleconference 19:29:55 Date: 27 October 2009 19:30:07 chair: Bob Freund 19:30:34 note that w3c list servers are jammed 19:30:40 gpilz has joined #ws-ra 19:30:46 Wi has joined #ws-ra 19:30:50 MartinC has joined #ws-ra 19:31:01 Tom_Rutt has joined #ws-ra 19:31:10 +[Microsoft] 19:31:11 - +91.98.49.99.aaaa 19:31:22 Bob- I will be a few minutes late joining the call today 19:31:34 +Wu_Chou 19:31:35 + +1.703.860.aabb 19:31:40 + +984999aacc 19:31:40 + +1.408.642.aadd 19:31:58 zakim, 408.642.aadd is gpilz 19:31:58 sorry, gpilz, I do not recognize a party named '408.642.aadd' 19:32:09 +Tom_Rutt 19:32:09 zakim, who is on? 19:32:09 I don't understand your question, dug. 19:32:12 zakim, add is gpilz 19:32:12 sorry, gpilz, I do not recognize a party named 'add' 19:32:24 asir has joined #ws-ra 19:32:27 Ram has joined #ws-ra 19:32:27 Ashok has joined #ws-ra 19:32:27 zakim, open the pod bay door 19:32:27 I don't understand 'open the pod bay door', gpilz 19:32:33 LOL 19:32:42 zakim, make love 19:32:42 I don't understand 'make love', dug 19:32:43 +fmaciel 19:32:50 zakim, "aadd" is gpilz 19:32:50 sorry, gpilz, I do not recognize a party named '"aadd"' 19:33:01 Wu has joined #ws-ra 19:33:11 zakim, +1.408.642.add is gpilz 19:33:11 sorry, gpilz, I do not recognize a party named '+1.408.642.add' 19:33:13 + +03531498aaee 19:33:23 zakim, 642 is gpilz 19:33:23 sorry, dug, I do not recognize a party named '642' 19:33:37

zakim, aadd is gpilz 19:33:37 +gpilz; got it 19:33:42 +Ashok_Malhotra 19:33:45 whose kid is talking? :-) 19:34:09 Yves???? 19:34:10 zakim, aaee is MartinC 19:34:10 +MartinC; got it 19:34:18 +Yves 19:34:30 yves - can you unblock me? 129.33.49.251 19:34:51 dug, I'll try 19:34:54 thanks 19:35:43 you're banned from two mirrors, good job ;) 19:36:07 LOL when i do something I go all out! 19:37:19 scribe: gpilz 19:37:37 topic: agenda 19:37:42 bob: some probs getting it out 19:37:47 ... everyone get it? 19:37:57 (no reply) 19:37:59 Sreed has joined #ws-ra 19:38:06 bob: i'll fix minutes later 19:38:19 topic: minutes 19:38:26 bob: minutes came out fairly recently 19:38:33 ... anybody need more time for 10/20? 19:38:35 dug, done (will be temporary, I fear) 19:38:36 (no reply) 19:38:52 q+ 19:38:55 thanks - seems ok for now 19:38:57 resolution: minutes from 10/20 accepted by UC 19:39:04 topic: F2F logistics 19:41:12 bob: Fredrick Hirsh contacted us about XPath-subset for fragment specification 19:41:38 q+ to ask a question 19:41:53 q- 19:42:09 ... they (XML Security WG) would like to caucus on 11/5 19:42:13 ack asir 19:42:13 asir, you wanted to ask a question 19:42:16 Vikas has joined #ws-ra 19:42:25 +JeffM 19:43:01 topic: new issues 19:43:04 q+ 19:43:07 bob: 8 new issues 19:43:13 q- 19:43:33 .. any objection to accepting all new issues and assigning ownership to the raiser? 19:43:36 (no reply) 19:43:43 resolution: new issues accepted 19:43:51 topic: issues with proposals 19:44:24 topic: 7586, 7588, 7828 19:44:25 http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Oct/0044.html 19:44:37 jeffm has joined #ws-ra 19:44:43 q+ 19:44:52 ack ram 19:44:56 ram: I agree with this 19:45:04 bob: any objection to accepting this proposal 19:45:22 resolution: 7586, 7588, 7828 resolved as per above proposal 19:45:57 topic: 7911 19:46:08 q+ 19:46:14 ack gpi 19:46:34 yves: need some more time 19:46:47 gil: proposing CWNA, why would you need more time? 19:47:09 bob: any objections to CWNA? 19:47:43 q+ 19:47:48 yves: (reviews email dialog) 19:48:02 asoldano has joined #ws-ra 19:48:04 ... if we use MAY, that would be enough 19:48:28 bob: are you proposing to say something like "they MAY"? 19:48:32 yves: yes 19:48:46 bob: any objection to it being a generic SOAP sender fault 19:49:03 ... any objections? 19:49:03 ack dug 19:49:08 doug: I object 19:49:11 + +039331574aaff 19:49:18 ... as you know, I like consitency 19:49:29 ... I agree that a generic SOAP Sender fault is the appropriate thing 19:49:41 ... but why are we focusing on this particular error? 19:49:48 ... there are lots of things that could be wrong 19:49:51 q+ 19:49:55 ... why call out this particular problem 19:50:01 q+ 19:50:02 q- 19:50:11 ... readers will wonder what is special about this condition 19:50:25 ... bad thing to imply that there is something special about this error condition 19:50:37 ... this is covered by a generic SOAP fault 19:50:45 bob: I want to move things along here 19:50:51 ... limit to 2 times in the queue 19:50:56 ack tom 19:51:00 q+ 19:51:01 tom: I was going to say the same thing 19:51:05 ... SOAP covers this 19:51:08 ack yves 19:51:22 yves: the SOAP spec doesn't cover this at all - verbs etc. not covered 19:51:38 ... we are defining in two places the way the receiver should process the message, so this is an issue 19:51:45 I apologize for being late, forgot about the timezone change because of daylight saving 19:52:04 ack ram 19:52:04 ... you can claim there is a requirement on the SENDER, but there is no corresponding requirement on the RECEIVER 19:52:20 ram: fundamental problem is the WG has introduced this new wrapper 19:52:28 ... doesn't change the semantics of the protocol 19:52:44 ... dummy wrapper is functionally insignificant 19:52:58 ... now we have to worry about a mismatch 19:53:36 ... I saw one of Doug's email exchanges; the semantics have to be consistent 19:53:43 bob: anybody else? 19:53:52 (no reply) 19:54:07 resolution: 7911 tabled for further consideration 19:54:11 Ram has joined #ws-ra 19:54:19 i have a problem with a MAY 19:54:23 completely worthless 19:54:27 me too 19:54:37 Proposal: “If the semantics (as defined by this specification) of the first child element of the SOAP Body [Body] of messages does not match the semantics (as defined by this specification) of the message as uniquely identified by the WS-Addressing [Action] message addressing property contained in the SOAP Header of those messages, the receiver MUST generate a ActionAndWrapperMismatch fault” 19:54:37 bob: does anyone have a problem with "MAY generate a sender fault" 19:54:38 Zakim, +039331574aaff is asoldano 19:54:38 +asoldano; got it 19:54:39 ok so my proposal will have a MUST then 19:54:51 LOL yves 19:54:52 q+ 19:54:56 ;) 19:54:56 (misc people have problem with "MAY generate") 19:55:13 ack ram 19:55:20 ram: let's not worry about MUST or MAY 19:55:30 ... just focus on the semantics 19:55:34 q+ 19:55:50 ... if we agree to the first part, we can work on the MAY, SHOULD, MUST 19:56:08 ack gp 19:56:23 q+ 19:56:32 gil: I don't agree with the semantics 19:56:34 q+ 19:56:53 Katy has joined #ws-ra 19:56:54 ... don't see why this case, out of all the possible error cases, should be singled out for special treatment 19:57:19 ack ram 19:57:23 ack tom 19:57:24 LOL tom 19:57:33 + +0125660aagg 19:57:53 I've put the backhoe through the cable (actually a roto-tiller, but the effect was the same) 19:58:47 topic: 7015 19:59:02 bob: issue has been around since Redwood Shores F2F 19:59:10 ... proposal is contained in the issue itself 19:59:24 ... is there a Microsoft rep willing to speak to this 19:59:32 ram: won't repeat what is already there 19:59:48 ... 7911 is a resolution to this issue 20:00:00 ... unless we can resolve 7911 we can't resolve this issue 20:00:15 ... but there is another way to resolve this 20:00:20 bob: you have a new proposal? 20:00:23 ram: yes . . . . 20:00:54 Ram has joined #ws-ra 20:01:04 Proposal: “If the semantics (as defined by this specification) of the first child element of the SOAP Body [Body] of messages does not match the semantics (as defined by this specification) of the message as uniquely identified by the WS-Addressing [Action] message addressing property contained in the SOAP Header of those messages, the receiver MUST generate a Server fault” 20:01:35 ram: I understand there are some reservations against the use of MUST 20:01:47 ... the semantics of the wrapper element and the action URI must be the same 20:01:59 yes 20:02:01 bob: this looks like the proposal for 7911 20:02:08 ... omnibus proposal 20:02:13 q+ 20:02:32 bob: any objections? 20:02:39 gil: I object 20:02:48 doug: I don't see what this has to do with 7015 20:03:04 ... I thought the problem was in having a separate wrapper per operation 20:03:15 bob: if you read the last paragraph of the issue the connection is clear 20:03:19 q+ 20:03:29 doug: I'm not sure I see it, can you point out the sentence 20:04:02 "The decision here, to require that the name of the first child element match the action, makes ambiguous the role of the first child element in defining the verb used for routing messages. Implementers could incorrectly dispatch using the first child element as the verb, rather than support the WS-Addressing action as the verb. Replication of information always decreases interoperability, and this continued polarization has to stop if interoperability is to be 20:04:14 bob: ram's proposal defines what should happen if there is a mismatch 20:04:28 doug: the issue in front of here is that there may be a mismatch 20:04:35 ... this puts us back to 7911 20:04:51 ... the specification is quite clear on what [Action], [Body], should be 20:05:01 ... not clear what else we need to specify 20:05:09 ... all other SOAP specs do it this way 20:05:10 +1 20:05:13 q+ 20:05:16 ack dug 20:05:18 ... propose we CWNA 20:06:36 Proposal 2: "The semantics (as defined by this specification) of the first child element of the SOAP Body [Body] of messages MUST match the semantics (as defined by this specification) of the message as uniquely identified by the WS-Addressing [Action] message addressing property contained in the SOAP Header of those messages". 20:06:41 gil: thinks CWNA 20:06:48 q+ 20:06:51 bob: any objection to CWNA? 20:06:55 yves: I object 20:06:56 ack gpi 20:07:05 ram: would like to agree to something and move on 20:07:14 ... see above proposal 20:08:10 bob: any objection to the above? 20:08:20 "The Get request message MUST be of the following form:" 20:08:22 doug: I object; this is already in the spec 20:08:27 ... see above 20:08:33 ... why are we repeating this MUST? 20:08:51 this MUST is a sender requirement, not a receiver requirement 20:08:57 hey: i have a modest proposal that maybe we could all agree to in the spirit of compromise - Close with no action 20:08:57 ram: doesn't that seem to be a shorter way of saying what you said above? 20:09:12 oops (bob said above) 20:09:17 ram: no, I don't agree 20:09:27 q+ 20:09:28 ... doesn't hurt to add the statement we want 20:09:33 ack ram 20:09:36 ... helps people understand better 20:09:38 q+ 20:09:43 bob: ram, not clear on what you said 20:10:07 +1 yves - CWNA and move on :-) 20:10:10 q+ 20:10:18 ram: the group has different opinions about whether we need the extra statement 20:10:32 ack wu 20:10:42 dug, I just said move on 20:10:45 ... the statement helps those of use that don't understand the use of separate [Action]/[Body] 20:10:50 wu: two issues are related 20:10:56 ... we tabled 7911 20:10:58 MAY move on :-) 20:11:00 ... we should table this 20:11:16 bob: there was no objection to discussing this issue when we discussed agenda 20:11:19 ... let's continue 20:12:16 ... is there anyone who would accept Ram's first proposal 20:12:19 wu: which one? 20:12:42 q+ 20:12:42 bob: (reads first proposal - see above) 20:13:11 ... (reads second proposal - see above) 20:13:27 ... third proposal is CWNA 20:13:37 ack tom 20:13:39 tom: I support CWNA 20:13:48 ... it's already covered in the existing spec 20:13:54 q+ 20:13:56 ... it's unnecessary to add this extra statement 20:13:57 MartinC has joined #ws-ra 20:13:59 ack jeff 20:14:04 ... the requirment is already there 20:14:14 jeffm: ram, what changes with your proposal? 20:14:25 hum, SOAP explicitely say that receivers may check the schema validity but it is not required (while the spec says that the sender must produce something based on the schema) 20:14:34 ... is something that was legal is now illegal, or this there something that was illegal that is now legal 20:14:42 ... if nothing changes, this is a no-op 20:14:43 ram: 20:15:06 ram: first of all, the proposal really helps that there is a consitency of understanding 20:15:18 ... if it's not there there is possibility, 20:15:34 ... some implementation rely on Action others on Body/child 20:15:44 ... it's not just me that has this problem, yves agreess 20:15:50 jeffm: that's not my question 20:15:59 ... what specific messages would become illegal? 20:16:11 ram: my proposal just re-states what the spec is trying to say 20:16:20 jeffm: that's not a compelling argument 20:16:38 ram: let's just put this to rest and add this harmless text and move on 20:16:48 bob: doug quoted the text that now says this 20:17:00 ... is your proposal an editorial moditication on this text? 20:17:06 ram: yes, it doesn't change anything 20:17:11 "The Get request message MUST be of the following form:" 20:17:25 Proposal 2: The semantics (as defined by this specification) of the first child element of the SOAP Body [Body] of messages MUST match the semantics (as defined by this specification) of the message as uniquely identified by the WS-Addressing [Action] message addressing property contained in the SOAP Header of those messages. 20:17:54 doug: I don't see how there could possibly be any confusion around this 20:18:03 q+ 20:18:14 Proposal 2 makes the intent clearer. 20:18:26 bob: is there any difference between these two? 20:18:30 Ram did not propose a replacement 20:18:30 doug: yes! 20:18:50 ack katy 20:18:51 ... this decreases interop because it only talks about [Action] and [Body] 20:19:05 katy: I think this is crazy and gives spec writing a bad name 20:19:21 there is a difference between putting requirement on the message form (ie: a sender requirement), and a receiver requirement of ensuring that the message is correct or not 20:19:22 ... I'm very uncomfortable with special casing WS-Transfer 20:19:23 ack ram 20:19:29 ram: I think we can all agree on one thing 20:19:39 ... we all want to read the spec and come out with the same interpretation 20:19:53 ... it helps us if we add that one line and makes things clearer for us 20:20:05 q+ 20:20:07 ... let's move forward and just add this one, harmless sentence 20:20:22 ack aso 20:20:28 in SOAP, it was explicitely said that schema validity checking was optional, because of performance, and because there are other ways to verify inputs 20:20:29 What other interpretation could there be? 20:20:31 ack gp 20:20:31 alession: we don't need this sentence 20:21:02 ack wu 20:21:10 gil: what's in the spec now is easier to understand than Ram's proposal 20:21:19 wu: we have similar questions to Ram 20:21:29 ... but ask the question "what do we do if they are not the same" 20:21:34 ... wording can be refined 20:21:44 ... suggest Ram work with people to refine the text 20:21:57 all specs 20:21:58 ? 20:22:23 bob: recognize yves to voice IRC comment 20:22:44 yves: would be willing to work with Doug and Gil to resolve this w/out taking up WG time 20:22:54 ... requirement is currently on SENDER 20:23:19 q+ 20:23:20 ... but leaves open the issue of what a RECEIVER is required to do 20:23:48 doug: I'm a little confused 20:24:08 ... if there is this much confusion about [Action] and [Body], does this apply to all specs 20:24:16 ram: I can only speak for myself and my product team 20:24:24 ... for us the problem is in WS-Transfer 20:25:02 doug: it seems to me that this has to cut across all the other specs since they all do things the same way (individual and separate [Action] and [Body]/child) 20:25:07 ... I'm confused by the confusion 20:25:15 ... what possible other interpretation could there be? 20:25:49 ram: this goes back to what this WG has done over the last several months 20:26:10 ... if you look at this from the perspective of someone who has previously implemented the Member Submission of WS-T 20:26:21 ... they have to wonder why these wrappers have added 20:26:29 ... it doesn't improve the protocol in any way 20:26:49 ... we owe an explantion to these people about why we introduced this wrapper and what it's semantics are 20:27:09 ... because we introduced ... raise a fundamental question 20:27:16 ... why is this wrapper there in the first place? 20:27:27 doug: you didn't answer my question 20:27:32 ... you said there is confusion 20:27:47 ... you said that there could be two outcomes? 20:27:51 ... what is the second outcome? 20:28:06 ram: my point is from the context of people who aren't used to this wrapper 20:28:12 doug: you are claiming there is confusion 20:28:22 ... therefore there must be two possible outcomes 20:28:32 ... please tell me what this second outcome could be? 20:28:40 ram: just need to make things clear 20:28:46 bob: everyone has had their turn 20:28:48 q+ 20:28:53 q- 20:29:10 ... 3 proposals on the table 20:29:18 ... let's see if we can inch closer 20:29:33 I am willing to go with just proposal 2. 20:29:35 ... my sense of the group is that proposal 1 had a substantially strong rejection rate 20:29:46 ... proposal 2 - people didn't understand what it changed 20:29:56 ... proposal 3 (CWNA) - changes nothing 20:30:03 ... proposal 1 seems like a non-starter 20:30:10 q+ 20:30:17 ... between 2 & 3, is there something we can put together? 20:30:31 q- 20:30:36 q+ 20:30:43 tom: I think it's a waste of ink and space 20:30:46 q+ 20:30:52 ... CWNA keeps things the same on the wire 20:30:55 ack tom 20:30:55 ... why bother? 20:31:01 ack katy 20:31:10 -JeffM 20:31:10 katy: part of the job of the WG is to make sure the specs align with each other 20:31:20 ... if we add this text, we have to add it to all 5 specs 20:31:24 q+ 20:31:26 ... think CWNA 20:31:34 q- 20:31:42 bob: katy, is there a variation of 2 that would be more attractive to you? 20:31:43 less is more :-0 20:31:46 katy: not really 20:31:52 ... this text is just not needed 20:31:58 ... hasn't been needed in the past 20:32:13 ram: if the concern is that this text appear in all specs 20:32:21 ... that's not my intent, WS-T only 20:32:26 bob: why just WS-T? 20:32:36 ram: because we added wrappers to WS-T 20:32:46 because transfer readers can't read specs :-) 20:32:59 bob: why isn't this a problem in the other specs? 20:33:04 ... it wasn't in MEX at one time 20:33:13 ram: problem is that we've added wrappers 20:33:26 q+ 20:33:31 q+ 20:33:43 Transfer is based on the REST model where verbs are not part of messages 20:33:43 ... WS-T aligns with HTTP 20:33:46 ack ram 20:33:48 ... it doesn't need wrappers 20:33:56 ack katy 20:34:08 katy: we implemented the previous version of MEX without wrappers 20:34:11 ack gpi 20:34:53 gil: ram is re-arguing a closed issue - wrappers have been added to WS-T 20:35:30 bob: seems to come down to proposal 2 and proposal 3 20:35:35 MartinC has joined #ws-ra 20:35:37 ... jeff asked, what does this change? 20:35:52 - +984999aacc 20:35:55 ... is there any modification to proposal 2 that would make people support it more? 20:36:01 ram: that remains to be seen 20:36:10 bob: this issue has been marinating a long time 20:36:13 q+ 20:36:16 q+ 20:36:21 q- 20:36:25 ... trying to figure out if there is a constructive resolution that people can agree on 20:36:32 I could go for a nice steak 20:36:41 ... since we have established that proposal 2 doesn't change wire behavior 20:36:46