From: Jim Schaad [mailto:jimsch(_at_)nwlink(_dot_)com]
Sent: Monday, March 08, 2004 2:34 AM
To: 'Blake Ramsdell'
Subject: Comments draft-ietf-smime-rfc2633bis-07.txt
1. I just realized there is no abstract for this document. Is one
Don't know -- someone comment.
2. Section 2, p1: s/[CMS] provides/[CMSALG] provides/
3. Section 1.1, p 4: Should there be a dependency/reference
to CMSALG here
Dunno. "No" for now.
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
Note that all OIDs associated with the MUST and SHOULD
are included in section A of this document.
Entire paragraph removed.
6. section 3, p 1: s/[ESS] document provides examples/[ESS] document
s/ESS provides an example of/ESS provides a
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.
This is like "advisor" vs. "adviser" I think. In any case, can't have
Word upset, so modified.
8. Section 3.2.1,
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."
What do you see as the confusion here? Not done.
10. Section 3.4: In general, the multipart/signed form is
receiving agents SHOULD be able to handle both. --- what is
the MUST handle?
Otherwise there is no interop.
Don't know -- bees nest. Start a discussion... If you say MUST send
SignedData, I imagine that's going to be an issue. Maybe MUST
11: Section 18.104.22.168: 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
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
Could use some language, but this may have been handled when I fixed it
for someone else.
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
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
to force meaning into p3).
No idea -- reword and I'll try and parse it again.
17. Section 2.2, p 3: s/the algorithms/the hash algorithms/
Done. "the digest algorithms" I believe is more correct.
18. Section 2.4.1, p1: s/signedData/SignedData/
- also envelopedData vs EnvelopedData and compressedData vs
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
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
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
And also add "and does not provide compression"? Should we just remove
"does not provide authentication" from the EnvelopedData section? Not
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
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.