David has outlined the two most obvious approaches, defining a subtype
of application and defining a new top-level type.
I think it would make sense to define either of these in terms of
unicode, making application/unicode or unicode/plain. I doubt the
other non-ASCII-derived are going to be either common enough or
similar enough to raw Unicode to make it worthwhile to combine them in
the same content types. For the same reasons it is useful to specify
the newline convention in text/* types, it will be useful to specify
the newline convention in the new type(s).
Whether or not it is appropriate to create a new top-level content
type for unicode-1-1 depends on how common it is going to be that
people want to transfer raw unicode (as opposed to, say, utf-8) and
need to use markup-language types which should default to the plain
type when unrecognized.
Personally, I tend to suspect things will tend to go more toward
UTF-8.
--
_.John G. Myers Internet: jgm+(_at_)CMU(_dot_)EDU
LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up