Comments draft-ietf-smime-rfc2633bis-07.txt

["Jim Schaad" <[e-mail]>]

Hi Blake,


1.  I just realized there is no abstract for this document.  Is one
required?

2.  Section 2, p1:  s/[CMS] provides/[CMSALG] provides/

3.  Section 1.1, p 4: Should there be a dependency/reference to CMSALG here
as well?

4.  Section 2.5.2, p1: Need to add text for Compression Algorithms.

5.  Section 2.5.2:  The following statement is no longer true (please
delete):
Note that all OIDs associated with the MUST and SHOULD implement algorithms
are included in section A of this document.

6.  section 3, p 1: s/[ESS] document provides examples/[ESS] document
provides descriptions/
			s/ESS provides an example of/ESS provides a
description of/

7.  Section 3.1, p 5, s/implementor/implementer/
    Section 3.6, p 3: ditto
    Section 4.1, p 2: ditto
	- I don't know if that is really an incorrect spelling, but MS Word
does not know it.

8.  Section 3.2.1, s/Application/pkcs7-signature/Application/pkcs7-signature
(SignedData)/

9.  Section 3.2.2, p last:  Suggest adding the text:  "An smime-type
parameters is not intended to give indications of security layers applied in
the event of multiple levels of wrapping."

10. Section 3.4: In general, the multipart/signed form is preferred for
sending, and
receiving agents SHOULD be able to handle both. --- what is the MUST handle?
Otherwise there is no interop.

11:  Section 3.4.3.2:  The text 
"The SHA-256, SHA-384 and SHA-512 algorithms [FIPS180-2] are not
currently supported in S/MIME, and are included here for completeness."
Is only partially correct.  They are supported, just not required by this
document.  I would like to clean this up by saying this in a tighter
fashion.

12.  Section 4, p 1: s/certification/certificate/

13.  Section A:  s/prefered/preferred/

14.  References:  CMSAES = RFC 3565

15.  Section 1.1, p 4: s/the Cryptographic Message Syntax/the Cryptographic
Message Syntax document/

16.  Is a specification MUST/SHOULD (section 1.1, p4) or the document
(section 1.1, p3) (The same word is used, but in completely different
meanings.  Would not be a problem but for the MUST in p4 potentially wanting
to force meaning into p3).

17.  Section 2.2, p 3: s/the algorithms/the hash algorithms/

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.

19.  Section 2.4.1, p1: s/encryptedContentInfo
ContentType/encryptedContentInfo contentType/

20.  Section 2.4.1, p1: s/in the envelopedData/in the EnvelopedData/

21.  Section 2.4.2, p1: Should add "This content type does not provide
privacy."

22.  Section 2.5 title, s/Attribute/Attributes and the/

23.  Section 2.5.2, p 3: s/SMIMECapabilites/SMIMECapabilities/

24.  I heard this comment at the last IETF meeting from somebody.  As I have
had the same problem in a number of cases (esp with doing interop matrixes)
I am throwing it out for your consideration:

The use of the words must, should and may in lower case causes some
confusion dealing with the question of - did the author just forget to
uppercase this or is it really not a protocol statement.  SHOULD examine all
instances of these words to see if a different word works just as well.

Jim