Re: Comments on draft-ietf-httpbis-content-disp-00.txt

On 15.09.2010 08:01, Bjoern Hoehrmann wrote:
> * Julian Reschke wrote:
>>> I don't think sending exactly the same value would make it useful to
>>> send both parameters, it would rather seem filename could be a fallback,
>>> which would imply a different, perhaps less sophisticated, value.
>>
>> Not sure what you're referring to here. Please elaborate.
>
> It did not occur to me someone might send different responses based on
> whether they believe the client supports `filename*`, so I read the text
> as referring to the values of the parameters and not the whole header.
> Clearly using the same value for the two parameters is not useful.

Ack. This text was written by somebody who had to use UA sniffing to do 
this in the past.

New text:

    The parameters "filename" and "filename*" differ only in that
    "filename*" uses the encoding defined in [RFC5987], allowing the use
    of characters not present in the ISO-8859-1 character set
    ([ISO-8859-1]).

    Many user agent implementations predating this specification do not
    understand the "filename*" parameter.  Therefore, when both
    "filename" and "filename*" are present in a single header field
    value, recipients SHOULD pick "filename*" and ignore "filename".
    This way, senders can avoid special-casing specific user agents by
    sending both the more expressive "filename*" parameter, and the
    "filename" parameter as fallback for legacy recipients (see Section 4
    for an example).

Does this make things clear?

>>     The parameters "filename" and "filename*" differ only in that
>>     "filename*" uses the encoding defined in [RFC5987], allowing the use
>>     of characters not present in the ISO-8859-1 character set
>>     ([ISO-8859-1]).  When both "filename" and "filename*" are present, a
>>     recipient SHOULD pick "filename*" and ignore "filename" - this will
>>     make it possible to send the same header value to clients that do not
>>     support "filename*".
>
> I still think the reference to ISO-8859-1 should be avoided (refer
> instead to characters not normally allowed in HTTP headers, or simply
> a wider repertoire of characters) and the last part should emphasize
> that the filename parameter can be used as fallback value for older
> clients, to avoid the confusion above if nothing else.

I haven't changed yet the wording with respect to ISO-8859-1, mainly 
because it reflects what's actually implemented.

That being said, I wouldn't be surprised that we'll get more feedback on 
this during the Last Calls. For now, I'll record this as a potential 
clarification: <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/243>.

Best regards, Julian

Received on Wednesday, 15 September 2010 13:40:33 UTC