OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: reliable messaging take 2 (or 222?)


Good idea. How can we get feedback on from the folks on the list and keep it
manageable? Is there a way to poll everyone to determine where we stand on
the fundamental questions you have presented? This would at least give us a
baseline to work with.

David Smiley
Director of Standards

-----Original Message-----
From: Colleen Evans [mailto:cevans@sonicsoftware.com]
Sent: Friday, August 17, 2001 12:02 AM
To: ebXML Msg
Subject: reliable messaging take 2 (or 222?)

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
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 Evans
Principal Product Manager
Sonic Software Corporation
phone:  720 480-3919 or 303 791-3090
email:  cevans@sonicsoftware.com

To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC