The current DataFlavor implementation assumes that all DataFlavors with a
primary MIME type of "text" have either an explicit or implicit charset
parameter. If a charset is not specified, then the charset is assumed to be the
platform's default.

This is an invalid assumption for several text/* MIME types. The most notable
subtype which does not use the charset parameter is 'rtf'. Others include
'rfc822-headers', 't140', and 'parityfec'. The IANA has registered numerous
vendor text subtypes. These may or may not support the parameter. I don't know
at this point.

As for unknown subtypes, such as those beginning with 'x-', RFC 2046 states that
they should be treated like "text/plain". So I believe we should assume that
they support the charset parameter.

The DataFlavor API needs to be revised to accomodate text DataFlavors which
do not support the charset parameter. This will include revisions to the
specification of selectBestTextFlavor, equals, and hashCode, among others.

Also, the current data transfer subsystem decodes encoded text using the
DataFlavor's charset, and reencodes in the encoding the native platform
expects, as specified in the flavormap.properties file. This process is
unnecessary for MIME types which do not support the charset parameter. Indeed,
for types like rtf, which include binary data, the conversion process could
fail, rendering the entire transfer unsuccessful.