- From: Dan Connolly <connolly@w3.org>
- Date: Thu, 21 May 2009 13:27:31 -0500
- To: John Kemp <john.kemp@nokia.com>
- Cc: "www-tag@w3.org" <www-tag@w3.org>
On Thu, 2009-05-21 at 13:33 -0400, John Kemp wrote: > After reading what I've written, my general feedback seems to be that > your examples are interesting, appear that they might be relevant, but > could probably be better placed into some context. I've attempted to > provide (hopefully not too oversimplified) in this email the context > in which I feel your examples make sense. Does that make sense to you? yes... > Summarizing my (basic) understanding: > > * Links are good, and a basic feature of the Web > * However, links are used in different contexts (for example, a link > in an HTML href is then used to make an HTTP request, specifically in > the case of an HTML form submission) > ... and the characters, character set and encoding used in one context > may not be appropriate in another context > * Some specifications defer to 3986 for URI encoding rules. 3986 > defers to scheme specifications in particular with regard to "reserved > characters". None of the relevant specifications say anything about > the use of IRIs in links (correct?) Well, none of the specs that I cited so far... > Your examples appear to indicate: > > i) That a space is not allowed in the path component of an HTTP > request, but a space should be escaped as %20 in HTML, as specified by > RFC3986 That doesn't sound quite right. The point is space works OK in an href attribute but not on a GET request line, so the %20 trick makes up the difference. > ii) That a colon in the path creates a link which is not useful > outside of the context of the document within which it appears (at > least, I _think_ that's what you mean here?) no. I'll try in another draft. > iii) That URIs only allow US ASCII characters per RFC3986 Yes. -- Dan Connolly, W3C http://www.w3.org/People/Connolly/ gpg D3C2 887B 0F92 6005 C541 0875 0F91 96DE 6E52 C29E
Received on Thursday, 21 May 2009 18:27:40 UTC