Two questions

(resent from correct address)

   1. I send you a message.  You receive it twice.  What message
      exchange(s) have occurred, consisting of what events?
   2. What does "reliable delivery" mean?


These can both be answered by

    A one-way message exchange is /reliable/ if the sender and receiver
    make the same state transitions and, if they enter the success
    state, they agree on the content of the .../Message property. 
    Reliable message exchange is an OPTIONAL feature.  However, bindings
    MUST indicate under what conditions, if any, they provide it.

    In the absence of any other guarantees, the receiver may transition
    out of the init state zero or more times for each time the sender
    does so.  If the receiver enters the success state, its .../Message
    property SHOULD be the same as that of the sender.

Notes:

    * The names "InboundMessage" and "OutboundMessage" make sense for
      request-response but not here, though they are carried over in the
      current proposals.  Here there should just be "Message", with the
      sender and receiver each having its own copy (just as they each
      have their own copy of InboundMessage and OutboundMessage).  I
      would recommend this change for whatever version we go with.
    * The second clause leaves open the question of how the receiver
      transitions back into the init state.  The more explicit way to do
      this is just to add transitions back up to the top (nearly
      doubling the number of lines with arrows in the picture -- oh
      no!).  Effectively, the sender and receiver both run in a loop of
      two parts: 1) wait to send/receive 2) succeed or detect failure.
    * In the reliable case, each side goes through the loop once per
      message.  In a /synchronous/ reliable case, the sides go through
      their loops in complete lockstep.  Otherwise messages may be
      reordered, but the receiver will still succeed or detect failure
      exactly once per sent message.
    * Synchrony (in-order) can be defined orthogonally to the above
      definition of reliability (exactly once).
    * If we really don't like state machines, another way to say the
      same thing would be to define a while loop for each side and talk
      about execution traces.