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

[David Fischer <david@drummondgroup.com>]

Chris said:

  The sender of a message cannot really know whether the
  receiver's application/service has idempotent semantics,
  it can only assert whether or not it wants
  these semantics to be applied.

Exactly!  This is why it was OK to have a value called duplicateElimination.
The sender is making a request.

Changing from deliverySemantics to duplicateElimination was just a name change.
It was not good but it was tolerable.  This is a fundamental change.  We are
only supposed to be making fixes and clarifications.  This does neither and does
not improve over the original deliverySemantics attribute at all.

Regards,

David Fischer
Drummond Group.

-----Original Message-----
From: Christopher Ferris [mailto:chris.ferris@sun.com]
Sent: Thursday, November 15, 2001 7:50 AM
To: Dan Weinreb
Cc: ebxml-msg@lists.oasis-open.org
Subject: Re: [ebxml-msg] Proposed "idempotent" parameter and attribute
and CPA element


Dan,

Thanks for this. Some comments though. Typically, it is the function that
is idempotent, not the input. My understanding of our discussion had been
that the sender of a message, by adding the idempotent attribute was
asserting
that the processing of that message MUST be idempotent (or not). How the
receiver
chooses to implement this is strictly up to the receiver. The receiving MSH
MAY know, through some unspecified means, that the application/service
that is intended to process the message has asserted that its function
is idempotent
(such as in the case of a request for status or a functional equivalent of a
typical HTTP GET). In this case, the MSH need not perform filtering to
eliminate
a potential duplicate message.

OTOH, the receiving MSH may know, through some similarly unspecified
means, that the application/service's function is NOT idempotent as in the
case of a message debiting some account, in which case the MSH MUST
assume responsibility to ensure that any duplicate message is filtered and
prevented from being received by the application/service.

The sender of a message cannot really know whether the receiver's
application/service
has idempotent semantics, it can only assert whether or not it wants
these semantics
to be applied.

Cheers,

Chris

Dan Weinreb wrote:

>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".
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>
>



----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>