In-optional out

I've just read over the minutes from last week, and I'm doubly sorry I 
missed the discussion.  I'd also like to thank Jonathan for the clear 
and thorough minutes.

When I first heard of an in-[out] (or even [in]-[out]) "über MEP", it 
seemed like it was trying to generalize any possible MEP.  An in-only 
would be treated as [in]-[out] with an in and no out, and so forth.

This seemed like a bad idea.  It wouldn't actually cover all possible 
MEPs, but it would add a layer of complexity to in-only or even in-out 
("in-out is [in]-[out] with both in and out present" as opposed to 
"in-out is in-out").  Thence the George Carlin quote about volleyball 
being team ping-pong with a raised net etc.

Reading through the minutes, though, in-[out] looks to be more narrowly 
focused on an important fact of life: In some scenarios you can't tell 
in advance whether you will get an application-level reply on the 
back-channel.  For example, if the normal course of action were to send 
messages on to the "approval" and "logging" endpoints given in the 
message addressing properties, while a fault should come back on the 
back-channel, you would have to find out dynamically which alternative 
was actually in effect.  I suppose the request/reply case with the one 
of the two endpoints directed to the back-channel and the other directed 
elsewhere would also be an example.

In such cases, the in-[out] pattern captures the fact that you might get 
back a message on the back-channel, or you might just get back an ACK.  
It doesn't quite capture the possibility of getting more than one 
message back on the back-channel (e.g., two or more 
non-mutually-exclusive endpoints both pointed at the back-channel), but 
perhaps it could be expanded to cover that, too.  It might also be 
better to describe the pattern as "in-(out|ACK)", emphasizing that 
/something/ always comes back (if that's what we mean).

As a side-effect, we could also model a one-way WSDL MEP as an in-[out] 
with just an ACK coming back.

This is all described at the SOAP level, without reference to HTTP or 
any other physical binding, which is why I say "ACK" instead of "202".  
It's up to the binding to say what form the ACK takes.

With this in place, as I understand it:

    * a in-only message would manifest as in-[out] with just an ACK in reply
    * existing synchronous request/reply still manifests as request/reply
    * asynchronous request/reply manifests as in-[out]

Is this all roughly correct?