- From: <bugzilla@wiggum.w3.org>
- Date: Mon, 23 Jun 2008 16:12:50 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5773 --- Comment #29 from Rob Burns <rob@robburns.com> 2008-06-23 16:12:50 --- (In reply to comment #28) > > As far as I can tell, the only mechanism that is currently available is > Content-Disposition; and there is no workaround for the I18N interop problem. > The other work around often used by authors is to incorrectly describe the user’s environment to them such as: “hold down the whatzit key and click on this link to download the file”. Obviously this provides users with a clear understanding of what will happen, but it doesn't really speak to all users. A better approach is to provide an HTML solution that doesn't rely on author access to the resource’s server where content-disposition headers might change. That way the author can provide something like: <a href='video.ogg' >View this video in this window</a> or <a href='video.ogg' target='_download' filename='afilename' >download it </a> for later. (In reply to comment #27) > The only available information for the filename would be the URI. That isn't > sufficient in all cases, as: > - the URI namespace may not be defined in a way that allows exposing the > filename (such as, when using numeric identifiers), > - there's no reliable way to map non-ASCII characters (we can't rely on > non-ASCII characters to be encoded in UTF-8) OK, that makes sense. I didn't think about that. However, two questions? 1. is there interoperability problems for UTF-8 percent encoded URL]s as recommended here: http://www.w3.org/International/O-URL-code.html 2. is anything being done in the http wg to get http headers updated to unicode transform or utf-8 specifically? -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Monday, 23 June 2008 16:13:32 UTC