19:58:48 RRSAgent has joined #ws-addr 19:58:48 logging to http://www.w3.org/2006/10/02-ws-addr-irc 19:59:05 zakim, this will be ws_addrwg 19:59:05 ok, bob, I see WS_AddrWG()4:00PM already started 19:59:27 meeting: Web Services Addressing WG Teleconference 19:59:49 Chair: Bob Freund 19:59:59 gpilz has joined #ws-addr 20:00:30 Jonathan has joined #ws-addr 20:01:13 MrGoodner has joined #ws-addr 20:01:14 agenda: http://lists.w3.org/Archives/Public/public-ws-addressing/2006Oct/0000.html 20:01:45 zakim, who is here? 20:01:45 On the phone I see no one 20:01:47 On IRC I see MrGoodner, Jonathan, gpilz, RRSAgent, Zakim, Katy, bob, prasad, plh, TonyR 20:01:56 dorchard has joined #ws-addr 20:02:07 anish has joined #ws-addr 20:02:35 Jonathan has joined #ws-addr 20:02:39 zakim, who is here? 20:02:39 On the phone I see no one 20:02:40 On IRC I see Jonathan, anish, dorchard, MrGoodner, gpilz, RRSAgent, Zakim, Katy, bob, prasad, plh, TonyR 20:02:57 zakim,who is on the phone? 20:02:57 On the phone I see no one 20:03:04 zakim, where am i? 20:03:04 I don't understand your question, TonyR. 20:03:17 zakim, what is the code? 20:03:17 the conference code is 2337 (tel:+1.617.761.6200), TonyR 20:03:34 pauld has joined #ws-addr 20:03:44 zakim, this is addr 20:03:44 TonyR, this was already WS_AddrWG()4:00PM 20:03:45 ok, TonyR; that matches WS_AddrWG()4:00PM 20:04:19 http://www.w3.org/1998/12/bridge/Zakim.html 20:04:30 zakim, bup-bump is me 20:04:30 sorry, pauld, I do not recognize a party named 'bup-bump' 20:05:34 Joanthan has joined #ws-addr 20:05:41 zakim, who is making noise? 20:05:52 pauld, listening for 10 seconds I heard sound from the following: ??P4 (24%), ??P5 (47%), ??P9 (9%), ??P14 (39%) 20:06:19 zakim, who is on the phone? 20:06:19 On the phone I see no one 20:07:47 Marsh has joined #ws-addr 20:08:06 Paco has joined #ws-addr 20:09:29 scribe: plh 20:09:39 Agenda: http://lists.w3.org/Archives/Public/public-ws-addressing/2006Oct/0000.html 20:09:41 PaulKnight has joined #ws-addr 20:09:45 Chair: Bob 20:09:56 Meeting: Web Services Addressing 20:10:38 Topic: Action items 20:10:50 2006-08-21: cr31 - Tony Rogers to implement CHANGE 1&2 to the table in 20:10:50 preparation for CR-31 PENDING 20:10:53 revised table from TonyR: http://lists.w3.org/Archives/Public/public-ws-addressing/2006Oct/att-0003/cr31.html 20:11:20 Tony: need more input from the Working Group 20:12:13 Paco and Anish outlined proposal for cr33: http://lists.w3.org/Archives/Public/public-ws-addressing/2006Oct/0002.html 20:12:17 Bob: Anish and Bob action item is on today's agenda. I propose that we take some steps back 20:13:18 Topic: previous minutes 20:13:33 Previous minutes: http://www.w3.org/2002/ws/addr/6/09/25-ws-addr-minutes.html 20:13:37 q+ 20:13:42 RESOLUTION: Previous minutes approved 20:14:01 ack anish 20:14:12 Anish: our proposal is more an outline than a full proposal 20:14:41 Topic: Time to reflect on what problem we are trying to solve wrt cr33 20:14:44 TRutt_ has joined #ws-addr 20:16:03 Bob: looking back at the origin of the issue in Addressing and WS-RX, [..]. It seems that WS-RX is looking at establishing some form of unique endpoint identification, or transmitting parameters from one endpoint to the others. 20:16:25 ... wanted to know where folks want to focus their energy 20:17:51 q+ 20:18:27 Jonathan: we gave a destination property (uri, none, anonymous). Lots of place were you give a union of user defined values. Don't think our design is really broken, but others didn't allow others that to redefine their values. Can we recognize that none and anonymous are special values for this version. 20:18:37 ... ie don't use it as extensibility points 20:19:03 q+ 20:19:03 ... I'm tempted to ask for an erratum for extensibility 20:19:07 ack do 20:20:22 q+ 20:20:34 David: architectural issue: address vs identifier. We tried to get away by only using addresses, but people are trying to give identifiers effect to them. Reference properties were architectured around that. 20:20:55 ... "use the back channel since there is no address, but there is an identifier" 20:21:04 ack anish 20:21:29 Anish: Jonathan, are you thinking asking for isAnon? 20:22:23 Jonathan: no, but we say that only none and anonymous are special 20:22:59 Anish: we have abstracted the thing so much that it's really unclear how things work. Anonymous URI doesn't mean much in the Core. 20:23:45 ... people want to change where the response goes and we haven't give the ability to do so. 20:23:54 GlenD has joined #ws-addr 20:24:07 +1 to Anish's points 20:24:21 also, apologies for showing up late 20:24:29 ... ws-rx realized that the soap binding isn't very useful as-is. 20:24:34 ack tr 20:24:53 q+ 20:25:16 q+ 20:25:18 Tom: we got rid of ref props because they affected dispatch. The WS-RX committee needs to investigate if using a ref param would work. 20:25:33 q- 20:25:50 q+ 20:25:55 ... rewording the document might be useful. +1 to Jonathan: the only special URIs are the one we define. 20:25:57 ack paco 20:26:41 Ref Properties were taken out since they effected the "dispatch" of where a message would be "delivered" on the receiving end, Ref parms do not affect "dispatch" but do provide additional information for intermediaries and the ultimate destination, WS-RX TC needs to consider if a queueId in an epr with wsa:anon address could work 20:27:27 Paco: The anonymous marker was badly designed. It is restrictive. That seems a shortsighted approach. We have to plan for composability. 20:28:00 q+ 20:28:03 ... from my point of view, it does make to look at a better semantic. 20:28:09 q+ Marc 20:28:14 ack an 20:28:17 q+ march 20:28:24 q- march 20:29:20 Anish: two ways to move forward: redesign anonymous using policy or no change anything and ask WS-RX to work around that (ie use ref params). 20:30:48 Bob: when we had the discussion about the meaning of anonymous, we used it as an identifier for the backchannel resource. Here folks would like to pass some additional information beyond it. 20:31:04 s/a queueid/a ref Parm with queueid/ 20:31:19 ack glen 20:31:34 q? 20:31:44 q+ Jonathan 20:31:56 q+ to comment on bob's comment 20:32:36 q- 20:32:53 Glen: I do think that people are using ref params to identify sub-resource beyond the endpoint. That's reasonable. Here, there is a thing that is meant when you send a ReplyTo URI. We polluted that space by adding special values. 20:33:48 ... there is no way to mark that a URI is special. 20:33:50 ... and they are special in the same way (back channel) 20:34:17 ... a solution could have been not include anything in the reply 20:34:17 ack marc 20:35:18 Marc: the distinction between ref props and ref params is a distraction, since there's the same for the receiver. RM is overloading ReplyTo. 20:35:29 q+ 20:35:36 ack jonath 20:35:37 q+ 20:35:44 ... the URI for anonymous is well-defined. 20:36:44 ack anish 20:36:51 q+ 20:36:52 Jonathan: addressing and identification is still confusing here. RM doesn't make use of the addressing functionality. 20:36:57 q+ 20:37:42 Anish: MakeConnection is about ... making a connection and you don't have a choice to redirect it somewhere else. That's the reason why ReplyTo is ignored. 20:38:48 Focusing on WS-addressing, we have a statement that other specs can define their own "anonymous" like urii, with the wsdl binding not providing markers to state their use 20:39:17 Anish: the fact that MakeConnection is one-way and still use the backchannel is a common pattern in RM. 20:40:22 ... the problem is about wsaw:Anonymous. Do we want to mean something specific about our anonymous URI, or to use the backchannel? 20:40:24 Anish - excellent way to frame that. Thanks. 20:40:27 ack katy 20:41:07 mlittle has joined #ws-addr 20:41:19 ack tonyr 20:41:35 Katy: the replyTo semantic is defining by our spec. Here we're saying that others can define their own semantic. In an ideal world, RM should ahve defiend their own URI 20:41:39 q+ DaveO 20:41:56 5.2.1 states "Note that other specifications MAY define special URIs that have other behaviors (similar to the anonymous URI)." 20:42:17 Tony: it was suggested in RM that they use the from header to identify who they are. 20:42:28 pauld_ has joined #ws-addr 20:42:36 ack tru 20:42:43 In an ideal world RM should have defined their own 'replyTo' for RM semantics (not URI as minuted) 20:42:52 s/in RM// 20:43:18 Tom: we have a problem in our spec in 5.2.1. They took a statement to heart and the WSDL binding doesn't enable their use. 20:43:19 pauld_ has joined #ws-addr 20:43:37 pauld_ has left #ws-addr 20:43:43 Jonathan2 has joined #ws-addr 20:44:00 pauld_ has joined #ws-addr 20:44:04 q+ 20:44:37 FWIW, the statement Tom quotes is the one I'm tempted to delete through errata. 20:45:27 Anish: you don't have the value in the from present in the response message. 20:46:21 ... [explains WS-RM] 20:47:22 Bob: they're making use of the from as a hack as well. 20:47:27 q? 20:47:35 ack dave 20:47:40 ack dave 20:48:30 q+ 20:48:40 q+ 20:48:59 David: Folks are trying to use WS-Addressing and they are finding some issues. It's important to think about this. WS-Addr is intended to be a Core spec. We should allow them to build what they want to do. 20:49:10 ... I'm not a big fan of ignoring it 20:49:29 ... we should try to address their use cases 20:50:35 ... re distinction between ref props/ref params was meant for identification. We prevented people from using EPR as identifiers. 20:50:39 q+ 20:50:58 I agree with Dave's comments about WS-A should provide building blocks (although it conflicts with my previous comment about separate rm replyTo) :o) 20:52:27 David: the other idea was to bring some other kind of identifying information, licensed to be used for EPR comparisons. 20:52:55 ack anish 20:53:08 Ref Parms, while not a part of identity used fo dispatching the message to the ultimate destination, they are data that the desitnation can use as part of its processing, In fact ws-rf has a way to use ref_parms to "select" an underlying resource at that endpoint for its querry operations. 20:53:47 Anish: cr33 is about wsaw:Anonymous and WS_Rm might have to change their spec. So should it about the two URIs we define or aobut the backchannel? 20:54:15 Tom: until recently, people thought that backchannel and anonymous were the same thing. 20:54:36 ack mrg 20:55:34 mlittle has joined #ws-addr 20:55:43 +1 20:55:45 ack paco 20:55:54 MarcG: Transaction does not have issues with WS-Addressing. Ditto for SecureConversation and WS-Trust. Seems like the Core problem is only coming from WS-RM, and on extensibility points added at their request 20:56:21 a brick is a brick is a brick 20:56:30 s/people/some people/ 20:56:39 Paco: WS-Addressing didn't really define how the semantics apply to the protocol. 20:56:42 Speaking as one of the editors of WS-TX, I agree. We've not had any problems with wsa. 20:57:23 Thanks, I'm an editor in SX and can't think of any problems with SC or Trust either 20:58:09 Paco: if we want to have a useful marker, we better focus on the backchannel 20:58:19 To be honest, we thought the wsa text was pretty clear about what can and can't be done. Very few ambiguities, which for a standard is compliment ;-) 20:58:30 In the use case of WS-RF, the Ref Parm presence in a request can have an effect on the semantics of the response to that message (e.g., used as a sub resource selector on a get state request) 20:58:44 ack tru 20:58:47 Tom: In the use case of WS-RF, the Ref Parm presence in a request can have an effect on the semantics of the response to that message (e.g., used as a sub resource selector on a get state request) 20:59:34 s/WS-RF/WS-RX/ 20:59:51 he did mean RF 20:59:59 RF = ResourceFramework 21:00:01 s/WS-RX/WS-RF/ 21:00:15 np 21:00:20 q? 21:01:14 Bob: we could go in and add ref props. We could change the way we restrict ref params so that people will use them. 21:02:01 ... we could suggest that they use their own replyTo. Or come up with new attr/elts for identification purpose. 21:02:21 ... Or clarify the meaning of wsaw:Anonymous 21:02:39 ... setting aside the WSDL marker discussion ... 21:02:49 q+ 21:03:11 q- 21:03:17 ... the specific use case is "attempt to provide some identifying information while expecting a response from something" 21:04:12 ... is there anyway we can do this in a normative way in our specification? 21:04:31 q+ 21:04:46 +1 21:05:04 Not sure what you're saying Bob, but it sounds scary! 21:05:09 Paco: we explicitly decided to stay out of the identification business. that would be a big change of direction... 21:05:11 q+ 21:05:21 q+ 21:05:56 Paco: re opaque. you don't want to build a dependency onto a particular structure. 21:06:18 Anish: I interpreted opaque to mean opaque to anybody but the minter. 21:06:43 ... all those options are about changing Core or SOAP binding. Is that correct? 21:06:48 Bob: not entirely sure yet 21:07:52 ... want to make sure that everyone understands why the RM folks arrived there, ie to put some identification into a form of anonymous URI. We have plenty of fields for that but we don't say what they mean. 21:08:17 ack ani 21:08:18 ack anish 21:08:25 ack gpil 21:09:20 q+ 21:09:23 Gil: I can basically use ref params and no worry about unintended side effects. 21:10:30 ... we're missing one of the constraints from the design of RM. They tried not to pervert common WS-A implementations. That's why they're not using from. From doesn't get reflected back in the headers of the reply message. 21:10:54 Bob: TX spits it back as a To 21:11:28 Gil: RM didn't want to change implementations. 21:11:31 that would mean that TX does not use replyTo and instead uses From 21:12:17 Anish: seems like TX uses from to identify the sender, ie they don't use replyTo. Then the requirements for TX is a little different. 21:12:47 TX defined that all messages patterns are really one-ways. There are responses, but they are application level messages. 21:12:56 +1 21:13:27 I agree with Bob that a key thing that WS-RX TC did to their wsrm:anon URI is to combine queueIdentity info in a "anonymous" address. 21:13:29 [...] 21:13:44 There are probably 1 or 2 places in the entire WS-TX specification where ReplyTo makes sense: those interactions are request-response. 21:13:52 q? 21:13:56 Anish: from an RX point of view, they can't do this. they're trying to make request/response MEP reliable 21:14:42 How backwardly compatible with existing implementations do we have to be? It's laudable that RX wants to work with existing implementations, but if that means we have to hack wsa, is that right? 21:15:30 ack pauld 21:15:58 q+ 21:16:04 q- 21:16:09 q+ 21:16:32 +1 21:16:36 mark, the problem is not compatiblility with existing implementations, but that whatever is specified in wsa:From MUST be included in the response message. It is certainly possible for ws-rx to make that a requirement. But that is not how they went. Without the contents of wsa:From in the response message, it is not possible to do what wsrx wants to do 21:16:38 Paul: we shipped our Core and SOAP. I'm not hearing that we're broken. 21:16:44 ack tr 21:17:29 ... so wsrx will have to specify where info in the wsa:From header is included in the response message (perhaps as a new soap header) 21:18:09 ack mrg 21:18:12 Tom: the key issue is to put identification on anonymous URIs. 21:18:43 Anish, ok so they should change and use wsa:From ;-) 21:19:22 mark, ... and define a new SOAP header that will be present in the response message? 21:19:31 MarcG: the RM are trying to initiate the response/request pattern. 21:19:51 I do not think the wsa group should try to be the wsrx group 21:19:59 Bob: do we agree that the problem is about the need of transfer identifying information? 21:20:30 Jonathan: that may be the problem, but I saw other solutions who were able to do RM without this. 21:20:43 ... (see PAOS) 21:20:43 q+ to say that PAOS does not work 21:21:10 ack anis 21:21:10 anish, you wanted to say that PAOS does not work 21:22:43 notes we have messageIds andan extensible relatesTo to provide correlation 21:23:22 Jonathan: would like to see a model for the polling behavior used by RM 21:23:25 s/andan/and an/ 21:23:51 q+ 21:24:02 ack tr 21:24:20 Tom: if we agree that you shouldn't put identification in the anonymous URI, we might want to change 5.2.1. 21:24:28 +1 of course ;-) 21:24:54 Bob: do we think that folks should be allowed to put identification information in the anonymous URI? 21:25:24 Anish: meaning the ws-addressing uri? 21:25:32 Tom: in 5.2.1 21:26:52 Bob: right now, they're trying to use their own URI to indicate the use of the backchannel? 21:28:03 Katy: the answer to that question might depend on whether we provide alternative solutions 21:28:08 q+ 21:28:16 q+ 21:28:25 ... without any, we would want to allow identifying info in anon URI 21:28:28 ack tr 21:29:07 Tom: we should on the long term here. If we told they couldn't this, that will force them to do something else. 21:29:16 ack gpil 21:29:48 Gil: I think we're asking the wrong question: How deeply into this identifying thing do we want to get? 21:30:24 ... addressing URI represents addressing and backchannel 21:30:34 ... should we separate those two? 21:30:46 q+ 21:31:40 Bob: if we stay out of the identity business, should we provide alternative ways? The specific resource that anon URI identifies is backchannel. 21:32:04 ... but we didn't say anything about the general URI 21:32:11 ack paco 21:32:39 Paco: many reason to stay away from identity business. It makes sense to try to use URIs for that effect. 21:33:08 q+ 21:33:34 ack gpil 21:33:36 ... I don't see much value in creating a template 21:35:13 q+ 21:36:02 ack paco 21:36:43 Tony hit it: they are trying to extend to back channel to allow responses from earlier requests! 21:37:12 q+ 21:37:20 ack gil 21:37:32 And since they are doing that they need to include some data to control which earier request can flow on the backchannel to the make connection request 21:37:51 they are also trying to enable initiating new requests as the response to the make connection request 21:38:04 Gil: they created a template for anon URIs and they're asking us to recognize it as the anon URI. 21:38:06 q+ 21:38:21 ack gpi 21:38:34 That concept doesn't actually make sense unless you understand RM anyway, right? 21:38:38 enabling the responses to previous requests works without the need for the RM anon URI 21:38:39 ack tr 21:38:50 q+ 21:39:03 Tom: they're trying to use the backchannel for earlier requests. 21:39:10 ack mrg 21:39:55 MarcG: RM anon URI was added as an alternative for initiating a new request 21:41:10 Bob: so is Anon URI with identifying information legal? Is there an error with trying to generate your own version of Anon? 21:41:21 ... should we solve this? 21:41:31 q+ 21:41:41 q+ 21:41:53 MarcH: you can always use a SOAP header! 21:42:22 Katy: but that SOAP header wouldn't be pass back 21:42:34 MarcH: you can say it has to be echoed. 21:43:01 Tony: they want something that magically appears in the response 21:43:06 q+ 21:43:07 q+ 21:43:10 yeah, let them eat soap! 21:43:51 How about rubbing soap in their mouth:-) 21:43:54 ... they want to encode it on the message going back 21:44:13 ... ref params are opaque only at the WS-Addressing level 21:44:14 ack tonyr 21:44:26 ack glen 21:44:28 ... RM shouldn't have to consider them open 21:44:46 Glen: the RM URI doesn't make sense to non-RM implementations 21:44:56 q- 21:45:52 ... the way we define anon is to make sure to connect the reply in a WSDL req/resp MEP to the request. 21:46:10 +1 to glen 21:46:25 Bob: the MEP that they use is unique 21:46:27 q? 21:46:35 ack gpil 21:47:20 Gil: the idea of pushing RM into the addressing layer. RM source and RM destination are async in their behavior. 21:48:56 q+ 21:49:00 ... THE RMS is trying to reach the RMD as best as it can. 21:49:15 ack katy 21:49:46 the RMS and RMD are asymmetric in their behavior 21:50:05 q+ 21:50:13 s/async/asymmetric/ 21:50:18 q+ 21:50:20 ack tr 21:50:43 q+ 21:50:56 one of the major drivers behind the WS-RM anon URI was the urge to allow WS-RM implementations to remain unaffected by the fact that the RMD is resident in a non-addressable entity 21:51:14 ack tony 21:52:25 MrGoodner1 has joined #ws-addr 21:52:33 Tony: RM wants something that is already being sent back. They want to pass the identifier with minimal effort 21:53:11 ... they really need to operate as a separate layer on top of addressing. 21:53:34 q+ 21:53:38 q- 21:54:01 .. expecting the state of RM to be passed around in the addressing URI seems wrong. 21:54:31 ack ani 21:55:13 +1 I want to use Addressing without RX, but RX layers Addressing, so has to work within its constraints 21:55:26 Anish: Marc suggestion to use SOAP headers wasn't considered. This is interesting feedback. Ref params has been considered at least. I'll get this back to WS-RM. 21:55:54 Bob: is this proposal something we ought to consider as a WG response? 21:55:56 q? 21:56:11 Tom: any formal thing would be counter productive move for the moment 21:56:13 dorchard has joined #ws-addr 21:56:34 Anish: I also need to think about this. We just didn't consider in WS_RX and needs to see if it really works for us 21:56:49 Bob: ok not to send a formal response but we need to have the dialog open. 21:58:02 Bob: I still didn't hear that we need to fix something? 21:58:21 Tom: we never thought of anonymous address carrying identifying information 21:58:41 Tony: I think the id should be carried an other way 21:59:35 ACTION Bob: enumerate the alternatives for cr33 22:00:43 [adjourned] 22:00:56 rrsagent, make logs public 22:01:02 TonyR has left #ws-addr 22:01:06 rrsagent, generate minutes 22:01:06 I have made the request to generate http://www.w3.org/2006/10/02-ws-addr-minutes.html bob 22:01:15 zakim, bye 22:01:15 Zakim has left #ws-addr 22:01:22 TRutt_ has left #ws-addr 22:01:22 philippe, thanks for scribing 22:01:53 welcome, I hope I didn't a bad job at it. the last 30 minutes were difficult. 22:02:05 now I need a good rest 22:02:13 (if it's ok to use this word :) 22:03:11 take one and get well 22:03:37 hodid the meeting help? 22:06:34 bob has left #ws-addr