RE: [ebxml-msg] Error handling issues

<df>comments inline </df>

 

Regards,

 

David.

  
-----Original Message-----
From: Arvola Chan 
  [mailto:]
Sent: Wednesday, November 07, 2001 6:16 
  PM
To: David Fischer
Cc: 
  
Subject: [ebxml-msg] Error handling 
  issues

  
David:

  
 

  
I have some embedded comments related to Section 4.2.3.3 in 
  the 1.08 draft.

  
 

  
Regards,

  
-Arvola

  4.2.3.3    Service and Action Element 
  Values
  
An ErrorList element can be included 
  in a SOAP Header that is part of a message being sent as a result of 
  processing of an earlier message.  
  In this case, the values for the Service and Action elements are set by the 
  designer of the Service.

  
<ac>

  
We should make it clear that an 
  ErrorList element can be piggybacked on a business response message only if 
  the highestSeverity is not Error. Otherwise, a separate Error message must be 
  used. (This rule derives from section 5.1.4 which states that an ErrorList 
  with Error as highestSeverity cannot be present with a Manifest 
  element.)

  
</ac> 

  
<df>I'm kind of opposed to having Error messages 
  piggyback on some other message.  Maybe we should take another look 
  at this.</df> 

  
An ErrorList element can also be 
  included in an SOAP Header that is not being sent as 
  a result of the processing of an earlier message.  In this case, if the highestSeverity is set to 
  Error, the values of the Service and Action elements MUST be set as 
  follows:

  
·      
  The Service element MUST be set to: uri:www.oasis-open.org/messageService/

  
·      
  The Action element MUST be set to MessageError.

  
If the highestSeverity is set to Warning, the Service and 
  Action elements MUST NOT 
  be used.

  
<df>Where did this line come 
  from?  Right, Service and Action are not optional.  Maybe this means 
  these values must not be used?  What if the Error message with a Warning 
  is sent back on its own?  What would the Service and Action be?  I 
  think this sentence needs to go.</df> 

  
 <ac>

  
The Service and Action elements are not 
  optional. What should they be set to in this case? Are you suggesting that 
  piggybacking on a response message is mandatory if the highestSeverity is not 
  Error?

  
It may also be useful to add another 
  subsection parallel to 4.2.3.3 to identify the delivery channel that should be 
  used for sending Error messages. If the incoming message that is in error asks 
  for a synchronous reply, then the Error message should be returned 
  synchronously. Otherwise, the CPA should be consulted to determine the 
  appropriate delivery channel for a standalone Error message. This delivery 
  channel must not specify the use of reliable messaging because Error messages 
  must not be acknowledged.

  
</ac> 

  
<df>We need to talk 
  about this.  I think Errors should be sent synchronously whenever using 
  HTTP regardless of the value of 
syncReply</df>