Re: Delivery Receipt,NRR and MSG/CPPA/BPSS (mis-)alignment andthelayering mishmash (was jumbledinto: reliable messaging - hop by hop)

[christopher ferris <chris.ferris@east.sun.com>]

David,

Retries are triggered by the retryInterval expiring before
the sending MSH receives an Acknowledgment. It performs this
loop retries times before giving up and reporting a DFN to the
"From Party". If the message is acknowledged then the sending
MSH ceases to retry delivery. It's job is done.

Sure, it (the MSH) doesn't "know" whether the message has actually
been received by the To Party, or even the MSH belonging to the To Party.
That isn't its concern because it (the sending MSH) cannot effect/influence 
the processing of the message between subsequent MSH nodes should some
manner of problem arise. It can only influence or effect the message
traffic between itself and the adjacent MSH node in the message path.

This is NOT to say that the eBusiness Server, of which an MSH may be
a component, might not be very concerned with tracking the progress
of the message such that its users (humans) might know more about
what is the state of the messages which their enterprise has outstanding
with its partners. To this eBusiness Server, a DR and/or a DFN may be very 
important to this layer of the software for purposes of reporting.

This layer of software doesn't concern itself with the physical delivery of
the messages (including retries, etc.), it delegates that function to the MSH.

The MSH doesn't concern itself with DFN's or DR's received, it merely
passes these artifacts/messages up to the eBusiness Server layer (or the
application as the case may be) for processing.

I sincerely hope that you understand the distinction I am, and have
consistently been, trying to draw here. The MSH functionality is merely a cog
in the greater wheel of things. The RM protocol is hop-to-hop as the TR&P team
agreed in face2face meetings long ago in a galaxy far, far (away about
a year ago now). We agreed to the "black-box" approach, meaning that
a receiving MSH takes responsibility for the reliable delivery (and
persistence, retries and all that goes with it). The sending MSH
does not know, nor does it need to know, what means by which an
intermediate MSH node might choose to use to effect that reliable
delivery as it has transferred the responsibility to the adjacent
MSH node.

The relay runner example I gave on the con call a couple of
weeks ago applies. The runner of the first leg cannot effect the
outcome of the race, he can only observe. He cannot re-run
the race or even his leg of it.

Cheers,

Chris

David Fischer wrote:
> 
> Chris, if DeliveryReceipt is not part of RM then how does the original sender
> know when to Retry (the essence of RM)?  The current Retry and RetryInterval
> parameters in CPPA are end-to-end *not* next-hop.  Are you saying the From Party
> MSH is not allowed to perform Retries?  That won't fly.
> 
> If you ARE allowing the From Party MSH to perform Retries then there must be
> some trigger.  I assume this trigger is DR (if not then what?).  If the From
> Party MSH is using lack of a DR for triggering Retries then what is the
> distinction from RM?  Just because DR is used for RM does not mean it cannot
> ALSO be used for NRR (double duty).
> 
> Are we talking past each other due to terminology?  Perhaps you are saying RM is
> by definition one hop at a time and if we have the exact same functionality over
> the entire path then we need a new term?
> 
> Regards,
> 
> David Fischer
> Drummond Group.
> 
> -----Original Message-----
> From: Chris.Ferris@Sun.COM [mailto:Chris.Ferris@Sun.COM]On Behalf Of
> christopher ferris
> Sent: Tuesday, September 04, 2001 10:03 AM
> To: Burdett, David
> Cc: ebxml-msg@lists.oasis-open.org; ebxml-cppa@lists.oasis-open.org;
> ebtwg@lists.ebtwg.org
> Subject: Re: Delivery Receipt, NRR and MSG/CPPA/BPSS (mis-)alignment
> andthelayering mishmash (was jumbled into: reliable messaging - hop by
> hop)
> 
> David,
> 
> Please see below. Thanks for trying to put this issue into perspective.
> 
> More specifically, with regards to the followimg "statements of fact",
> I have to take issue:
> 
> > 2. There is some support for keeping End-to-end receipts in the current ebMS
> > spec, the main dissenter being Chris F
> > 3. There is some support for removing End-to-end receipts from the current
> > ebMS spec - the main proposer being Chris F
> 
> I have been attempting to assert my position that the end-to-end
> receipts have nothing to do with the RM protocol that is defined
> for ebMS. I have never suggested that the DeliveryReceipt be removed
> from the ebMS spec.
> 
> An end-to-end receipt is useful in many use cases, but I maintain that
> it has nothing to do with reliable messaging as we have defined it.
> An end-to-end receipt IS useful for providing NRR.
> 
> An NRR receipt can be used/useful without RM. An NRR receipt can be
> used/useful when a transport-specific reliable protocol is used whether
> in single or multi-hop environments.
> 
> End-to-end reliability is achieved by REQUIRING that ALL nodes
> that participate in the exchange adopt the semantic equivalence
> of OnceAndOnlyOnce delivery. How they choose to do this is irrelevant.
> If two adjacent MSH nodes use the ebMS defined RM protocol, then
> a positive Acknowledgment from the receiving node serves as the
> means by which the sending node can be certain that the responsibility
> to deliver the message along its path has been successfully transferred
> to the receiving node. Any MSH node along the path MUST either be
> satisfied that the message has been safely delivered to the subsequent
> MSH node OR it MUST generate a delivery failure notification (DFN)
> which is targetted at the originator of the message (the From Party).
> 
> The delivery semantic of OnceAndOnlyOnce applies not only to
> the two ends, which is clearly the objective, but to all MSH nodes
> in between, especially when these nodes are intended to act upon
> the message for purposes other than routing. These processing intermediaries
> have just as much an interest that the message be received/processed with
> OnceAndOnlyOnce semantics as do the two ends.
> 
> As to the (mis)alignment of the receipts between BPSS, CPP/A and MS
> and third-party frameworks such as RosettaNet, I am all in favor of
> resolving the issue such that all of the relevant points of view
> are considered fully and such that all of the parties can come
> to a common understanding/agreement.
> 
> Cheers,
> 
> Chris
> 
> "Burdett, David" wrote:
> >
> > Chris/Dale/Arvola/Scott
> >
> > I agree with just about everything that was said in your recent emails on
> > this topic
> >
> > I also think we are getting close to a consensus and so perhaps we can take
> > the next step and come to a resolution.
> >
> > So below I have attempted to state the current consensus as a "statement of
> > fact" - i.e. there should be no disgareements on this ;)
> 
> I disagree, see above.
> 
> >
> > I then propose a course of action designed to achieve resolution of the
> > issue.
> >
> > Can everyone please:
> > 1. Review the statement of fact and indicate any corrections or omissions.
> > 2. Review the proposed set of actions and indicate whether they think they
> > are appropriate ... again please indicate any improvements
> >
> > Once we agree then we can carry out the actions and ... Bingo! ... the
> > decision is made.
> >
> > Regards
> >
> > David
> > ====================
> > BACKGROUND
> > Firstly, I think we haved recognized that there are two types of receipt:
> > 1. Messaging Infrastructure Receipts (i.e. generated by the MSH)
> > 2. Application Level Receipts (i.e. generated by the application or process
> > that will process the payload in a message)
> >
> > The receipts generated by the messaging infrastructure also fall into two
> > categories:
> > 1. Point-to-point receipts - i.e. a MSH acknowledges receipt of a message
> > back to the sending MSH when there are no other MSHs inbetween (these are
> > Acknowledgment Messages in the current spec)
> > 2. End-to-end receipts - i.e. a MSH at the To Party sends a message back to
> > the From Party to indicate that the message has been received (these are
> > Delivery Receipts in the current spec)
> >
> > There has also been a lot of our debate around:
> > 1. Whether any (or all) of these receipts could/should/must be used for
> > non-repudiation in ebXML
> > 2. How receipts such as these overlap with receipts specified in the ebXML
> > MSG, BPSS and CPPA specs.
> > 3. The extent to which these receipts can/should/might/must? be substitutes
> > for similar messages that exist in other protocols, e.g. RosettaNet.
> 
> All of the above is true, but I also think that what is missing above
> is any statement about whether the various receipts are required for RM.
> 
> >
> > STATEMENT OF FACT
> > So here's my take on the consensus we have reached presented a series of
> > statements of fact:
> > 1. There is agreement on the need for Point-to-point receipts
> > (Acknowledgment Messages) in the ebMS spec
> 
> Agreed, for use to effect the "ebXML" reliable messaging protocol.
> 
> > 2. There is some support for keeping End-to-end receipts in the current ebMS
> > spec, the main dissenter being Chris F
> 
> I do not dissent to this. I simply maintain that they are not an
> aspect of reliable messaging from the MSH POV.
> 
> > 3. There is some support for removing End-to-end receipts from the current
> > ebMS spec - the main proposer being Chris F
> 
> I have never suggested that they be removed.
> 
> > 4. There is agreement that Application Level Receipts are not part of the
> > ebMS spec
> > 5. There is consensus that we need to consider NRR as part of the ebMS spec.
> 
> I don't think that there is consensus on this.
> 
> > 6. There is consensus that:
> >    6a) A signed End-to-End receipt "can" (see note 1) be used to provide
> > some measure of non-repudiation
> 
> I agree to *can*.
> 
> >    6b) Complete Non Repudiation will in some circumstances require signed
> > Application Level Receipts
> 
> Agreed.
> 
> > 7. There is consensus that there is overlap between the various types of
> > "ebXML Receipts" (in the MS, CPP/A & BPSS specs) that needs to be resolved
> 
> Agreed.
> 
> > 8. There is agreement that there is overlap between the "ebXML Receipts" and
> > similar receipts in other specs, for example RosettaNet.
> 
> Agreed.
> 
> > 9. Other standards groups, e.g. RosettaNet, OAG, have stated that they want
> > to adopt the ebXML messaging spec
> 
> Agreed.
> 
> >
> > Note 1. I use the word "can" in 6a) above because all the security related
> > aspects of signing message have to be used in an appropriate way, e.g. trust
> > hierarchies, privacy of keys, etc before an End-to-End receipt could be used
> > for non-repudiation
> 
> Agreed.
> 
> >
> > PROPOSED ACTIONS
> > Given the above "Statement of Fact" I propose that we do the following:
> > 1. Hold a vote on whether or not End-to-End Receipts (signed Delivery
> > Receipts) stay in the ebMS spec, and if the result is positive ...
> > 2. Include a section in the spec on Non Repudiation explaining the benefits
> > and limitations of using a signed Delivery Receipt for this purpose - this
> > should reflect the recent discussions on this list and needs be separately
> > agreed
> > 3. Set up a joint sub-team between MSG, CPP/A and BPSS project teams to
> > create a common approach towards the specification and use of "receipts".
> > This team should seek input from RosettaNet and OAG (only?) to make sure
> > that the methods identified meet the needs of these standards groups.
> > 4. Revise the ebMS specification taking the results of the previous three
> > steps into account
> > 4. Let other standards groups, such as RosettaNet and OAG build on the ebMS
> > spec as they see fit.
> 
> This is all fine, but doesn't address the main issue of whether the
> delivery receipt is an artifact of RM or something else.
> 
> >
> > Thoughts?
> >
> > David
> >
> <snip/>
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
begin:vcard 
n:Ferris;Christopher
tel;cell:508-667-0402
tel;work:781-442-3063
x-mozilla-html:FALSE
org:Sun Microsystems, Inc;XTC Advanced Development
adr:;;;;;;
version:2.1
email;internet:chris.ferris@east.sun.com
title:Sr. Staff Engineer
fn:Christopher Ferris
end:vcard