At 02:25 PM 4/14/98 -0500, Rik Drummond wrote:
I have read the ESS document (SMIME V3). It is clearer to me than before
that the ESS signed-receipt must be modified to support
receipt-status-codes along the lines of RFC2298 before it is allowed to
move up the RFC track.
Rik, I can't disagree with you more, and I'm confused by your insistence here.
draft-ietf-ediint-as1 very clearly states that the MDNs used by EDI should be
in MDN format. Further, that draft describes that if a recipient can't sign a
requested receipt, they should send an unsigned receipt back. These two
mechanisms make perfect sense to me.
Now you're saying, "forget MDN format, and forget sending back unsigned
receipts" by demanding this in ESS, and demanding that EDIINT use this
mechanism only. What the heck is wrong with using non-ESS S/MIME v3 to sign
RFC
2298 content?
It would be no problem to define a new attribute which is carried in the
signed-receipt which shows status that could be used by applications.
Status such as "deleted", "processed", etc.
Yes it would. We would also have to describe what a recipient should do if
they
receive a message that has an ESS attribute marked "deleted" that is
signing an
MDN that says "processed", and so on. Which takes precedence? This is why I
said that putting the attribute outside the received message is a layering
violation.
Additionally, the draft should clearly state that the preferred method of
signing a document is "multipart/signed" and the PKCS7 signed is optional.
This is not covered in the ESS document: it's covered in the MSG document.
We've debated it endlessly before, and the group concensus was that both have
valid purposes, and neither is always better than the other.
--Paul Hoffman, Director
--Internet Mail Consortium