The question that remains, I think, is a simple one: how many
troublesome cases like Vincent's example will there really be, and how
important are they? Without much evidence to support it, I have a gut
feeling that the answer is "not too many and not too important." If
this is the case, we can handle them much more simply with a small
proliferation of content-types, e.g.:
Content-Type: nroff/iso-8859-1; null; tbl, ms
In other words, if there aren't too many such cases, we can handle them
by defining different content-types to handle the charset-variations
within a type such as nroff.
I disagree, Nathaniel. Vincent's example demonstrates that the central
question remains "What is meant by content-type?". Is a content-type a
symbol-mapping, or is it a language-mapping? Your original choices -- IA5,
USASCII, or NVT-ASCII specify a symbol map. But Vincent suggests the latter.
It seems to me that part of what you are trying to do is specify the lingua
franca of messages, besides provide a method to negotiate some other encoding.
I believe this is the proper thing to do. But trying to enumerate the
universe of language maps is probably a fruitless task. Any enumeration
will restrict the set of content-types, which is definitely the wrong thing.
Let us specify that the symbol set for describing message parts shall be
USASCII. Further, I suggest that the interpretation of the content-type
argument be left to the UAs. In the absence of any content-type specifi-
cation, the bytes of data should be interpreted as USASCII symbols.
This provides a framework for communication, and provides a means to
negotiate more complex encodings without restricting the set of content-
types available. (It also avoids having to decide if content-type is a
symbol map or a language :-) But I believe this _should_ be left to the
discretion of the UAs.)
I think it would be wise to provide a list of well-known content types, and
the rules for their interpretation as examples. But I don't believe (nor
do I think it is your intent that) the RFC should restrict the range of
content-types included in messages.
-jwn2