Re: [apps-discuss] draft-ietf-iri-comparison

["Roy T. Fielding" <[e-mail]>]

On Jan 26, 2015, at 10:21 AM, David Singer wrote:
>> On Jan 26, 2015, at 15:56 , Graham Klyne <[e-mail]> wrote:
>> 
>> IF this issue gets further discussion, I'd be very concerned that a comparison of URI beyond simple character comparison would not be universally implemented.  E.g., I do from time-to-time use URIs as index values for dictionary lookups - that depends implicitly on character-based equality.
>> 
>> Further I don't believe it is possible to completely define URI equivalence of different URI strings in a meaningful way, because the notion of equivalence depends on context of use.  When working with, say, RDF, when it is important to be sure that two references are denoting the same thing, the easy way is to just use the same referring string;  alternatively, use some extrinsic assertion that two different URIs are denoting the same thing.
>> 
>> In other words, why bother?  Just keep it simple.
> 
> I guess it depends on what you mean by simple. 
> 
> The simplest for the receiver is to say it’s byte-by-byte equality.  The simplest for each environment that the URI might pass through is to insist it’s in the normal form for that environment.
> 
> These are in conflict.
> 
> So, if at the terminal the URIs arrive, hypothetically one by a route that wants UTF-8 and escaping, and the other by a route that handles everything in UTF-16, the terminal won’t find byte equality when the user expects it. The URIs need to be put in a canonical form.  Which means that that needs defining, alas.

Technically speaking, what namespaces use is character-by-character
equality.  Hence, that is not a problem.

> What am I missing?

I think people assume there exists some canonical form, and that it
makes some difference to the application that it knows that form (or at
least is able to derive it from a non-canonical URI).

The reality is that a canonical form (if any) is only known by the person
who configures the software to provide a service that is associated with
a given URI.  All other forms are aliases. Some of those aliases might
be mechanically expected (like hostname case), but others could be
just as canonical as the first.

In some cases, the preponderance of use in one form over another causes
the original owner to change their mind about which URI is canonical.

Regardless, what Graham noted is true: the definition of canonical for
caching/reusing a GET is very different from the definition of canonical
for something like namespaces.  That was a deliberate decision, whether
we agree with it or not, so it is fair to say that there is no single
standard for canonicalizing a URI (or URL).

This is, of course, why we have a link relation for canonical.

It is not an algorithm that can be written, in code or in spec,
so it is not a bug that needs fixing in RFC3986 (or anything that
pretends to supplant it).  The URI spec defines normalization of
URIs in ways that are not scheme-specific.  The scheme specs are
supposed to define what can be normalized within each scheme.

....Roy

p.s.  Am I the only one that finds it incredibly annoying that the
      APPS area uses this umbrella list for technical discussions about
      topics for which we still have the original working group mailing
      list active, archived, and populated with folks still capable of
      answering these questions?  Ya know,

         "http://lists.w3.org/Archives/Public/uri/"
         "http://lists.w3.org/Archives/Public/public-iri/"