On May 2, 2012, at 7:43 , Julian Reschke wrote: > If browser implementers want to try something new that will not affect the > old code paths, supporting the encoding defined in RFC 5987 might be the > right thing to do (yes, it's ugly, but it's unambiguous).
It seems to me like that is a potential solution that could be evaluated. It would be nice to have both the HTTP response header and the POST form encoding be the same. However, a critical question is if the server software that parses the form headers would do the "right thing" if it sees both an ASCII fallback filename= and an escaped filename*= parameter in the Content-Disposition header. Without looking at any code, I suspect some will and some won't. My conclusion: I would be willing to help with bugs, testing, test cases, looking at server code, etc related to this issue. However, I believe someone who is experienced with the technology and politics of web standards to really champion any change because I don't fully understand the processes or the issues. If I don't hear anything in a few days, I'll try filing some additional bugs with Webkit, Firefox, and the HTML5 spec and otherwise give up. Thanks, Evan Jones -- http://evanjones.ca/
