[Top] [All Lists]

RE: Rethinking Receipt

1998-04-14 07:06:00
It can't be independent of the signed-receipt.

A signed-receipt which only gives status information that it got there and 
the signature was readable is not good enough for many 
application-to-application implementation. They often need to know more 
than that.  The signed-receipt (or just receipt) should convey the type of 
information that these applications need to automate the process. The 
status codes should be expanded to allow things like "deleted" or 
"processed" .

A tremendous amount of work went into this area over the last two years the 
groups should at least look at it to understand why I am saying what I am 

The IETF's EDIINT WG which has I-D out on how to do secure EDI over 
internet would some day like to use the work you are doing. We can't unless 
we have additional status codes in the signed-receipt.

Thanks for your help, Rik

-----Original Message-----
From:   John Pawling [SMTP:jsp(_at_)jgvandyke(_dot_)com]
Sent:   Tuesday, April 14, 1998 8:28 AM
To:     Rik Drummond; 'ietf-smime(_at_)imc(_dot_)org'
Subject:        RE: Rethinking Receipt


You are proposing to add a security service to ESS that is very different
than the services provided by the ESS signed receipt.  I am not oppossed to
you proposing new features to be added to ESS.  I am opposed to proposals
that overload the current ESS signed receipt concept and syntax.  Please
re-formulate your proposal so that it is independent of the ESS signed
receipt concept and syntax.

John Pawling, jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.

At 07:45 AM 4/14/98 -0500, Rik Drummond wrote:
Then I suggest we relook at what applies and what does not, because if you 
don't implement "reply-status" functionality such as in the RFC 2298, then 
you are greatly reducing the applicability of S/MIME v3 for
application-to-application implementations. I-Ds are not authoritative
sources.... that is why they are called Internet-Drafts......and my
comments apply....

The best regards, Rik

<Prev in Thread] Current Thread [Next in Thread>