- From: Roy T. Fielding <fielding@apache.org>
- Date: Thu, 3 Jul 2003 17:29:12 +0200
- To: "Larry Masinter" <LMM@acm.org>
- Cc: <uri@w3.org>
>> Escaping unreserved characters in a URI does not >> change what resource is identified by that URI. > > I think this is OK, although I'm uneasy about "does not". > Is it "will not", "should not", "must not"? Are we > establishing a conformance requirement, describing current > deployed software? In no cases does escaping unreserved > characters change the resource identified in all of the > deployed software in the world? I guess "must not" is more accurate. >> However, it may change the result of a >> URI comparison (section 6) > > "some URI comparisons" might be better than "a URI comparison" okay >> potentially leading to >> less efficient actions by an application. > > Not just "less efficient". In the case of caching, the result > is less efficient. In the case of namespaces, the result is > incorrect. Still just less efficient -- it results in the application thinking there are two similar namespaces when there is, in fact, only one. I don't know of any case where that would result in system failure. However, I guess it won't hurt to add incorrect. >> Therefore, unreserved >> characters should not be escaped unless the URI is being used in a >> context that does not allow the unescaped character to appear. > > I'd rather not encourage the use of such contexts, and even > in such contexts, some other mechanism might be better. Often > designers employ another layer of encoding. For example, URIs > inside XML don't URI-encode '&' as %26, but rather use XML > encoding as &. > > I offer the following rewrite: > > Escaping unreserved characters in a URI should not change > what resource is identified. However, escaping characters > may change the result of some URI comparisons (section 6), > potentially leading to incorrect or inefficient behavior. > Therefore, unreserved characters should not be escaped > unnecessarily. okay, I like shorter paragraphs. ....Roy
Received on Thursday, 3 July 2003 11:29:42 UTC