Request/reply/reply

This is not a formal issue (yet :-) but a request for clarification:

In section 3 we claim: "Message addressing properties collectively 
augment a message with the following abstract properties to support one 
way, request reply, /and any other interaction pattern"/ (emphasis added)

Suppose I invent an interaction pattern, perhaps described in some 
choreography notation, where an incoming message may produce further 
messages to be sent on to one of two third parties (or may produce a 
fault).  Perhaps one endpoint would be for normal processing and another 
would be for special handling.  It would be nice to talk abstractly 
about the MAPs of the initiating message as having something like 
[normal endpoint] [special handling endpoint] and [fault endpoint].

How would we fit this into the existing framework, or could we?

Put another way, it seems like the real core of MAP is [source], 
[destination], [message id] and [relationship].  Every message has a 
source and destination, and message correlation requires message ID and 
relationship.  As I've said, I have no problem with including the rest 
of the current definition in the core, as convenient hooks for the 
well-known case of SOAP/WSDL request/reply.  My concern is that we 
neither preclude more exotic situations such as the example above, nor 
burden simple one-way messaging with properties that don't concern it.

 From this point of view, [reply endpoint], [fault endpoint] and even 
[action] are best seen as pre-defined extensions within a framework.  
That is, if we /hadn't/ defined them in the core, we /could have/ done 
so without having to change the core.  So my request for clarification 
is, if the existing core were to be adopted without any mention of 
[reply endpoint], [fault endpoint] or [action], how would we, or could 
we, define them without having to change the core?