MAPs and SOAP

I've been going back through the core and SOAP specs after today's 
discussion, and I'm still concerned about the difference between 
reply/fault and any other kind of endpoint.  I also have an at least 
partially worked out example below the horizontal line, which I'd 
encourage everyone to look through and comment on even if the concerns 
below hold no interest.

To take Dave O's example, as I understand it, if I have a MEP that's 
basically request/reply but also has an alternate reply, then two of the 
three endpoints are considered MAPs, have properties defined for them in 
the SOAP addressing module, and appear in the wsa:namespace.  The third 
is just some random SOAP header.

While it is true that one can always put an EPR wherever one wants, 
whether as a header or in some distinguished place in the body, or 
someplace out of band for that matter, it still seems strange to have 
such an asymmetry instead of somehow allowing for an extensible set of 
endpoints.  It seems particularly strange when we explicitly make 
[relationship] extensible.  We could just as well have (and maybe once 
did have?) an [in-reply-to] property and depend on SOAP extensibility 
for anything further.

I would think that the reasons for making [relationship] extensible are 
the usual ones: People are bound to define relationships other than 
in-reply-to, and we would like to give them a standard place to put 
those, in such a way that a processor could generically gather "all 
related messages" from a message without having to understand what 
in-reply-to and whatever other headers mean.  I'm not precisely sure 
what the use case would be for this, but it seems like a good thing overall.

I'm hard-pressed to see why it wouldn't be equally good to do the same 
thing with associated endpoints.  As with [relationship], one could then 
generically determine what endpoints might be expected to receive 
messages due to a given message, without having to understand what my 
custom "alternate-reply" header means (or assume that any unknown EPR in 
a header is liable to carry ongoing traffic).  This might make routing 
easier, or help predict traffic volume, or have entirely other uses.  If 
anything, this seems like it might be more directly useful than handling 
[relationship] generically.

If nothing binding documents for new interactions might be somewhat 
easier to read.  Along those lines, here is a draft of what an 
"in-out-alternateOut" MEP might look like under the status quo.  I'm 
neither endorsing nor disparaging this version (at this point).  I'm 
more interested in whether this looks about right so far as what would 
be required.  Any feedback would be welcome.

------------------------------------------------------------------------


        XXX. In-out-alternateOut

This is a two-way MEP. A reply is expected hence mandating [reply 
endpoint] in the request message. The response message might be a 
fault.  */In addition, an alternate reply may occur, hence mandating 
[alternate reply endpoint] in the request message.  The [alternate reply 
endpoint] property is an abstract property like the standard Message 
Addressing Properties.  If present, it MUST be mapped to the SOAP 
yatns:AlternateReply header, analogously to the mapping of Message 
Addressing Properties described in sections 3 and 4 of the WS-Addressing 
SOAP binding.
/*

*/When formulating an alternate reply, follow the rules in section 3.2 
of the WS-Addressing Core Spec (Formulating a Reply Message), but with 
rule 1 carrying the following additional clause:
/*

    * */If the reply is an alternate reply message, select the EPR from
      the incoming message's [alternate reply endpoint] property. If
      none is present, the processor MUST fault./*

*/
/*

Table xxx-1. Message addressing */and other /*properties for in message. 
Property 	Mandatory 	Description
[destination] 	Y 	Provides the address of the intended receiver of this 
message
[action] 	Y 	Identifies the semantics implied by this message
[source endpoint] 	N 	Message origin. Unused in this MEP, but may be 
included to facilitate longer running message exchanges.
[reply endpoint] 	Y 	Intended receiver for the reply to this message.
/[alternate reply endpoint]/
	/Y/
	/Intended receiver for alternate replies to this message./
[fault endpoint] 	N 	Intended receiver for faults related to this 
message. May be included to direct fault messages to a different 
endpoint than [reply endpoint].
[message id] 	Y 	Unique identifier for this message. Used in the 
[relationship] property of the out message.
[relationship] 	N 	Indicates relationship to a prior message. Unused in 
this MEP, but may be included to facilitate longer running message 
exchanges.


*/
/*
Table xxx-2. Message addressing /*and other */properties for out 
message. Property 	Mandatory 	Description
[destination] 	Y 	Provides the address of the intended receiver of this 
message
[action] 	Y 	Identifies the semantics implied by this message
[source endpoint] 	N 	Message origin. Unused in this MEP, but may be 
included to facilitate longer running message exchanges.
[reply endpoint] 	N 	Intended receiver for replies to this message. 
Unused in this MEP, but may be included to facilitate longer running 
message exchanges.
/[alternate reply endpoint]/
	/N/
	/Intended receiver for alternate replies to this message.  Unused in 
this MEP, but may be included to facilitate longer running message 
exchanges./
[fault endpoint] 	N 	Intended receiver for faults related to this 
message. Unused in this MEP, but may be included to facilitate longer 
running message exchanges.
[message id] 	N 	Unique identifier for this message. Unused in this MEP, 
but may be included to facilitate longer running message exchanges.
[relationship] 	Y 	Indicates that this message is a response to the in 
message using the in message [message id] value and the predefined 
|http://www.w3.org/@@@@/@@/addressing/reply| IRI.


*/
/**/
/*
Table xxx-3. Message addressing /*and other */properties for 
alternateOut message. Property 	Mandatory 	Description
[destination] 	Y 	Provides the address of the intended receiver of this 
message
[action] 	Y 	Identifies the semantics implied by this message
[source endpoint] 	N 	Message origin. Unused in this MEP, but may be 
included to facilitate longer running message exchanges.
[reply endpoint] 	N 	Intended receiver for replies to this message. 
Unused in this MEP, but may be included to facilitate longer running 
message exchanges.
/[alternate reply endpoint]/
	/N/
	/Intended receiver for alternate replies to this message.  Unused in 
this MEP, but may be included to facilitate longer running message 
exchanges./
[fault endpoint] 	N 	Intended receiver for faults related to this 
message. Unused in this MEP, but may be included to facilitate longer 
running message exchanges.
[message id] 	N 	Unique identifier for this message. Unused in this MEP, 
but may be included to facilitate longer running message exchanges.
[relationship] 	Y 	Indicates that this message is a response to the in 
message using the in message [message id] value and the predefined 
|http://www.alternate.org/addressing/alternateReply| IRI.


*/
/*