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,

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