NEW ISSUE: Handling arbitrary sets of associated endpoints

Title: Handling arbitrary sets of associated endpoints.

Description: Asynchronous applications may define interactions in which 
an incoming message may produce outgoing messages to any number of 
different endpoints.  To take a concrete example, a service may be 
required to receive a message and do one of

   1. Send a fault to a fault destination.
   2. Send application data to a "normal processing" destination.
   3. Send (possibly different) application data to a "special
      processing" destination.

Obviously arbitrarily many variations are possible.

It is not clear from section 3 of the core spec exactly how to handle 
this in terms of Message Addressing Properties.  If it is possible, the 
text should make clear how interactions beyond the well-known cases of 
one-way and request/reply may be realized.  If, as it appears, the 
Message Addressing Properties cannot cover such cases, they should be 
amended to do so.  If such interactions are out of scope, which appears 
doubtful, this should be clarified.

Justification: The WSA charter dictates that "The components must be 
extensible to enable other mechanisms such as new kinds of relationships 
between correlated messages, policies, or service semantics to be built 
upon Web Services Addressing." and section 3 amplifies this, saying that 
"Message addressing properties collectively augment a message with the 
following abstract properties to support one way, request reply, and any 
other interaction pattern:"

Target: core, with some impact on bindings

Proposal:

Review section 3 and either demonstrate a direct means of handling use 
cases such as the above, or determine that they cannot be handled.  In 
the event that the current MAPs cannot cover cases such as the one 
above, I have proposed a modification [1] to MAPs to replace the ad-hoc 
[reply endpoint] and [fault endpoint] properties with a more general 
[associated endpoints] property (suggestions for a better name are 
always welcome), similar in structure to the existing [relationship] 
property.  We would pre-define IRIs designating "reply" and "fault" 
endpoints, just as we pre-define an IRI for the "reply" relationship.

I do not detail in that proposal how to bind this to SOAP, but the 
resulting headers should be of the form

<wsa:associatedEndpoint type="anyUri">EPR</wsa:associatedEndpoint>

where the @type attribute is the IRI component from the 
associatedEndpoint and the EPR child is the EPR component.  It would 
also be possible to special-case the SOAP binding of fault and reply 
endpoints to appear in SOAP as wsa:FaultTo and wsa:ReplyTo elements, if 
this is deemed necessary or desirable.

While it would be possible to implement this proposal without changing 
the existing descriptions of reply and fault endpoint semantics (e.g., 
default and anonymous destinations), it would be desirable to migrate 
these descriptions to the binding documents, which already cover much of 
the mechanics of request/reply.  I have proposed this, from the point of 
view of the core spec, in [2].  I would regard this as a sub-issue of 
the main issue, and again, the main issue can be resolved without 
implementing it.

References:

[1] 
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Mar/0078.html
[2] 
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Mar/0074.html