OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: reliable messaging - hop by hop


You are right a NRR would have to be signed. So perhaps the correct way is
to state that:
1. A Delivery Receipt is evidency that the To Party MSH has received the
message.
2. A Delivery Receipt signed with a valid signature using a certificate that
identifies the To Party can be used as non-repudiation or receipt (NRR) of
the message.

OK? Any tweaks?

David

-----Original Message-----
From: Ralph Berwanger [mailto:rberwanger@bTrade.com]
Sent: Thursday, August 30, 2001 11:20 AM
To: ebxml-msg@lists.oasis-open.org
Subject: RE: reliable messaging - hop by hop


David,
	Not to be pedantic, but when would you expect to have unsigned
NRR?  Anyway, I agree with the scope of the definition.  I also agree
with Arvola that we are mixing two issues.  You start with the question
of NRR, then define Delivery Receipts.  Can I assume that we still
intend to support the Delivery Receipts that do not provide NRR--that
is, they are not signed.  Somehow, we need to uncouple these two points.

Ralph Berwanger


-----Original Message-----
From: Burdett, David [mailto:david.burdett@commerceone.com]
Sent: Thursday, August 30, 2001 1:07 PM
To: 'Dan Weinreb'; mwsachs@us.ibm.com
Cc: david@drummondgroup.com; chris.ferris@east.sun.com;
ebxml-msg@lists.oasis-open.org
Subject: RE: reliable messaging - hop by hop


I think that we should define the signed NRR as being sent by the To
Party
MSH and not require that the application has previously been notified. 

The issue is that there may be further stores and queues between the To
Party MSH and the actual application that prevent the To Party MSH from
EVER
knowing if the application received it. So how about this as the
definition
for the Delivery Receipt ...

"The Delivery Receipt is a message sent by the To Party MSH back to the
sender of the original message that indicates that the To Party MSH has
received the message and will forward it to the appropriate To Party
process
or application."

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 tha 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.
I actually think that the second one is really an application level
acknowledgement,

David

-----Original Message-----
From: Dan Weinreb [mailto:dlw@exceloncorp.com]
Sent: Wednesday, August 29, 2001 9:35 PM
To: mwsachs@us.ibm.com
Cc: david@drummondgroup.com; chris.ferris@east.sun.com;
ebxml-msg@lists.oasis-open.org
Subject: Re: reliable messaging - hop by hop


   Date: Wed, 29 Aug 2001 15:34:37 -0400
   From: Martin W Sachs <mwsachs@us.ibm.com>

   MWS:  This is one of the really sticky points about time-to-live. One
   possibility is that once the application is made aware of the
presence
   of a given message in the persistent store, that message shall not be
   deleted except by the application.  

Yes, you're right.  Once the message has reached persistent storage
at the To Party MSH, there's no longer any reason to worry about
time-to-live.	

				       If the signed NRR is returned
only
   when the To application is made aware of the message, that should
take
   care of this problem except that it then isn't clear what the value
of
   time-to-live is.

Its value is for duplicate elimination, so that a receiver is free
to garbage-collect this message ID from its persistent table of
message ID's.  Once the message has arrived at the To MSH and
at arrival time found to not be a duplicate, we don't have to
worry about expiring it.  OK, no problem then.  "Never mind."

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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC