RE: Issue: How CPA is used in the spec

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

OK although I would just change the last paragraph to read ...

"An MSH MAY either report the inconsistency with an Error Message to the
sender with an errorCode of Inconsistent and a severity of Error, or use the
parameters in the header to over-ride the parameters in the CPA."

As it currently reads, we specifically allow one of the alternative actions
(i.e. an error) but not the other (i.e. an over-ride) - we should allow
both. 

David

-----Original Message-----
From: christopher ferris [mailto:chris.ferris@east.sun.com]
Sent: Monday, March 12, 2001 9:59 AM
To: ebXML Transport (E-mail)
Subject: Re: Issue: How CPA is used in the spec


David,

This doesn't capture the jist of Rich's comment (IMO).

How about the following:

"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
appropriate handling of this conflict is undefined by this specification.
Therefore, senders SHOULD NOT generate such messages unless they have prior,

out-of-band knowledge about the receiver's capability to deal
with this conflict.

An MSH MAY report the inconsistency with an Error Message 
to the sender with an errorCode of Inconsistent and a severity
of Error."

Cheers,

Chris

"Burdett, David" wrote:
> 
> 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."
> 
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-transport-request@lists.ebxml.org

------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-transport-request@lists.ebxml.org