Friends,
I would like to offer the following counter-proposal for textual mailing.
There is a single textual content type called TEXT. In the absence of
any resource-refs, the precise definition of the document character set is
unspecified. How an unspecified document is to be interpreted depends upon
national, site, or individual user conventions; in the absence of any of these
an unspecified 7-bit document SHOULD be treated as MAILASCII and an
unspecified 8-bit document SHOULD be treated as <???something here???>.
A resource-ref, if present, identifies the character set in use. The
currently defined character sets are:
MAILASCII
ISO-IR-???
etc.
I would also like to collapse inputs to programs, such as Scribe, TeX,
etc. into a single type, perhaps also all of the binary stuff as well.
What I am trying to accomplish here is to have a limited number of major
types and use the resource-refs to add the fine details. Remember, an
implementation has to make some general decisions of what to do with a
document based on its type, and the more types which exist the more trouble it
is for that implementation. If it does not know about a particular type it is
going to have a much harder time deciding than it would if it had some basic
information to go on.
I would go as far to propose limiting types to these:
TEXT unstructured text in some character set, specified by
a resource-ref
BINARY binary data, specified by a resource-ref
[more precisely, input to a program. This includes
Postscript, Scribe, etc. It may be alright to
differentiate between those formats which are
reasonable to display on a text terminal (e.g.
Scribe) and those which are not (e.g. PBM)]
MULTIPART multiple part message
X-mumble strongly discouraged
Note that this is still just as open-ended as the current RFC-XXXX is.
What I have done is made it easier for a less-ambitious implementation.
-- Mark --