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

[Doug Bunting <dougb62@yahoo.com>]

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