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
