Re: What problem are we trying to solve?

Here are the semantics of anonymous response endpoints (i.e., [reply
endpoint] and [fault endpoint]).  To be brief, I'll just cover [reply
endpoint].  The handling of [fault endpoint] is basically the same.

The core just says that [reply endpoint] denotes "the intended receiver
for replies to this message" and places some requirements on the
contents of such messages (e.g., the [relationship] to the [message id]
of the original message).

However, section 5 of the SOAP binding defines the semantics of
anonymous in such cases.  In particular, for SOAP 1.2 it says that if
you use a response endpoint with an anonymous address, "then any
response MUST be the http://www.w3.org/2003/05/soap/mep/OutboundMessage
property of the /same instance/ of the SOAP request-response MEP".
(italics mine).

Section 5 doesn't talk about none, presumably since the core already
says that it means not to send anything.  This behavior is implicitly
covered by section 5.2, which says that if the [address] of the response
endpoint is not anon, the response "SHOULD NOT be the
http://www.w3.org/2003/05/soap/mep/OutboundMessage property of the same
instance of the SOAP request-response".  If no response is sent at all,
that certainly fits.

Further, section 5.2 says "Note that other specifications MAY define
special URIs that have other behaviors (similar to the anonymous URI)."

As I recall, the idea behind this was specifically to cater for cases
like RM's, where related messages would be sent as the
.../OutboundMessage property of /any of several/ instances of the SOAP
request-response MEP.  Using anon in [reply endpoint] in such cases runs
counter to both section 5.1 (which says how anon should behave) and 5.2
(which encourages the creation of other URI).

That leaves the WSDL issue.  As I've said, it looks to me like the
wsaw:Anonymous marker could use a bit of re-work.



Doug Davis wrote:
>
> Bob,
> > Doug,
> > The list is what I heard from the folks on the call.  It is intended
> > to provoke discussion and possibly correction.
> > The question of priority is if the exposition is the correct
> > description of the problem to be solved.
> > There was also discussion of a potential errata that would remove 5.
> > 2.1 which I did not include in my summary.
> > For now, I would be content to have a well characterized definition
> > of the problem so that it might be bounded.
> > Several folks have expressed reservations about synonyms for
> > anonymous.  If it is intended that anonymous identify a specific
> > resource (such as the backchannel).  It then would make as much
> > sense as defining a synonym for www.cnn.com.
> > More than that, some folks have said that this synonym overloads
> > replyTo and defines semantics associated with a definition of this
> > uri that only RM will understand.
>
> It doesn't overload ReplyTo any more than switching from
> http://www.cnn.com   to  smtp://cnn.com   overloads it.
> There are transport level semantics associated with each URI
> that relate to how the message is transferred from one endpoint
> to the other. The semantics of ReplyTo are totally unchanged when
> the RM anon URI is used.  It still means it contains the EPR of
> the destination endpoint for replies.  If I have an EPR with
> an address of http://www.cnn.com  but it also includes a policy
> assertion that tells it to use RM - meaning send a CreateSequence
> first, add a Sequence header to the app msg, and then send a
> TerminateSequence, this one policy assertion greatly changed the
> MEP used to transfer the message but it did not redefine the
> semantics of ReplyTo - did it?  I would hope not.  The
> RM anon URI is no different - it controls the transport layer
> interaction between two endpoints - it _does not_ redefine
> ReplyTo in any way.
>
> > Do you disagree with the exposition?  Does the RM redefined URI
> > convey identifying or parametric information or does it not?
>
> It doesn't matter :-)  Whatever information it may or may not
> choose to convey is outside the scope of what WSA or ReplyTo
> needs to understand.  All that needs to be acknowledged is that
> its a special URI (just like anon and none), let the piece of
> code that wants to understand that URI deal with it.  All the
> soap stack needs to know is who to give the message to when it
> sees a special URI.  In the anon/none case it gives it to WSA
> aware code and in the RManonURI case it gives it to RM code.
> We're not asking for WSA to understand RM, we're asking for
> WSA to provide the hooks for other specs to have the same
> flexibility that WSA provides for itself.
>
> > Thanks
> > -bob