RE: What problem are we trying to solve?

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