This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
The top-level media type "text" has some restrictions on MIME entities and they are described in [RFC2045] and [RFC2046]. In particular, the UTF-16 family, UCS-4, and UTF-32 are not allowed (except over HTTP[RFC2616], which uses a MIME-like mechanism). Thus, if an XML document or external parsed entity is encoded in such character encoding schemes, it cannot be labeled as text/xml or text/xml-external-parsed-entity (except for HTTP).
CCing core developers as they also play with MIME resolvers..
Consistent use of the I18N keyword.
Please check Chapter 3 of RFC2046 named Overview Of The Initial Top-Level Media Types. Here is th text: > (1) text -- textual information. The subtype "plain" in > particular indicates plain text containing no > formatting commands or directives of any sort. Plain > text is intended to be displayed "as-is". No special > software is required to get the full meaning of the > text, aside from support for the indicated character > set. Other subtypes are to be used for enriched text in > forms where application software may enhance the > appearance of the text, but such software must not be > required in order to get the general idea of the > content. Possible subtypes of "text" thus include any > word processor format that can be read without > resorting to software that understands the format. In > particular, formats that employ embeddded binary > formatting information are not considered directly > readable. A very simple and portable subtype, > "richtext", was defined in RFC 1341, with a further > revision in RFC 1896 under the name "enriched". So if we have text in UTF-16 or any other encoding and we have software which can show text in UTF-16 encoding we do not break any RFC limitation. The same idea you can find in Chapter 4.1 of RFC2046.
CCing to ffjspb@netbeans.org