RE: Factoring out Content-Disposition (i123), was: Content-Disposition (new issue?)

Julian Reschke wrote:
> By default, message header parameters in Hypertext 
> Transfer Protocol  (HTTP) messages can not carry characters 
> outside the ISO-8859-1 character set. RFC 2231 defines an 
> escaping mechanism for use in Multipurpose Internet Mail 
> Extensions (MIME) headers.  This document specifies a 
> profile of that encoding suitable for use in HTTP.

During the IETF meeting, what was the result of the discussions about
Unicode support in HTTP? Looking at the IRC log, it looked like the
discussion was leaning towards allowing UTF-8 in an otherwise-unencoded form
in headers (applications should start accepting unencoded UTF-8 but should
avoid sending it right now). If that is the way things are going to go, a
general RFC 2231 profile for HTTP seems counterproductive.

RFC 2231 + UTF-8 is an especially bad interchange format for text since it
requires over 9 bytes per letter for the vast majority of people's native
languages. Plus, there are no features for language tagging (needed for CJK
languages), BIDI (needed for middle-eastern languages), or accessibility
(for users of screen readers). IMO, the best thing to do is to keep
language-sensitive text out of HTTP as much as possible by recommending that
applications transfer language-sensitive text in entity bodies as much as
possible. Really, it is only suitable for short, language-neutral  strings
like (file and IRI) path fragments.


The draft references Unicode 4.0 indirectly through RFC3629. It would be
better to allow implementations to use any later versions, or at least the
current version, 5.1.

I don't see the point of requiring ISO-8859-1. ISO-8859-1 can only encode a
very small number of languages that are used by a small minority of people
(who just happen to be over-represented in standards committees). Advocating
ISO-8859-1 also seems to be the opposite of what was discussed at the IETF
meeting (AFAICT from the logs).


Received on Friday, 15 August 2008 19:54:46 UTC