Reliable Messaging Definition

I believe that one of the actions that came out of the F2F as generally
desirable was to agree on a definition of reliable messaging.  There were
some threads on this subject a couple months ago, and I did not see a
consensus emerging at that time.  Following I document the "end points" I
can find from these threads, along with some personal comments in
[brackets].  I start with the definition that seemed to come closest to
generating consensus and work downward according to my personal perception
of how much consensus was achieved.  One overall comment:  None of these
definitions seem to recognize explicitly that the degree of certainty
achieved by reliable messaging is, in practice, a matter of balancing cost
and benefit.

Definition I - (Amalgamation of two)
http://lists.w3.org/Archives/Public/www-ws-arch/2002Aug/0283.html
<http://lists.w3.org/Archives/Public/www-ws-arch/2002Aug/0283.html> 

http://lists.w3.org/Archives/Public/www-ws-arch/2002Aug/0290.html
<http://lists.w3.org/Archives/Public/www-ws-arch/2002Aug/0290.html> 

Reliable messaging refers to:
1)  the ability of a sender to be able to determine whether a given 
message has been received by its intended receiver and to take compensating
action in the event a given message has been determined not to have been
received

2) the ability of the intended receiver to be assured that it receives and
processes a given message once and only once

3)  the ability of both sender and receiver to carry out 1 & 2 with a high
probability of success in the face of inevitable, yet often unpredictable,
network, system, and software failures.

[This one was the result of the longest thread and seemed to be the one
closest to having some consensus.  I personally think that it needs
restating to say positively what reliable messaging "is", not what it
"refers to", and at that point the choice of verbs is likely to be tricky in
order to avoid appearing to guarantee that which cannot be done.]

Definition I(a) - (Addition to Definition I)
http://lists.w3.org/Archives/Public/www-ws-arch/2002Aug/0290.html
<http://lists.w3.org/Archives/Public/www-ws-arch/2002Aug/0290.html> 

4) The ability of a participating web services to coordinate and align their
transaction-related operations such that they can either commit or roll back
updates to their respective resources (e.g., application database and
transactional objects, persistent queues, etc.) used in the end-to-end web
service transaction. 

[I personally think that this issue is outside the scope of what people are
generally talking about when they use the term reliable messaging, and I am
not in favor of going in this direction.]

Definition II -
http://lists.w3.org/Archives/Public/www-ws-arch/2002Aug/0281.html
<http://lists.w3.org/Archives/Public/www-ws-arch/2002Aug/0281.html> 

I was involved in ebXML Messaging from the early days, so how about this as
a statement of the requirement from an ebXML perspective ...

Reliable Messaging is the ability for one service to use a protocol to send
a message to another so that: 1. The sender of the message is provided with
positive confirmation that the message was successfully delivered 2. The
probability of successful delivery of the message is very high 3. The
recipient of the message can identify and, if required, ignore any
duplicates of the message 4. The sender of the message is notified if, for
some reason, delivery of the message was not possible or is uncertain

[I personally like this one, except that I'm not sure if 4 is possible to
guarantee and I would be happier if the verbiage was wordsmithed to make it
seem less like a sure thing that these things are going to happen every
time].

Definition III -
http://lists.w3.org/Archives/Public/www-ws-arch/2002Aug/0218.html
<http://lists.w3.org/Archives/Public/www-ws-arch/2002Aug/0218.html> 

Reliable messaging is a protocol for sending and receiving messages over the
web which, if followed by all participants in the messaging, will reduce the
uncertainty of the message transmission to a practically acceptable level.
More specifically, if A sends a "reliable message" to B, who is not
necessarily expecting a message at a particular time, A may be assured that
the process will terminate (usually after a known time interval) in one of
three states.  The reliable messaging protocol attempts to maximize the
probability of the first state and minimize that of the third state.

State 1: The message has been received by B and a confirmation has been sent
back to A.  Both A and B agree that the message has been successfully
received.  (An elaboration of this is that B may send a confirmation message
back to A that the message has been received but that it was "damaged in
transit").

State 2: The message has not been received by B.  Both A and B agree that no
message has been successfully received.

[This was my stab at a definition that started the threads.  I personally
like it because I understand it and I think it is reasonably accurate, but
it did not seem to gather a lot of support.]

Definition IV -
http://lists.w3.org/Archives/Public/www-ws-arch/2002Aug/0277.html
<http://lists.w3.org/Archives/Public/www-ws-arch/2002Aug/0277.html> 

Here is a quote from the ebXML Message Service Specification v2.0 [1], p.
35:
  "Reliable Messaging defines an interoperable protocol such that two
   Message Service handlers (MSH) can reliably exchange messages, using
   acknowledgement, retry and duplicate detection and elimination
   mechanisms, resulting in the To Party receiving the message
   Once-And-Only-Once.  The protocol is flexible, allowing for both
   store-and-forward and end-to-end-messaging."

[I personally feel that this definition is flawed because it seems to
promise something that probably cannot be done and certainly is not done by
the ebXML messaging spec.  The ebXML messaging spec does not guarantee that
the To Party will receive a message once and only once, and I believe that
it does not recognize adequately the possibility that Sender and Receiver
will disagree at the end of the process about whether the message has been
delivered.]