RE: Issue: How CPA is used in the spec

["Burdett, David" <david.burdett@commerceone.com>]

Rich

Following on from todays conference call. How about the following wording
which combines elements from both your and my wording.

>>>
The values for the reliable messaging parameters are determined by
appropriate elements from the CPA identified by the CPAid. If a receiver
determines that a message is in conflict with the specified CPA, then the
receiver MAY either:

* report the inconsistency with an errorCode of Inconsistent and a severity
of either Warning or Error, or
* use the parameters in the header to over-ride the parameters in the CPA. 

If the parameters are not present in the header, then the parameter values
identified by the CPAId MUST be used if the CPAId is recognized. If the CPA
is not recognized, then report an error with an errorCode of NotRecognized
and Severity of Error.

Senders of messages SHOULD therefore only send messages containing reliable
messaging parameters if they have prior knowledge of the receiver's
behavior.
<<<


-----Original Message-----
From: Rich Salz [mailto:rsalz@zolera.com]
Sent: Friday, March 09, 2001 6:36 PM
To: Burdett, David
Cc: ebXML Transport (E-mail)
Subject: Re: Issue: How CPA is used in the spec


If only to have something to vote on for Monday ...  I think that if an
MSH gets a message that is in conflict with the CPA, the results should
be undefined.  The receiver can return an error, ignore the conflict,
accept the override, or invoke a remote HCF (halt and catch fire)
instruction on the sender.

So my suggested wording for section 8.5.3 (on the CPAId element) after
line 438 is:

"The values for the reliable messaging parameters are determined by
appropriate elements from the CPA identified by the CPAid. If a receiver
determines that a message is in conflict with the specified CPA, the
results are undefined. Therefore, senders SHOULD NOT generate such
messages unless they have prior, out-of-band knowledge about the
receiver's behavior."