W3C home > Mailing lists > Public > www-talk@w3.org > November to December 2001

Re: What is at the end of the namespace?

From: Roy T. Fielding <fielding@ebuilt.com>
Date: Mon, 19 Nov 2001 14:48:29 -0800
To: Patrick.Stickler@nokia.com
Cc: sean@mysterylights.com, www-talk@w3.org, uri@w3.org
Message-ID: <20011119144829.A8640@waka.ebuilt.net>
> > > Are you saying that HTTP URLs are also URNs?
> > 
> > No, URNs are only those URI that start with a "urn" scheme.  
> I disagree.
> Yes, I know that the recent "clarification" could be interpreted
> to say that, but it doesn't actually *say* that ;-)

Fine, whatever.  Don't you have something better to do than to reopen
this argument?

> The abstract concept of URN is still a valid concept by which
> to describe and classify URI schemes, and I intend to submit
> I-D proposals for just such a URN scheme that compliments
> the 'urn:' scheme. And one could also assert that the 'tag:'
> URI scheme is a URN scheme. 
> Thus, similarly, one can view PURLs as essentially being URNs
> but URNs for which the agency handling the mapping to URL is
> defined in the URI itself.

All arguments that I have made in the past.  Nevertheless, the people who
have the most right to decide what "URN" means have apparently made their
decision, and I will abide by it in order to reduce confusion.

> > What I said is
> > that HTTP URLs are identifiers, and hence names, and 
> > therefore capable of
> > being a symbolic replacement for any other identifier, including URNs.
> And I never said that folks *couldn't* use HTTP URLs as names,
> only that they *shouldn't*, because it is IMO unreasonable to presume
> that HTTP URLs would have an interpretation not in any way related
> to the HTTP protocol.

The basic problem here is that your opinion should not get to decide
what people can do with their identifiers.   The specifications define
what the technology is capable of doing (or expressing), not what some
people think it should be limited to do.

Received on Monday, 19 November 2001 17:51:15 UTC

This archive was generated by hypermail 2.4.0 : Monday, 20 January 2020 16:08:26 UTC