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

Re: Updated Content-Disposition error handling proposal on the wiki

From: Martin J. Dürst <duerst@it.aoyama.ac.jp>
Date: Tue, 14 Dec 2010 15:47:23 +0900
Message-ID: <4D0712FB.8020408@it.aoyama.ac.jp>
To: Maciej Stachowiak <mjs@apple.com>
CC: Adam Barth <ietf@adambarth.com>, httpbis <ietf-http-wg@w3.org>


On 2010/12/14 2:28, Maciej Stachowiak wrote:
>
> On Dec 13, 2010, at 2:55 AM, Adam Barth wrote:
>
>> I've updated the proposal for Content-Disposition error handling on the wiki:
>>
>> http://trac.tools.ietf.org/wg/httpbis/trac/wiki/ContentDispositionErrorHandling
>>
>> I think Julian and I are in agreement by-and-large, except for whether
>> to apply \-decoding or %-decoding to the filename parameter value.
>
>
> In brief, what are the arguments for and against \-decoding and %encoding respctively?
>
> I notice that the ultimate decoding doesn't include the steps where the encoding of the referer is tried, or where an encoding specific to the user's locale is tried. I understand the reasons either of these rules might be problematic to put into the standard, but do we expect that browsers will be willing to drop them? Is it reasonably Web-compatible to do so?

The Web does not assume that client and server use the same encodings. 
Therefore such rules are inherently Web-INcompatible. The sooner the 
implementers can drop it, the better.

Regards,    Martin.

> If we expect implementations to keep doing these things, then I think the proposal needs to at least give implementations license to try other encodings, even if it doesn't require it. Better to incompletely reflect reality than to require things contrary to what we expect to be implemented.
>
> Regards,
> Maciej
>
>
>

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst@it.aoyama.ac.jp
Received on Tuesday, 14 December 2010 06:48:07 GMT

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