Re: [ebxml-msg] More Editiorial Comments (Fw: duplicateEliminationand7.5.2 & others)

[Arvola Chan <arvola@tibco.com>]

Dan:

I think the main problem with section 7.5.2 (starting with line 1662 in
particular) is that it assumes duplicate elimination is always performed. On
the other hand, if duplicateElimination is set to false in the incoming
message, no attempt should be made to determine if the message is a
duplicate at all. The message may still have to be stored persistently
before being acknowledged. Otherwise, it may be difficult to guarantee "at
least once" delivery if Acknowledgment is returned before the message is
delivered to the  application. Once it has been passed on to the
application, the persistent copy can be discarded. There is no need to wait
for the PersistDuration to expire.

I agree with you that section 3.1.7.1 requires some rewording.

Regards,
-Arvola

-----Original Message-----
From: Dan Weinreb <dlw@exceloncorp.com>
To: arvola@tibco.com <arvola@tibco.com>
Cc: ebxml-msg@lists.oasis-open.org <ebxml-msg@lists.oasis-open.org>;
mwang@tibco.com <mwang@tibco.com>
Date: Wednesday, November 28, 2001 9:48 AM
Subject: Re: [ebxml-msg] More Editiorial Comments (Fw: duplicateElimination
and7.5.2 & others)


>   Date: Wed, 28 Nov 2001 08:34:51 -0800
>   From: Arvola Chan <arvola@tibco.com>
>
>   >section 7.5.2 item 2a.  (line1663-1667)
>   >this does not fall inline with my current understanding of use
>   >of duplicateElimination attribute.
>   >
>   >it should say: MUST NOT deliver to application ONLY WHEN
>   >duplicateElimination is TRUE.
>
>I'm not sure that this change is needed, because if
>duplicateElimination had been false, nobody would have stored the
>MessageId in the persistent list.  The persistent list of MessageId's
>is only there for duplicate elimination; at least that's how I imagine
>implementing all this.  So if a matching MessageId is found in
>persistent memory, then you know that duplicateElimination must have
>been requested.
>
>On the other hand, if duplicateElimination is not being requested
>for this message, the receiving implementation can avoid the
>cost of looking up the MessageId in the persistent store.
>
>
>By the way, section 3.1.7.1 still isn't exactly right.  It says:
>
>   Valid values for duplicateElimination are:
>    true -- this results in a delivery behavior of At-Most-Once.
>    false -- this results in a delivery behavior of Best-Effort.
>
>This is only the case if acknowledgements are not being used.