Stepping back a bit ...

In the interest of getting through this whole MAP extensibility thing, 
I'd like to step back and try to describe the high points as I see 
them.  I'm trying to give a little background for my reasoning here, and 
not necessarily argue for one proposal or another.

One thing that jumps out from looking at MAPs is that the extensibility 
is inconsistent.  On the one hand, we have an open [relationship] 
property allowing for messages to relate to each other in arbitrary 
ways.  We predefine "reply" as a relationship and say that replies and 
faults are both replies, but we explicitly allow for other patterns.  We 
also define [reply endpoint] and [fault endpoint], but /don't/ allow for 
other possibilities.  Maybe there's no benefit from calling out an 
endpoint in the MAPs, in which case the point is moot.  But in that 
case, why define [reply endpoint] and [fault endpoint]?  If there's any 
benefit to defining them in WSA as opposed to elsewhere, that benefit 
should be extensible.  I explore possible benefits a bit below.

Another question that arises about MAPs is, how do they manifest?  As I 
understand it, we map them to SOAP properties, and these in turn will 
generally become headers.  This certainly accords with the example in 
section 3.2, which is the classic "async request/reply" use case.  
However, that can't be the whole answer for classic SOAP/HTTP, or for 
any other SOAP request/reply MEP binding that comes along.  SOAP/HTTP -- 
the 99% case as far as I know -- already works fine without a reply-to: 
header present.  Further, the SOAP 1.2 binding in section 6.2 doesn't 
mention a "replyTo" or "faultTo" property that we could latch onto, and 
SOAP 1.1 doesn't even try.  In short, there seem to be two options:

   1. Require that [reply endpoint] and [fault endpoint] manifest as
      headers.  Unless I missed something, this would mean that
      practically all existing traffic would be regarded as
      non-compliant with WS-A, which could slow adoption.
   2. Deal with existing traffic as it is, and say that, for example, an
      HTTP POST request has the [reply to] property of "the back
      channel", though this is nowhere manifest in the message (until
      you go digging into TCP headers).  This seems more sensible, and
      also seems to be what we're driving at with the "anonymous" EPR.

But in the second case, why does it matter?  If I have an existing 
SOAP/HTTP request/reply service, my clients already know how to 
correlate messages, and I already know where to send replies and 
faults.  We can talk about the [reply to] MAP floating over all this, 
but who cares?

And in fact, what if I define an "async request/reply" service?  If I'm 
advertising the service, I get to advertise the semantics.  I can say 
"If I see a header called 'ReplyTo', I'll send replies there.  
Otherwise, I'll send them back to the requester.  If I can't figure out 
how to do that (some bindings may allow for this, some may not), you're 
hosed."  This has the same semantic effect as trying to define a [reply 
endpoint] MAP, but it's more direct in that it defines default /behavior 
/directly instead of trying to define a default /value/ and then 
defining behavior in terms of value.  (insert Latin epigram here).

As far as I can tell, the only place this distinction could matter, and 
the only place endpoint MAPs matter, is if we want intermediaries to be 
able to do the right thing with messages without knowing what MEP the 
ultimate sender and receiver are participating in.  If we want to enable 
this, there are all kinds of interesting questions to deal with.  For 
example:

   1. Can the intermediary know just from looking at the message what
      endpoints might get further traffic due to this message?  If so,
      and none of them is the back channel to the sender, then that
      back-channel can be closed.  In any case, the intermediary might
      be able to send routing hints down the line.
   2. Suppose the message is being sent reliably.  The intermediary is
      participating in <your favorite reliability protocol> and thus may
      produce reliability-related faults.  Should those faults go to the
      [fault endpoint] (if any), or to an administrative endpoint for
      reliability, or possibly both?
   3. What about security faults?  Certain security faults may convey
      sensitive information by their mere presence (the problem of
      over-friendly error messages).  Again, the "security fault"
      endpoint may not be [fault endpoint], or at least the disposition
      of security faults requires special care.

This is all speculative, but if we allow for such a scenario at all, the 
presumption has to be that anything we haven't specifically been able to 
rule out could happen.  It may well be the case that there aren't that 
many fundamental questions with this scenario, or that they're all 
easily answered, but whatever the case, they all appear out of scope for 
the WS-A core.  The core should only be concerned with not making such 
questions harder to answer, to the extent that we can assess that.

(2) and (3) above argue that, even if request/reply is the only MEP in 
the world, there may be cause for further message-routing EPRs to be 
attached to a message by reliability modules, security modules and 
such.  (1) argues that it would be good if an intermediary could tell 
just by looking what EPRs might carry messages.  In retrospect, one 
obvious way to do this is the same way we did with EPRs:  There, we 
pre-define basic parts of the EPR and give them element names in the 
wsa: namespace, and we also provide an attribute in the wsa: namespace 
that tags a header as belonging to the "reference parameters" 
extensibility point.  Here, we would leave the basic parts pre-defined 
as they are, and define another attribute for the "other endpoints" 
extensibility point in MAPs.

An intermediary then knows that "ReplyTo" and "FaultTo" may carry 
traffic, and so can anything tagged with the wsa:otherEndpoint (or 
whatever) attribute.  Further, in a profile that requires /all/ 
potential endpoints to be present, if only tagged with "backChannel", an 
intermediary can make assumptions about what channels will /not/ carry 
traffic, and optimize accordingly.