The details of resending belong to the reliability function, but none of
the existing reliability (RM)specification(s) specify or even
parameterize such a feature which is left to implementation decision.
(the RM specs mostly focus on the major delivery assurances, and on
everything that affect interoperability, and this does not. Even the
parameters for controling resnding were left out, because there was so
many options that couldn't be all covered, while not affecting interop.)
This means some RM implementations may support this , some won't.
Specifying this behavior at MSH level (above the RM function) would
create problems with the elimination of duplicates.
I believe the best way to address this is in a "deployment profile" that
defines details of usage and of deployment of an MSH for a particular
user community, as well as required properties of an implementation.
Deployment profiles handle everything that comes on top of the "base
spec" - best practices, domain-specific extensions, implementation-level
features, etc.
(the IIC produced templates for defining ebMS2 deployt profiles, used by
eAC, HL7, EAN/UCC, RosettaNet...)
Jacques
Original Message-----
From: ian.c.jones@bt.com [mailto:ian.c.jones@bt.com]
Sent: Thursday, February 22, 2007 9:14 AM
To: ebxml-msg@lists.oasis-open.org
Subject: FW: [ebxml-msg] Groups - ebXML Messaging TC weekly call added
Team,
for info from yesterdays call this was the start of the discussion
of a potential 2nd level retry for long outages etc.
Ian