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.
What a sloppy argument.
Read ancient RFCs. In them, ASCII is clearly stated to be 0-127.
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)?
I do understand that ISO 8859/* with left part invoked as GL and right
part invoked as GR is 0-255.
Or are you trying to illustrate that the spec is
unclear? And if neither of the above, what *is* your purpose?
No. The spec is so clear that I can't unnderstand you insist that 8bit
is not 0-255.
Once upon a time, the spec was clearly 0-127 but there are too many
broken implementations, which does not mean that the implementation
must be broken once again.
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.
What you are trying to do is rather obfuscation, I'm afraid.
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.
And? None is the current case.
That's the consensus I think exist but Keith disagrees.
Then it's not a consensus, is it?
If your opinion is founded.
The reason that both 8bit and binary exist in rfc 1321, is: at the time RFC
1321 was written,
What? RFC 1321 is for MD5. Anyway, RFC 1426 IS 0-255.
there were a great many MTAs that could safely transmit text
written with 8859/* character sets, but which were NOT binary transparent.
This is still the case today.
So? Base 64 is provided for such broken implementations. Use it.
Masataka Ohta