Re: Issue 261: Check for requirements backing test cases, was: Comments on draft-ietf-httpbis-content-disp

On 02.11.2010 19:36, Adam Barth wrote:
> ...
>> That may be true for Chrome, but certainly *was* not true for IE when I
>> first encountered the problem (trust me, I *was* sending UTF-8).
> Indeed.  We don't need to slavishly copy IE.  We just need to stay
> within some compatibility bound.  Usually we aim for somewhere between
> 99.99 and 99.999% compatibility.  That usually isn't the same as the
> unanimous intersection of all browser behavior.
> ...

I like numbers. Can we *please* get numbers about actual use, and names 
of sites that use it?

>>> Now, of course, that would still leave us with UA-sniffing code on
>>> servers until everyone implements the spec, but that at least sounds
>>> implementable, unlike the current document, and puts us on a path to a
>>> better future.
>> Why do you keep saying the current document is not implementable? That's not
>> helpful; the RFC 2231 encoding has three independant implementations (four
>> if I'm allowed to count iCab).
> The document has two pieces:
> 1) filename
> 2) filename*
> What the document says about (1) isn't implementable by some number of
> user agents.  What the document says about (2) is suboptimal, but
> might be implementable if we can get jungshik on board (and whoever
> the relevant decision makers are on the ie-team).


So you say that the spec currently does not allow percent-unescaping 
(btw: the applicable specs never did, for the late comers to this 

Björn already pointed out that the filename is advisory only, and that a 
UA can already do what it wants to derive a final filename (mostly due 
to security considerations and local FS conventions). But I would agree 
that this is not optimal.

Another way to address this is to recognize the problem, and suggest 
that servers that actually *want* a verbatim %-sequence in the filename 
will *have* to use the 2231/5987 encoding. If that's what's needed to 
get the missing UAs to implement filename*, I'll be more than happy to 
make that change.

>> From this discussion, it seems you care much more about (2) than about
> (1).  One alternative is to remove the parts of the document that
> discuss (1) since those appear to be more controversial than the parts
> that discuss (2).

That's an interesting thought. But I think one of the reasons for the 
missing interoperability was the confusion in the specs (is the token 
form allowed?, is RFC 2047 encoding allowed/required?, is 2231 
allowed/required?) Etc. So I really believe that a single document that 
defines C-D for HTTP is needed, and this WG has decided long ago (issue 
123) that we want to do just that.

Best regards, Julian

Received on Tuesday, 2 November 2010 19:06:05 UTC