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.
Of course. I thought that would be obvious in this context.
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?
Serious question: Are you really not understanding that 8bit was intended to
label unencoded text from ISO 8859/* charsets (and so it obviously must be able
to represent 160-254 also)? Or are you trying to illustrate that the spec is
unclear? And if neither of the above, what *is* your purpose?
There are several content-transfer-encodings sharing the name: "8bit".
I haven't seen that this is happening in practice. I think the spec just needs
some clarification. Are there really a lot of different ideas about what
"8bit" means that are reflected in incompatible implementations?
If the message contains 8bit character text, nothing bad will happen.
What's "8bit character text"?
Text in a character set that requires 8 bits to represent it, which contains
the ASCII graphic set as a subset, and also (at least when used in MIME) uses
the ASCII control characters in the same way as in emailed ASCII text.
It IS important for those who care interoperability.
It does not have to be fine-grained.
It MUST be precise.
I agree that protocol specifications should be precise enough to allow
independent implementations from those specifications to interoperate.
Specifications should also be easy to understand, so that they will not be
misinterpreted in a way that will cause the implementations to fail to
interoperate. These two goals are often in conflict, and sometimes precision
will be compromised for readability, and vice versa.
On the other hand, if all *discussion* of the specs has to be that precise, we
can scarcely communicate at all.
Keith