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.
Right. The purpose of the binary, 8bit, and 7bit c-t-e's is to serve
as a clue to user agents and translating MTAs/gateways to tell them
approximately what range of octets might appear within.
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.
Well, in fact, those labels are not currently legal. The number of c-t-e's
was deliberately kept small, because having lots of different c-t-e's
decreases interoperability.
If NULL is not preserved, we must have QP clone in each message type.
You may be right. But it's not easy to define one, for this reason: We have a
lot of experience with "7bit" mailers, so we know pretty well which characters
are likely to get munged. By contrast, we don't have anywhere near that
amount of experience with "8bit" mailers. A lot of 7bit mailers did
translation to/from ASCII to their native character set, so quoted-printable
discourages use of any character that is not in pretty much every charset.
(Well, not exactly, but the appendix in 1521 has a recommended list...)
What do the so-called "8bit" mailers do? I'm aware of some that do translate
between character sets and may not yet be MIME-aware. These mailers might do
something reasonable with 8bit character data (in the sense that the recipient
might be able to read the message), but would corrupt 8bit binary data.
Anyway, that's my explanation of why there's not a 8bit-quoted-printable
c-t-e.
I'm pretty sure that almost all the implementation handle 8bit and binary
equally and, if 8bit does not preserve NULL, binary either.
Not sure what you mean by "implementation" here. But just because you label
something with a particular c-t-e is no guarantee that the mail system will
recognize it. It is the job of the sender (or his user agent) to pick a c-t-e
that will survive mail transport. Defining new c-t-e's won't change that.
Then, what is your idea on safe code points with 7bit and 8bit CTE?
For 7bit, look at the appendix in rfc 1521.
For 8bit, I think the answer (beyond that for 7bit) is "insufficient data".
It seems to me that you are trying to ignore interoperability issue,
once again.
Who me? I could make the same claim about you. But let's not get
into that, okay? :)
I think I can see your point about wanting a new c-t-e. But assuming that
nobody has a good idea of what can be expected from "8bit" transport, I think
it would be more effective to just encourage the development of 0-255
transparent "binary" transport. Then the binary c-t-e will be sufficient.
I do want to have 8bit transparency so that audio/vidual encoding won't
have strange restrictions.
Sounds reasonable to me.
Keith