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.
It's you who claim we have a lot of different CTEs.
Not labelling them makes the matter only worse.
That is, according to you, MIME has serious interoperability problem.
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.
We don't have to. 8bit MUST be 0-255.
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.
Such a broken transport SHOULD NOT be 8bit in MIME sense.
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.
I never want to have new CTEs. It's you who insist we have a lot of CTEs.
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".
Insufficcient data for what?
It seems to me that you are trying to ignore interoperability issue,
once again.
Who me?
You.
I think I can see your point about wanting a new c-t-e.
It's your point, not mine.
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.
My point is that:
There must be consensus that 8bit MUST be 0-255.
and we don't need new CTE names. And you objected.
Considering those people like you who don't care so much about
interoperability issues, I think 0-255 should be worded strongly in
the revised RFC.
I do want to have 8bit transparency so that audio/vidual encoding won't
have strange restrictions.
Sounds reasonable to me.
Which way is reasonable? Having strange restrictions?
Masataka Ohta