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
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
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
The best regards, Rik