I objected to "8bit must be 0-255", because that is clearly NOT what
"8bit" was intended to mean. "BINARY" c-t-e was created for that case.
"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.
If that is really what is intended, and also (as I believe) consistent with
current practice, then we should change the MIME text to say that explicitly.
"insufficient data", because I don't have enough information to answer
your question. I suspect that nobody knows what kinds of data will
survive "8-bit transport", since it hasn't been defined (in SMTP,
anyway) long enough for anyone to have sufficient experience with
how "8-bit transport" really behaves.
OK. You insist that there are various kinds of "8bit" CTEs.
NO I DO NOT. Where did you get that idea?
MIME "8bit" have serious interoperabilitty problem, then.
And what kind of interoperability problem are you talking about?
It's completely unreasonable to try to retroactively change the "8BIT"
content-transfer-encoding to mean something different than was originally
intended.
Then, I propose to remove "8bit" CTE, because of the original brain-dead
intention.
I don't think its original intention was brain-dead, just (a) maybe not
what you thought it was and (b) maybe not documented well enough.
KEith