Thanks Keith, Rick, Dave, Pete, and Parik.
I'm very much satisfied with the answer that CTE: 7bit is appropriate
for charset=iso-2022-jp.
And the quenstion "How about ISO-8859-1?" means that which CTE: should
be used for charset=iso-8859-1. (Sorry for confusion.) Some person
says that quoted-printable is the one.
This time I'd like to ask Europe environment. In ISO-8859-1 area, 8bit
data ISO-8859-1 is usually send directly before MIME? Or
quoted-printable encoding exists and pepole used to use it before
MIME?
How about present situation? "charset=ISO-8859-1 CTE:8bit" is used
with 8BITMIME transportation? Or do people use "CTE:
quoteted-printable" with MIME UA?
BTW
The reason I ask about CTE: in my previous message is to make certain
the intention of draft-ietf-822ext-mime-imb-01.txt. It is a little bit
confusing. I let 5 Japanese people read
draft-ietf-822ext-mime-imb-01.txt and ask, "What CTE: you think shoud
be used for ISO 2022 JP as long as you read this I-D?"
All people answered 8bit or Base64.
The reason is inappropriate words definition, I think. So I suggests
several things to improve its readability.
(1) On page 10, the definition "7bit date" is given as follows;
"7bit data" refers to data that is all represented as short
lines of US-ASCII. CR (decimal value 13) and LF (decimal
value 10) characters only occur as part of CRLF line
separation sequences and no NULs (US-ASCII value 0) are
allowed.
I think "us-ascii date" is better. And "7bit date" should mean line
based octet date whose 8th bit is not set(i.e. 0 - 127).
(2) On page 22, the definitions of "7bit domain", "8bit domain", and
"binary domain" should be given.
My friends misunderstood like this: "'7bit data' means us-ascii.
'CTE: 7bit' is only appropriate for us-ascii. Therefore 'CTE: 8bit' or
'CTE: base64' should be used for iso-2022-jp.
(3) On page 24, the example
Content-Type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: base64
should be changed into
Content-Type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: quoted-printable
.
(4) On appendix, the definition of US-ASCII should be given rather
than refering ANSI X3.4-1986 since it's hard to retrieve this
document. I think one page long explanation is enough. The table like
UNIX manual page of 'ascii' and additional restriction like lines or
control character should be explained.
If my suggestions make sense, please reflect them to the next I-D.
P.S.
Can we say that a documents that includes control-l like RFC is
US-ASCII?
--Kazu