Similar to ASCII, sure.
sigh.
Similar to ASCII in that the 8-bit character set contains the
ascii character set as a subset, and uses the same code points
for CR and LF.
Perhaps, you want to say ASCII graphic characters, not ASCII.
Then, 8bit is 32-126 + CR + LF. Or do you want to restrict further that
characters must be EBCDIC safe?
Anyway, what's the difference to 7bit?
On the other hand, there are no, documented nor defacto, definition of
what code points constitutes "plain text".
What's your point?
What's your "plain text"?
If some 8bit VTE can pass some character and some can't, they are of
different kind.
There is only one content-transfer-encoding named "8bit".
There are several content-transfer-encodings sharing the name: "8bit".
If an MTU receives a 8bit mail from 0-255 channel and relay it to
somewhere else through 1-255 channel, what happens?
If the message contains 8bit character text, nothing bad will happen.
What's "8bit character text"?
Should the MTU read the whole content of the mail to check whether
a NULL byte is included in the message or not?
No. The whole point of the c-t-e distinction between binary/8bit/7bit
is that the USER AGENT does the labelling. That way the MTAs don't
have to do two passes.
But I don't think it is important to have a c-t-e that says
"this body part can contain any octets between 1 and 255 inclusive"
as opposed to one that says
"this body part can contain any octets between 0 and 255 inclusive".
It IS important for those who care interoperability.
Why it can't be 1-254 when a lot of character sets do not use 255?
We don't need things to be that fine-grained.
It does not have to be fine-grained.
It MUST be precise.
What we have now is one that was intended to say (something like):
You forget 127.
I think it harmful and unnecessary to allow line wrapping, tab expansion
or line termination without CRLF.
If "binary" is to be supported, "8bit" can be supported as pure 8bit.
If your requirement is 1-255, there are hardly no way to use EBCDIC
(or any other braindead encoding) inbetween without allowing NULL also.
Of course this is my opinion. Others may think it was intended
to encompass something a bit broader.
Then, we don't have to have standards.
Masataka Ohta