See also: IRC log
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: 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
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]