W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2010

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 02 Nov 2010 09:54:21 +0100
Message-ID: <4CCFD1BD.5070200@gmx.de>
To: Mark Nottingham <mnot@mnot.net>
CC: Adam Barth <ietf@adambarth.com>, httpbis <ietf-http-wg@w3.org>
Mark,

thanks for categorizing.

Before I get to the details, I'd like to emphasize that missing 
interoperability for invalid headers is *not* the main problem at all.

The *real* problem we have today is missing interop for *valid* headers, 
in particular when I18N comes into play. Before we focus on edge cases, 
we really need to get *that* improved.

On 02.11.2010 01:43, Mark Nottingham wrote:
>> The comments below are relative to
>> http://tools.ietf.org/html/draft-ietf-httpbis-content-disp-03, which
>> is the most recent version I could find on the IETF web site.
>
> Yes; that's the version that is under WGLC.

Actually, it was -02 which *was* under WGLC, -03 resolves a few comments 
I received during LC.

>> The document defines filename* by referring to RFC5987, but RFC5987
>> does not define a precise algorithm for computing the file name from a
>> sequence of input bytes.
>
> If you have specific issues (rather than just a general desire for an algorithm), please raise them (e.g., as in #261, although even more specificity would be appreciated).

I don't see a problem here.

RFC5987 uses ABNF + prose, but not an algorithm. This is actually more 
detailed than what RFC2231 said, and we have four independant 
implementations getting this right, and none getting this wrong (as far 
as I can tell).

>> 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.
>
> The 'crazy encoding' you refer to isn't dreamed up by the Web server. Regardless, if you'd like to pursue this path, you need to make a proposal and do the legwork to show that implementers will support it, with a reasonable backwards-compatibility story.

Absolutely. Document the format. Align with IE (where it depends on the 
UA's locale). Document how servers can detect the right encoding when 
sending the header. Document how that affects caching/vary. And then 
explain how to get this implemented in all UAs.

> ...

Best regards, Julian
Received on Tuesday, 2 November 2010 08:54:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:32 GMT