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

[Christopher Ferris <chris.ferris@sun.com>]

Please see below.

Doug Bunting wrote:

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


The submission actually has to happen a month before the beginning
of a new quarter, thus it needs to be submitted *before* March 1
to be considered in Q2.


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


+1


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


+1


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


+1


> 
> thanx, 
> 
>     doug
> 
>  
>