There are some problems with the "Content-Type: text/us-ebcdic" proposal.
1. Encoding of the header itself. The header could be encoded in ASCII
always, and the user agent would switch to an EBCDIC-ASCII translation
table for interpreting either the header or the contents. If the message
is encoded in the native character set of the user agent, the information
to be found is already known beyond reasonable doubt.
2. Information value. As indicated, the header has no informational
value when referring to the native character set of a system, and this is
true of "text/us-ascii" as well. The purpose of a type is to distinguish
it from all other types, but we already have enough information to know
that a message is in the native character set when we read it, and have
thus established a typing mechanism which distinguishes a type from the
_base_type_.
3. EBCDIC is not EBCDIC. ISO 646 exists is numerous versions, and there
is a well-defined way to indicate which version one is using. This is,
to my knowledge, not the case with EBCDIC. There are code pages, to be
sure, but no way to distinguish them from each other.
4. EBCDIC version vs ISO 646 version. Very often, a ISO 646 national
version maps cleanly to an EBCDIC version. If we are about to include
EBCDIC in the problem domain, we should also think of this problem.
5. Self-sufficiency of the Internet and other networks. What other
networks do should not be a major concern for the IETF, or we will get
nowhere. The IETF should define the format for Internet messages, with an
ear to what we might have to interface to, but we should NOT cross that
interface to solve the other side's problems.
In short, let the gateways to networks with such coded character sets
specify how and what to do with conversions to and from the Internet
standard for messages. That's the way they already do it for other
networks they connect to.
</Erik>
--
Erik Naggum Professional Programmer +47-2-836-863
Naggum Software Electronic Text
<erik(_at_)naggum(_dot_)no>
0118 OSLO, NORWAY Computer Communications
<enag(_at_)ifi(_dot_)uio(_dot_)no>