- From: Sander Tekelenburg <st@isoc.nl>
- Date: Fri, 23 Mar 2007 02:30:21 +0100
At 19:46 +0000 UTC, on 2007-03-22, Nicholas Shanks wrote: > On 22 Mar 2007, at 19:23, Sander Tekelenburg wrote: [...] >> We're not talking about IDs, just fragment identifiers. My point >> was that >> with video, you could use fragment identifiers *without* the need >> for the author to provide IDs. > > I see your point, but i would like for fragment identifiers within a > video to be equal to fragment IDs in text fallback content. I completely agree that that would be ideal. But I consider it an argument to try to find a solution for that, or if that's not possible, live with that. I don't see it as an argument to give up on such a useful feature for users who do not need/choose to fetch non-video fallback content. (Note that a mechanism to allow authors to define anchors in videos is not a solution, because it's then still the author who is in control. What I'm suggesting is about giving the user control.) [...] >> the client doing the request should be smart enough to know to >> escape the colon > > Wikipedia section IDs have lots of escaping, but it's all done by the > wiki server, not the UA. I don't know if this is because UAs can't be > trusted to get it right or not. I'm getting the impression from RFC 3986 that it is up to the app that sends the request to ensure the URL is properly percent-encode (meaning special characters are escaped). For instance Section 2.2: "[...] URI producing applications should percent-encode data octets that correspond to characters in the reserved set [...]". And section 2.4: "[...] Under normal circumstances, the only time when octets within a URI are percent-encoded is during the process of producing the URI from its component parts. This is when an implementation determines which of the reserved characters are to be used as subcomponent delimiters and which can be safely used as data. Once produced, a URI is always in its percent-encoded form [...]" -- Sander Tekelenburg The Web Repair Initiative: <http://webrepair.org/>
Received on Thursday, 22 March 2007 18:30:21 UTC