20:03:15 RRSAgent has joined #ws-addr 20:03:15 logging to http://www.w3.org/2006/08/07-ws-addr-irc 20:03:23 +Anish 20:03:30 Agenda: http://lists.w3.org/Archives/Public/public-ws-addressing/2006Aug/0019.html 20:03:45 Meeting: Web Services Addressing 20:03:45 prasad has joined #ws-addr 20:03:49 Chair: Philippe 20:03:52 pauld has joined #ws-addr 20:03:54 +Prasad_Yendluri 20:04:12 +??P12 20:04:31 gpilz has joined #ws-addr 20:04:41 +Pete_Wenzel 20:05:02 marc has joined #ws-addr 20:05:14 TonyR has joined #ws-addr 20:05:25 +??P9 20:05:35 zakim, ??p9 is me 20:05:35 +TonyR; got it 20:07:09 SCRIBE: gpilz 20:07:20 TOPIC: Agenda 20:07:40 TOPIC: Minutes 20:07:49 RESOLUTION: minutes approved 20:07:57 TOPIC: Action Items 20:08:09 Long running action items around test cases. 20:08:15 No new issues 20:08:22 TOPIC: CR27 20:08:30 http://www.w3.org/2002/ws/addr/cr-issues/#cr27 20:09:10 Jonathan: Really an erratta issue although it appears on the crR list 20:09:52 Jonathan: I don't have a detailed proposal but it shouldn't be hard to fix the wording. 20:10:33 ACTION: Phillipe to propose errata to resolve CR27 20:10:51 TOPIC: CR29 20:10:57 http://www.w3.org/2006/05/ws-addr-errata.html 20:11:10 RESOLUTION: mark as done and close the issue 20:11:19 TOPIC: CR30 20:12:15 http://www.w3.org/2002/ws/addr/cr-issues/Overview.html#cr30 20:12:28 Anish: (provides overview of the issue) 20:13:51 +Paul_Downey 20:14:08 source mail: http://lists.w3.org/Archives/Public/public-ws-addressing/2006Jul/0020 20:14:20 Jonathan: If I had an existing WSDL 1.1 doc with an SOAP Action with a relative URI, I couldn't migrate this to WSDL 2.0? 20:14:54 Anish: You wouldn't be able to use that WSDL document with WS-Addressing. 20:15:13 pauld has joined #ws-addr 20:15:38 Jonathan: Is there any evidence that people specify SOAP Actions that are not absolute URIs? 20:15:46 rrsagent, where am i? 20:15:46 See http://www.w3.org/2006/08/07-ws-addr-irc#T20-15-46 20:15:56 Anish: BP states that a service shouldn't depend on the SOAP Action header. 20:16:26 Jonathan: If I have a WSDL I would just like to use it with addressing. If the SOAP Action is bogus, I'd just like to ignore it. 20:16:42 Phillipe: We'd have to change the SOAP binding to say we can ignore it? 20:16:48 q+ 20:17:04 ack gpilz 20:17:05 q+ 20:17:27 Gil: What was the reason behind mandating that they be the same? 20:17:45 Jonathan: They seem to be nearly identical concepts. So they should be the same. 20:17:52 ack pauld 20:18:24 Paul Downey: It makes sense to make them the same. Haven't two different values is just asking for trouble. 20:18:31 s/Haven't/Having/ 20:19:26 Paul Downey: What is the chance of this being a real problem? If you were adding addressing to an existing WSDL you'd probably be editing these values in any case. 20:19:30 -Mark_Little 20:19:47 Phillipe: Let's go with Anish's proposal and just declare this case invalid. 20:20:39 Phillipe: Is there any objection to disallowing the case where (missing detail) 20:20:59 All: (clarify exact case that should be disallowed) 20:21:45 Anish: Only a problem when addressing is engaged. 20:22:13 Phillipe: So when addressing is engaged and you have a SOAP Action which has a non-empty, non-absolute URI . . . that is an invalid WSDL. 20:22:26 Jonathan: (works through the logic and agrees its ok) 20:23:03 Anish: If there are WSDLs which are being used that don't explicitly engage addressing but addressing is enabled at run-time, this would result in invalid SOAP messages. 20:23:13 Anish: There is nothing we can say in the WSDL binding about this. 20:23:25 notes that currently many tools are deaf to SOAPAction in WSDL,, especially if the value is empty '' they tend to assert their own values. I'd also note that most SOAPActions used by tools are currently urn/uris anyway 20:24:16 Gil: That's still a poroblem. We don't want to lose sight of this problem. 20:24:40 Anish: We point this out in various specs; SOAP HTTP binding; WS-Addr SOAP Binding 20:25:23 Phillipe: If your implemention is well done it should catch this error at run time. 20:25:40 Anish: Not sure if its obvious to everybody. 20:26:19 Gil: Isn't BP going to be taking into account WS-Addr? 20:26:26 Phillipe: BP 1.1 and BP 2.0 20:26:45 Correction: BP 1.2 20:26:48 s/BP 1.1/BP 1.2/ 20:27:11 ACTION: Anish to raise an issue with WS-I BP 1.2 to make sure this error condition is caught. 20:27:34 Phillipe: We still have an issue in our WSDL Binding spec. 20:28:13 ACTION: Tony draft the necessary changes for a resolution to CR30 20:28:24 TOPIC: CR31 20:28:31 http://www.w3.org/2002/ws/addr/cr-issues/Overview.html#cr31 20:28:34 http://www.w3.org/2002/ws/addr/6/08/cr31.html 20:29:04 Arun: (reviews table) 20:32:24 Phillipe: How many people did not review the table? 20:32:44 Phillipe: Let's review the grey one's for now . . . . 20:33:30 Arun: (reviews grey cells) 20:33:52 can we combine row 1 and 2; they are the same 20:33:56 pauld has joined #ws-addr 20:34:18 Tony: I recall a lengthy discussion of this issue. We decided that it would be acceptable to return the fault along the backchannel before the connection closes. 20:34:57 q+ 20:35:08 Tony: Up until you closed the connection its fair to use the backchannel since its better for the requester to know something bad has happened. 20:35:16 q+ 20:35:19 ack anish 20:35:29 Anish: MAY or MUST? 20:35:31 Tony's timeline from SAP: http://www.flickr.com/photos/psd/9877189/ 20:35:33 Tony: MAY 20:35:34 ack jonathan 20:35:56 Phillipe: This logic can be applied to many of the grey boxes. 20:36:17 Anish: Rows 1 and 2 look the same. 20:36:21 Arun: Agreed. 20:36:35 Phillipe: Where do we document this. 20:37:06 David Illsley: I thought we agreed that it would be good to get this entire table into the spec. 20:37:22 (all): Back and forth on where the table should go. 20:38:48 Jonathan: We are talking about changes to the text of the table. 20:39:19 RESOLUTION: 1E and 2E should be ammended to include optional use of back-channel. 20:39:37 Arun: I'm tracking the changes as well. 20:40:20 Arun: (reviews cell 3D) 20:41:40 Phillipe: It seems that its better to deliver something on the back-channel rather than just dropping it. 20:41:45 Tony: I like A. 20:41:55 Jonathan: I thought A was wierd. 20:42:25 Jonathan: Can we delay a decision on this until my people get back to me on how we work? 20:43:02 Anish: Why shouldn't we allow the reciever to decide whether it wants to send it back on the back-channel or not? 20:43:09 q+ 20:43:30 Jonathan: That would work. Its consistent with 1E and 2E. 20:43:31 q+ 20:43:36 q+ 20:44:02 Tony: The reason I like 3D.a is that its more useful than a situation where the requester never gets a response. 20:44:18 (all): Back and forth on various aspects of this issue. 20:45:29 Phillipe: What we are proposing is a MAY. 20:46:10 Jonathan: It sounds like what we're talking about is a proposal where we leave it up to the implementation to figure out if wants to send the fault on the back-channel. 20:46:27 Phillipe: We are saying you may use the back-channel. 20:46:35 Tony: That's all you can reasonably say. 20:46:59 Phillipe: This is not the same a 3D.a. Its more in line with our resolution to 1E and 2E. 20:47:11 q- 20:47:20 Jonathan: I'd prefer if we have a proposed resolution on the table next week. 20:47:24 q- 20:47:39 ack anish 20:48:22 Anish: I like the resolution (MAY use back-channel). Its important to note that, if the reciever decides to use the back-channel, the sender may not be able to grok this. 20:48:45 Phillipe: Is our goal to put this table into the spec? 20:48:54 Tony: Yes. 20:49:08 Arun: Are we going to define any meta-rules to apply to the whole table? 20:49:30 Arun: I'm hearing a general rule that if the back-channel is still open a reciever MAY use it to send back a fault. 20:50:01 Marc: What is the scope of this rule? Does it cross transport boundaries (HTTP, FTP)? 20:50:11 Tony: If you can scream for help, scream. 20:50:32 Tony: I'd like to use any available means to tell the sender that they messed up and there is a problem. 20:50:54 Marc: Arun's table says if FaultTo can't be used then fall back to ReplyTo. 20:51:15 Tony: If you can't use the FaultTo or the ReplyTo then try to use the back-channel. 20:51:36 (all): back and forth around meta-rules 20:52:01 David: If there is a header you don't like, ignore it. 20:52:11 Phillipe: Move on to 5D. 20:52:48 Arun: (reviews 5D) 20:53:18 Tony: 5D has a non-anonymous ReplyTo. Subtly different but the effects are the same. 20:53:36 Phillipe: Follow our principal and specify "MAY use the back-channel". 20:54:06 Jonathan: It seems like a lot of the rest of the cases are going to break down the same way. What are implementers actually going to do? 20:54:12 q+ 20:54:16 Arun: Haven't got there yet. 20:54:48 Jonathan: Everyone is free to implement it either way. This is an interop problem. 20:55:08 Tony: The one thing you can test (like in 5D) is that you don't get the fault on the non-anonymous channel. 20:55:42 Arun: We will have to correlate test cases to these grey cells. We may be able to catogorize these as either optional or required tests. 20:55:51 Phillipe: These would be optional tests. 20:56:06 Phillipe: Is is still worth going through the rest of the grey cells? 20:56:13 Arun: Yes 20:57:38 TOPIC: CR32 20:58:14 David: My proposal is that the None URI should be treated as a special case and allowed where anonymous=required. 20:59:07 David: This relates to the recent issue about "alternate" anonymous URIs 20:59:19 Arun: Does this need a special case? 20:59:30 David: I'm not sure if this needs a special case or not. 20:59:43 Jonathan: I always thought if it more as a special case. 21:00:04 Tony: I thought of it as a special case, but None is still meets the requirements. 21:00:14 q? 21:00:30 ack anish 21:01:09 Arun: In terms of the table, 10E goes to option 'a' and 11D goes to (??) 21:02:07 (all): discussion on nature of "None" vs. "Anonymous" 21:02:13 s/(??)/option a/ 21:02:54 ack arun 21:03:02 ack agupta 21:03:10 Arun: I want to understand the impacts on 10E and 11D 21:03:29 Phillipe: Option 'a' in both cases 21:03:58 Jonathan: What David was suggesting is neither 'a' nor 'b'. 21:04:13 David: This table is predicated on my proposal; see 4D 21:06:00 (all): Clarifying David's proposal for CR32. 21:06:16 TonyR has left #ws-addr 21:06:26 -TonyR 21:06:30 David: If my proposal for CR32 did not go forward the current 10D would be incorrect. 21:06:54 Jonathan: 10D and 10E don't seem consistent then. 21:07:16 Jonathan: In 10E I would expect that a normal response would also be discarded. 21:07:34 David: Because anonymous is prohibited causes a fault to be generated. 21:08:12 Jonathan: The effects of A and B are the same in that nothing comes back. 21:08:30 Anish: In this case, why wouldn't we give the option to the reciever to send the fault back. 21:08:49 David: This is for 10E; None is a valid address to have in you ReplyTo 21:08:59 s/you/your/ 21:09:50 Anish: Anon is prohibited, FaultTo is anon, generate a fault, default to ReplyTo and drop the fault? 21:10:05 Anish: This seems out of line with our previous decisions. 21:10:32 David: This is in line with other SOAP bindings. 21:11:03 Anish & David: (back and forth on 10E) 21:11:45 Anish: In this case we are talking about how the fault it routed. To be consistent and allow for interop we should allow the reciever to attempt to get the fault back to the sender. 21:11:50 David: I take your point. 21:12:14 Phillipe: What do other peple think? 21:12:21 (all): deafening silence 21:12:31 Phillipe: David what do you think? 21:12:54 David: I think Anish's idea is more in line with the other grey boxes. 21:13:16 David: That still provides a reasonably clear statement that we can make 'at the top of the box'. 21:13:46 Marc: If we allow the responder to ignore None then we don't need to keep it. 21:14:05 Marc: The reason for None was for the sender to say 'I don't want any response back' 21:14:23 Marc: If we allow the reciever to ignore this and send back a fault, why specify 'None'? 21:14:49 Phillipe: A mistake has been made. We need a way to tell the sender that something is wrong rather than being silent. 21:14:50 q+ 21:15:08 Marc: We need to be consitent about our defaulting rules. 21:15:18 ack anish 21:15:33 Marc: If we default to ReplyTo and ReplyTo is 'None' we should honoer th 'None' semantics and not send anything. 21:16:10 Anish: In this case the sender has indicated that they want to see faults (FaultTo=anon). 21:16:38 Anish: The defaults are meaningful if the sender doesn't have a preference about where the want faults sent. 21:16:59 Anish: But in this case they were explicit (but wrong) about where they wanted faults sent. 21:17:13 Marc: I agree (for this case) but we need to be consistent. 21:17:36 Marc: Going back to previous question: We are doing somehting that is specific to anonymouse, correct? 21:18:37 Marc: Are we doing something that is specific to 'anonymous' or are we saying that, in general, if the reciever doesn't like FaulTo it should default to ReplyTo? 21:18:43 Anish: The former: 21:19:01 Marc: That's ok, but we need to be consistent. 21:19:31 David: The later (FaultTo defaults to ReplyTo) was the original proposal in the table. 21:20:16 Anish: I was saying something different: if FaultTo is specified we never default to ReplyTo . . . 21:20:27 David: That's untestable. 21:20:45 Arun: You may not be capable of sending a fault to a non-anon FaultTo 21:21:34 Anish: The initial sender created a message which was incorrect. If you strictly followed the rules the fault would never get to the sender. 21:21:55 Anish: If these things make it harder for the test suite, that's ok, as long as we promote interop. 21:22:09 Phillipe: If would be nicer to the users if they can find out when things go wrong. 21:23:32 Phillipe: General rule is try to use back-channel to send any faults. 21:23:45 David: This is directly opposite to what 6E says. 21:24:26 Anish: If the sender explicitly separates faults and replies this indicates that the sender . . . . 21:25:10 Phillipe: Don't drop faults on the floor. Try to send them through the back-channel if you can. Try to respect the FaultTo, but if that resulsts in doing nothing try to send the fault through the back-channel. 21:25:31 Arun: It would help me if someone could summarize the rules that should apply to the whole table. 21:26:30 Phillipe: We still have the rule "try to use FaultTo and if you can't fall back to ReplyTo". We are adding a rule that says "Rather than drop a fault on the floor, try to use the back-channel if it is still open". 21:26:57 Arun: By the second rule - we are overriding the semantics of 'None' URI. 21:27:21 Anish: I am pushing back on the idea of using ReplyTo when you can't use FaulTo 21:27:31 s/FaulTo/FaultTo/ 21:27:48 Phillipe: Your addition is that if you can't use FaulTo try to use the back-channel. 21:28:08 Phillipe: We have the rule that if you can't use FaulTo fall back to ReplyTo? 21:28:35 Anish: We have that rule, and we need to be consistent. 21:29:01 Anish: If ReplyTo is None and FaultTo is invalid, our current rules say drop the fault on the floor. 21:29:35 Phillipe: The new rule is don't drop faults on the floor if the back-channel is open. 21:29:47 Gil: But we have to reconcile this with 'None'. 21:31:01 Gil: Need to call out that we are overrding the behavior of 'None' in some cases. 21:31:09 Phillipe: I suppose so. 21:31:22 Phillipe: Can we adopt Anish's rule? 21:31:30 Gil: Can we get a clear statement of it? 21:32:16 Anish: If the FaultTo value is incorrect the reciever is going to generate a fault. At its choosing it may send this fault over the back-channel with the understading that the sender may not reciever or process this fault. 21:32:31 David: I'd like to get some mention of the ReplyTo in there, if possible. 21:32:54 David: Such as the sender may use the ReplyTo 21:33:23 Anish: You want the ability for the reciever to use either the back channel or the valid, non-anon ReplyTo? 21:33:28 David: Yes. 21:33:38 Gil: This sounds like an interop nightmare. 21:33:52 Arun: If the ReplyTo is None we ignore it? 21:34:05 Anish: Which case is this? 21:34:25 Jonathan has joined #ws-addr 21:34:55 Arun: The case you just mentioned. Invalid FaultTo; try to send via back-channel or, if there is a non-anon ReplyTO, use that? 21:35:11 Arun: Unless ReplyTo is None? 21:36:04 Arun: David's proposal does the right thing for ReplyTo equal anon, non-anon but doesn't do the right thing for None. 21:36:11 Phillipe: I don't get it. 21:36:25 Arun: This means treating None like anon. 21:36:54 David: I wanted an additional step where you can use ReplyTo if it is useful. 21:37:11 Anish: In your change, None is irrelevant? 21:38:21 David: FaultTo is invalid (1) try to use ReplyTo if it gets you somewhere useful (2) if not try to use the back channel 21:38:57 Phillipe: There are two proposals 21:39:08 Phillipe: In both cases FaulTo is invalid 21:39:22 Phillipe: According to Anish you try to send the fault on the back channel 21:39:33 Phillipe: According to David you look at ReplyTo 21:40:01 Phillipe: If it is non-anon or anon you try to use it, but if it is 'None' you then use the back-channel 21:40:12 Jonathan: But all of this is optional 21:40:20 Phillipe: Correct? David? 21:40:30 David: Yes. 21:40:36 q+ 21:41:03 ack gpilz 21:42:05 David: (more complex than Phillipe said - ReplyTo should be ignored in cases where it is anon and the WSDL says anon is not supported) 21:42:16 Gil: Anish, why don't you like using ReplyTo? 21:42:46 Anish: The sender explicity set a value for FaultTo. This indicates that they really don't want faults going to ReplyTo. 21:42:53 q+ 21:43:22 ack gpilz 21:44:06 Gil: (question for David - when doesn't ReplyTo 'get you anywhere useful')? 21:44:20 David: When is either 'None' or just plain invalid 21:44:56 Phillipe: Seems we are on the same page. Who likes what? 21:45:10 Anish: Results are the same except for 2 cases. 21:45:24 Phillipe: Non-anon ReplyTo is one, what's the other? 21:45:52 Anish: The only case is when ReplyTo is non-None, non-Anonymous and valid according to WSDL. 21:46:18 Phillipe: David, you want a MUST for using non-None, non-Anon ReplyTo 21:46:23 David: Yes. 21:46:36 Phillipe: But Jonathan seemed to want this optionality. 21:46:44 David: (ref 6E) 21:47:24 David: I think Microsoft can handle this. 21:48:00 Jonathan: I don't know. It seems like we're going to a lot of trouble to get a fault back by any means possible even though they probably can't handle it. 21:48:24 Jonathan: My perference would be to say "well there's no way of getting this fault back - so drop it". 21:48:55 Jonathan: Would like to leave open the option of taking a strict interpretation of what the sender told you they wanted. 21:49:06 Anish: That optionality is there. 21:49:19 Jonathan: I think I'm ok, but I need to see the final proposal. 21:49:26 Phillipe: Sense of group? 21:49:34 Phillipe: Jonathan are you ok with both? 21:49:44 Jonathan: Like both, but prefer Anish's. 21:50:08 Marc: I prefer Anish's. It will be a lot easier to write down. 21:50:41 Gil: I could live with either, but prefer Anish's. 21:50:55 Phillipe: David can you live with Anish's approach. 21:51:10 David: Probably, but I don't want to commit to anything today. 21:51:24 Phillipe: Can you regenerate the table based on Anish's prinicipal? 21:51:27 Arun: Yes. 21:51:39 Phillipe: We'll come back to the table next week and look at the results. 21:51:53 s/Jonathan: Like both/Jonathan: Not thrilled with either/ 21:52:04 Arun: I can pick the words from the chat session. 21:52:06 (2:32:48 PM) gpilz: Anish: If the FaultTo value is incorrect the reciever is going to generate a fault. At its choosing it may send this fault over the back-channel with the understading that the sender may not reciever or process this fault. 21:53:10 Phillipe: Going back to CR32, where do we stand? 21:53:32 David: It sounds to me like no one disagrees with the principal behind the proposal. 21:53:51 Anish: The proposal is to treat None as allowed by wsaw:Anonymous? 21:53:55 David: Yes. 21:54:05 Anish: Why do you think this is right? 21:54:17 Anish: When you say anon=required it means you want a back-channel. 21:54:33 Anish: If you have None, you can't send a response anywhere. 21:55:01 ACTION: Arun to regenerate his table based on Anish's principle 21:55:02 David: My interpretation was that anon=required meant that the reciever was not being called upon to open a new HTTP connection. 21:55:18 David: None satisfies this requirement. 21:55:43 David: 'None' is a special case to begin with, why would it be limited by anon=required? 21:55:58 Anish: We have slightly different interpetations of anon=required. 21:56:37 Anish: You think it means 'I won't open a separate HTTP connection' I think it means 'I will use the same back-channel' 21:57:22 David: I agree that your understanding is in line with what the spec says today. It is not in line with my understanding up until we began interop testing . . . 21:57:54 Anish: It seems like you want finer granularity on wsaw:Anonymous that we currently have. 21:58:22 Anish: It seems like you want WSDL markers that allow you to talk aout ReplyTo and FaultTo independently of one another. 21:59:12 Anish: For example, you would like to specify in WSDL that the ReplyTo should be anon and not choke on the case where FaulTo=None 21:59:33 David: I'm not asking for finer granularity (missed the rest) 22:00:21 Phillipe: WSDL says anonymous required but still you set the FaulTo to None. "I know I'm supposed to use anonymous but I really don't want to see any faults". 22:01:11 it's past 3pm, need to go. 22:01:15 Jonathan: My conception of wsaw:Anonymous was about whether the service would be required to open a separate connection for response messages. None means no message so its ok. 22:01:23 -agupta 22:01:28 Jonathan: (agrees with David) 22:03:08 -Marc_Hadley 22:03:19 Phillipe: We'll resume this discussion next week. 22:03:53 Anish: Can we consider CR33 ASAP? 22:04:13 Phillipe: Is CR33 related to CR32? 22:04:19 David: It seems like. 22:04:36 Phillipe: Lets tackle CR32, CR33, then go back to CR31 22:04:42 -Jonathan_Marsh 22:04:43 -Anish 22:04:45 -David_Illsley 22:04:45 -Pete_Wenzel 22:04:46 -Gilbert_Pilz 22:04:47 -Paul_Knight 22:04:48 -Prasad_Yendluri 22:04:49 -Plh 22:05:27 rrsagent, make logs public-visible 22:05:51 zakim, who's here? 22:05:51 On the phone I see ??P12, Paul_Downey 22:05:52 On IRC I see Jonathan, marc, gpilz, prasad, RRSAgent, Zakim, anish, PaulKnight, agupta, David_Illsley, plh 22:06:02 zakim, drop ??p12 22:06:02 ??P12 is being disconnected 22:06:04 -??P12 22:06:09 zakim, drop Paul_Downey 22:06:09 Paul_Downey is being disconnected 22:06:11 WS_AddrWG()4:00PM has ended 22:06:12 Attendees were Mark_Little, Plh, Paul_Knight, David_Illsley, agupta, Jonathan_Marsh, Gilbert_Pilz, Marc_Hadley, Anish, Prasad_Yendluri, Pete_Wenzel, TonyR, Paul_Downey 22:06:15 zakim, bye 22:06:15 Zakim has left #ws-addr 22:06:22 rrsagent, generate minutes 22:06:22 I have made the request to generate http://www.w3.org/2006/08/07-ws-addr-minutes.html plh 22:06:42 gpilz has left #ws-addr 23:24:37 agupta has left #ws-addr