As I understand it, the only problem with relegating character-set
information to the resource-reference field for a "text" content-type is
that this doesn't address the problem of programs such as troff which
can be used on input of differing character sets. Frankly, I've never
been terribly convinced of the seriousness of that problem: If troff
doesn't define a way to tell, from its own data stream, what character
set is being used, why should mail add this information? So I'm
personally in favor of Mark's proposed simplification, but I'm mostly
resigned to a separate character set field in the content-type header,
which I don't think will do any harm, and which will allow character set
information to be attached to various content-types, even if they use
resource-ref for something else.
However, I'm very much opposed to folding nearly every kind of data in
the world into a "binary" content-type. Basically, you're losing
information -- for each of these types, you're adding the word "binary"
and removing the opportunity to specify version & resource information
for each of the subtypes. I don't believe it really helps a "minimal"
UA that much, because a UA can always just have a default behavior for
unrecognized content-types that is more or less what you would probably
do for "binary" -- e.g. offer the user the option of puting the data in
file to do with as he will. But we probably should add clarifying prose
to the effect that a UA doesn't need to implement all the named
content-types in order to be RFC-XXXX compliant. (Indeed, it doesn't
need to implement ANY of them, really...)