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

[Dan Weinreb <dlw@exceloncorp.com>]

   Date: Fri, 31 Aug 2001 09:40:39 -0700
   From: Dale Moberg <dmoberg@cyclonecommerce.com>

   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. 

Yes.  This signed DR can be used to prove that a message was
"received", whether you think that's important or not.

		     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).

I don't think this needs to be done by putting a separate "extension
mechanism" into the MS protocol.  The higher levels like BPSS can use
MS to exchange arbitrary messages, and if they want these arbirary
messages to contain various signed data, that's up to them.  In
other words, MS's ability to deliver payloads is already an
extension mechanism.

   What is an application level acknowledgement 
   as opposed to the application
   level response? 

I don't think there's any difference.  The application level will be
able to send back signed documents that mean "I hereby promise that I
took the following real-world business action", which is what the
sender is really interested in.