|Julian Reschke||Mar 14, 2008 6:48 am|
|Lachlan Hunt||Mar 14, 2008 7:42 am|
|Julian Reschke||Mar 14, 2008 7:50 am|
|Julian Reschke||Mar 14, 2008 7:54 am|
|Lachlan Hunt||Mar 14, 2008 8:01 am|
|Julian Reschke||Mar 14, 2008 8:17 am|
|Michael A. Puls II||Mar 14, 2008 9:25 am|
|Julian Reschke||Mar 14, 2008 9:38 am|
|Brian Smith||Mar 14, 2008 11:45 am|
|Julian Reschke||Mar 14, 2008 12:04 pm|
|Maciej Stachowiak||Mar 15, 2008 10:54 pm|
|Julian Reschke||Mar 16, 2008 4:02 am|
|Maciej Stachowiak||Mar 16, 2008 11:34 am|
|Julian Reschke||Mar 16, 2008 12:00 pm|
|Maciej Stachowiak||Mar 16, 2008 3:46 pm|
|Karl Dubost||Mar 16, 2008 10:56 pm|
|Leif Halvard Silli||Mar 17, 2008 11:45 am|
|Julian Reschke||Mar 17, 2008 2:35 pm|
|Brian Smith||Mar 18, 2008 9:01 am|
|Julian Reschke||Mar 18, 2008 9:58 am|
|Brian Smith||Mar 21, 2008 9:24 am|
|Julian Reschke||Mar 21, 2008 5:07 pm|
|Subject:||Re: UA support for Content-Disposition header (filename parameter)|
|From:||Julian Reschke (juli...@gmx.de)|
|Date:||Mar 16, 2008 12:00:53 pm|
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.