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

["Blake Ramsdell" <[e-mail]>]

> -----Original Message-----
> From: Jim Schaad [mailto:[e-mail]] 
> 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