Re: Comments on draft-ietf-httpbis-content-disp

On 02.11.2010 05:52, "Martin J. Dürst" wrote:
>
>
> On 2010/11/01 17:30, Adam Barth wrote:
>
>> Jungshik Shin writes:
>>
>> [[
>> As for RFC 5987, I'm aware that it's a profile of RFC 2231 (it's good
>> that it's simpler than the full RFC 2231), but I wrote that it's
>> unnecessarily 'complex' and not many web servers would adopt that
>> anytime soon. That's why I advocated a much simpler approach of using
>> (percent-encoded) UTF-8. I'm aware that it has its own share of
>> issues, but I suspect that it's got a better chance of being adopted
>> by web servers.
>> ]]
>>
>> I agree with his assessment. We should simply use percent-encoded
>> UTF-8 instead of letting the server specify whatever crazy encoding it
>> dreams up.
>
> For the record, I also agree with this. The simpler, more general, and
> more straightforward the encoding is, the better. This can be specified
> as an additional layer on top of header processing, if necessary.

Yes. It would be nice if we could fix HTTP/1.1, or existing headers. But 
we can't.

>> Also, we should remove the language tagging facility
>> because it is gratuitous.
>
> I also agree with this. There is currently no OS or any related facility
> that 'knows' in any way in what language its filenames are. There is
> also no way for a user to enter that information, in the interfaces I
> know. There is also no practice of language negotiation for filenames
> (there is language negotiation for different language versions of
> content, where as a result the filenames may also be different, but
> that's a different thing).

It's optional, and the encoding is generic so it can be used for other 
parameters as well (such as "title" in Link:).

>> http://tools.ietf.org/html/draft-ietf-httpbis-content-disp-03#appendix-C.2
>>
>>
>> As far as I can tell, this is actually the biggest interoperability
>> problem with the Content-Disposition header field. Unfortunately,
>> this document does nothing to resolve this issue. I recommend that
>> this document take a position with respect to how to handle
>> percent-encoded values in the filename parameter. Specifically, I
>> recommend that the document instruct user agents to decode percent
>> encoded values using the user's preferred encoding. Yes, that's ugly,
>> but it's the way Content-Disposition works in the real world and the
>> most likely requirement to actually be implemented by user agents.

a) As far as I recall, this is not true for Chrome.

b) Even if it was, it's useless for a sender unless it can find out what 
the encoding is.

c) That it's most likely to be implemented is just an opinion, so far 
the evidence is against it.

> Well, you say 'ugly', but in this case, it's equivalent to "does *NOT*
> work". [Users don't prefer encodings, it's the user's system's preferred
> encoding.] Preferred encodings on the receiving side, and used encodings
> on the server side, differ, and the result of that is garbage. I'm not
> sure recommending to produce garbage is a good idea at all.

+1

> As for the wording of Appendix C.2, even if it stays more or less as it
> is, it is confusing. It first says that some user agents accept UTF-8,
> then it says that the first user agent to implement this (i.e. UTF-8)
> used the local encoding (i.e. NOT UTF-8).

That's true: this sections needs to be rephrased. To get this right it 
would be valuable to get feedback from Chrome and IE what they actually do.

Best regards, Julian

Received on Tuesday, 2 November 2010 09:06:02 UTC