IRC log of ws-addr on 2006-10-02
Timestamps are in UTC.
- 19:58:48 [RRSAgent]
- RRSAgent has joined #ws-addr
- 19:58:48 [RRSAgent]
- logging to http://www.w3.org/2006/10/02-ws-addr-irc
- 19:59:05 [bob]
- zakim, this will be ws_addrwg
- 19:59:05 [Zakim]
- ok, bob, I see WS_AddrWG()4:00PM already started
- 19:59:27 [bob]
- meeting: Web Services Addressing WG Teleconference
- 19:59:49 [bob]
- Chair: Bob Freund
- 19:59:59 [gpilz]
- gpilz has joined #ws-addr
- 20:00:30 [Jonathan]
- Jonathan has joined #ws-addr
- 20:01:13 [MrGoodner]
- MrGoodner has joined #ws-addr
- 20:01:14 [bob]
- agenda: http://lists.w3.org/Archives/Public/public-ws-addressing/2006Oct/0000.html
- 20:01:45 [bob]
- zakim, who is here?
- 20:01:45 [Zakim]
- On the phone I see no one
- 20:01:47 [Zakim]
- On IRC I see MrGoodner, Jonathan, gpilz, RRSAgent, Zakim, Katy, bob, prasad, plh, TonyR
- 20:01:56 [dorchard]
- dorchard has joined #ws-addr
- 20:02:07 [anish]
- anish has joined #ws-addr
- 20:02:35 [Jonathan]
- Jonathan has joined #ws-addr
- 20:02:39 [bob]
- zakim, who is here?
- 20:02:39 [Zakim]
- On the phone I see no one
- 20:02:40 [Zakim]
- On IRC I see Jonathan, anish, dorchard, MrGoodner, gpilz, RRSAgent, Zakim, Katy, bob, prasad, plh, TonyR
- 20:02:57 [TonyR]
- zakim,who is on the phone?
- 20:02:57 [Zakim]
- On the phone I see no one
- 20:03:04 [TonyR]
- zakim, where am i?
- 20:03:04 [Zakim]
- I don't understand your question, TonyR.
- 20:03:17 [TonyR]
- zakim, what is the code?
- 20:03:17 [Zakim]
- the conference code is 2337 (tel:+1.617.761.6200), TonyR
- 20:03:34 [pauld]
- pauld has joined #ws-addr
- 20:03:44 [TonyR]
- zakim, this is addr
- 20:03:44 [Zakim]
- TonyR, this was already WS_AddrWG()4:00PM
- 20:03:45 [Zakim]
- ok, TonyR; that matches WS_AddrWG()4:00PM
- 20:04:19 [plh]
- http://www.w3.org/1998/12/bridge/Zakim.html
- 20:04:30 [pauld]
- zakim, bup-bump is me
- 20:04:30 [Zakim]
- sorry, pauld, I do not recognize a party named 'bup-bump'
- 20:05:34 [Joanthan]
- Joanthan has joined #ws-addr
- 20:05:41 [pauld]
- zakim, who is making noise?
- 20:05:52 [Zakim]
- pauld, listening for 10 seconds I heard sound from the following: ??P4 (24%), ??P5 (47%), ??P9 (9%), ??P14 (39%)
- 20:06:19 [pauld]
- zakim, who is on the phone?
- 20:06:19 [Zakim]
- On the phone I see no one
- 20:07:47 [Marsh]
- Marsh has joined #ws-addr
- 20:08:06 [Paco]
- Paco has joined #ws-addr
- 20:09:29 [plh]
- scribe: plh
- 20:09:39 [plh]
- Agenda: http://lists.w3.org/Archives/Public/public-ws-addressing/2006Oct/0000.html
- 20:09:41 [PaulKnight]
- PaulKnight has joined #ws-addr
- 20:09:45 [plh]
- Chair: Bob
- 20:09:56 [plh]
- Meeting: Web Services Addressing
- 20:10:38 [plh]
- Topic: Action items
- 20:10:50 [plh]
- 2006-08-21: cr31 - Tony Rogers to implement CHANGE 1&2 to the table in
- 20:10:50 [plh]
- preparation for CR-31 PENDING
- 20:10:53 [pauld]
- revised table from TonyR: http://lists.w3.org/Archives/Public/public-ws-addressing/2006Oct/att-0003/cr31.html
- 20:11:20 [plh]
- Tony: need more input from the Working Group
- 20:12:13 [pauld]
- Paco and Anish outlined proposal for cr33: http://lists.w3.org/Archives/Public/public-ws-addressing/2006Oct/0002.html
- 20:12:17 [plh]
- Bob: Anish and Bob action item is on today's agenda. I propose that we take some steps back
- 20:13:18 [plh]
- Topic: previous minutes
- 20:13:33 [plh]
- Previous minutes: http://www.w3.org/2002/ws/addr/6/09/25-ws-addr-minutes.html
- 20:13:37 [anish]
- q+
- 20:13:42 [plh]
- RESOLUTION: Previous minutes approved
- 20:14:01 [bob]
- ack anish
- 20:14:12 [plh]
- Anish: our proposal is more an outline than a full proposal
- 20:14:41 [plh]
- Topic: Time to reflect on what problem we are trying to solve wrt cr33
- 20:14:44 [TRutt_]
- TRutt_ has joined #ws-addr
- 20:16:03 [plh]
- 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 [plh]
- ... wanted to know where folks want to focus their energy
- 20:17:51 [dorchard]
- q+
- 20:18:27 [plh]
- 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 [plh]
- ... ie don't use it as extensibility points
- 20:19:03 [anish]
- q+
- 20:19:03 [plh]
- ... I'm tempted to ask for an erratum for extensibility
- 20:19:07 [plh]
- ack do
- 20:20:22 [TRutt_]
- q+
- 20:20:34 [plh]
- 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 [plh]
- ... "use the back channel since there is no address, but there is an identifier"
- 20:21:04 [bob]
- ack anish
- 20:21:29 [plh]
- Anish: Jonathan, are you thinking asking for isAnon?
- 20:22:23 [plh]
- Jonathan: no, but we say that only none and anonymous are special
- 20:22:59 [plh]
- 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 [plh]
- ... people want to change where the response goes and we haven't give the ability to do so.
- 20:23:54 [GlenD]
- GlenD has joined #ws-addr
- 20:24:07 [GlenD]
- +1 to Anish's points
- 20:24:21 [GlenD]
- also, apologies for showing up late
- 20:24:29 [plh]
- ... ws-rx realized that the soap binding isn't very useful as-is.
- 20:24:34 [bob]
- ack tr
- 20:24:53 [GlenD]
- q+
- 20:25:16 [Paco]
- q+
- 20:25:18 [plh]
- 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 [GlenD]
- q-
- 20:25:50 [anish]
- q+
- 20:25:55 [plh]
- ... rewording the document might be useful. +1 to Jonathan: the only special URIs are the one we define.
- 20:25:57 [bob]
- ack paco
- 20:26:41 [TRutt_]
- 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 [plh]
- Paco: The anonymous marker was badly designed. It is restrictive. That seems a shortsighted approach. We have to plan for composability.
- 20:28:00 [GlenD]
- q+
- 20:28:03 [plh]
- ... from my point of view, it does make to look at a better semantic.
- 20:28:09 [GlenD]
- q+ Marc
- 20:28:14 [plh]
- ack an
- 20:28:17 [bob]
- q+ march
- 20:28:24 [plh]
- q- march
- 20:29:20 [plh]
- 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 [plh]
- 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 [TRutt_]
- s/a queueid/a ref Parm with queueid/
- 20:31:19 [plh]
- ack glen
- 20:31:34 [pauld]
- q?
- 20:31:44 [MrGoodner]
- q+ Jonathan
- 20:31:56 [anish]
- q+ to comment on bob's comment
- 20:32:36 [anish]
- q-
- 20:32:53 [plh]
- 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 [plh]
- ... there is no way to mark that a URI is special.
- 20:33:50 [anish]
- ... and they are special in the same way (back channel)
- 20:34:17 [plh]
- ... a solution could have been not include anything in the reply
- 20:34:17 [bob]
- ack marc
- 20:35:18 [plh]
- 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 [anish]
- q+
- 20:35:36 [bob]
- ack jonath
- 20:35:37 [Katy]
- q+
- 20:35:44 [plh]
- ... the URI for anonymous is well-defined.
- 20:36:44 [bob]
- ack anish
- 20:36:51 [TonyR]
- q+
- 20:36:52 [plh]
- Jonathan: addressing and identification is still confusing here. RM doesn't make use of the addressing functionality.
- 20:36:57 [TRutt_]
- q+
- 20:37:42 [plh]
- 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 [TRutt_]
- 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 [plh]
- Anish: the fact that MakeConnection is one-way and still use the backchannel is a common pattern in RM.
- 20:40:22 [plh]
- ... 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 [GlenD]
- Anish - excellent way to frame that. Thanks.
- 20:40:27 [bob]
- ack katy
- 20:41:07 [mlittle]
- mlittle has joined #ws-addr
- 20:41:19 [bob]
- ack tonyr
- 20:41:35 [plh]
- 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 [GlenD]
- q+ DaveO
- 20:41:56 [TRutt_]
- 5.2.1 states "Note that other specifications MAY define special URIs that have other behaviors (similar to the anonymous URI)."
- 20:42:17 [plh]
- Tony: it was suggested in RM that they use the from header to identify who they are.
- 20:42:28 [pauld_]
- pauld_ has joined #ws-addr
- 20:42:36 [bob]
- ack tru
- 20:42:43 [Katy]
- In an ideal world RM should have defined their own 'replyTo' for RM semantics (not URI as minuted)
- 20:42:52 [TonyR]
- s/in RM//
- 20:43:18 [plh]
- 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_]
- pauld_ has joined #ws-addr
- 20:43:37 [pauld_]
- pauld_ has left #ws-addr
- 20:43:43 [Jonathan2]
- Jonathan2 has joined #ws-addr
- 20:44:00 [pauld_]
- pauld_ has joined #ws-addr
- 20:44:04 [anish]
- q+
- 20:44:37 [Jonathan2]
- FWIW, the statement Tom quotes is the one I'm tempted to delete through errata.
- 20:45:27 [plh]
- Anish: you don't have the value in the from present in the response message.
- 20:46:21 [plh]
- ... [explains WS-RM]
- 20:47:22 [plh]
- Bob: they're making use of the from as a hack as well.
- 20:47:27 [plh]
- q?
- 20:47:35 [plh]
- ack dave
- 20:47:40 [bob]
- ack dave
- 20:48:30 [MrGoodner]
- q+
- 20:48:40 [Paco]
- q+
- 20:48:59 [plh]
- 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 [plh]
- ... I'm not a big fan of ignoring it
- 20:49:29 [plh]
- ... we should try to address their use cases
- 20:50:35 [plh]
- ... re distinction between ref props/ref params was meant for identification. We prevented people from using EPR as identifiers.
- 20:50:39 [TRutt_]
- q+
- 20:50:58 [Katy]
- 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 [plh]
- David: the other idea was to bring some other kind of identifying information, licensed to be used for EPR comparisons.
- 20:52:55 [bob]
- ack anish
- 20:53:08 [TRutt_]
- 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 [plh]
- 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 [plh]
- Tom: until recently, people thought that backchannel and anonymous were the same thing.
- 20:54:36 [bob]
- ack mrg
- 20:55:34 [mlittle]
- mlittle has joined #ws-addr
- 20:55:43 [mlittle]
- +1
- 20:55:45 [bob]
- ack paco
- 20:55:54 [plh]
- 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 [pauld]
- a brick is a brick is a brick
- 20:56:30 [TRutt_]
- s/people/some people/
- 20:56:39 [plh]
- Paco: WS-Addressing didn't really define how the semantics apply to the protocol.
- 20:56:42 [mlittle]
- Speaking as one of the editors of WS-TX, I agree. We've not had any problems with wsa.
- 20:57:23 [MrGoodner]
- Thanks, I'm an editor in SX and can't think of any problems with SC or Trust either
- 20:58:09 [plh]
- Paco: if we want to have a useful marker, we better focus on the backchannel
- 20:58:19 [mlittle]
- 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 [TRutt_]
- 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 [bob]
- ack tru
- 20:58:47 [plh]
- 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 [plh]
- s/WS-RF/WS-RX/
- 20:59:51 [MrGoodner]
- he did mean RF
- 20:59:59 [MrGoodner]
- RF = ResourceFramework
- 21:00:01 [plh]
- s/WS-RX/WS-RF/
- 21:00:15 [MrGoodner]
- np
- 21:00:20 [bob]
- q?
- 21:01:14 [plh]
- 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 [plh]
- ... we could suggest that they use their own replyTo. Or come up with new attr/elts for identification purpose.
- 21:02:21 [plh]
- ... Or clarify the meaning of wsaw:Anonymous
- 21:02:39 [plh]
- ... setting aside the WSDL marker discussion ...
- 21:02:49 [anish]
- q+
- 21:03:11 [anish]
- q-
- 21:03:17 [plh]
- ... the specific use case is "attempt to provide some identifying information while expecting a response from something"
- 21:04:12 [plh]
- ... is there anyway we can do this in a normative way in our specification?
- 21:04:31 [anish]
- q+
- 21:04:46 [mlittle]
- +1
- 21:05:04 [Jonathan2]
- Not sure what you're saying Bob, but it sounds scary!
- 21:05:09 [plh]
- Paco: we explicitly decided to stay out of the identification business. that would be a big change of direction...
- 21:05:11 [gpilz]
- q+
- 21:05:21 [pauld]
- q+
- 21:05:56 [plh]
- Paco: re opaque. you don't want to build a dependency onto a particular structure.
- 21:06:18 [plh]
- Anish: I interpreted opaque to mean opaque to anybody but the minter.
- 21:06:43 [plh]
- ... all those options are about changing Core or SOAP binding. Is that correct?
- 21:06:48 [plh]
- Bob: not entirely sure yet
- 21:07:52 [plh]
- ... 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 [bob]
- ack ani
- 21:08:18 [plh]
- ack anish
- 21:08:25 [bob]
- ack gpil
- 21:09:20 [TRutt_]
- q+
- 21:09:23 [plh]
- Gil: I can basically use ref params and no worry about unintended side effects.
- 21:10:30 [plh]
- ... 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 [plh]
- Bob: TX spits it back as a To
- 21:11:28 [plh]
- Gil: RM didn't want to change implementations.
- 21:11:31 [anish]
- that would mean that TX does not use replyTo and instead uses From
- 21:12:17 [plh]
- 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 [mlittle]
- TX defined that all messages patterns are really one-ways. There are responses, but they are application level messages.
- 21:12:56 [mlittle]
- +1
- 21:13:27 [TRutt_]
- 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 [plh]
- [...]
- 21:13:44 [mlittle]
- 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 [bob]
- q?
- 21:13:56 [plh]
- Anish: from an RX point of view, they can't do this. they're trying to make request/response MEP reliable
- 21:14:42 [mlittle]
- 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 [bob]
- ack pauld
- 21:15:58 [Jonathan2]
- q+
- 21:16:04 [Jonathan2]
- q-
- 21:16:09 [MrGoodner]
- q+
- 21:16:32 [mlittle]
- +1
- 21:16:36 [anish]
- 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 [plh]
- Paul: we shipped our Core and SOAP. I'm not hearing that we're broken.
- 21:16:44 [bob]
- ack tr
- 21:17:29 [anish]
- ... 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 [bob]
- ack mrg
- 21:18:12 [plh]
- Tom: the key issue is to put identification on anonymous URIs.
- 21:18:43 [mlittle]
- Anish, ok so they should change and use wsa:From ;-)
- 21:19:22 [anish]
- mark, ... and define a new SOAP header that will be present in the response message?
- 21:19:31 [plh]
- MarcG: the RM are trying to initiate the response/request pattern.
- 21:19:51 [TRutt_]
- I do not think the wsa group should try to be the wsrx group
- 21:19:59 [plh]
- Bob: do we agree that the problem is about the need of transfer identifying information?
- 21:20:30 [plh]
- Jonathan: that may be the problem, but I saw other solutions who were able to do RM without this.
- 21:20:43 [plh]
- ... (see PAOS)
- 21:20:43 [anish]
- q+ to say that PAOS does not work
- 21:21:10 [bob]
- ack anis
- 21:21:10 [Zakim]
- anish, you wanted to say that PAOS does not work
- 21:22:43 [pauld]
- notes we have messageIds andan extensible relatesTo to provide correlation
- 21:23:22 [plh]
- Jonathan: would like to see a model for the polling behavior used by RM
- 21:23:25 [pauld]
- s/andan/and an/
- 21:23:51 [TRutt_]
- q+
- 21:24:02 [bob]
- ack tr
- 21:24:20 [plh]
- 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 [Jonathan2]
- +1 of course ;-)
- 21:24:54 [plh]
- Bob: do we think that folks should be allowed to put identification information in the anonymous URI?
- 21:25:24 [plh]
- Anish: meaning the ws-addressing uri?
- 21:25:32 [plh]
- Tom: in 5.2.1
- 21:26:52 [plh]
- Bob: right now, they're trying to use their own URI to indicate the use of the backchannel?
- 21:28:03 [plh]
- Katy: the answer to that question might depend on whether we provide alternative solutions
- 21:28:08 [TRutt_]
- q+
- 21:28:16 [gpilz]
- q+
- 21:28:25 [plh]
- ... without any, we would want to allow identifying info in anon URI
- 21:28:28 [bob]
- ack tr
- 21:29:07 [plh]
- 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 [bob]
- ack gpil
- 21:29:48 [plh]
- Gil: I think we're asking the wrong question: How deeply into this identifying thing do we want to get?
- 21:30:24 [plh]
- ... addressing URI represents addressing and backchannel
- 21:30:34 [plh]
- ... should we separate those two?
- 21:30:46 [Paco]
- q+
- 21:31:40 [plh]
- 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 [plh]
- ... but we didn't say anything about the general URI
- 21:32:11 [bob]
- ack paco
- 21:32:39 [plh]
- Paco: many reason to stay away from identity business. It makes sense to try to use URIs for that effect.
- 21:33:08 [gpilz]
- q+
- 21:33:34 [bob]
- ack gpil
- 21:33:36 [plh]
- ... I don't see much value in creating a template
- 21:35:13 [Paco]
- q+
- 21:36:02 [bob]
- ack paco
- 21:36:43 [TRutt_]
- Tony hit it: they are trying to extend to back channel to allow responses from earlier requests!
- 21:37:12 [gpilz]
- q+
- 21:37:20 [bob]
- ack gil
- 21:37:32 [TRutt_]
- 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 [MrGoodner]
- they are also trying to enable initiating new requests as the response to the make connection request
- 21:38:04 [plh]
- Gil: they created a template for anon URIs and they're asking us to recognize it as the anon URI.
- 21:38:06 [TRutt_]
- q+
- 21:38:21 [bob]
- ack gpi
- 21:38:34 [GlenD]
- That concept doesn't actually make sense unless you understand RM anyway, right?
- 21:38:38 [MrGoodner]
- enabling the responses to previous requests works without the need for the RM anon URI
- 21:38:39 [bob]
- ack tr
- 21:38:50 [MrGoodner]
- q+
- 21:39:03 [plh]
- Tom: they're trying to use the backchannel for earlier requests.
- 21:39:10 [bob]
- ack mrg
- 21:39:55 [plh]
- MarcG: RM anon URI was added as an alternative for initiating a new request
- 21:41:10 [plh]
- 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 [plh]
- ... should we solve this?
- 21:41:31 [GlenD]
- q+
- 21:41:41 [TonyR]
- q+
- 21:41:53 [plh]
- MarcH: you can always use a SOAP header!
- 21:42:22 [plh]
- Katy: but that SOAP header wouldn't be pass back
- 21:42:34 [plh]
- MarcH: you can say it has to be echoed.
- 21:43:01 [plh]
- Tony: they want something that magically appears in the response
- 21:43:06 [gpilz]
- q+
- 21:43:07 [anish]
- q+
- 21:43:10 [pauld]
- yeah, let them eat soap!
- 21:43:51 [TRutt_]
- How about rubbing soap in their mouth:-)
- 21:43:54 [plh]
- ... they want to encode it on the message going back
- 21:44:13 [plh]
- ... ref params are opaque only at the WS-Addressing level
- 21:44:14 [bob]
- ack tonyr
- 21:44:26 [bob]
- ack glen
- 21:44:28 [plh]
- ... RM shouldn't have to consider them open
- 21:44:46 [plh]
- Glen: the RM URI doesn't make sense to non-RM implementations
- 21:44:56 [anish]
- q-
- 21:45:52 [plh]
- ... 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 [TRutt_]
- +1 to glen
- 21:46:25 [plh]
- Bob: the MEP that they use is unique
- 21:46:27 [bob]
- q?
- 21:46:35 [bob]
- ack gpil
- 21:47:20 [plh]
- Gil: the idea of pushing RM into the addressing layer. RM source and RM destination are async in their behavior.
- 21:48:56 [Katy]
- q+
- 21:49:00 [plh]
- ... THE RMS is trying to reach the RMD as best as it can.
- 21:49:15 [bob]
- ack katy
- 21:49:46 [gpilz]
- the RMS and RMD are asymmetric in their behavior
- 21:50:05 [TRutt_]
- q+
- 21:50:13 [plh]
- s/async/asymmetric/
- 21:50:18 [TonyR]
- q+
- 21:50:20 [bob]
- ack tr
- 21:50:43 [anish]
- q+
- 21:50:56 [gpilz]
- 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 [bob]
- ack tony
- 21:52:25 [MrGoodner1]
- MrGoodner1 has joined #ws-addr
- 21:52:33 [plh]
- Tony: RM wants something that is already being sent back. They want to pass the identifier with minimal effort
- 21:53:11 [plh]
- ... they really need to operate as a separate layer on top of addressing.
- 21:53:34 [gpilz]
- q+
- 21:53:38 [gpilz]
- q-
- 21:54:01 [plh]
- .. expecting the state of RM to be passed around in the addressing URI seems wrong.
- 21:54:31 [bob]
- ack ani
- 21:55:13 [pauld]
- +1 I want to use Addressing without RX, but RX layers Addressing, so has to work within its constraints
- 21:55:26 [plh]
- 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 [plh]
- Bob: is this proposal something we ought to consider as a WG response?
- 21:55:56 [bob]
- q?
- 21:56:11 [plh]
- Tom: any formal thing would be counter productive move for the moment
- 21:56:13 [dorchard]
- dorchard has joined #ws-addr
- 21:56:34 [plh]
- 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 [plh]
- Bob: ok not to send a formal response but we need to have the dialog open.
- 21:58:02 [plh]
- Bob: I still didn't hear that we need to fix something?
- 21:58:21 [plh]
- Tom: we never thought of anonymous address carrying identifying information
- 21:58:41 [plh]
- Tony: I think the id should be carried an other way
- 21:59:35 [plh]
- ACTION Bob: enumerate the alternatives for cr33
- 22:00:43 [plh]
- [adjourned]
- 22:00:56 [bob]
- rrsagent, make logs public
- 22:01:02 [TonyR]
- TonyR has left #ws-addr
- 22:01:06 [bob]
- rrsagent, generate minutes
- 22:01:06 [RRSAgent]
- I have made the request to generate http://www.w3.org/2006/10/02-ws-addr-minutes.html bob
- 22:01:15 [plh]
- zakim, bye
- 22:01:15 [Zakim]
- Zakim has left #ws-addr
- 22:01:22 [TRutt_]
- TRutt_ has left #ws-addr
- 22:01:22 [bob]
- philippe, thanks for scribing
- 22:01:53 [plh]
- welcome, I hope I didn't a bad job at it. the last 30 minutes were difficult.
- 22:02:05 [plh]
- now I need a good rest
- 22:02:13 [plh]
- (if it's ok to use this word :)
- 22:03:11 [bob]
- take one and get well
- 22:03:37 [bob]
- hodid the meeting help?
- 22:06:34 [bob]
- bob has left #ws-addr