Date: Mon, 15 Oct 2001 08:43:37 -0700
From: Arvola Chan <>
Under the QualityOfServiceInfo element, I would prefer to see the
boolean attribute duplicateElimination renamed as reliableMessaging.
The reason for making this change in the first place was to try to
separate the various underlying elements of reliable messaging into
orthogonal dimensions.
The idea is that duplicateElimination is really orthogonal to
retry-and-ack.
retry-and-ack duplicate elimination resulting semantics
no no best effort
no yes at most once (it might not arrive, it might arrive once)
yes no at least once (it might arrive once or more than once)
yes yes once and only once
This seems conceptually elegant.
Whether it has practical value depends on whether our customers might
really want all four of the possible resulting semantics. It seems to
me that all four combinations reflect the needs of use cases that are,
at least, plausible. Whether those use cases are compelling is a
judgement that I don't know how to make. On the other hand, there
doesn't seem to be much downside to separating these orthogonal
behaviors.
From your later mail:
I just find the discussion
on duplicateElimination in sections 3.1.7.2 and 7.4 not very
satisfactory. In particular, section 7.4 talks about a ReliableMessaging
element that is not really described in the document.
I agree that the wording in 3.1.7.2 could be improved. In my opinion,
it would be better if 3.1.7.2 talks about what duplicate elimination
means, in its own right, rather than being written entirely in terms
of the resulting semantics.
More important, what 3.1.7.2 says currently is assuming that
retry-and-ack is turned on, whereas the whole reason (as far as I
remember it) for separating out duplicateElimination was so that
duplicateElimination could be used either with or without
retry-and-ack.
