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