[ebxml-msg] Proposed "idempotent" parameter and attribute and CPAelement

[Dan Weinreb <dlw@exceloncorp.com>]

Here's the proposal that I said I'd provide:

This proposal changes the "duplicateElimination" attribute to the
"idempotent" attribute.  Note that the sense is reversed; that is,
loosely speaking, idempotent being false means the same thing as
duplicateElimination being true.

Very unfortunately, the current CPA spec has an element called
"idempotency", which is TRUE if the message IS NOT idempotent, and
FALSE if the message IS idempotent.  (The CPA spec uses the phrase
"idempotency check" to mean "duplicate check".)  We propose that the
CPA group change the name of the element to "idempotent", with the
sense that the value is true if and only if the message is idempotent.

The following text is proposed to replace sections 3.1 and 7.4.1; in
accordance with earlier decisions of the MS TC, the
QualityOfServiceInfo element of MessageHeader is removed, and the
"idempotent" attribute is "promoted", so to speak, to the
MessageHeader element.

This text assumes that the CPA definition adopts our suggestion about
the use of the "perMethod" value.  If the CPA does not adopt this
suggestion, the rules at the end of 7.4.1 must be changed accordingly.


3.1. idempotent attribute

Valid values for idempotent are:

true - the To Party MSH MAY assume that the message has idempotent semantics
false - the To Party MSH MUST NOT assume that the message has idempotent semantics

The definition of "idempotent", and the interaction of this attribute with
the "idempotent" element from the CPA, are described in section 7.4.1.

7.4.1 idempotent

A message is said to be "idempotent" if processing the message more
than once has the same effect as processing the message once.

If the value of the "idempotent" parameter for a message is "true",
the To Party MSH MAY safely assume that the message has idempotent
semantics.  If a duplicate idempotent message is received, i.e. if the
same idempotent message is received more than once, the To Party MSH
MAY deliver the message to the application more than once.  (However,
the To Party MSH is free to perform duplicate elimination even knowing
that the message has idempotent semantics.  This might be wise if the
cost of re-processing the message exceeds the cost of duplicate
elimination.)

If the value of the "idempotent" parameter is "false", the To Party
MSH MUST assume that the message might not be idempotent.  If a
duplicate non-idempotent message is received, the To Party MSH MUST
not deliver the message to the application more than once.  That is,
the To Party MSH must eliminate duplicates.

The value of the "idempotent" parameter is controlled by the
"idempotent" element of the CPA together with the "idempotent"
attribute of the MessageHeader, as follows:

-- If the value of the "idempotent" element of the CPA is "true" or "false":

then the value of the "idempotent" parameter is "true" or "false"
respectively.  Furthermore, if the "idempotent" element is present in
the MessageHeader, it must agree with the parameter value, or else the
To party MSH reports an error with errorCode set to Inconsistent and
severity set to Error.

-- If the value of the "idempotent" element of the CPA is "perMessage":

If the "idempotent" attribute of the MessageHeader is "true", the
idempotent parameter is "true", otherwise the idempotent parameter
is "false".