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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

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


Subject: Re: reliable messaging - hop by hop


+1

Dan Weinreb wrote:
> 
>    Date: Wed, 29 Aug 2001 09:54:15 -0400
>    From: christopher ferris <chris.ferris@east.sun.com>
> 
>    A NRR *may* not be meaningful in a legal sense unless it is
>    signed by an authorized signer. The private key for the certificate
>    that is authorized *may* not be available to the MSH for security
>    reasons.
> 
>    This is why it is my strong belief that NRR is an "application"
>    function.
> 
> I agree with you, but I think there is an additional argument that NRR
> must be an "application" function, independent of the question of the
> handling of the private keys.
> 
> If an NRR is not application-level, then presumably the NRR merely
> means that the message reached the MSH of the To Party, i.e. that the
> message was delivered into a persistent queue at the To Party, or
> something like that.
> 
> If that's all that the NRR means, it seems to me that it's not
> terribly useful.  Suppose party F sends a message to party T, and gets
> back such an NRR.  Later there is a dispute, and F wants to "prove"
> (introduce evidence that) T really did "receive" the message, and so
> it introduces the signed NRR as evidence.  T replies that, well, yes,
> the message did get into its MSH, but T never actually processed the
> incoming message; it was just sitting there on the disk somewhere and
> nobody ever actually looked at it.  In this way T can effectively
> repudiate the message in spite of the existence of a signed NRR.
> So the signed NRR really doesn't help F; he might as well not have
> it at all.


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


Powered by eList eXpress LLC