I don't believe that the 8bit content-transfer-encoding was intended
to be used with contents that can contain the entire range of octet
values from 0-255.
The spec does not constrain the valid characters. It explicitly states
that the line-length and crlf requirements apply, the same as for 7BIT.
So, what characters do you believe are not allowed and why?
I believe 8bit was intended to label body parts which could safely be
transmitted with the so-called "8-bit clean" SMTP transports which were already
in common use in Europe (and perhaps elsewhere) at the time RFC 1321 was being
drafted.
At the time, there was no specification for "8-bit clean" SMTP, so there was no
specification for which octets can be expected to pass through an 8-bit SMTP
without damage. However, the "8-bit clean" SMTPs in use at the time were only
expected to carry "plain text" messages using either the iso 8859/* character
sets, or iso 646 national variants which are 7-bit only. So it is my belief
that the use of the 8bit content-transfer-encoding to label body parts which
contain octets other than
(a) those used for graphic characters in an 8859/* character set, and
(b) those used to represent the ASCII control characters which are commonly
used in Internet email,
goes beyond the intended use of the 8bit label.
I further claim that although any c-t-e may (legally) be used with any
content-type, the use of the 8bit c-t-e to label anything other character data,
increases the risk that that data will be corrupted in transit.
...
Finally, there seems to be some belief that the use of a particular
content-transfer-encoding, is a binding request for a particular kind of
service at the transport level.
My opinion is that a 7bit/8bit/binary content-transfer-encoding is merely a
label, which places no requirements whatsoever on the transport itself.
However, a transport-level entity has the option of using the c-t-e information
when deciding what transformations are appropriate for a particular body part.
Keith