Issues against editor's draft

Summarizing previous discussion:

    * It appears that the sender and receiver have separate copies of
      the properties, but this is not explicitly mentioned.
    * The State property is defined as containing either Success or Fail
      "at a terminal state", but there is no mention of when which copy
      of this property takes which value, or when "a terminal state
      occurs", or in what way the property containing Fail may
      correspond to generation of faults.
    * The FailureReason property "denotes a pattern-specific,
      binding-independent reason for the failure of a message."  Given
      that a binding-independent reason cannot be defined by a
      particular binding, and no such reasons are mentioned in the MEP
      description itself, where are such reasons to be defined?
    * It seems likely, though again this is not stated, that "more
      binding-specific details of the failure" may bear some relation to
      faults produced by the sender or receiver.  Is there any such
      relation?
    * Addressing the previous three points would most likely only
      complicate matters, and in any case error handling is driven by
      the generation and disposition of faults.  It seems best to drop
      the properties altogether.
    * The receiver MUST determine whether a message was successfully
      received.  It is not stated explicitly, but presumably this would
      be for a given instance of the MEP.  In some realizations of the
      MEP, it will not necessarily be possible for the receiver to know
      that the sender has done anything at all.  In practice, either the
      receiver's set of properties will be populated, or it won't.  This
      argues for defining receipt of a message as population of the
      receiver's set of properties, and stating that this can happen
      zero or more times in a given instance of the MEP.
    * Unlike the request-response case, it is quite feasible and useful
      to realize the one-way MEP directly in a multicast environment. 
      In such an environment, there may be zero or more receivers for
      any given message -- that is, for a given ImmediateDestination --
      and this set may change from instance to instance of the MEP.  The
      statement that "The scope of a one-way MEP is limited to the
      exchange of a message between one sending and one receiving SOAP
      node." directly precludes this useful behavior.  Nor can multicast
      be usefully treated as multiple MEP instances without specifying
      how it is that the instances share the OutboundMessage property
      and how the limitation to exactly one sender and receiver squares
      with the case where there is one sender and no receiver.  Spelling
      out such a scheme would add needless complexity.

Proposal:

A revised proposal [1] eliminates the redundant and under-specified
properties, explicitly states that the sender and receivers each have
their own copies of the remaining properties, states that a receiver's
properties may be populated zero or more times in an instance of the
MEP, and specifically allows for multicast.  This proposal also attempts
to state more explicitly what a valid binding is obligated to define. 
Further discussion [2] has suggested further possible clarifications,
particularly regarding the use of the term "notification of receipt". 
These should be discussed and possibly incorporated.

[1]
http://lists.w3.org/Archives/Public/xml-dist-app/2006Jun/att-0004/one-way-mep-june-2006.html
[2] http://lists.w3.org/Archives/Public/xml-dist-app/2006Jul/0001.html
and following thread