"0-255" does NOT imply lack of CRLF-separated line structure, which is the
only difference documented between "8bit" and "binary".
Good point.
Regardless of what 1521 says, I believe that 8bit c-t-e was intended for
"plain text" in so-called "8-bit character sets" that are similar to ASCII,
and will probably be treated that way.
Similar to ASCII, sure.
In various RFCs including 822, ASCII is defined to be 0-127.
On the other hand, there are no, documented nor defacto, definition of
what code points constitutes "plain text".
So, don't repeat the foolishness never again.
OK. You insist that there are various kinds of "8bit" CTEs.
NO I DO NOT. Where did you get that idea?
If some 8bit VTE can pass some character and some can't, they are of
different kind.
MIME "8bit" have serious interoperabilitty problem, then.
And what kind of interoperability problem are you talking about?
Are you sure?
If an MTU receives a 8bit mail from 0-255 channel and relay it to
somewhere else through 1-255 channel, what happens?
Should the MTU read the whole content of the mail to check whether
a NULL byte is included in the message or not? If so, what the point
of having three CTEs: 7bit, 8bit, binary? Can you say streaming?
Then, I propose to remove "8bit" CTE, because of the original brain-dead
intention.
I don't think its original intention was brain-dead,
If ASCII were 0-127, it was not.
Masataka Ohta