Re: URI versus URI Reference

Michael Mealling wrote:

> There are some rather large specifications that depend on URIs in 2396
> being what the ABNF calls 'absoluteURI' for various reasons that stem
> from the entire concept of 'bases', relative addressing and fragments being
> invalid. If you attempt to change this you are going to break
> several specifications such as LDAP, Whois++, Rwhois, probably the URN
> URI scheme. I can give you a longer list if you want....

I don't doubt it.  My concern is with the lack of clarity in 2396 on the relationship between
URI and absolute URI.  If the world insists that the two terms are synonymous and must be
because of the consequences of deciding otherwise, I won't continue to argue that all the
other soldiers are out of step.

> > Actually, that doesn't deal with the problem of fragments, I now realize.  But one could
> > write in Sec 4:
> >
> >    URI-reference = [URI] [ "#" fragment-identifier]
> >    URI = absoluteURI | relativeURI
> >
> > That pins down what a URI is and also what the difference between a URI
> > and a URI reference is.  It does explicitly accept relative URIs as a
> > kind of URI and also as a kind of URI reference.
>
> That change breaks things and violates a large amount of concensus that
> has been reached over almost a decade about what a URI is and isn't.

But that consensus isn't clearly and unambiguously recorded in 2396, which is obviously the
place it belongs.   I don't think anyone here would maintain that standards can be based on
oral tradition.

> A relative URI is a bit of syntactic sugar to make life easy for people
> who edit XML with /bin/vi or notepad. It is not and never has been
> a useful part of making the architecture work.

Saying that a relative URI is not a URI is logically possible but surely confusing.

> Your suggestion is IMNSHO a rather fundamental and radical change that
> doesn't buy us anything other than broken specs. Please remember that
> URIs are used for things other than HTML and XML...

If history binds us to misleading terminology - and it's hardly the first time that's
happened - then the best course is to explain very clearly in the relevant standard what each
term means and to note the problem.

Paul Abrahams

Received on Thursday, 25 May 2000 12:25:39 UTC