W3C home > Mailing lists > Public > xml-uri@w3.org > May 2000

Re: URI versus URI Reference

From: Paul W. Abrahams <abrahams@valinet.com>
Date: Thu, 25 May 2000 10:39:24 -0400
Message-ID: <392D3B1B.C0FB644E@valinet.com>
To: John Cowan <cowan@locke.ccil.org>
CC: abrahams@acm.org, timbl@w3.org, jcowan@reutershealth.com, xml-uri@w3.org
John Cowan wrote:

> Paul W. Abrahams scripsit:
>
> > Is there an explicit definition of ``the
> > strict data type `URI' '' in 2396 that I've missed?
>
> Seemingly not.  However, 2396 supplies a generic syntax for URIs
> and URI references.

For URI references, yes.  For URIs, no.  There are no syntax rules with URI on the left
side.

> The actual syntax for URIs is the union of the
> known schemes and their specific syntaxes, which are defined in
> RFC 1738 (which is *not* superseded by 2396 with respect to the
> syntax of specific schemes) and other RFCs.

RFC 1738 speaks only of URLs, not URIs.  So it provides no answer to the question
``What, exactly, is a URI''.  And RFC 2396 says, at the end of the first paragraph of
the Abstract, ``it revises and ***replaces*** the generic definitions in RFC 1738 and
RFC 1808''.


RFC 1630 says:

``A complete URI consists of a naming scheme specifier followed by a
   string whose format is a function of the naming scheme.''

That would provide support for the proposition that a URI is necessarily absolute.
However, RFC 1630 also contains the following disclaimers:

<snip>
Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

IESG Note:

   Note that the work contained in this memo does not describe an
   Internet standard.  An Internet standard for general Resource
   Identifiers is under development within the IETF.
</snip>

In other words, RFC 1630, by its own statement, has no normative force.  It is merely a
statement of intent and philosophy.  It is also not referenced from RFC 2396.  And RFC
2396, by its own statement, supersedes and replaces RFC 1808 and RFC 1738, so there's no
need to go look at those.

John, I wouldn't be pushing this point so hard if I hadn't been so often seeing the
argument that URI references must not be confused with URIs, and that the distinction is
vital.

This seems to me a clear case of people believing that they actually said what they
meant to say.  (RFC 1630 appears to be what they meant to say.)  Fortunately the
evidence, one way or the other, is in publicly available documents.  Looking at it from
the outside, it appears that RFC 2396 was the result of a hasty edit of some previous
(invisible) document.  The content of Appendix G1 and the disagreement between the
heading of Appendix A and the actual nonterminals within it reinforce that impression.

You might also be asking yourself, ``What's with this guy from the outside coming in and
telling us how we should be dealing with this stuff that we've been working on for
years?''  Well, everyone agrees that there are, if not contradictions among, at least
unintended consequences of, the existing XML-related specs.  The details of the actual
wording matters, as is demonstrated by the extended discussion of the comparison rule
for URI's.   No one doubts that repairs are needed.

RFC 2396 is a foundation stone of much of the discussion, and it doesn't say what
everyone seems to think it says.  Perhaps it takes an outsider to notice that.  W3C is
probably  not in a position to fix RFC 2396, but at least W3C should avoid propagating
its mistakes.

I believe that the repair to RFC2396 would be simple, however: drop the term ``URI
reference'' and replace it by ``URI'' in all its occurrences within the document.  It's
an odd term in any case, since it seems to mean ``Universal Resource Identifier
identifier'' (no one seems to be arguing that a URI reference points to a URI rather
than to a resource).

Paul Abrahams
Received on Thursday, 25 May 2000 10:39:34 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:42 UTC