What URIs are and are not.

Tim Berners-Lee <timbl@www3.cern.ch>
Date: Wed, 3 Nov 93 18:04:28 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-id: <9311031704.AA02012@www3.cern.ch>
To: uri@bunyip.com, www-talk@nxoc01.cern.ch
Subject: What URIs are and are not.
Reply-To: timbl@nxoc01.cern.ch

Let me put down the *original* functional spec for URIs.
I fear that some people have gotten away from the original
requirement, and wanted to start designing things.

Listen good if you are a newcomer to the list or on the
IESG ;-)

There are many protocols on the net which imply a data model
which can be mapped onto some concept of "objects" and
addresses/names/identifiers/locators for those objects.

 Examples:	Protocol	Objects
		FTP		Directories
		SMTP		mail addresses
				mail messages
		NNTP		newsgroups
		HTTP		objects
		Gopher		menus
		DNS		hosts
				Mail eXchanges

There will be many more future examples.

The characteristics of the objects and the properties of the
names.addresses/identifiers/locators vary and are defined by:-

	a. The protocol specification
	b. The way the protocol is actually used
	c. The conventions which are used by people
 (Example:  a.The FTP RFC implies that a directory object may contain  
 in defining that NLST on a directory returns a list of files.
 b.The protocol is in fact often used using only A and I
 modes, and with the user/pass pair being "anonymous" and
 a mail address.  c. A convention is that ftp.x.x.x host names
 are not changed very often, but can change
  Hence the properties of 

 are that it contains files, maybe listed by anonymous
 ftp to info.cern.ch, the files may change, but lifetimes
 will be of the order of year for directories.)

 There is for each protocol an implicit name/address/identifier
 space for the n/a/i s in th implicit data model.

I am trying to get across the great variety of schemes.

What you can do with an address/name/identifier depends also
on who and where you are and what facilities you have.  So
it is difficult to define.  (This is why I don't feel that the
URL/URN taxonomy debate has given us much).

HOWEVER, it is still extremely useful to have the concept of
the universal set of all identifier/name/addresses in all
It is also useful to have a syntax for writing down the value

One cannot deny that it is useful, because WWW *uses* it.  This
is *not* to say that the WWW installed base prevents any bugs
in the URL spec from being fixed, but it is an existence proof
of the need.

The syntax for the universal set was called, in WWW, the URI
syntax, for Universal Resource Identifier.  The WG changed
"Universal" to "Uniform", but in doing so lost the important
significance of the Universality: that fact that, if you create
a name space, whatever its properties, I can give it a name
and map its syntax into acceptable UDI syntax.

Note that attepmts to make URIs a subset of another
name space are of couse possible but pointless by

The URI working group pointed out very sensibly that a
system of more persistent names was necessary.

Unfortunately, and this was the *big mistake*, we then
set about a taxonomy of all name spaces, to divide them into
URLs (of which they had several) and URNs (of which they used
none as no lookup method existed), and worse, to extend the
taxonomy to new schemes not yet invented,

I had hoped that a distributed persistwent name lookup
service would arise, but it didn't.  What did happen was
that great world-designing started and never finished.

Anyway, all existing schems have been called URLs, and
URN is a reserved name.

Since, there have been long discussion about, for example, whether
a news article id is a URL or a URN.  The IIIR community is trying
to retrofit a top-down design onto all existing systems. This
is foolish because

	1.	If you retrofit a design onto existing practice
		to make it clean you have to lie about existing
	2.	To do a top-down design in this area won't work.
		We have to progress by a sequence of brilliant
		independent ideas.
	3.	If you manage to categorize all the existing schemes
		into a taxonomy you will only end up restricting the
		future dschemes into yoru current mind set.

What SHOULD we be doing?  Valid things to define and, therefore,
argue over are:

	1.	Interpretation of the implicit data model.
		For example, my interpretaion of the FTP model
		was that you browse directories, and the filenames
		are the names, and the files the addresses.
		The data type is guessed from the filename.
		This was my laying of a formal model onto the FTP
		protocol which didn't dedfine one.
		Others take the view that one doesn't browse a
		directory, one gets an address from a mail message,
		and there is information th the filename (etc)
		to tell you which transfer type to use.
		Obviously both are valid mappings, we need to chose
		and maybe use both.
	2.	Design of new data models. This is valid for HTTP
		and for URNs.
	3.	The mapping of names in the model onto a concrete
		string syntax. Malinly a question aof character sets,
		and settled, thank you.
The URL document talked about "requirements" on names
and addresses in different schemes. That was a mistake. It should
have talked about "characteristics" of names in different models.
We can only document these characteristics for current protocols,
we can't define them.  What we can do though is invent new schemes,
and in particular the fabled URN scheme.
Discussion of the relative merits of characteristics is
outside the bounds of the URL document.

In summary, the URL document

	- defines a Universal syntax for ANY past or future

	- defines a spoecific mapping of name spaces
	  implicit in existing protocols into URI space.

The URIs defined for existing protocols are known as URLs
and they have the property that they map directly onto a
single protocol in each case.

If the URI WG wants to define something other than URIs
as defined above (and I hope in the document) then they
should first decide what to do with URIs.

Tim Berners-Lee