Re: T2 Non repudiation and MSG, CPP/A, BPSS spec alignment

[Arvola Chan <arvola@tibco.com>]

David:

In the BPSS spec, a BusinessTransaction has an isGuaranteedDeliveryRequired
attribute (see section 7.2.1 BusinessTransaction). I believe this is
equivalent to the reliable messaging concept in the CPP/A and MSG specs.

IsNonRepudiationRequired and IsNonRepudiationOfReceiptRequired, on
the other hand, are specified at the BusinessAction level (see section 7.2.2
Business Action). My understanding is that the isGuaranteedDeliveryRequired
and isNonRepudiationOfReceiptRequired attributes can be set independently.
In other words, non repudiation of receipt can be turned on without the use
of reliable messaging also being enabled.

Cheers,
-Arvola

-----Original Message-----
From: David Fischer <david@drummondgroup.com>
To: Arvola Chan <arvola@tibco.com>; ebxml-msg@lists.oasis-open.org
<ebxml-msg@lists.oasis-open.org>
Cc: ebxml-cppa@lists.oasis-open.org <ebxml-cppa@lists.oasis-open.org>
Date: Thursday, August 30, 2001 12:17 PM
Subject: RE: T2 Non repudiation and MSG, CPP/A, BPSS spec alignment


>
>NRR and RM are not orthogonal.  We need to send a Receipt to the sender
stating
>that the Message has arrived -- RM.  NRR is something we add to a Receipt
to
>ensure authenticity.    Security is never orthogonal to anything.  Security
is
>always an add-on.
>
>Regards,
>
>David Fischer
>Drummond Group.
>
>-----Original Message-----
>From: Arvola Chan [mailto:arvola@tibco.com]
>Sent: Thursday, August 30, 2001 12:28 PM
>To: ebxml-msg@lists.oasis-open.org
>Cc: ebxml-cppa@lists.oasis-open.org
>Subject: T2 Non repudiation and MSG, CPP/A, BPSS spec alignment
>
>
>The BPSS spec says that nonRepudiationOfReceipt (NRR) is tied to the
>ReceiptAcknowledgement signal. NRR and reliable messaging are orthogonal. A
>business process may specify the non repudiation of receipt for the
>requesting business activity business message and/or the repudiation of
>receipt for the responding business activity business message, without
>requiring that reliable messaging be used. I think the Messaging Service
>should not tie NRR to the DeliveryReceipt element if the latter is used
>exclusively in reliable messaging.
>
>The MSH is not responsible for validating the syntax of payloads. NRR at
the
>MSH level does not really implement NRR as called for by the business
>process specification. NRR at the BPSS level includes syntax validation on
>the payloads. Receipt Acknowledgement business signals have to be persisted
>in order to satisfy legal requirements implied by NRR. I just don't see the
>utility of persisting the DeliveryReceipt generated at the MSH level in
>addition to the ReceiptAcknowledgement signal. This may just be unnecessary
>overhead.
>
>Currently, NRR parameters are tied to the DeliveryChannel element in the
>CPP/A. According to Marty, these parameters may have to be relocated /
added
>to the ProcessSpecification and/or the Role element in order to properly
>model the non repudiation requirements associated with the business
process.
>
>I strongly feel that non repudation is one area that the MSG, CPP/A, and BP
>groups must closely coordinate among themselves in their 1.1
specifications.
>
>-Arvola
>
>
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>
>