Re: Content-Disposition filename encoding

Frank Ellermann wrote:
> Julian Reschke wrote:
> 
>> do you really believe that this is acceptable for the
>> average customer?
> 
> Don't know, I never try to impose a filename of my choice
> on other folks in a MIME or HTTP Content-Disposition, I
> would consider it on the border of net abuse to try this,
> because I have no idea what their file system supports.

Well.

In practice, file systems support the national characters people need. I 
suppose that's Unicode everywhere, although other encodings may be used 
in practice (such as ISO-Latin in Europe, or Big-5 etc in Asia; dunno 
for sure).

Specifying the *original* file name of a document has absolutely nothing 
to do; it provides essential additional information along with an HTTP 
resource.

> ...
>> should we simplify things by stating precisely what 
>> parts of RFC2231 are really needed (the line folding
>> is not needed, and support for a single charset (UTF-8) 
>> would be sufficient)?
> 
> Let's take 2231 "as is", implementations not supporting 
> odd charsets can ignore the proposed file name, limiting
> it to UTF-8 could be a bad idea if it's actually less
> (us-ascii, latin-1, etc.) and the target platform can

If it's "less", you don't neede RFC2231-encoding anyway.

> only do less.  The strict length limits for RFC 2047 are
> no issue for RFC 2231 parameters, or are they ?

No, they aren't. But I've seen people using the complexity with respect 
to line folding as argument not to support RFC2231 at all. Thus it 
probably would be wise to state the profile that is actually needed in 
the context of HTTP.

BR, Julian

Received on Monday, 24 March 2008 16:20:20 UTC