OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: [ebxml-cppa] [ebxml-msg] Attributes specified in both the messageand the CPA

Rejoinders below (MWS2:)


Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com

Dan Weinreb <dlw@exceloncorp.com> on 11/01/2001 10:47:05 PM

Please respond to "Dan Weinreb" <dlw@exceloncorp.com>

To:    Martin W Sachs/Watson/IBM@IBMUS
cc:    ebxml-msg@lists.oasis-open.org, ebxml-cppa@lists.oasis-open.org
Subject:    Re: [ebxml-cppa] [ebxml-msg] Attributes specified in both the
       message and the CPA

   Date: Thu, 1 Nov 2001 16:21:20 -0500
   From: "Martin W Sachs" <mwsachs@us.ibm.com>

   For version 1.1, the F2F ended up breaking out 6 or 8 separate Boolean
   parameters that together define the delivery semantics.

6 or 8?  Oh, come on, gimme a break... The only breaking out we did
was to separate retry/ack from duplicate elimination to create the
four possibilities BestEffort, AtLeastOnce, AtMostOnce, and

You may be thinking of a table with 8 *rows*, due to *3* booleans.
The reason there were 3 booleans in the table was to distinguish
between Ack and DeliveryReceipt and/or between hop-by-hop Ack and
end-to-end Ack, a distinction that was *already* in place before the
F2F meeting.

MWS2:  Right. I was thinking of the 8 rows.  Mea culpa.

           The CPA
   will have to agre with however this redefinition comes out in the MS
   spec. This point applies to all the following paragraphs.

Yes, I agree that the CPA will have to agree with this.

   MWS: I think there is a problem with interpreting the word "idempotent".
   Formally, idempotent means that repeating the function will produce the
   same result and therefore it is not necessary to eliminate duplicates,
   which I think is what you are saying here.  The problem (which I think
   we discussed at the F2F) is that "idempotency" in our context means
   "test for duplicates" (a common misuse of the word "idempotency"). We
   should say "eliminate duplicates", not "idempotency".

I agree.  The word "idempotent" has been around for a very long time
with the formal meaning that you give above, and we should not try
to redefine it.

   MWS: I agree:  The problem with splitting delivery semantics into
   a bunch of boolean parameters means that some combinations are
   and in other cases, settings of two different parameters to "yes" is a

I see it the other way: by splitting one boolean into two orthogonal
booleans, we get four combinations, each of which is meaningful and
potentially valuable.  The current CPA, in contrast, has booleans for
"idempotency" (sic) and "reliable", which are not orthogonal, hence
the meaningless combinations.

MWS2:  I agree.  However you are looking at the V 1.0 CPA spec.  We all
understand that the CPA spec will have to be put in sync with the
of delivery semantics.

-- Dan

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC