> 1. Should Section 1.4 reference RFC 3369?
This section just describes where "prior practice of S/MIME" is located.
I think that RFC 3369 is "current practice of S/MIME".
> 2. Delete section 1.6 before the document is sent to the IESG.
> 3. Section 2.4 probably should point out that ContentInfo is
> needed to
> encapsulate each of the protection content types.
Hmm. I don't agree. This is meant to describe the subset of types that
are supported by S/MIME, independent of their encoding.
Okay. I accept that ContentInfo is not a content type.
> 4. What compression algorithm MUST be implemented if
> CompressedData is
Has this train finished wrecking or is it still in progress?
I think we know where all the pieces landed.
> 5. Section 2.5.2: s/SMIMECapabilities attribute
> attribute SHOULD/
> 6. Section 2.6: the first two paragraphs are not clear.
> S/MIME v3.1 MUST
> support both issuerAndSerialNumber and subjectKeyIdentifier
> for sending and
S/MIME v3.1 implementations MUST support both issuerAndSerialNumber as
well as subjectKeyIdentifier. Messages that use the
subjectKeyIdentifier choice cannot be read by S/MIME v2 clients.
Works for me.
> 7. Section 184.108.40.206: s/not currently supported in S/MIME/not
> recommended in S/MIME/