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

RE: What is at the end of the namespace?

From: <Patrick.Stickler@nokia.com>
Date: Wed, 21 Nov 2001 10:33:00 +0200
Message-ID: <2BF0AD29BC31FE46B78877321144043114C0C1@trebe003.NOE.Nokia.com>
To: fielding@ebuilt.com
Cc: sean@mysterylights.com, www-talk@w3.org, uri@w3.org

> -----Original Message-----
> From: ext Roy T. Fielding [mailto:fielding@ebuilt.com]
> Sent: 20 November, 2001 00:48
> To: Stickler Patrick (NRC/Tampere)
> Cc: sean@mysterylights.com; www-talk@w3.org; uri@w3.org
> Subject: Re: What is at the end of the namespace?
> > > > 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?

With all due respect (really)...

This "argument" happens to intersect with one the primary focus
areas of my work, and is an issue that I consider to be in 
great need of attention -- and if you had any idea what my work
load was and considered the time I am spending discussing these
issues in forums such as this, you would not make condescending
quips such as the above.

Forgive me for stepping on the omniscient toes of the founding
fathers of the internet. I'm sure you all got it right the first
time... It must surely be perfect and fully suitable to meet
all present and future needs, known or unknown...

And surely anyone who would presume to think differently is
clearly insane, ignorant, or just wanting to rock the boat
for fun...

> > 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, 

Well, I for one am not clear on what that decision actually is,
and the presumed "clarification" certainly doesn't clarify what
that actual decision is.

And what if that decision, and others like it, are the very source 
of the confusion?

> and I will abide by it in order to reduce confusion.

You're free to do as you like, as am I. 

At least I am encouraged that we seem to share the same goal of 
reduced 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.

I would never be so presumptuous to think that my opinions would
necessarily decide anything (though it appears that there are others
who do hold such presumptions).

The crux of the issue is what those actual specifications define; and
not whether a given technology is *capable* of something but whether
it is *optimal* for something, and if not the latter, then what may
be a better option.


Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com
Received on Wednesday, 21 November 2001 03:33:29 UTC

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