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

[David Fischer <david@drummondgroup.com>]

Yes, absolutely, everything the MSH does is at the behest of an application.
The sending MSH performs/requests NRR when receiving a signal from the
application, in conjunction with a file to be sent.  The receiving MSH actually
does NRR when receiving a deliveryReceiptRequested=Signed.

David Fischer
Drummond Group.

-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Wednesday, September 05, 2001 1:15 AM
To: David Fischer
Cc: Dale Moberg; ebxml-msg@lists.oasis-open.org
Subject: RE: Delivery Receipt, NRR and MSG/CPPA/BPSS (mis-)alignment and
the layering mishmash (was jumbled into: reliable messaging - hop by
hop)



David,

I'm not an expert on security matters but I am sensing from the discussions
that there is a substantial body of opinion on the side of considering
nonrepudiation as an application-level function even if the entity that
actually applies it is the MSH acting on behalf of the application and that
on the receiving end, it is the application that is interested in
nonrepudiation and has the responsibility to save the nonrepudiation
information in tamperproof storage, etc.

In any case, the main point that I tried to make was that there was no
serious thought behind putting the CPA nonrepudiation element in the
delivery channel.  In fact, I believe it is there because it was there in
the IBM tpaML submission and none of us on the TP team gave any thought to
whether it is in the right place.  The first step is to come to a consensus
as to which architectural layer is the right place for nonrepudiation.
Then, if it is not in an appropriate place in the CPA, it should be moved.

Regards,

********************************************************************************
*****

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
********************************************************************************
*****



David Fischer <david@drummondgroup.com> on 09/04/2001 12:42:45 PM

To:   Martin W Sachs/Watson/IBM@IBMUS, Dale Moberg
      <dmoberg@cyclonecommerce.com>
cc:   ebxml-msg@lists.oasis-open.org
Subject:  RE: Delivery Receipt, NRR and MSG/CPPA/BPSS (mis-)alignment and
      the layering mishmash (was jumbled into: reliable messaging - hop by
      hop)



Marty, you said you are now understanding that NRR is not MSH
functionality.
Why?  What has made you come to that conclusion?

David Fischer
Drummond Group.

-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Sunday, September 02, 2001 1:35 AM
To: Dale Moberg
Cc: ebxml-cppa@lists.oasis-open.org; ebxml-msg@lists.oasis-open.org
Subject: Re: Delivery Receipt, NRR and MSG/CPPA/BPSS (mis-)alignment and
the layering mishmash (was jumbled into: reliable messaging - hop by
hop)



Dale,

With regard to your statement:

   If there is a
   BPSS requirement for NRR, does that mean that
   the lower layers are to provide an implementation
   supporting NRR? Or is it an indication that the design
   of the business data structures in Requests and
   Responses support NRR functionality? Or is something
   else meant? CPPA has, I think, mainly been thinking
   that a BPSS requirement of NRR was a request that
   the underlying layers provide an implementation for
   NRR (an implementation that can be a basic or
   a more enriched implementation).

I believe that the CPPA team was (implicitly or explicitly) thinking that
NonRepudiation in the CPA is an explicit request for the MSH to provide
NRR.  The reason is that the NonRepudiation element is under DocExchange,
which is the configuration information for specific MSH functionality.  I
am now beginning to understand that the thinking is not correct.  From an
implementation viewpoint, NRR may well be implemented by "the lower
layers", but architecturally not by MSH.  NRR may well be implemented by a
middleware module acting on behalf of the application but architecturally,
NRR is application function. If I am right, NonRepudiation should be moved
to be a child of one of the elements related to the BPSS, probably to
CollaborationRole or one of its child or grandchild elements.

Regards,
Marty

********************************************************************************

*****

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
********************************************************************************

*****



Dale Moberg <dmoberg@cyclonecommerce.com> on 08/31/2001 12:40:39 PM

To:   ebxml-cppa@lists.oasis-open.org, ebxml-msg@lists.oasis-open.org
cc:
Subject:  Delivery Receipt, NRR and MSG/CPPA/BPSS (mis-)alignment and the
      layering mishmash (was jumbled into: reliable messaging - hop by hop)



David,

I read one of your recent notes in which
you present some interesting alternatives,
and I would like to comment on these in the
hopes of aligning BPSS, MSG, and CPPA on
the NRR issues.

David Burdett says, almost as an aside:
"The other alternative would be to provide
two variations of the Delivery
Receipt, one which indicated that the
To Party MSH had received and the
second that the To Party Application
had been notified of the message, but I
don't really want to go there as it
is definitely additional functionality."

Despite your disclaimer, I think this is
an area we should discuss so that we
can align BPSS CPPA and MSG on NRR.
(Maybe pretty soon I can write a
sentence consisting entirely of
acronyms.)

I think that there _could_ be one DeliveryReceipt
with an extension mechanism
that could be used for all the additional
conditions that tend to get
tacked on to the DeliveryReceipt:
One condition would be that the To Party
Application was notified, another would be
that the syntax had been checked,
a third, that the syntax had been checked
and the data typing had been
checked and the values were in
allowed ranges, and so on. We would in CPPA
need an enumeration for the main
different extensions, and a general
"namespace supported" element to gesture at
yet unthought of extensions (or whatever
is the extension mechanism du jour).

But strictly speaking,
the functionality in these NRR
extensions is beyond what
a MSH needs to carry out its main
jobs, even when that job includes
supporting NRR. Let me briefly
expand on this.

NRR is something that
rarely ends up getting uniquely
characterized in terms of what needs
to be _implemented_. We know what we
want to obtain more or less, but can rarely agree
upon what will always be sufficient
to attain it. Because any processing
exception that occurs after the MSH
finishes its work may provide the To-Party
a legal "way out," NRR always seems to be falling
short of removing all wiggle room.

I seriously doubt that we will remove
all the wiggle room, and that there will always
be some exceptional condition after receipt
and after sending a DeliveryReceipt, that
would result in a processing failure on
the ReceivingParty side (bad syntax,
semantics, and so on). To try to rule out
each of these conditions by checking each of them
before sending a DeliveryReceipt, leads to
endlessly bloating DeliveryReceipt functionality, and
finally a need to be in the position of being able
to produce the Business Response before issuing
a DeliveryReceipt. Clearly this drift leads to a layering
mish-mash.

In EDIINT we had very similar requirement
flux. Eventually we just left an open extension
mechanism for receipts, in terms of what
can be added by industry groups. RosettaNet
went through similar struggles in working
out its private/public division.

I personally think it would
be good just to draw a line and say that
"Receipt is obtained when the MSH has persisted the
message payload off the wire," and let the MSH
handle sending the DeliveryReceipt, signed
and including an appropriate hash for the
original message. Nevertheless, adding on an
extension mechanism may appease others (especially
in the BPSS side of things) enough
that we can get all three main groups
(BPSS, CPPA, and MSG) to agree that NRR has been
implemented OK. The problem then will be
in documenting this extension mechanism
so that we can capture publication of and
agreements upon extensions within CPPs and CPAs.
We can then let the CPA adjudicate just how
much "creep" into the application realm occurs
(syntax check on payload, etc).

So, David B's compromise might be a good way
to proceed if the MSH is to provide
NRR functionality.

An alternative would
be to follow Chris Ferris general preference
to push all NRR all the way back up to the application.
(At least I hope I am not misrepresenting Chris here.)
I think, though, that would make the MSH far less
interesting as a middleware component module.
Pragmatically, NRR is not something that anything
but new applications would be able to provide and even
then, it might be difficult to ensure access to the
data elements needed to compute the hash to indicate
being in posession of the original message/payload/whatever.

Moving on, David B. later says:

"I actually think that the second one
[involving an application notification assurance]
is really an application level acknowledgement."

I think we need to wonder why the application
layer needs an acknowledgement, or why
it needs to get involved in NRR issues.

What is an application level acknowledgement
as opposed to the application
level response? Why should an application
need to get involved in producing a
receipt instead of its defined application level response?
This seems to be forcing applications to get involved
in detailed delivery related issues, when an application
may only know only about its tasks to be performed
and what do with its results (regardless of how the task got
queued up to it...).

I think that the BPSS group needs to explain
why business applications should at all be in the
business of worrying about generating acknowledgements
or receipts. This is a source of layering conflict that is
causing both CPPA and MSG difficulties in understanding
how to finish their own tasks. If there is a
BPSS requirement for NRR, does that mean that
the lower layers are to provide an implementation
supporting NRR? Or is it an indication that the design
of the business data structures in Requests and
Responses support NRR functionality? Or is something
else meant? CPPA has, I think, mainly been thinking
that a BPSS requirement of NRR was a request that
the underlying layers provide an implementation for
NRR (an implementation that can be a basic or
a more enriched implementation).

Is an application level acknowledgement
an application response in addition to the real
application business response or perhaps instead of a
business response? I think that if a business
layer process thinks it needs such an
acknowledgement for its own purposes,
then that function should be built into BPSS
specifications as requirements concerning the
detailed algorithms, hashes, etc in the structured data
exchanged in requests and responses. In this
case, NRR will be opaque to the MSH layer,
and there will need to be no agreement on how
NRR is to be achieved/implemented (so DeliveryChannel
characteristics do not need to be assessed
to see whether NRR is supported on a channel.)
This may be consistent with the Chris Ferris option
discussed above; I personally would like to see
a POC demonstrating this approach working interoperably
before allowing it in an approved spec.

Dale Moberg

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




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


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




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