(why do I feel like we're about to get hit over the head with something?)
With the exception of a couple of warts in quoted-printable,
content-transfer-encodings don't care what kind of data is being encoded.
It can be audio or video or iso-2022 or unicode or whatever. Any kind of
data *can* be encoded with any c-t-e;
That any data can be encoded does not mean any data can be transferred.
the reason you pick one c-t-e over
another is to ensure robustness during transmission.
If you think there are various kinds of 8bit CTE, we MUST label them as
CTE: 8bit-0-255
CTE: 8bit-1-255
CTE: 8bit-32-254
...
by introducing corresponding names.
Otherwise, saying "pick ONE c-t-e" is meaningless.
If NULL is not preserved, we must have QP clone in each message type.
Specifically, either 8BIT or BINARY content-transfer-encoding can be used to
encode a 0x00. However, I doubt seriously that using the 8BIT label on a
body part that contains bare NULs is sufficient to protect the integrity of
that body part when handled by the various systems out there that recognize
the 8BIT content-transfer-encoding. BINARY labelling would be more
appropriate for body parts that contain 0x00 octets.
I'm pretty sure that almost all the implementation handle 8bit and binary
equally and, if 8bit does not preserve NULL, binary either.
Anyway, I don't think you have the consensus you were looking for.
Then, what is your idea on safe code points with 7bit and 8bit CTE?
It seems to me that you are trying to ignore interoperability issue,
once again.
(But I'm sure you will push on anyway...)
I do want to have 8bit transparency so that audio/vidual encoding won't
have strange restrictions.
Masataka Ohta