Re: Registration of new charset "UTF-16"

[Chris Newman <Chris.Newman@INNOSOFT.COM>]

On Fri, 15 May 1998, MURATA Makoto wrote:
> Makoto:
>       This character set is not permitted for use with MIME text/* media
>       types.  However, the MIME-like mechanism of HTTP may use this
>       character set for text/*.
 
I prefer this one or anything along these general lines.
 
> Erik:
>       This charset is not suitable for use with text/* media types in
>       protocols that are sensitive to the line break issues described in
>       section 4.1.1 of RFC 2046 (MIME). However, this charset is suitable for
>       use with text/* media types in other protocols. See also section 19.4.1
>       of RFC 2068 (HTTP).
 
HTTP is the only protocol which uses MIME but doesn't follow the text
rules.  I hope there will never be another.  The rules for text media
types are not email centric.  They were put in so that:
(1) Any text media type could be displayed directly to the user without
    interpretation (treated as text/plain).
(2) Text has a canonical form so that signatures can be more easily
    verified.
(3) Even if the charset is unknown, dumping the message to the screen
    might be useful.
(4) It can normally be sent unencoded through line-oriented protocols
    with line length limits.
I wouldn't be surprised if there are other good reasons for the text rules
that I'm not familiar with.

> Larry:
>       In accordance with the rules on end-of-line convention and 'text/',
>       UTF-16 is inappropriate for use with 'text' media types. Those media   
>       types which might be deployed with UTF-16 might consider registering an
>       'application' type as well.
 
This omits mention of the HTTP exception, which seems important to some.
 
                - Chris