Re: The UR* scheme registry, Citing URL/URI specs

=?iso-8859-1?Q?Martin_J=2E_D=FCrst?= (
Mon, 27 Oct 1997 11:20:05 +0100 (MET)

Date: Mon, 27 Oct 1997 11:20:05 +0100 (MET)
From: =?iso-8859-1?Q?Martin_J=2E_D=FCrst?= <>
To: Keith Moore <>
Subject: Re: The UR* scheme registry, Citing URL/URI specs
In-Reply-To: <>
Message-ID: <>

On Sun, 26 Oct 1997, Keith Moore wrote:

> So the question is, does W3C:
> a) define the term "URIs" to be (essentially) "the set of 
> resource identifiers that we might want to use in HTML", or

Probably it shouldn't, because of URCs and stuff.

> b) assign some other name besides "URIs" to that set, or
> c) simply list the currently known kinds of resource identifiers
> that have this property, without assigning a name to that set?
> (note that if one set of resource identifiers is a subset
> of another set, it doesn't hurt to list them both)

Not having a name is rather impossible. That stuff turns up time
and again in the spec.

> Actually, the more we have this discussion, the more I'm inclined
> to suggest that IETF and W3C ban (= "agree to not define") any new 
> kinds of resource identifiers, beyond URL and URN, whose names 
> begin with the letter U. 

Currently, the spec uses URL. That's somewhat close to b),
but not exactly. Also, it's close to what non-technical
people understand. And one has to say that the HTML spec
is quite a bit more geared towards non-technical people
than the average IETF standard.

So what I would suggest is to use the term "URL", and to
have a note that says:

In the context of this specification, the term "URL" includes
both URLs as formally defined in [RFC URL-Syntax] as well as other
kinds of identifiers that are syntactically compatible and
offer the same functionality (allow to obtain some resource).
The only currently know kind of indentifiers that fits this
description are URNs [RFC URN-Syntax].

Of course, the above text can be improved.

But it is easy in that the HTML spec defines the ways it's using
the words it's using, by reference to the relevant IETF documents.
And it doesn't need a separate RFC, nor does it preclude a different
use in different W3C specs, for examlpe because things have moved
on by that time, or because the more formal language of such different
specs would make other language more preferable.

Regards,	Martin.