-----Original Message-----
From: Jim Schaad [mailto:jimsch(_at_)nwlink(_dot_)com]
Sent: Monday, March 08, 2004 2:34 AM
To: 'Blake Ramsdell'
Cc: Ietf-Smime
Subject: Comments draft-ietf-smime-rfc2633bis-07.txt
1. I just realized there is no abstract for this document. Is one
required?
Don't know -- someone comment.
2. Section 2, p1: s/[CMS] provides/[CMSALG] provides/
Done.
3. Section 1.1, p 4: Should there be a dependency/reference
to CMSALG here
as well?
Dunno. "No" for now.
4. Section 2.5.2, p1: Need to add text for Compression Algorithms.
Suggest language.
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.
Entire paragraph removed.
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/
Done.
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,
s/Application/pkcs7-signature/Application/pkcs7-signature
(SignedData)/
Done.
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
preferred for
sending, and
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
multipart/signed?
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.
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/
Done.
13. Section A: s/prefered/preferred/
Done.
14. References: CMSAES = RFC 3565
Done.
15. Section 1.1, p 4: s/the Cryptographic Message Syntax/the
Cryptographic
Message Syntax document/
Done.
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).
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
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.
Done.
19. Section 2.4.1, p1: s/encryptedContentInfo
ContentType/encryptedContentInfo contentType/
Done.
20. Section 2.4.1, p1: s/in the envelopedData/in the EnvelopedData/
18.
21. Section 2.4.2, p1: Should add "This content type does not provide
privacy."
And also add "and does not provide compression"? Should we just remove
"does not provide authentication" from the EnvelopedData section? Not
changed.
22. Section 2.5 title, s/Attribute/Attributes and the/
Done.
23. Section 2.5.2, p 3: s/SMIMECapabilites/SMIMECapabilities/
Done.
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.
Ugh. MAY.
Blake