Proposal (Was: When are and aren't two URLs the same?)

[Johannes Ernst]

Imperative vs. declarative? I'm fine with either ... I decided to use  
the algorithmic form because it appeared to me it was more likely  
that implementors would implement it correctly ...

Is your declarative proposal [intended to be] semantically equivalent  
to my imperative one?

On Apr 21, 2006, at 14:57, Keith Howe wrote:

> On 4/21/06, Johannes Ernst <jernst+lists.danga.com at netmesh.us> wrote:
>> Maybe this rule shouldn't actually be in the list, or maybe it needs
>> to be put differently. I'm just trying to express that
>>     http://charlie/foo
>> does not necessarily equal
>>     http://charlie/foo
>> because to be able to tell, we need to know the DNS context.
>>
>> Anybody have an idea how to say that better? It could be we simply
>> say: DNS names in Yadis URLs must always be fully qualified.
>
> Perhaps the algorithm itself should merely be an example
> implementation of a more formal rule-set. Then the purpose and intent
> of each transformation can be made clear in the rule itself. Something
> like this (mapping a rule to each of the steps in the algorithm):
>
> 1. Yadis identity URLs must be fully qualified.
> Reasoning: prevents ambiguity when using relative domains; the
> concerned parties must come to a common agreement to resolve their
> identities to qualified names in these cases. Also keeps identity URLs
> properly unique.
>
> 2. Internationalized URLs (IRIs) are equivalent to their URI form.
> Reasoning: preserves the semantic meaning of an identity URL.
>
> 3. Secure and insecure versions of the same protocol in an identity
> URL are considered identical.
> Reasoning: many sites use secure and non-secure URLs interchangeably.
>
> 4. An implicit default port is identical to an explicit default port.
> Reasoning: it is not always in the user's control to decide where and
> when explicit default port mappings may be applied to or stripped from
> URLs. See also [i].
>
> 5. The host component is case-insensitive.
> Reasoning: See [i].
>
> 6&7. An escaped character is equivalent to its unescaped counterpart.
> Reasoning: See [i].
>
> I couldn't really come up with a suitable rule for 8, and I'm not sure
> it's necessary anyway, but feel free to adlib here :)
>
> [i] I didn't notice this before when I was looking at RFC2616, but
> they have a section specifically for comparing URIs. Granted, Yadis is
> not obliged to follow these rules at all, but I also feel it would be
> beneficial not to deviate from these rules either, as they probably
> represent "expected" behavior in the minds of many users and
> implementors alike.
>
> Quoted from http://www.w3.org/Protocols/rfc2616/rfc2616- 
> sec3.html#sec3.2.3 --
>
> 3.2.3 URI Comparison
> When comparing two URIs to decide if they match or not, a client
> SHOULD use a case-sensitive octet-by-octet comparison of the entire
> URIs, with these exceptions:
>
>       - A port that is empty or not given is equivalent to the default
>         port for that URI-reference;
>         - Comparisons of host names MUST be case-insensitive;
>         - Comparisons of scheme names MUST be case-insensitive;
>         - An empty abs_path is equivalent to an abs_path of "/".
> Characters other than those in the "reserved" and "unsafe" sets (see
> RFC 2396 [42]) are equivalent to their ""%" HEX HEX" encoding.
>
> For example, the following three URIs are equivalent:
>
>       http://abc.com:80/~smith/home.html
>       http://ABC.com/%7Esmith/home.html
>       http://ABC.com:/%7esmith/home.html

Johannes Ernst
NetMesh Inc.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: lid.gif
Type: image/gif
Size: 973 bytes
Desc: not available
Url : http://lists.danga.com/pipermail/yadis/attachments/20060421/16f47365/lid.gif
-------------- next part --------------
  http://netmesh.info/jernst