Re: "semantics" of URI

>>    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