Re: UA support for Content-Disposition header (filename parameter)

Maciej Stachowiak wrote:
>> The latest HTTP RFC (2616) doesn't even require Content-Disposition; 
>> it is described under "Additional Features" 
>> (<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.19.5>):
>>
>> "RFC 1945 and RFC 2068 document protocol elements used by some 
>> existing HTTP implementations, but not consistently and correctly 
>> across most HTTP/1.1 applications. Implementors are advised to be 
>> aware of these features, but cannot rely upon their presence in, or 
>> interoperability with, other HTTP/1.1 applications. Some of these 
>> describe proposed experimental features, and some describe features 
>> that experimental deployment found lacking that are now addressed in 
>> the base HTTP/1.1 specification."
>>
>> Also note that RFC2231 describes more things as those needed for I18N 
>> support of filenames. I'm not sure whether these parts are implemented 
>> anywhere.
> 
> OK, it sounds like the HTTP working group is the place to start, then. 
> Have you tried asking them?

There's no point in asking, because the HTTP WG is chartered with 
revising RFC2616, not with introducing new features. As RFC2231 is not 
required by RFC2616, it can't be required by RFC2616bis by definition.

What could be done inside the IETF (but not inside the HTTP WG) is 
revising both RFC2183 (Content-Disposition) and RFC2231 (encoding), 
potentially cutting unimplemented stuff, clarifying, and progressing it 
in the standards process.

However I'm not sure how that would help bringing the message across to 
browser vendors that this stuff is needed for I18N. I think a statement 
in the HTML5 spec (referring to the RFCs) would be much more efficient.

>> However, I'm sort of surprised to hear these kinds of arguments in the 
>> context of this working group. What happened to "pave the cow paths", 
>> "do not reinvent the wheel", "solve real problems", "support world 
>> languages" and so on...?
> 
> I don't see how any of these are relevant to my suggestion (not 
> argument) that making optional parts of the HTTP protocol mandatory is 
> better done in the HTTP spec, if possible. More generally, problems in 

Well, it's not possible; at least it's not in scope of the HTTP WG's 
charter.

> the areas of other working groups are better solved by those working 
> groups, until they show they can't or won't. So if you fail to get 
> traction on your proposal with the HTTP WG, then as far as I am 
> concerned you are welcome to bring your proposal back here. Still, in my 
> mind RFC2231 is indeed a solution, and if it is not getting deployed, 
> then your beef is with implementors, not standards groups.

Couldn't the same thing be said about *most* of what is new in HTML5 as 
well?

> I agree that it is a good approach which should become a cross-browser 
> solution. On the other hand, RFC2231 does have problems, namely it does 
> not provide good support for degrading gracefully in UAs that only 
> support the plain Content-Disposition header, meaning in practice you 
> have to UA sniff to use it at all.

Right now this is true. But as far as I can tell, that's the case for 
*any* solution to the problem.

So all one can hope for is that someday all relevant user agents do the 
right thing, and then UA sniffing can be removed.

>> So why would this be out-of-scope for HTML5, while it (still) includes 
>> crap like "Peer-to-peer connections over IrDA" 
>> (<http://www.w3.org/html/wg/html5/#irda-peer>)?
> 
> Now I'm not sure if you are trying to solve a problem in good faith or 
> making an ironic suggestion to prove some sort of philosophical point.

I'm being ironic because I have no idea where the people who decide 
what's in and what's out draw the line.

> For what it's worth, I personally think "peer-to-peer connections over 
> IrDA" and indeed all of "6.3 Network connections" should be dropped, and 
> I would expect it will be dropped in due course due to lack of 
> implementation support. It is arguably "in scope" in the technical 
> sense, since our charter includes "Networking APIs for server-push, 
> asynchronous two-way client-server communication, peer-to-peer 
> communication, and client-side cross-domain communication" 
> <http://www.w3.org/2007/03/HTML-WG-charter.html>. But I think this 
> section is immature and at least in the case of TCP connections poorly 
> designed.
> 
> Still, I don't see what this has to do with your suggestion.

It was a process comment, see above.

BR, Julian

Received on Sunday, 16 March 2008 19:02:13 UTC