That paragraph
simply RESTATES, in terms of the MIME content-type, the definition that
was already made in RFC 822.
Read RFC 822 again. We have designed ISO-2022-JP, which is NOT US-ASCII,
10 years ago with full understanding on RFC 822.
Make no mistake. The use of ISO-2022-JP DOES violate RFC 822.
RFC 822 specifies ASCII. ISO-2022-JP, as you say, is NOT ASCII.
ASCII, not ASCII graphic characters, which does include ESC, which is
NET-ASCII. If the issue is not clear to you see other documents (for
example for ftp) on how NET-ASCII is.
ISO-2022-JP was very carefully engineered to not cause problems with MTAs and
user agents that expect ASCII, and it's a fine piece of work. But strictly
speaking, its use is NOT allowed by the RFC 822 specification.
See extended BNF in RFC 822:
CHAR = <any ASCII character> ; ( 0-177, 0.-127.)
CTL = <any ASCII control ; ( 0- 37, 0.- 31.)
character and DEL> ; ( 177, 127.)
Few people would blame anyone for violating RFC 822 by using ISO-2022-JP, in
part because it is so well designed. But it's another matter entirely to
insist that MIME should be backward compatible with such nonstandard usage.
Yes, MIME default should be US-ASCII.
Masataka Ohta