Doug:
I don't quite agree with your statement:
>At the moment, a Receiving MSH has the
>option (a poor word meaning interoperability problem) of checking the CPA
or
>always not doing duplicate elimination when DuplicateElimination is not
>present. A Sending MSH has the option of including or leaving out the
>DuplicateElimination element when the CPA says "always". Our document
>should specify one approach and avoid the two MSH having to come to yet
>another agreement.
At least, I don't think that is our intent. My assumption has been that the
receiving MSH must always check that the incoming message is consistent with
the CPA (or configuration parameters). If the CPA indicates "never", the
DuplicateElimination element must not be present. If the CPA indicates
"always", the DuplicateElimination element must be present. This behavior is
consistent with our treatment of the AckRequested element.
Perhaps Section 7.4.1 is a little bit ambiguous:
"The DuplicateElimination element MUST be used by the From Party MSH to
indicate whether the Receiving MSH MUST eliminate duplicates (see section
7.6 for Reliable Messaging behaviors). If the value of duplicateElimination
in the CPA is never, DuplicateElimination MUST NOT be present."
My interpretation of the the first "MUST" in the above statement is that the
sender must include a DuplicateElimination element if its desires the
elimination of duplicates. It will be helpful if we also explicitly state
that this is permissible only if the duplicateElimination attribute in the
CPA is either "always" or "perMessage". Conversely, it would be inconsistent
for the sending MSH to include a DuplicateElimination element if the
duplicateElimination attribute in the CPA is "never".
Regards,
-Arvola
