MHonArc v2.5.2 -->

















ebxml-msg message






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [Elist Home]








Subject: Re: [ebxml-msg] Messaging Spec v1.092




From: Doug Bunting <dougb62@yahoo.com>
To: ebXML Msg <ebxml-msg@lists.oasis-open.org>
Date: Fri, 04 Jan 2002 12:37:14 -0800









Going back to a few 
other issues:
 
1. Line 18: 
Don't we have to wait for a calendar quarter boundary before the spec can be 
presented to the OASIS membership for consideration as an OASIS 
specification?  
<df>Fixed -- this means we will submit on April Fools 
Day  ;-) 
      We still don't have 
anything under the *This Version* 
heading</df>

  
The ebXML RIS and RS specifications have already been 
  submitted for comments to the OASIS membership.  Why would we 
  wait?
7. Line 1491: I think an errorCode of 
Inconsistent should be accompanied by a severity of Error rather than warning. 
Didn't we decide that inconsistency between the CPA and the message header must 
always result in an error being returned?  
<df>This might not be an inconsistency with the CPA 
(perMessage).  If we say this must be an Error then we must also say the To 
Party MSH MUST NOT deliver to the Application.  IMO This needs to be a 
Warning.</df>

  
This type of 
  inconsistency could result in an Error and the message might not be 
  delivered to the application.  It's up to the recipient to decide whether 
  or not an inability to generate the requested type of MSH signal (a signed 
  Acknowledgment in this case) is an error or warning.  I don't think this 
  line should be so prescriptive as to disallow that 
choice.
8. 1502: 
The statement "An Error Message MUST NOT contain an AckRequested element" is not 
correct and should be struck out. Please see http://lists.oasis-open.org/archives/ebxml-msg/200111/msg00231.html (Resolution of issues in the issues database), 
IssueId 73, and/or http://lists.oasis-open.org/archives/ebxml-msg/200111/doc00004.doc, Issue 73.  
<df>We have gone back and forth on this several 
times.  I think the latest was to change to *no Ack on Error*.  If we 
go back to *no Error on Ack* then I need to go back through the spec and make 
several changes.  See *[ebxml-msg] Ack on Error, or Error on Ack* thread 
starting 12/10/01.</df>

  
This came up during the most recent face-to-face and I 
  believe we made the decisions to allow an Ack on an Error.  I quote from 
  Colleen's document:

1.1    
Issue 
73.  Alllowed Acknowledegements/Errors.  Error on ack, but not ack on error?  Determined can�t ack on an ack, error on 
error, or error on an ack.  Wording 
already precludes asking for an ack on a message that contains an ack (ignored). 
David F. will revise the spec to this 
effect.  Line 1517 
(errors are never sent reliably) must be fixed during this revision 
process.

  
This is the latest decision on this 
topic.
22. Line 2098: I think the statement "The Receiving MSH MUST NOT send 
an Acknowledgment Message until the message has been delivered to the Next MSH" 
is not correct.  This does not correspond to store and forward behavior 
(see line 2043). The Receiving MSH cannot know for sure that the message has 
been delivered to the Next MSH until it receives an Acknowledgment from the 
latter. The prescribed behavior defeats the purpose of intermediate 
Acknowledgments.
<df> What would be more 
correct?  Should it say *The Receiving MSH MUST NOT send an Acknowledgment 
Message until the message has been persisted?*  Actually, I don't see 
a problem as it is.  What should I 
do? </df>

  
I'd 
  suggest updating the document using your replacement 
text.
thanx, 
    doug
 





Follow-Ups:

Re: [ebxml-msg] Messaging Spec v1.092
From: Christopher Ferris <chris.ferris@sun.com>



References:

RE: [ebxml-msg] Messaging Spec v1.092
From: David Fischer <david@drummondgroup.com>






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [Elist Home]


  









Powered by eList eXpress LLC