that ess in 'https'

[Peter Davis]

On 6/27/2006 5:38 PM, "Jonathan Daugherty" <cygnus at janrain.com> wrote:

> # Might I suggest that this decision is best left to RFC 3986, which
> # lays out clearly normalization rules for URIs.  Doing otherwise, I
> # think, will lead to madness and mayhem.  If implementations
> # presently do not support this, than it's a problem with the
> # implementation, I think, and should be fixed there, not grafted into
> # a specification.
> 
> The decision we're talking about isn't whether two URLs are equivalent
> in general, but whether they are the same identifier; and that is
> still an application- or protocol-level decision.  I haven't claimed
> that two URLs are equivalent even if they differ only by scheme.

I suppose I've a hard time distinguishing the difference between the
questions:

"are these two URIs equivalent?"

  and

"are these two URIs the same identifier?"

What I _think_ you're getting at, in reality:

"are the representations located at this URI and that URI equivalent?"

And for this, I think the only sane we to determine this, is to dereference
them, and find out ;-)

After all, Yadis prescribes two possible representations at the same
resource (URI), doesn't it?

One of the points I was really trying to make, however, are all the nasty
corner cases of URI comparisons, the pitfalls as described in various RFCs
and elsewhere, and what should be considered when evaluating URI
equivalence.  This thread thus far has touched on the scheme portion of the
URI, but what about % encoded values, internationalized characters in the
authority production (which registries are increasingly allowing), case
sensitivity, etc...  These will all become issues at one point or another.
Other people have thought about this issue, and you should avail yourself of
that work.

=peterd  ( http://xri.net/=peterd )