John:
I do not know about the UK Postal service, but a receipt from the US Postal
Service means that the parcel was delivered. It does not mean that the
recipient could comprehend the contents.
The digitally signed receipt offers more service than is available in the
physical world today.
Russ
At 09:10 AM 4/15/98 -0700, John Ross wrote:
In my view part of the problem is in the name. The service provided by ESS
signed receipts is a proof that the message was delivered, all signature and
other security services where OK. It does not imply that the semantics of
the message as viewed by the user (or user application) are understood. It
could still be rubbish as far as an application processing the message is
concerned.
I do support the need for the two layers of "Receipt", one at the point of
delivery and the other at the point of the EDI application processing (or
human user notification in the case of E-mail).
Perhaps the name ESS signed receipt can be changed and made more
descriptive of the service it is providing, may I proposed "ESS proof of
delivery".
Regards
John Ross
-----Original Message-----
From: Paul Hoffman / IMC <phoffman(_at_)imc(_dot_)org>
To: ietf-smime(_at_)imc(_dot_)org <ietf-smime(_at_)imc(_dot_)org>
Date: Tuesday, April 14, 1998 12:16 PM
Subject: RE: Rethinking Receipt
At 08:36 PM 4/13/98 -0500, Rik Drummond wrote:
I believe if you read the RFC for the MDN, which includes how to do
receipts you will find that a signed receipt may contain information such
as "deleted" and "processed".
Warning, warning: layering violation! RFC 2298 never talks about signed
receipts. And nor should it.
The ESS signed receipt has a much narrower focus than RFC 2298 for good
reason: it's much simpler for the recipient of the receipt to understand
what they get. S/MIME with or without ESS works just fine with RFC 2298
messages. The recipient of the RFC2298 message has the option of signing
their MDN using plain, ordinary S/MIME without ESS.
Please remember that ESS is an optional part of S/MIME v3. I do not want a
situation where in order to get a signed copy of the kind of information an
MDN gives, both sides must have ESS. That's a protocol layering violation.
As long as S/MIME v3 doesn't prohibit MDN messages (which it of course
doesn't), we've got all the parts we need. If we duplicate the kind of
information in an RFC2298 response, we open ourselves to all sorts of
problems, and I doubt we'll get it on standards track with such an obvious
layering violation.
As for EDIINT, I would strongly urge you to simply have RFC 2298 MDN
messages that are signed by S/MIME v3 without ESS. You should add the
requirement that the recipient of a receipt request should not sign the
response unless they could validate the originator's signature.
--Paul Hoffman, Director
--Internet Mail Consortium