ietf-smime
[Top] [All Lists]

Re: New versions of the drafts: please read

1997-09-10 17:25:54
Reply details intertwined... (Paul, I assume you'll make some of these
changes?)  LL

At 1:31 PM +0900 9/8/97, Kazu Yamamoto
(=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) wrote:
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.

Kazu, can you write some language here?  Or someone else that knows the
char set stuff better.


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

Sounds right, perhaps combined with the above text, and alluding to the
fact that 2022 is Japanese so other implementors that don't know about
Japanese don't get confused.



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

I agree, the default should be 7BIT.  This likely what all S/MIME
implementations are doing now too.  I would go so far as to exclude binary
CTE all together.  Many S/MIME implementations can't handle binary now
anyway.


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

Yes, switch to image/jpeg is probably a good idea.  wally-waggle isn't
registered (yet).


(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


Yes, the latter is probably better.

--Kazu, WIDE project




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