[Top] [All Lists]

RE: WG LAST CALL: draft-ietf-smime-rfc2633bis-07.txt

2004-03-26 07:32:00


> 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
> supported?

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
> should/SMIMECapabilities
> 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
> 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.

Works for me.

> 7.  Section s/not currently supported in S/MIME/not
> currently
> recommended in S/MIME/