One-way MEP proposals

In a moment of insomnia, I've been looking at the three recent one-way
MEP proposals ([1], [2], [3]).  I'm not thrilled with any of them, but a
couple of things jump out

    * A description of a one-way MEP should at a minimum say that a
      message is being transferred and that the sender and receiver may
      disagree about what happened (or whether anything happened at all).
    * Not all of the documents do this.
    * Including a state machine is simple and painless.
    * The sticky bit is defining the properties.

Personally, if given the choice between spending an inordinate amount of
time arguing over a formal description, or spending an even more
inordinate amount of time arguing over "simple" prose, I'll side with
decades of computing history and millennia of mathematical history and
take the formalism.

Those who find discussion of particulars tedious may tune out now.

[1] is Dave Orchard's "simplified" proposal.  In our discussions it's
been implied that the main simplification is the removal of the state
machine (though, curiously, the .../State property remains).  Closer
examination shows that the property set has been reduced as well.  This
is important in that one of the main features of the MEP is that the
sender and receiver may differ as to whether anything has happened.  In
other words, the sender and receiver have different sets of properties. 
There should at the very least be one property for what the sender
thinks it's sending, and one for what the receiver thinks it got.

Beyond this, I don't see where this version says that anything ever
happens, except possibly for failures.  This seems a bit of an
oversimplification.

[2] Is Dave Orchard's "not-simplified" proposal.  It takes up
considerably more space in the browser (not quite twice, in mine).  A
fair chunk of this is a picture of the state diagrams for the sender and
receiver, containing four boxes and three arrows for each party.  If
this is complexity, I'd like more, please.

There is also a fair bit of fluff carried over from the request-response
MEP.  For example "Once the message exchange context is initialized,
control of the context is passed to a (conforming) local binding
instance."  Sounds nice.  Not sure what it means, particularly on the
receiving side -- presumably this is all happening in the context of a
(conforming) local binding instance anyway.

I call this out because, with all due respect to the authors of the
original MEPs, I believe it is this sort of statement and not the mere
presence of two state machines with a handful of states that makes the
document look "complex" in some subjective way.

[3] Is the version I ran up several months ago (well after [1] but
possibly before [2]).  It also contains state machines.  It's the
shortest of the three, but this is mostly because it doesn't have a
short table of contents at the top or references at the bottom.  It also
lacks a picture.  With these, it would probably fall in between the
other two.

The state machine section here consists of some of the same fluffy
statements I don't like about [2] together with two two-line tables. 
This is the "complexity" that is supposed to stymie legions of
prospective implementors.

This version could stand to be cleaned up a bit more.  For example,
.../InboundMessage is mentioned in the receiver's state table but not in
the property listing, and in general it still suffers from cut-n-paste
syndrome.  It also fails to say explicitly that, say, the sender can end
in "success" without the receiver doing anything at all.  However, I
think it comes closest in providing something complete and definite to
poke at and argue over.

[1]
http://lists.w3.org/Archives/Public/xml-dist-app/2006Mar/att-0045/one-way-mep-simple.html
[2]
http://lists.w3.org/Archives/Public/xml-dist-app/2006Mar/att-0044/one-way-mep.html
[3]
http://lists.w3.org/Archives/Public/xml-dist-app/2006Mar/att-0037/one-way-MEP.htm