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

[David Fischer <david@drummondgroup.com>]

<<df>> Comments in line <</df>>

David.

-----Original Message-----
From: Christopher Ferris [mailto:chris.ferris@sun.com]
Sent: Friday, January 04, 2002 3:05 PM
To: Doug Bunting
Cc: ebXML Msg
Subject: Re: [ebxml-msg] Messaging Spec v1.092


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.

<<df>>We missed our original deadline so now the document will be submitted to
the OASIS membership in April (calendar quarter).  To make that deadline, we
must submit to Karl Best by March. <</df>>

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

<<I think what I am being told is that we need to let the implementation decide
if this is an Error (inconsistent with the CPA) or a Warning (Not Supported). >>

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


<<df>>We have discussed this since the above quote and it was pointed out that
if we do not allow Errors on Acknowledgments that there is no way to respond to
an Invalid Signature on an Acknowledgment.  It has also been pointed out that
Errors are system messages, like Acknowledgments, and should not themselves be
acknowledged. <</df>>

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

<<df>> done <</df>>
>
> thanx,
>
>     doug
>
>
>



----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>