Re: Comments on url-syntax-draft...

Roy T. Fielding (fielding@liege.ICS.UCI.EDU)
Sat, 28 Dec 1996 01:30:19 -0800

To: Ryan Moats <>
Subject: Re: Comments on url-syntax-draft... 
In-Reply-To: Your message of "Fri, 27 Dec 1996 10:39:46 CST."
Date: Sat, 28 Dec 1996 01:30:19 -0800
From: "Roy T. Fielding" <fielding@liege.ICS.UCI.EDU>
Message-Id:  <>

> I forsee problems in the URL draft with any potential "meta-scheme",
> an example of which is providing checksums for a URx if it maintains
> its current section 1.1 language.

I see no such problems.  For one thing, there is no such thing as a
"meta-scheme" which would have separate requirements from any "normal"
scheme.  If it can't be parsed by the generic-URL syntax, then it can't
be used in any context in which URLs are found, which would place it
well outside the bounds of the URN charter's definition of URNs.

> The point is that the current draft is unacceptable in its making a
> statement about URNs without realizing that URNs are a superset of URLs
> and should not be bound by the URL syntax (in fact one could argue the
> reverse).

Both points are in error.  URNs are not a superset of URLs -- both are
subsets of URI.

There does not exist a URN that cannot be *parsed* as a URL.  In fact,
the URL syntax is much less restrictive than the proposed URN syntax.
Claims that such a URI syntax is "too restrictive" are not useful
without an example of a legal URN which would be disallowed by the
URL syntax.  Personally, I have yet to even imagine one.

> One reason is that URNs are more general than URLs. 

How so?

> Another is that
> URN syntax pushes the deterministic structure off to the namespace
> resolver.

No it doesn't.  In order to parse a URN, you need to know where it
begins and where it ends.  That is the definition of an opaque URI.

> Another is that URLs are inherently tied to the underlying
> filesystem structure.

That is totally misinformed -- there is nothing in an http URL which
is inherently tied to any filesystem, and the same goes for news, mid,
cid, telnet, wais, etc.

The URL document contains the wording about URI in general because
there currently does not exist a standard reference for URI, which
is the thing that HTTP and HTML use in references.  Without that
wording, the HTML and HTTP specifications will have to restrict themselves
to using URLs, thus making an artificial distinction created for
political reasons part of the official standard.  Since I assume you want
to actually use URNs in HTML and HTTP and other areas where URLs are
currently found (I certainly do), it would be pretty stupid for us to
remove any mention of the URI syntax from the URL standard.  Waiting
for URNs to achieve the same standard status as URLs is not reasonable.

I included only the most basic of requirements in defining the URI syntax.
If the URN WG cannot live with the requirements as stated, then I cannot
possibly imagine that URNs can be used in the ways intended by your
own requirements documents.  But that can't be the case, since your own
syntax document is *more* restrictive than the URL spec.  I can only
assume that you need to read it again and point the actual problems
and not presuppositions.