Re: Factoring out Content-Disposition (i123), was: Content-Disposition (new issue?)

William A. Rowe, Jr. wrote:
> 
> Brian Smith wrote:
>>>
>>> That being said, you can't always avoid it, such as in 
>>> Content-Disposition or Slug.
>>
>> Since the primary (only?) use case for RFC2231 in HTTP is the
>> Content-Disposition header, why not just fold this into the spec. that 
>> you
>> are writing for Content-Disposition? URI references are already
>> ASCII-encoded IRIs, and Atom's Slug header field already has its own
>> mechanism for handling non-ASCII text.

(to Brian) The interoperability problems with Content-Disposition 
motivated me to work on this, right. But putting the RFC2231 profile for 
HTTP into the same spec as a discussion of Content-Disposition would 
mean conflating separate issues. Furthermore, RFC2231-style encoding 
could be used in other headers as well, such as in the title parameter 
for the Link header (which clearly should support I18N, but can't be 
sent in the entity body).

> Or more to the point, TEXT* is defined as RFC2047 charset-encoded values,
> so defining Content-Disposition filename as TEXT* solves the ascii/iso/uft8
> puzzle.
> ...

Doesn't work for me. We *know* that RFC2231-encoding already is in use, 
and that 2 out of 4 UAs have been supporting it for a long time.

Why invent something new? How do you deploy it?

> The issue with filename is that it can (and often does) vary from the
> resource name, e.g. download.aspx v.s. thatdocument.pdf.

Yes. That's one of the reasons Content-Disposition is useful.

BR, Julian

Received on Saturday, 16 August 2008 07:46:14 UTC