19:53:10 RRSAgent has joined #ws-addr 19:53:10 logging to http://www.w3.org/2006/10/09-ws-addr-irc 19:53:33 zakim, this will be ws_addrwg 19:53:33 ok, bob; I see WS_AddrWG()4:00PM scheduled to start in 7 minutes 19:53:53 meeting: WS-Addressing WG Teleconference 19:53:59 chair: Bob Freund 19:54:15 TRutt_ has joined #ws-addr 19:56:36 agenda: http://lists.w3.org/Archives/Public/public-ws-addressing/2006Oct/0040.html 19:57:06 regrets+ paco 19:57:39 regrets+ pauld 19:58:00 WS_AddrWG()4:00PM has now started 19:58:06 regrets+ anish 19:58:08 +Mark_Little 19:58:37 TonyR has joined #ws-addr 19:58:45 +Bob_Freund 19:59:11 +Gilbert_Pilz 19:59:21 prasad has joined #ws-Addr 19:59:26 MrGoodner has joined #ws-addr 19:59:40 gpilz has joined #ws-addr 19:59:42 +??P3 19:59:53 zakim, ??p3 is me 19:59:53 +TonyR; got it 20:00:35 +Tom_Rutt 20:01:12 +??P5 20:01:42 scribe: Tom Rutt 20:01:52 zakim, ??P5 is me 20:01:52 +MrGoodner; got it 20:02:05 scribenick: TRutt_ 20:02:26 +Dave_Hull 20:02:50 +Prasad_Yendluri 20:03:00 +[IPcaller] 20:03:09 yinleng has joined #ws-addr 20:03:24 Katy has joined #ws-addr 20:03:25 dhull has joined #ws-addr 20:03:25 zakim IPcaller is katy 20:03:46 zakim, IPcaller is katy 20:03:46 +katy; got it 20:05:06 +??P9 20:05:20 PaulKnight has joined #ws-addr 20:05:29 zakim, ??p9 is me 20:05:29 +yinleng; got it 20:05:56 +Paul_Knight 20:06:28 Topic: Roll Call 20:06:35 Tom agreed to be scribe 20:06:42 Topic Agenda Review 20:06:56 s/Topic/Topic:/ 20:08:44 agreed to add discussion on "what is the problem 20:08:50 Agenda accepted. 20:09:07 Topic: minutes 10/02/06 20:09:26 Prasad: was attendance updated 20:09:35 Bob: yes it was 20:09:59 No objection, minutes are approved with Prasad on roll 20:10:05 Topic: Action Items 20:10:23 http://lists.w3.org/Archives/Public/public-ws-addressing/2006Oct/0040.html 20:11:29 http://lists.w3.org/Archives/Public/public-ws-addressing/2006Oct/0003 20:11:47 http://lists.w3.org/Archives/Public/public-ws-addressing/2006Oct/att-0003/cr31.html 20:12:52 Tony: Explained the new rules he proposed in http://lists.w3.org/Archives/Public/public-ws-addressing/2006Oct/att-0003/cr31.html 20:13:06 q+ to ask about none and "required" 20:14:10 Tony: would it be better to replace grey box text replaced with a ref to rule 5 20:14:14 ack dhull 20:14:14 dhull, you wanted to ask about none and "required" 20:14:29 all agreed to replace grey text with pointer to rule 5 20:15:33 Bob: can we give tony action item to do the next bit 20:15:42 action: Tony do the next bit 20:15:52 ACTION: Tony to complete his proposal on cr31 20:16:48 Topic: CR33 proposal 20:17:11 Bob: due to absence of Anish and Paco, we will defer discussion of proposal 5 framework. 20:17:24 http://lists.w3.org/Archives/Public/public-ws-addressing/2006Oct/0006.html 20:17:28 Topic: What Problem we are trying to solve 20:18:00 s/Topic: Action Items/Topic: CR31/ 20:18:26 s/CR31/CR33/ 20:18:34 q+ 20:19:06 ack dhull 20:19:08 Bob: Is there agreement on my problem statement. 20:19:42 Dave H: the main issue of cr33 is not with rm, but it is how to advertise what is understood beyond wsa:anon or wsa:none. 20:20:34 Dave H: asynch task force showed need to advertise other capabilities beyond anon. 20:20:53 -Mark_Little 20:21:04 Dave H: wsrm has their own uri, and we can expect others to come up with their own magic uris which they would want to advertise. 20:23:24 Dave H: in strrict sense we are not standing in way, but could clarify for guidance. Provide a marker that enables talking about particular kind of endpoint. We do not have anything that expressive now. Optional does not mean shutting out some other kind of magic uri. We should at least clarify what optional means here 20:23:41 q+ 20:23:59 ack mrg 20:24:52 sounds like a separate issue 20:25:07 Marc G: RM took advantage of advice added by request of RM TC. Some think this was bad advice, independent on how we resolve cr33, I do not think it is a good idea to have other specs define such URIs like wsrm did. 20:25:40 q+ to talk a bit about layering (then have to leave for a bit) 20:26:05 thinks RM is the only spec that has walked through the magic door 20:26:18 Bob: Discussion points: How are these two endpoints interacting, what information they are exchaning for these exchanges, is there issue with mechanism within the specification. 20:26:36 ack dhull 20:26:36 dhull, you wanted to talk a bit about layering (then have to leave for a bit) 20:27:29 q+ 20:27:32 Dave H: perhaps we should raise it as a separate issue , outside cr33, if we do not want other special uris. 20:28:23 Dave H: in some layering cases, the reply to is an application layer thing. Can give this special mechanism a URI. 20:28:29 q+ 20:29:11 ack tonyr 20:29:13 Dave H: there is a separate issue, however CR33 is still an issue. 20:29:39 -Dave_Hull 20:30:46 Tony R: Some things annoy me. The layering irritates me the most. If the back channel is used to send information back, it is a request response, it is not one way. If they do not have queued response to come back on back channel, they send a pending. They should be using anonymous in reply to and all this happens at a layer higher than addressing. 20:31:04 ack trutt 20:32:28 http://lists.w3.org/Archives/Public/public-ws-addressing/2006Oct/0042.html 20:33:07 Tom: Paul Fremantle from wsrm tc has proposed that the wsa:anonymous behaviour for replyTo applies for non failure cases, the makeConnection alternative would come in as a failure recovery mechanism based on wsrm. 20:33:28 q+ 20:33:47 ack gpil 20:33:54 Bob: has anyone a coment on the above mail from Marc Hadley 20:36:09 Gil: I have a problem about using generic soap headers. What Doug is trying to do with this special URI is to leverage the behavour of soap stacks to change replyTo to return address. ON server side, request comes in, pass up to applicaiton, then a response goes out, to make sure the correct replyTo is used, the wsrm layer has to know that message b is the response to message a. The RM layer never has enough knowledge to know which message is a respons 20:36:39 Bob: does Marc H provide new kind of relationships. 20:37:02 q+ 20:37:16 q+ 20:37:58 ack katy 20:38:01 Gil: on step 4 who puts in that relationship type initial reaues, if it is higher level, then the higher level had to understand it is using RM beneith it. IF not higher level then it is rm layer, it would have to understand that the message going out on step 4 is in response to the request in step 1. How does rm layer have this informaion? 20:38:39 q+ 20:39:29 Katy: The client identifying info is passed back on response. Some stated refParms could be used. If we do not need a separate URI for RM it make things easier. If the response does echo the Client id there could be a problem. 20:39:32 ack mrg 20:40:46 Marc G: why does Gil see ReplyTo not troubling, but using relationship is troubling. 20:41:55 ack gpil 20:42:03 Gil: Somewhere up the stack the replyTo gets translated into the to for the response. In the to there is already the correlator parameter. Having another relationship implies higher layer extra processing. 20:42:49 Gil: Or the rm layer has to correlate outgoing response to which other message. 20:43:13 q+ 20:43:45 q+ 20:44:19 q- 20:44:33 q+ 20:44:51 ack mrg 20:45:08 Gil: whenever we go away from the responder copying the reply to to construct the to for the response, we have to ask what endity will do that extra processing 20:45:39 Above, I meant "If the response does NOT echo the Client id there could be a problem." an important 'not' was missed :o) 20:45:57 q+ 20:47:30 Gil: at transport layer, when sending message, you look at to address for response, if none, you put it on floor, if anon you send it on the back channel. Additional handlers could be put into place at that point. 20:47:42 q+ 20:47:59 ack tonyr 20:48:11 q+ 20:49:28 Tony R: conjunction between incoming and outgoing message is confused. It is easy to code this. Keeping track that the message that went in, is correlated to response is not difficult. It is back channel of message that is already going in. 20:50:14 ack gpilz 20:51:02 Gil: correlation of request and response is not difficult, however it depends on where you are on the protocol stack. 20:51:10 ack trutt 20:52:01 Dug has joined #ws-addr 20:53:51 Tom: we could use wsa:anon for reply to with a refParm for a queueID which only is used by rm when it cannot directly send the response on the primary backchannel of the request. This would view the make Connection mechanism as being implemented by the wsrm layer, the queues are managed in that layer. 20:54:52 Bob : does the Mark Hadley email provide a viable alternative for Use by RM 20:55:26 +[IBM] 20:55:55 zakim, ibm is dug 20:55:55 +dug; got it 20:55:57 +Chris_Ferris 20:55:58 q+ 20:56:28 cferris has joined #ws-addr 20:56:56 q+ 20:56:59 Tom: I need more time to look at Marc H proposal 20:57:10 ack trutt 20:58:08 q+ 20:58:28 ack dug 20:58:37 q- 20:58:45 Tom: I think we need time to discuss other alternatives, using refParm for reliability queueID to use with makeConnection. 20:59:36 Doug D: WSRM has some non typical request response cases. These responses are brand new messages being sent out. 21:01:04 Doug D: with respect to using refParms, a sending endpoing only has to look at to values, they are not for their use. If you look at refParms, it is a drastic change. Asking it to look at outgoing headers is going beyond the scope. This is changing the processing model 21:01:08 q+ 21:02:22 ack trutt 21:04:41 q+ 21:04:51 ack dug 21:05:04 Tom: I am speaking of a third proposal, the reply to has wsa:anon with queueID ref Parms. This is not the same as Marc H proposal. The sender would know it is using wsrm makeconnection as reliability mechanism, and that is why it would put the queueID ref parm in its reply To> It may actually ignore the queue ID ref parms echo, if it is useing the correlation mechanism. 21:05:38 Doug D: Is it the belief that there should be no other special URS defined in other specs. 21:06:08 Bob F: that is a strong current wthin this WS addressing WG. 21:06:16 q+ 21:06:25 ack mrg 21:07:14 Marc G: ws discovery URIs do not impact the transport layer, They do not impact the ws addressin behaviour in my understanding. I have found no other URIs that trigger the "back channel" 21:07:18 q+ 21:07:46 Doug D: I am asking if other specs hava a URI which is not "addressable" and needs extra processing to understand its use. 21:08:03 Bob: no other group has raised an issue to use about this. 21:08:27 ack mrg 21:09:21 urn:schemas-xmlsoap-org:ws:2005:04:discovery 21:09:28 Doug D: non addressable uri is one which requires the user to go elsewhere to determine where to send the message to. 21:10:33 Doug D: if the uri above was used in a replyTo header, it could cause problems for some systems. That is my concern. 21:11:16 Marc G: scheme handling for urn is different than scheme handline for http. Are you assuming it is unreachable since it has a urn. 21:11:22 q? 21:11:39 Marc G: I would like to understand how that urn is being used in ws discovery. 21:12:30 Tony R: wsaw: anonymous does not represent backchannel. 21:13:41 q+ 21:14:06 q+ 21:14:09 Tony R they are trying to identify back channel, and also which queue of responses in server should be used to get response back from. That is what the anonymous uri does, it puts two identifiers into one. 21:14:23 ack cferris 21:15:23 q- 21:15:54 Chris F: It does not identify a queue, it defines a backchannel. the backchannel is identified by the wsrm:anonymous URI template. 21:15:57 q+ 21:16:42 q+ 21:17:00 Tony R: the extra ID is a second thing that is being identified, other than use of the backchannel. You are conbining two identifiers. 21:17:35 Chris F: the extra id info is an identifier for the backchannel itself. 21:18:10 ack trutt 21:18:27 ack dug 21:19:24 Tom: I do not think that a backchannel id is any different than a queue id. One is from the sender view, the other is from the responser view. The responder has to treat the backchannel identified by the replyTo as a particular queue, waiting for that backichannel ID on the makeConnection poll message. 21:20:24 Doug D: what is problem with our uid. 21:20:57 Tony R: it requires special processing, beyond detecting wsa:anonyous or wsa:none. 21:21:24 +1 to chris 21:21:29 +Dave_Hull 21:21:47 dorchard has joined #ws-addr 21:22:08 Chris F: address could have a base address which is an http address, with the extra backchannel id info as a fragment. This could have been made to work. Using Relative URL. We could use anonmous uri as base, with the backchannel as a fragment. 21:23:07 Discussion on the benefits of alternative 21:23:49 q+ 21:24:53 ack tru 21:26:21 Tom: this new proposal still requires the responder to hold back the reply for the propser message, and cannot just send it using that to address on a response sent at the wrong time (i..e, not to a make connection request). 21:26:23 q+ 21:27:05 q+ 21:27:13 q+ 21:27:23 Doug D: for now only anonymous and none http addresses require extra processing for WSA. 21:27:56 ack bob 21:28:20 -Chris_Ferris 21:28:23 ack cferr 21:28:37 cferris has left #ws-addr 21:28:47 Bob F: composing extra information with base http address might work 21:29:28 q+ 21:29:43 ack dug 21:29:52 Doug D: you still need some other flag for the client to state is is going to use the make connection. That is why we used a special uri template. I agree with Tom that the new proposal from Chris F does not signal use of make connection. 21:29:57 q+ 21:30:03 ack mrg 21:30:18 ack dhull 21:31:12 Dave Hull: um um I think we need to careful in packing too much info into a uri. Virtual channels may be ok, but "send to this party using a make connection" type protocol information, this seems dodgy. 21:32:29 q+ 21:32:39 ack mrg 21:32:45 Dave Hull: If we can be careful to separate resource represented, as opposed to what mechanis is used to reach that resource, that is good. 21:33:59 Marc G: Doug D example of wsrm:anonURI has behaviour not defined in the wsrm specification 21:34:02 q+ 21:34:10 ack tru 21:34:42 Tom: what about a new uri scheme. 21:35:47 Doug D: the overhead of registering a new uri schem for makeConnection protocl with IETF made that not acceptable. However you would still have problem with wsdL: anon required marker. 21:36:56 Dave Hull: we still could clarify the semantics of the wsdl:anonRequired attribugte to be more flextible. 21:37:27 "# 21:37:29 "required":This value indicates that all response endpoint EPRs in a request message MUST always use anonymous URI as an address. 21:37:31 If a response endpoint EPR does not contain the anonymous URI as an address value, then a predefined InvalidAddressingHeader fault defined in Web Services Addressing 1.0 - SOAP Binding [WS-Addressing SOAP Binding] MUST be generated." 21:37:32 Seems clear enough. 21:38:00 Bob: we still have question, does core and soap binding need change? Do we support the use case requested? Is the change required limited to the wsdlBinding doc? 21:38:32 (none comes in through the core: "Messages sent to EPRs whose [address] is this value MUST be discarded (i.e. not sent). This URI is typically used in EPRs that designate a reply or fault endpoint (see section 3.1 Abstract Property Definitions) to indicate that no reply or fault message should be sent." 21:38:34 q+ 21:38:52 Bob: we have to winnow through these for a small set of final approaches to take. I would like to add the BAseURI approach. 21:38:55 ack mrg 21:39:15 Marc G: does taking wsa:anonymous as base uri require changing the core? 21:40:01 Bob: how much is does depends on the exact proposal. If anonymous is changed to a base URI, it allows a definition of wsdl Marker along lines of what wsrm desires. 21:40:36 Bob: another approach is to use a from field. 21:40:54 Bob: another approach for one way messages is the Marc H approach of a domain specific relationship type. 21:41:27 Bob: we also have to consider eventual use of a ws:policy assertion. 21:41:38 q+ 21:41:51 Bob: key question is whether it requires changes to core. 21:41:51 q- 21:42:42 Bob: are we within a call, or is there specffic information we need before we make that call. 21:43:14 Bob: put on agenda for next call , a vote, do we need to change core arch or not. 21:43:44 Doug D: would you not need the exact proposal for that determiniation. 21:44:13 q+ 21:44:34 ack tru 21:45:36 q+ 21:45:59 Tom: What about a w3c hosted call to have a wider discussion with invited guests from WS-RX TC. 21:46:14 Topic: Next call 21:46:30 Do we really think more people will help come to a decision? I have my doubts. 21:47:38 Bob: many will be travelling to WS-I plenary in bay area. Those might not be able to make this call. I propose our next ws-addressin call be schedule for 23 of october. 21:48:09 Tom: can we bring in Observers or invited experts to that call. 21:48:57 Katy: I would prefer we try to work in this group first. 21:49:10 ack katy 21:50:41 Bob: I will rework the list to include all the proposals so far, outside of changes to the wsdl binding. I will get this out tomorrow morning. 21:51:20 Bob : I would like to winnow this down. 21:51:27 Tom: can we send this email to other groups. 21:51:42 Bob: everything on the public list is available to the public. 21:52:04 -Gilbert_Pilz 21:52:08 Topic: adjourn 21:52:10 -yinleng 21:52:11 -MrGoodner 21:52:13 -Paul_Knight 21:52:14 -katy 21:52:16 -Bob_Freund 21:52:16 -dug 21:52:17 -Prasad_Yendluri 21:52:17 -TonyR 21:52:24 yinleng has left #ws-addr 21:52:27 rrsagent, make logs public 21:52:31 TonyR has left #ws-addr 21:52:33 TRutt_ has left #ws-addr 21:52:38 rrsagent, generate minutes 21:52:38 I have made the request to generate http://www.w3.org/2006/10/09-ws-addr-minutes.html bob 21:52:45 -Dave_Hull 22:05:00 disconnecting the lone participant, Tom_Rutt, in WS_AddrWG()4:00PM 22:05:02 WS_AddrWG()4:00PM has ended 22:05:05 Attendees were Mark_Little, Bob_Freund, Gilbert_Pilz, TonyR, Tom_Rutt, MrGoodner, Dave_Hull, Prasad_Yendluri, katy, yinleng, Paul_Knight, dug, Chris_Ferris 22:47:18 rrsagent, generate minutes 22:47:18 I have made the request to generate http://www.w3.org/2006/10/09-ws-addr-minutes.html bob 22:53:21 bob has left #ws-addr