Re: Anon / RM MakeConnection: response to Doug

Alastair Green <alastair.green@choreology.com> wrote on 08/09/2006 
03:29:42 AM:
> Thanks for your detailed response. For me at least this is 
> clarifying. Point by point:.
> 
> A. You view MC as passing an EPR. But it's a very odd EPR.

No, it passes in a URI or an RM Identifier.

> 1) It is constrained to the address (has no way of communicating ref
> params). You maintain that we can and must pass be able to pass ref 
> params.  How, where?  There are two possible elements in wsrm:
> MakeConnection -- wsrm:Identifier and wsrm:Address. Where is the 
> space for reference parameters in wsrm:Address? 

We purposely avoided asking for comparision of ref-p's - hence no
ref-p's passed in on the MC.  However, there are ref-p's on the full
EPR that was given to the service (e.g. replyTo or targetEPR in the e.g.)
and those will be echoed back in the message is sent back because of
the MakeConnection.

> 2) It means: "use the transport response".

Just like WSA's anon.

> 3) It is computable from a subset (the UUID), and it is therefore 
> not necessary to pass it in its entirety. Or to put it another way, 
> precisely because we can't pass a full EPR, we only need to pass a UUID.

We avoided asking people to do substrings of URI comparing.  While
technically the UUID is all that might be needed to pass around we
decided that asking people to do URI comparing is far more natural
when talking about identifying Web endpoints.

> All comments to the effect: the UUID alone is not sufficient, is 
> irrelevant etc, are rendered moot by point 3). 

Not really - since the RM spec says you must compare the full URI
the UUID does, sort of, become a minor issue.  It just becomes
part of the uniqueness of the URI.  My main point in trying to
convey the irrelevance of the UUID is that you seemed to want to
tie it to the applications somehow and that is totally wrong. You
can not tie it any more or less to the application than you could
with an EPR that points to www.ibm.com.  Perhaps I was reading too
much into your previous notes, but when you started to talk about
the UUID being used to identify the Subscription it lead me down
this path.

> If the URI equals well-known constant A, suffixed by variable UUID, 
> then it is absolutely unnecessary to pass A, and only necessary to pass 
UUID. 

That's just a syntactical sugar kind of difference.

> To put this another way: MakeConnection is not really an RM 
> mechanism, it is an application mechanism. RM is defining something 
> that WS-Addressing really ought to define. The channel can be used 
> to send application messages of any description.

WSA could very well have defined this mechanism but it didn't. 
RM saw a critical need for it, no one was trying to address it, so...

> Overall, I think the mental model "pass an EPR, and then receive 
> communication back to that EPR" does not match what is in the spec. 
> What the spec actually says is: send me a reply to this request 
> (where the reply may simply be a receipt ack). The correlation or 
> addressing is given by the transport response. (Which is why, 
> ultimately, the connection identifier/UUID, however carried, is 
> unnecessary: it is purely application context, which RM is giving 
> house room to.)

To be honest you lost me :-)   But I think I disagree. 
The RManonURI is not application context - it uniquely identifies
an endpoint - just like most other URIs (anon/none being the most
obvious exceptions).

> B. "The UUID does not identify the subscription, it identifies the 
> stream of messages from producer to consumer". Actually the UUID 
> identifies a channel whose scope/ meaning is application-defined. It
> is an app-level context. Creating more complicated application 
> examples doesn't clarify -- it just adds redundant detail.

Disagree. If the same RManonURI were used across lots of different
applications (which it can be) what does that do to your assertion
that its application-defined?  Again - is an EPR with www.ibm.com as
its wsa:Address application defined when I pass that in on a
Subscribe()?  I don't think so.  Its use, in terms of what messages
will be sent to that EPR, is application defined - and RManonURI
is no different.

> C. If "UUID" is the identity of the "stream", and the stream is 
> constructed by two application parties, then the use of UUID is a 
> way of ensuring that the parties aren't lazy, but the UU bit is not 
> necessary. It's a BUID -- bilaterally unique ID. Secondary point.
> 
> D.  I said that the publisher needs to know that all traffic on this
> stream is related to the passage of the content relating to this 
> subscription. In the context of RM, traffic establishing sequence 
> etc is indeed related to the passage of the content relating to this
> subscription. I did not say "traffic which is application data only,
> and has nothing to do with RM context or apparatus". In other words,
> we are violently agreeing.
> 
> E. How can anon=required refer to the set up message? WS-Addressing 
> has no concept of a message that passes by out-of-band (application)
> means the need to respond on the back-channel. That is a process 
> which cannot be specified by WS-A means: it requires RM-level 
> specification, or an amendment to WS-Addressing.

This is the heart of the issue.  WSAW anon refers to "all response
endpoint EPRs in a message" - this to me says it controls what can go
into the wsa:ReplyTo EPR. And RM would like to put some other
anon URI in there.

> F. I take reference to CloseSequence (which embeds Identifier) to 
> mean: "Yes, it's true that sequence Identifier is a proxy for UUID 
> (application stream identity). Yes, it's true that the RM URI plays 
> no part in the sequence case".
> 
> G. The [destination endpoint] splits into wsa:To (the address) and 
> wsa:ReferenceParameters. Putting the UUID in the address is not 
> "just like normal EPRs". It is precisely unlike normal EPRs, which 
> put the routing/contextualization in another element, and keep the 
> address for the transport-level address.

RManonURI is a transport-level address just as much as anon is :-)

> H. I think that you and Chris are straining far too hard to deny 
> that MC induces responses. Each and every MC invites a response. The
> response may be empty (the ack alone). So what? By this "physical" 
> means (solicit message, solicit message, solicit message) we create 
> a logical stream of "message, message". 

It would be a lie to say we don't want messages to flow back on the
wire as a result of a MC.  But those messages are _NOT_ responses to
MC - they are (and I'm a bit afraid to say this, but here goes) more
like new one-way messages - in the same way that a message sent to
a non-anon EPR is a new one-way message.  The message
flowing in the non-anon EPR case may be a request or a 
response message but it is carried over an HTTP request flow. MC
is no different except the message is carried over an HTTP response
flow.  We are very careful to say that it is not a response to
the MC because it isn't.  Is it simply establishing a connection
and providing some correlation data so the receiver knows who is
at the other end of the connection.  It is no different than the
non-anon EPR case except the other side initiated the connection.
Perhaps we haven't made this clear, but we never expect any application
code to ever process the MC - this would typically be handled by
the infrastructural layer (not required but typically).  Maybe you
didn't realize this and that's why you think the app gets involved.
Just like the "resend until acked" part of RM doesn't typically impact
the application, the use of MC doesn't either.

> I. Example 1b. Where is the wsa:To? It defaults to the anonymous 
> URI, like wsa:ReplyTo. No need to state on the wire.

Oh yea, I forgot WSA did that.  No comment on that one  :-)

> J. Example 2b. How did ConnectionIdentifier get into the message? 
> Because the sender of the back-channel response read the MC element,
> and found the sub-element ConnectionIdentiifier ... and reflected it
> back. Just like reflecting back the sequence Identifier.

You lost me because I don't understand how it go into the message
before the MC arrived and I think that's critical. But I think its
a tangential issue.

> K. An RM header called Connection Identifier is no more a reference 
> parameter than sequence Identifier. The app needs to establish a 
> non-opaque context for the stream or relationship. This is analogous
> to passing transaction context id explicitly in WS-Coordination 
Register. 

RM decided that creating a well-defined ref-p would be bad.

> L. To must equal ReplyTo legal because this is a one-way. If [reply 
> endpoint] = none URI, then true. Thus far, [reply endpoint] was 
> defaulted to anon URI, so not true. But see response to Chris and 
> Paul re [reply endpoint] = none.

One more time - the message sent because of a MC is not a response to
MC.  Any WSA headers in that message are defined by the application
or the WSA processing rules - not by RM or the MC operation.  This is
no different than how any message gets its WSA headers.