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".
"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.
MIME "8bit" have serious interoperabilitty problem, then.
If NULL is not preserved, we must have QP clone in each message type.
...which I took to be a suggestion of new c-t-e's.
No, of course.
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.
Masataka Ohta