ietf-smime
[Top] [All Lists]

Re: New versions of the drafts: please read

1997-09-07 21:30:35
Hello S/MIME guys,

I have some comments on draft-dusse-smime-msg-03.txt.

(1) 3.1.1

The most common and important canonicalization is for text, which is
often represented differently in different environments. MIME entities
of major type "text" must have both their line endings and character
set canonicalized. The line ending must be the pair of characters
<CR><LF>, and the character set should be a registered character set.

Does "registered character set" mean one of character sets found in
"ftp://ftp.isi.edu/in-notes/iana/assignment/character-sets/";?

If so, you should change this sentence. "ISO-2022-JP" and "EUC-JP" is
registered by IANA. But to canonicalize Japanese text, "ISO-2022-JP"
MUST be used if it is transfered by SMTP.

(2) 3.1.1

Note that some character sets such as ISO-2022 have multiple
representations for the same characters. When preparing such text for
signing, the canonical representation specified for the character set
MUST be used.

Great. It is nice if the following sentence is appended to this
paragraph.

        "For instance, redundant escape sequences in ISO-2022 text 
        SHOULD be removed."

(3) 3.1.2

When generating any of the secured MIME entities below, except the
signing using the multipart/signed format, no transfer encoding at all
is required.  S/MIME implementations MUST be able to deal with binary
MIME objects. If no Content-Transfer-Encoding header is present, the
transfer encoding should be considered binary.

Is this default rule intentional? 

RFC2045 defines that "7BIT" is assumed if the
Content-Transfer-Encoding header field is not present.

(4) 3.1.4

For readability, I like to have more popular Content-Type: of the
second part of the multipart/mixed example than
"application/willy-waggle". How about image/jpeg?

I don't know what application/willy-waggle is, however,
Content-Transfer-Encoding: base64 is necessary if it is replaced with
other CT: value.

(5) 3.2.1

RFC 2183 should be referred for Content-Dispostion:.

(6) 3.4.2.3

Do you intend that the first part of the example in Sec 3.4.2.3 ends
without line delimiter?

If so, the following is more readable.

    --boundary42
    Content-Type: text/plain

    This is a clear-signed message. No line delimiter here.
    --boundary42

If no, you should fix it as follows:

    --boundary42
    Content-Type: text/plain

    This is a clear-signed message.

    --boundary42

--Kazu, WIDE project









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