Action items

---

2006-08-21: cr31 - Tony Rogers to implement CHANGE 1&2 to the table in

preparation for CR-31 PENDING

<pauld> revised table from TonyR: http://lists.w3.org/Archives/Public/public-ws-addressing/2006Oct/att-0003/cr31.html

Tony: need more input from the Working Group

<pauld> Paco and Anish outlined proposal for cr33: http://lists.w3.org/Archives/Public/public-ws-addressing/2006Oct/0002.html

Bob: Anish and Bob action item is on today's agenda. I propose that we take some steps back

previous minutes

Previous minutes: http://www.w3.org/2002/ws/addr/6/09/25-ws-addr-minutes.html

RESOLUTION: Previous minutes approved

Anish: our proposal is more an outline than a full proposal

Time to reflect on what problem we are trying to solve wrt cr33

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.
... wanted to know where folks want to focus their energy

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.
... ie don't use it as extensibility points
... I'm tempted to ask for an erratum for extensibility

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.
... "use the back channel since there is no address, but there is an identifier"

Anish: Jonathan, are you thinking asking for isAnon?

Jonathan: no, but we say that only none and anonymous are special

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.
... people want to change where the response goes and we haven't give the ability to do so.

<GlenD> +1 to Anish's points

Anish: ws-rx realized that the soap binding isn't very useful as-is.

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.
... rewording the document might be useful. +1 to Jonathan: the only special URIs are the one we define.

<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 ref Parm with queueid in an epr with wsa:anon address could work

Paco: The anonymous marker was badly designed. It is restrictive. That seems a shortsighted approach. We have to plan for composability.
... from my point of view, it does make to look at a better semantic.

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).

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.

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.
... there is no way to mark that a URI is special.

<anish> ... and they are special in the same way (back channel)

Glen: a solution could have been not include anything in the reply

Marc: the distinction between ref props and ref params is a distraction, since there's the same for the receiver. RM is overloading ReplyTo.
... the URI for anonymous is well-defined.

Jonathan: addressing and identification is still confusing here. RM doesn't make use of the addressing functionality.

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.

<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

Anish: the fact that MakeConnection is one-way and still use the backchannel is a common pattern in RM.
... the problem is about wsaw:Anonymous. Do we want to mean something specific about our anonymous URI, or to use the backchannel?

<GlenD> Anish - excellent way to frame that. Thanks.

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

<TRutt_> 5.2.1 states "Note that other specifications MAY define special URIs that have other behaviors (similar to the anonymous URI)."

Tony: it was suggested that they use the from header to identify who they are.

<Katy> In an ideal world RM should have defined their own 'replyTo' for RM semantics (not URI as minuted)

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.

<Jonathan> FWIW, the statement Tom quotes is the one I'm tempted to delete through errata.

Anish: you don't have the value in the from present in the response message.
... [explains WS-RM]

Bob: they're making use of the from as a hack as well.

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.
... I'm not a big fan of ignoring it
... we should try to address their use cases
... re distinction between ref props/ref params was meant for identification. We prevented people from using EPR as identifiers.

<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)

David: the other idea was to bring some other kind of identifying information, licensed to be used for EPR comparisons.

<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.

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?

Tom: until recently, some people thought that backchannel and anonymous were the same thing.

<mlittle> +1

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

<pauld> a brick is a brick is a brick

Paco: WS-Addressing didn't really define how the semantics apply to the protocol.

<mlittle> Speaking as one of the editors of WS-TX, I agree. We've not had any problems with wsa.

<MrGoodner> Thanks, I'm an editor in SX and can't think of any problems with SC or Trust either

Paco: if we want to have a useful marker, we better focus on the backchannel

<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 ;-)

<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)

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)

Bob: we could go in and add ref props. We could change the way we restrict ref params so that people will use them.
... we could suggest that they use their own replyTo. Or come up with new attr/elts for identification purpose.
... Or clarify the meaning of wsaw:Anonymous
... setting aside the WSDL marker discussion ...
... the specific use case is "attempt to provide some identifying information while expecting a response from something"
... is there anyway we can do this in a normative way in our specification?

<mlittle> +1

<Jonathan> Not sure what you're saying Bob, but it sounds scary!

Paco: we explicitly decided to stay out of the identification business. that would be a big change of direction...
... re opaque. you don't want to build a dependency onto a particular structure.

Anish: I interpreted opaque to mean opaque to anybody but the minter.
... all those options are about changing Core or SOAP binding. Is that correct?

Bob: not entirely sure yet
... 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.

Gil: I can basically use ref params and no worry about unintended side effects.
... 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.

Bob: TX spits it back as a To

Gil: RM didn't want to change implementations.

<anish> that would mean that TX does not use replyTo and instead uses From

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.

<mlittle> TX defined that all messages patterns are really one-ways. There are responses, but they are application level messages.

<mlittle> +1

<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.

[...]

<mlittle> There are probably 1 or 2 places in the entire WS-TX specification where ReplyTo makes sense: those interactions are request-response.

Anish: from an RX point of view, they can't do this. they're trying to make request/response MEP reliable

<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?

<mlittle> +1

<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

Paul: we shipped our Core and SOAP. I'm not hearing that we're broken.

<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)

Tom: the key issue is to put identification on anonymous URIs.

<mlittle> Anish, ok so they should change and use wsa:From ;-)

<anish> mark, ... and define a new SOAP header that will be present in the response message?

MarcG: the RM are trying to initiate the response/request pattern.

<TRutt_> I do not think the wsa group should try to be the wsrx group

Bob: do we agree that the problem is about the need of transfer identifying information?

Jonathan: that may be the problem, but I saw other solutions who were able to do RM without this.
... (see PAOS)

<Zakim> anish, you wanted to say that PAOS does not work

<pauld> notes we have messageIds and an extensible relatesTo to provide correlation

Jonathan: would like to see a model for the polling behavior used by RM

Tom: if we agree that you shouldn't put identification in the anonymous URI, we might want to change 5.2.1.

<Jonathan> +1 of course ;-)

Bob: do we think that folks should be allowed to put identification information in the anonymous URI?

Anish: meaning the ws-addressing uri?

Tom: in 5.2.1

Bob: right now, they're trying to use their own URI to indicate the use of the backchannel?

Katy: the answer to that question might depend on whether we provide alternative solutions
... without any, we would want to allow identifying info in anon URI

Tom: we should on the long term here. If we told they couldn't this, that will force them to do something else.

Gil: I think we're asking the wrong question: How deeply into this identifying thing do we want to get?
... addressing URI represents addressing and backchannel
... should we separate those two?

Bob: if we stay out of the identity business, should we provide alternative ways? The specific resource that anon URI identifies is backchannel.
... but we didn't say anything about the general URI

Paco: many reason to stay away from identity business. It makes sense to try to use URIs for that effect.
... I don't see much value in creating a template

<TRutt_> Tony hit it: they are trying to extend to back channel to allow responses from earlier requests!

<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

<MrGoodner> they are also trying to enable initiating new requests as the response to the make connection request

Gil: they created a template for anon URIs and they're asking us to recognize it as the anon URI.

<GlenD> That concept doesn't actually make sense unless you understand RM anyway, right?

<MrGoodner> enabling the responses to previous requests works without the need for the RM anon URI

Tom: they're trying to use the backchannel for earlier requests.

MarcG: RM anon URI was added as an alternative for initiating a new request

Bob: so is Anon URI with identifying information legal? Is there an error with trying to generate your own version of Anon?
... should we solve this?

MarcH: you can always use a SOAP header!

Katy: but that SOAP header wouldn't be pass back

MarcH: you can say it has to be echoed.

Tony: they want something that magically appears in the response

Tony: they want to encode it on the message going back
... ref params are opaque only at the WS-Addressing level
... RM shouldn't have to consider them open

Glen: the RM URI doesn't make sense to non-RM implementations
... the way we define anon is to make sure to connect the reply in a WSDL req/resp MEP to the request.

<TRutt_> +1 to glen

Bob: the MEP that they use is unique

Gil: the idea of pushing RM into the addressing layer. RM source and RM destination are asymmetric in their behavior.
... THE RMS is trying to reach the RMD as best as it can.

<gpilz> the RMS and RMD are asymmetric in their behavior

<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

Tony: RM wants something that is already being sent back. They want to pass the identifier with minimal effort
... they really need to operate as a separate layer on top of addressing.
... expecting the state of RM to be passed around in the addressing URI seems wrong.

<pauld> +1 I want to use Addressing without RX, but RX layers Addressing, so has to work within its constraints

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.

Bob: is this proposal something we ought to consider as a WG response?

Tom: any formal thing would be counter productive move for the moment

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

Bob: ok not to send a formal response but we need to have the dialog open.
... I still didn't hear that we need to fix something?

Tom: we never thought of anonymous address carrying identifying information

Tony: I think the id should be carried an other way

<scribe> ACTION: Bob to enumerate the alternatives for cr33 [recorded in http://www.w3.org/2006/10/02-ws-addr-minutes.html#action01]

[adjourned]