MEPs part I: WSDL

After considerable thought, I believe that the rules below will cover 
both synchronous and asynchronous forms of the existing WSDL MEPs and 
will extend smoothly to cover a number of generally similar interactions 
not currently described by WSDL, using existing SOAP extensibility to 
cover endpoint MAPs other than those defined in the core, and keeping 
the current form of the endpoint MAPs currently defined in the core.  
They are not quite those currently given in the core, but they are 
similar, and are compatible with them in a sense described below.

The guiding principle here is that the party advertising a service gives 
the terms of the contract and the party using the service may follow 
that contract however it sees fit.   The descriptions below thus 
describe what the service will do given the possible values (or lack of 
values) of the various MAPs.  This is exactly the information that the 
client needs in order to ensure interoperation with the service.   We do 
not directly specify the behavior of the client.  For example, there is 
no general statement that [message Id] is required if [reply endpoint] 
is present.  Instead, there are a number of ways to comply with the 
contract given, ranging from existing SOAP/HTTP behavior to full use of 
the MAPs defined in the core.

A final point:  In all interactions (even fire-and-forget in-only) there 
is always the possibility of a transport fault.  In an HTTP binding, 
this would include things like a 404 response as well as more basic 
failures like an unknown host name.  It would of course /not/ include an 
application-level fault reply.  A transport fault will generally refer 
to detailed information that will not be intelligible at this level 
(beyond knowing that something went wrong with the transport), but will 
presumably be intelligible to other layers.


      Request/Reply

    * All MAPs other than [destination] and [action] are OPTIONAL.
    * If the request message defines a [message Id], the outbound
      message's [relationship] MUST contain the pair (/in-reply //IRI//,
      ID)/, where ID is the [message Id] of the request.
    * If the outbound message is a reply and [reply endpoint] is
      defined, the outbound message MUST be sent to the [reply endpoint].
    * If the outbound message is a fault and [fault endpoint] is
      defined, the outbound message MUST be sent to the [fault endpoint]
    * Otherwise, if a [source endpoint] is defined, the outbound message
      MUST be sent to the [source endpoint] (see note 1)
    * Otherwise, if the binding defines a default means of delivering
      outbound messages, the outbound message MUST be sent by that means.
    * Otherwise, the message has been constructed inappropriately for
      the binding.  It will not generally be possible to signal this at
      message delivery time, but there will have been enough information
      in the WSDL binding to detect the situation prior to message
      delivery time.

Note 1: This rule is not strictly necessary, but it accords with the 
existing practice in email of defaulting reply-to: to from: and IMHO, 
allows for smoother extensibility to other patterns.  The overall 
approach will still work if this rule is omitted, or replaced (or 
augmented) by the rule defaulting [fault endpoint] to the [reply 
endpoint] (if any).

This formulation covers existing request/reply as a special case 
(assuming that the receiver can always extract an [action]), and it 
allows the client to include only the MAPs it needs.  There's no need to 
construct a message ID if correlation is handled by other means, and no 
need to give a reply address if it's provided by the transport.

A service following these rules will also be compatible with a client 
following the stricter rules described in the core.  In such a case, the 
client will always include a [reply endpoint] (since a reply is 
expected) and will always include a [message Id] (since the rules 
require it if [reply endpoint] is present).  The service will then be 
able to include the appropriate entry in the [relationship] property.  
As the existing rules on formulating a reply are unconstrained if [fault 
endpoint] is missing, the behavior described above is also compatible 
with them.


      Robust in-only

This is the same as request/reply, but without the rule for [reply 
endpoint].

    * All MAPs other than [destination] and [action] are OPTIONAL.
    * If the request message defines a [message Id], the outbound
      message [relationship] MUST contain the pair (/in-reply //IRI//,
      ID)/, where ID is the [message Id] of the request.
    * If the outbound message is a fault and [fault endpoint] is
      defined, the outbound message MUST be sent to the [fault endpoint]
    * Otherwise, if a [source endpoint] is defined, the outbound message
      MUST be sent to the [source endpoint] (see note 1)
    * Otherwise, if the binding defines a default means of delivering
      outbound messages, the outbound message MUST be sent by that means.
    * Otherwise, the message has been constructed inappropriately for
      the binding.  It will not generally be possible to signal this at
      message delivery time, but there will have been enough information
      in the WSDL binding to detect the situation prior to message
      delivery time.


      In-only (fire and forget)

    * All MAPs other than [destination] and [action] are OPTIONAL.
    * And that's it.


      Other patterns (e.g., request/reply/alternate,
      initial/normal/urgent etc.)

The service advertising such a service can set any contract it likes and 
define whatever properties it likes.  However, the pattern given above 
would provide a useful starting point, with modifications shown in bold:

    * All MAPs other than [destination] and [action] are OPTIONAL.
    * If the request message defines a [message Id], the outbound
      message [relationship] MUST contain the pair (/*relation IRI*,
      ID)/, where *relation IRI indicates the type of outbound message
      and *ID is the [message Id] of the request.
    * *Put rules for specific outbound endpoints here*
    * Otherwise, if a [source endpoint] is defined, the outbound message
      MUST be sent to the [source endpoint] (see note 1)
    * Otherwise, if the binding defines a default means of delivering
      outbound messages, the outbound message MUST be sent by that means.
    * Otherwise, the message has been constructed inappropriately for
      the binding.  It will not generally be possible to signal this at
      message delivery time, but there will have been enough information
      in the WSDL binding to detect the situation prior to message
      delivery time.