Excerpts from info-mime: 12-Jul-94 Ambiguity on 8859-* and bi-..
Masataka Ohta(_at_)necom830(_dot_)c (533)
It seems to me that thee definitions on ISO-8859-* are ambiguous
in RFC1521 and draft-ietf-822ext-mime-imb-00. Perhaps, ISO-8859-*
is intended to be used with 8 bit without designating escape sequences.
But there is no such description.
There's no such description, nor do I really think one is needed. There
is to my knowledge nothing ambiguous about the canonical data format,
I think we have the common idea on canonical data format, which is not
and should be specified.
which includes non-ASCII octets, which means that you can't use it
without worrying about the normal transfer-encoding problems inherent in
any non-ascii data, which is treated in the spec at great length.
The problem has nothing to do with CTE.
It is perfectly possible to encode text with ISO 8859/1 with pure 7
bit as:
"ASCII_string" ESC - A "8859/1_right_part_string" ESC ( B "ASCII_string"
Can't I call the encoding "ISO-8859-1"? Or must MUAs supporting
"ISO-8859-1" be able to decode the above stateful encoding? Or,
shall we call the encoding "US-ASCII"? But, if we can call any 7
bit encoding "US-ASCII", why there is "ISO-2022-JP"?
To disambigufy, you can just simply say
announcer of 4/3 is, though omitted, assumed
The concern about bi-directional text is a valid one, but I think it's
beyond the scope of the MIME spec.
I think RFC 1556 was written because it was felt necessary according to
the scopr of the MIME spec.
If basic MIME spec does not contain Hebrew nor Arabic scripts, we may
expect rational default for non-Hebrew, non-Arabic text and deffer the
solution later. But, with them, we should be able to handlee Hebrew or
Arabic text.
While it might be nice to cite RFC
1556, I think this raises procedural problems, because (as I understand
it) an RFC that is an Internet standard has to avoid making reference to
non-standard RFC's.
Then, some text should be copied from 1556.
It is already a procedural problem that RFC 1556 specify the behaviour
of charset defined in standard track RFC.
Masataka Ohta