It's you who claim we have a lot of different CTEs.
I have never made such a claim. There are exactly five
content-transfer-encodings.
(Perhaps if, when you would use the word "CTE", you would use it mean a MIME
content-transfer-encoding, as defined in RFC 1521, what you say might make
more sense. As it is, I can only guess at what you are trying to say.)
We don't have to. 8bit MUST be 0-255.
Sorry, 8BIT c-t-e is not defined to mean 0-255. BINARY *is* defined
to mean 0-255. Insisting that 8BIT needs to have a different meaning
than the one you want, won't make it so.
Such a broken transport SHOULD NOT be 8bit in MIME sense.
Maybe not. But MIME doesn't define transports; that's SMTP's job. MIME
content-transfer-encodings label body parts. MIME-aware user agents and
gateways can look at those labels and decide how to handle a body part based
on its c-t-e label. But the c-t-e label in a MIME message DOES NOT SPECIFY
ANY PARTICULAR TYPE OF TRANSPORT.
I never want to have new CTEs. It's you who insist we have a lot of CTEs.
You must have me mistaken for someone else.
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?
"insufficient data", because I don't have enough information to answer your
question. I suspect that nobody knows what kinds of data will survive "8-bit
transport", since it hasn't been defined (in SMTP, anyway) long enough for
anyone to have sufficient experience with how "8-bit transport" really behaves.
RFC 1427 does state:
A server which supports the 8-bit MIME transport service extension
shall preserve all bits in each octet passed using the DATA command.
But this only applies to SMTP servers that advertise the 8BITMIME capability.
(And given that most of the SMTP servers out there that do advertise that
capability, are modified "7-bit only" SMTP servers, I suspect that many of
them do not in fact meet this requirement....they probably cannot deal with
bare NULs, and they probably still map CRLF to and from their local newline
convention.)
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.
I objected to "8bit must be 0-255", because that is clearly NOT what
"8bit" was intended to mean. "BINARY" c-t-e was created for that case.
You said:
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.
...which I took to be a suggestion of new c-t-e's.
I apologize if I misunderstod you.
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?
It's very reasonable to want 8-bit transparency of message transport, and a
way to label binary body parts in MIME, so that you can represent audio and/or
video without encoding.
It's completely unreasonable to try to retroactively change the "8BIT"
content-transfer-encoding to mean something different than was originally
intended.
Keith