RE: [ebxml-msg] Section 3.1.2 reworking of what appeared tobeconsensus view, action item 1

Title: RE: [ebxml-msg] Section 3.1.2 reworking of what appeared to beconsensus view, action item 1

Dale,

 

I 
wasn't able to attend the meeting so my comments may reflect a lack of context, 
if so please disregard. 

 

Does 
"conflict" refer to "any message exchange sequence that deviates 
from *all* the agreed to behavior defined in the CPA contract"? If so, the 
statement may be too broad.

 

For 
example, suppose the CPA mandates the use of S/MIME for payload 
encryption but the trading partner uses PGP during a message exchange. This may 
be a case where one may want to "turn on" compliance 
checking.

 

I 
believe the ability to turn on/off CPA compliance checking may need to be 
specified at a granular level. Was that the intent of the 
statement?

 

As I 
said earlier, my question may be suffering from a "lack of 
context".

 

Thanks,

 

Dick Brooks
Systrends, Inc
7855 South River Parkway, Suite 
111
Tempe, Arizona 85284
Web: www.systrends.com <http://www.systrends.com>
Phone:480.756.6777,Mobile:602-684-1484,eFax:240-352-0714
  

  
-----Original Message-----
From: Dale Moberg 
  [mailto:]
Sent: Thursday, March 13, 2003 
  8:00 PM
To: Martin Sachs; ebxml-msg
Subject: RE: 
  [ebxml-msg] Section 3.1.2 reworking of what appeared to beconsensus view, 
  action item 1

  
Marty, 

  
Let me rephrase the second sentence because I _did_ intend to 
  say that 
something is optional to implement. I think 
  this optionality to 
implement (the real MAY) is what 
  the consensus was in the group. 

  
"A receiver MAY implement the ability to turn off checking for 
  conflicts 
between a CPA and messages (for performance 
  or other reasons)." 

  
In other words, it is not mandatory to implement a 
  configurability 
capability that allows turning off 
  checking. The implication would be 
that a sender 
  cannot count on being able to avoid error code reports of 
Inconsistent, and so must be prepared to deal with them always. 
  The 
implementer must be able to check for 
  "Inconsistent" type errors, and 
can always do 
  so--never ignoring the error. However, a vendor may choose 
to allow an Inconsistent error to be ignored by turning off a 
  check. 

  
But this section was agreed by all to be tricky. Is this any 
  better? Has 
the apparent inconsistency been 
  removed? 

  
Dale Moberg 

  
============== 
Marty said 

  
The word MAY is not appropriate in the second sentence  
  because it 
permits 
a vendor to 
  omit checking whether messages conflict with the CPA, in 
conflict with the first sentence, which requires that the check be 
  
implemented.  I suggest for the second 
  sentence:  It is permissible for 
a 
  
receiver to configure its MSH not to check whether 
  messages conflict..." 

  
At 06:57 PM 3/12/2003 -0700, 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. 
> 
>---------------------------------------------------------------- 
  
>To subscribe or unsubscribe from this elist use the 
  subscription 
>manager: <http://lists.oasis-open.org/ob/adm.pl> 
  
************************************* 
Martin Sachs 
standards architect 
  
Cyclone Commerce 
 

  
************************************************* 
  
Martin W. Sachs 
email:  
   
phone:  203-226-0524 
  

  
---------------------------------------------------------------- 
  
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>