Re: [ebxml-msg] Section 3.1.2 reworking of what appeared to be consensusview, action item 1

[Pete Wenzel <pete@seebeyond.com>]

This leads to a new issue:

Lines 1597-1599 in section 6.4.1 require a related fix to avoid a
conflict with this clarification of 3.1.2.  I propose removing the
CPA clause from the sentence, allowing 3.1.2 to govern that case.

Original text:

   If the To Party is unable to support the requested functionality, or
   if the value of duplicateElimination in the CPA does not match the
   implied value of the element, the To Party SHOULD report the error to
   the From Party using an errorCode of Inconsistent and a Severity of
   Error.

Proposed rewording:

   If the To Party is unable to support the requested functionality, the
   To Party SHOULD report the error to the From Party using an errorCode
   of Inconsistent and a Severity of Error.

In  addition, there are more incorrect references to Error than we had
previously identified.  Where it points to section 4.1.5, it should
instead be 4.2, in 8 places throughout the document.

--Pete
Pete Wenzel <pete@seebeyond.com>
SeeBeyond
Standards & Product Strategy
+1-626-471-6311 (US-Pacific)

Dale Moberg wrote:
> From Section 3.1.2
> New DRAFT language
> 
> A receiver MUST be capable of determining that a message is in conflict
> with an actual CPA agreed to between the parties. A receiver MAY be
> configured not to check whether messages conflict with the CPA governing
> the message, for performance or some other reason. If a receiver checks
> whether the message conforms with an agreed upon CPA governing the
> message, then if a Receiving MSH detects an inconsistency, then it MUST
> report it with an errorCode of Inconsistent and a severity of Error.