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

Brian Smith wrote:

> URI references are already ASCII-encoded IRIs

That would be a downref in 2616bis, because 3987 and IDNA
are only at PS at the moment.  I think it's best to say that
URI references are what is specified in STD 68.  Not some
HTML5 disease, XML LEIRI, ooXML gobbledegook, or what else.

> Atom's Slug header field already has its own mechanism for
> handling non-ASCII text.

Never heard of that...  RFC 5023, some percent-encoded UTF-8
with (ugh, there it is again) RFC 2616 LWS.  That's fine, it
is for a completely new header field.  

BTW, RFC 5023 references RFC 3629, this does _*NOT*_ limit
slugtext to Unicode 4.0.

> For example, RFC 2231 only allows a language tag for the
> entire parameter value, but doesn't provide a means of
> handling mixed-language text.

AFAIK this is not the case in RFC 2231, each piece can have
its own charset and language, please check.  But admittedly
Julian's draft permits only one piece.

> Historically, ISO-8859-1 seems to be very difficult for 
> implementers to get right since Windows-1252 and other
> similar encodings are often sent as ISO-8859-1.

Yeah.  OTOH if you'd really believe in Latin-1, it has some
small advantages:  It's short (one code point => one octet),
any HTTP/1.0 or HTTP/1.1 software is supposed to be able to 
handle it, no matter how old it is, and the chances that all
interested parties support the 191 glyphs to display Latin-1
are excellent.  

 Frank

Received on Saturday, 16 August 2008 03:11:53 UTC