Blake:
> 1. I just realized there is no abstract for this document. Is one
> required?
Don't know -- someone comment.
There is supposed to be one. RFC 2633 got through without one. Today's
IESG would not have let it happen. I suggest:
This document defines S/MIME (Secure/Multipurpose Internet Mail Extensions)
version 3.1. S/MIME provides a consistent way to send and receive secure
MIME data. Digital signatures provide authentication, message integrity and
non-repudiation with proof of origin. Encryption provides data
confidentiality.
> 2. Section 2, p1: s/[CMS] provides/[CMSALG] provides/
Done.
> 3. Section 1.1, p 4: Should there be a dependency/reference
> to CMSALG here
> as well?
Dunno. "No" for now.
I think it is a good idea to include the reference.
[snip]
> 18. Section 2.4.1, p1: s/signedData/SignedData/
> - also envelopedData vs EnvelopedData and compressedData vs
> CompressedData.
> signedData does not actually exist in the CMS
> documents. The type
> is SignedData or the concept is signed data. I think we need
> to clean this
> up.
> Russ: Please note there is one section in CMS that needs to be
> cleaned up in the same way.
Thanks. It will be fixed in rfc3369bis-02.
> 21. Section 2.4.2, p1: Should add "This content type does not provide
> privacy."
And also add "and does not provide compression"? Should we just remove
"does not provide authentication" from the EnvelopedData section? Not
changed.
I think we should be talking about "confidentiality" not "privacy." See
the definitions of these words in RFC 2828.
[snip]
Russ