reliable messaging take 2 (or 222?)

[Colleen Evans <cevans@sonicsoftware.com>]

Can we take a step back and look at this discussion again
from the top?  Once we determine how this SHOULD work, we
can then determine what we do to fix the existing
specification for V1.1, and what new requirements MAY go
into V2.0.

MSHs can take on different roles, each with associated
actions and expected behaviors.  Any MSH is expected to
conform to all defined roles.  The MSH roles defined in V1.0
are:
Sending MSH
Receiving MSH
Intermediary MSH

And the points we seem to be arguing are (maybe we should
have a different thread for each point?):
(1) Should the third role exist, or should the first two
roles just cascade (the 'chasm' model)?  It was determined
for V1.0 that it was a required, but the question is
surfacing again.
(2) If the intermediary MSH role is required, what are the
behaviours?  (There are a number of issues related to the
intermediary role, but let's limit it to the context of
reliable messaging for this discussion if possible.)
(3) If the intermediary MSH role is required, is there a
requirement for both hop to hop reliability (ack), and end
to end reliability (delivery receipt)?  What should be in
the CPP / A to support this role?
(4) If there is a need for both levels of reliability, how
do they work in concert?  Should the ack (ack/delivery
receipt) be reliably transmitted?  What are the error
conditions, and the expected behaviours?

Colleen

--
Colleen Evans
Principal Product Manager
Sonic Software Corporation
phone:  720 480-3919 or 303 791-3090
email:  cevans@sonicsoftware.com
http://www.sonicsoftware.com