[Top] [All Lists]

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

2004-03-25 21:44:17

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

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
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
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/


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

11:  Section  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 
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
      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
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

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 
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.


<Prev in Thread] Current Thread [Next in Thread>