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

[Doug Bunting <dougb62@yahoo.com>]

David,

It's worth adding one more thing to your statements: The separate
discussion of hop-by-hop delivery acknowledgment versus end-to-end
reliable messaging indicates we need to improve that wording.  A
corollary might recognize a potential overlap between the two
mechanisms and that additional requirements on intermediate nodes may
increase the potential overlap.  This leads to work items improving the
text and making the use cases for either approach more clearly
distinct.

From reading through this discussion, I'm also unsure we've come to a
common position on whether NRR is an application-level signal in all
cases.  The layering issues cover a broader spectrum than just "MS
versus application" in any case.

Otherwise, thanks for a good summary of 100s of messages.

...doug

PS. I didn't include ebxml-cppa or ebTWG in this reply because I seem
to be focusing on the ebMS issues.  Please forward if you think the
other groups need to hear more.

--- "Burdett, David" <david.burdett@commerceone.com> 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 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.
> 
> 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
> 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
> 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.
> 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
>    6b) Complete Non Repudiation will in some circumstances require
> signed
> Application Level Receipts
> 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
> 8. There is agreement that there is overlap between the "ebXML
> Receipts" and
> similar receipts in other specs, for example RosettaNet.
> 9. Other standards groups, e.g. RosettaNet, OAG, have stated that
> they want
> to adopt the ebXML messaging spec
> 
> 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
> 
> 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.
> 
> Thoughts?
> 
> David
> 
> 
> Arvola ...
> >>>One thing I like to see clarified in the MSG spec is that signed
> DeliveryReceipts are not intended to satisfy the NRR requirement for
> business signals in the UMM model that underlies the BPSS spec.<<<
> 
> Define what it is but remember trust.
> 
> Arvola ...
> >>>Yes, ReceiptAcknowledgements are generated by the
> RosettaNet middleware. It may not be entirely feasible for the
> the middleware to automatically generate the
> AcceptanceAcknowledgement because the validation of
> business rules is withint the domain of the private processes.
> However, this issue is kind of moot because no PIP uses
> the AcceptanceAcknowledgement signal.<<<
> 
> Scott H ...
> >>>I would hope that Rosettanet would throw away OASIS Messaging
> would do -
> but all of this said without detail involvement with the Rosettanet
> mapping.<<<
> 
> Scott H ...
> >>>I agree. Further, I suggest it [the Delivery Receipt] be renamed
> to
> "MessageReceipt".<<<

</ SNIP>


__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
http://im.yahoo.com