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

Title: Message

OK, 
let's try again. Instead of trying to resolve the questions that the 2nd 
statement raises, let me attempt another variation that probably captures the 
consensus but omits those tantalizing hints that seem to make the reader want to 
know more.

 

Here 
is the new revised 2nd sentence.

 

It is 
not NECESSARY that a receiver check for conflicts between its "CPA" and 
messages.

 

Is 
this better?

 

Dale 
Moberg

 

(Dick, incidentally checking that a signature is OK is a policy, 
something like an ACL policy. We don't currently have these ACL like policies in 
the CPA, but may soon allow extensions so that XACML or otherwise expressed 
policies can be referenced. 

 

I 
guess if you were missing a signature or had the wrong kind according to the 
governing CPA, an INCONSISTENT error could be sent back--unless you did not want 
to do this--because, for example, it would give bad guys feedback. I think you 
raise a number of interesting points, but this 3.1.2 place is not probably the 
best place to get into all of it...Hope that is responsive.)

  

  
-----Original Message-----
From: Dick Brooks 
  [mailto:] 
Sent: Friday, March 14, 2003 7:23 
  PM
To: ebxml-msg
Subject: 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>