Erik,
Clever issue you have raised.
First, I am of the camp that believes you really are suggestion a
Transfer-Encoding mechanism, rather than a characters set.
Second, while I think Keith's observations about being octet-oriented are
interesting, I don't think they win, long term. I.e., he may well be
correct in observing an historical orientation, but I believe that we
will be shooting ourselves in the foot to stick to it.
While the world of "interesting" international character standards stills
seems quite fluid (to state the matter politely), there is much pressure,
activity, etc. hence, it seems likely that something will yet come into
common use. (Note to the general reader: please refrain from lobbying
for your favorite candidate, in response to this note.)
The observation that Transfer-encodings are independent of Content-types
strikes me as technically correct and operationally wrong. Quoted-printable
was carefully designed for a certain class of content-types. Applyin it to
a graphics or program body-part would be silly. Similarly, using bin64
on a ascii body is highly unfriendly.
So, I believe that you are pursuing definition of a content-encoding to
be used with a class of multi-byte "character" standards, with some rather
interesting characteristics to the multi-bye form. By exploiting the
form of the "native" encoding, you can accomplish a re-mapping of the
data to be semi-usable in more limited transfer environments, similar to
the intent of quoted-printable.
Have I missed something?
In any event, I suggest that writing the spec for the q-t-e and publishing
it as an experimental rfc, with registration of the q-t-e with IANA
would be expeditious.
Dave