Re: What problem are we trying to solve?

Speaking in support of option A5 and option A6.  There are two issues
here: the behavior (for which A5 seems appropriate) and how to advertise
the behavior (for which A6 seems appropriate).

The WSA core mainly defines two things: EPRs and MAPs.  For my money
EPRs are the real core.  I've seen them used in several different places
without apparent problem.

MAPs and the rules for processing them are more an application on top of
EPRs.  I would include anon and none as part of this application as they
only have meaning (or at least we only give them meaning) in the context
of a particular interaction.  The whole notion of using anon as a name
for a resource with no name and none as the name of an endpoint that
doesn't exist has always had a certain Zen-like quality for me.  As far
as I can tell they're just markers telling the receiver to behave in a
particular way.

As such, I don't see anything particularly sacred about the MAPs and our
magic URI.  If they work, go ahead and use them.  If it hurts, don't do it.

Even after exposition and much discussion I'm still a little unclear on
exactly what behavior is desired, but as far as I can tell it's either
the behavior described in section 3 or it's something else.

If, for example, you want to send some cookie with your message, and
you're expecting a reply back, and you want that reply to come back as
the response half of an underlying SOAP request-response, containing
that cookie, then use anon reply-to and include a ref param in the
anon.  I don't think this is what RX wants.

On the other hand, if you want to send a one-way message containing a
cookie, and you want future one-way messages containing that cookie to
receive certain information in the response half of an underlying SOAP
request-response, then don't use [response endpoint] to convey any of
this.  It doesn't behave that way.  Use some other header/property to
request this behavior.  If the only reason for this property is to
request piggybacking on the response message, then I don't think anon
needs to be mentioned at all.  If there is one variant of this behavior
for piggybacking and one for sending to a third party at a given EPR,
then anon might be useful.

As for advertising, the wsaw:Anonymous marker refers to the use of anon
in /response endpoints/ ([reply endpoint] and [fault endpoint]).  If you
buy that neither one of them should be used for the one-way messaging
use case, then it doesn't matter what restrictions the anon marker
places on their use in those endpoints.

Strictly speaking, there's no need to change the WSDL binding at all to
accommodate headers besides what we define.  However, making our markers
more composable with Policy seems like a good thing anyway.  If done
right these markers could also be re-used to say things like "I can send
this particular RX information, as described in header wsrx:Foo, either
to a given EPR or as the response half of an underlying SOAP
request-response.