-----Original Message-----
From: Russ Housley [mailto:housley(_at_)vigilsec(_dot_)com]
Sent: Sunday, February 29, 2004 9:16 PM
To: Blake Ramsdell; ietf-smime(_at_)imc(_dot_)org
Subject: Re: WG LAST CALL: draft-ietf-smime-rfc2633bis-07.txt
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.
Deleted.
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.
4. What compression algorithm MUST be implemented if
CompressedData is
supported?
Has this train finished wrecking or is it still in progress?
5. Section 2.5.2: s/SMIMECapabilities attribute
should/SMIMECapabilities
attribute SHOULD/
Fixed.
6. Section 2.6: the first two paragraphs are not clear.
S/MIME v3.1 MUST
support both issuerAndSerialNumber and subjectKeyIdentifier
for sending and
receiving.
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.
7. Section 3.4.3.2: s/not currently supported in S/MIME/not
currently
recommended in S/MIME/
Fixed.
Blake