Re: Content-Disposition filename encoding

Julian Reschke wrote:
 
> tell an Asian customer that they have to retype the name whenever 
> they do "Save As".

Beats me, I guess that these platforms allow ASCII file names among
others.  I18N of file systems is an interesting topic, but for HTTP
I think we can simply say that RFC 2231 is a possible solution, and
finding something better is no job for a HTTP/1.1 2616bis.  

For a similar problem compare EAI vs. 2821bis:  2821bis + 2822upd
stick to US-ASCII, where EAI needs or only wants something better
it has to say so.  The wannabe-MIME update in EAI is controversial.

8bit clean, e.g. NetNews, or Latin-1, e.g. HTTP/1.1, isn't the same
as "assume UTF-8", unfortunately.  For real net-utf8 support we'd
have to make sure that applications catch any attempts to smuggle
in UTF-7, CESU-8, or overlong encodings in historic UTF-8 variants.
We'd also have to talk about NFC for net-utf8, interesting topics,
but I don't see this as a part of the 2616bis job.

> NTFS in fact is case-sensitive, but most Windows APIs hide that.
> (In doubt, try Microsoft's Posix stuff).

Of course I can have a file AAbb, but I can't have aaBB in the same
directory, and if I look for AABB I find an existing AAbb.  AFAIK
that's not the same idea of case-sensitive as for *NIX file systems
- unless I missed something important.  I'm too lazy to reboot and
test it ;-)

Whenever we get down to individual servers like apache, individual
browsers like IE, or here individual file systems, I think we miss
the point:  2616bis has to specify something working for everybody
based on 2616.  And where apache, IE, HTML5, IIS, atom, etc. do
something else it's their problem.  If they all happen to agree on
what they do, we are free to align the theory with common practice.
And I'll scream if it breaks the oldest curl or wget I can find :-)

 Frank

Received on Monday, 24 March 2008 09:22:17 UTC