The first URL discussion?
Dateline: October 21, 1991.This document, is the first record I can find of discussions of URLs. The four of us:
- Dean Tribble then at Xanadu,
- Brewster Kahle, then at Thinking Machines and now president of WAIS,
- Bob Schumaker then at AMiX, now at Fujitsu Cultural Technologies
- Mitra, then at Pandora now freelance,
had met at the Hackers conference in Tahoe (note this is the old use of the word Hackers - meaning people who push technology to its limits, not people who break into systems!), and we were trying to come up with an identifier, that could be used across multiple information systems to refer to documents on others.
The WALS (Wide Area Location Server) server described here was basically a URN resolver, that used a URL as a URN. The clever part was that the WALS server could either locate, or retrieve the document, allowing it to also be a proxy server.
Nothing much came of the WALS server, it was ahead of its time, but matches some of the current URN discussions. However Brewster took these ideas to IETF in Boston, where they were described over beers to Tim Berners Lee who was looking for something like this for WWW. The rest, as they say, is history.
For the curious and rushed, skip to the BNF and examples to see just how close they were to the final version.
Bob' s version of this is at http://www.io.com/~cobblers/URLS.html
- Mitra <mitra@mitra.biz>
bob, tribble, brewster,
Dean: Here's my interpretation of the last slide. I tried to capture things
that we talked about at various places on the slide. Don't shoot me
if I'm wrong :-) I'll be writing up something like a proposal RSN.
Mitra: - this looks good, it seems to cover what we are talking
about, some additional notes.
Mitra: Some pseudo-code which I hope makes some things clearer, note
I'm not suggesting things have to be done this way, only that this is
one way to do it, and may clarify intentions to some people.
external locate(Identifier) -> Identifier
# the returned identifier presumably has more location information.
{ locatelocal(Identifier) # Can we locate this in our rule-base
if sufficient(Identifier) # If we can locate it exactly
then return(Identifier) # Then we have the answer
else if Host=wheretoask(Identifier) # Otherwise who might know
then Host!locate(Identifier) # Ask that WALS server
else return Identifier # Cant tell you anything more
}
local locatelocal(Identifier) -> Identifier
# Mitra: This is a simple subset of locate which wont ask another server,
its needed to save fetch having to traverse a tree of WALS servers once
to find the document and then to fetch it
{ if can find Identifier in its rule-base
(see below for example rule-base)
then transform Identifier by rule and recurse
else return Identifier
}
local sufficient(Identifier) -> Boolean
# Mitra: I've added this, its needed below to know when to ask other hosts
{ Return true if if this identifier contains sufficient location
information to retrieve the document
}
local wheretoask(Identifier) -> WALS-server | NULL
# Mitra: Again a rule based function to figure out which WALS server to
ask about this Identifier. This could be part of locatelocal,
{ return the name of another WALS server to ask about this Identifier
typically returns the host portion of the location
if not possible to ask anyone else about this then return NULL
}
external fetch(Identifier) -> doc
# get the contents of the document corresponding to the identifier.
{ locatelocal(Identifier) ; Find as much as we can locally
if Host=wheretoask(Identifier) ; Figure out who to ask about it
then return Host!fetch(Identifier) ; ask that host for the document
else return NULL
}
store(doc, <Identifier>)=> <Identifier>
# Dean: Register the document at some new location. The operation here is
clearly bogus, but something like that needs to be available. (For
instance a Xanadu server could claim that it stores a particular
document, and supply the navigation information.
BNF
Mitra: I've re-written the BNF from Dean's description, I think my version
is the same, but just more precise if my memory of BNF is still
intact, Dean - please check and see that this is what you meant.
Explanation:
"," means the character comma
[xxx] means none or one occurances of xxx (the [] is for grouping
[xxx]* means none or more occurances of x
[xxx]+ means one or more occurances of xxx
[a-z] means any of the letters a thru z
<Identifier> ::= <GID> [ "," <Location> ]*
# Mitra: Note the , is repeated for multiple locations, also that it is not
# anticipated that multiple Locations will be supported by early
# implimentations
<Location> ::= [[ <LocalID> ":" ] <Server> @ ] <SiteAddress>
# Mitra, note that if there is no LocalId the : is ommited, ditto the @
Mitra: Please check I have the next group is correct, what we allow here will
ensure whether we have an Identifier we can parse from right to left
<SiteAddress> ::= <a standard internet site>
<a standard internet site> ::= [ <site part> "." ]+ <site part>
<site part> ::= <alphanumeric>+ # Is this sufficient?
<GID> ::= <SubGID> ":" <Naming convention>
Dean: renamed DB to Server so that we remember that the servers could do
anything to retrieve the document once they are supplied with the
localID. FTP is an example.
Mitra: Do we want to keep this as restrictive as below, or is Server
anything but ":"
<Server> ::= <alphanumberic>+
<alphanumeric> ::= [a-zA-Z0-9]
Mitra: The SubGID can be anything, it is bounded by the known,
parsable, pattern on the right of it.
<SubGID> ::= <any printing ascii character>+
Mitra: I'm not sure what LocalID can be, we need to be able to find
the "," on the left of it, so I'm not sure what we allow - maybe
anything but ","
Dean:
Examples of GIDs:
<hash><docID><backendID>:xanadu
docID:lexus
locdocID:db@think.com:wais
/pub/foo@think.com:ftp
Mitra: I've taken out the {} - where they intended?
Dean:
An example of ftp:
locate(/pub/foo@think.com:ftp) returns either:
/pub/foo@think.com:ftp, /pub/foo@think.com:myFTP@localhost
to invoke a local server "myFTP" with the LocalID: /pub/foo@think.com, or
/pub/foo@think.com:ftp, /pub/foo:ftp@think.com
to call WALS at think.com and have it run an ftp server there.
Dean: Note that the mapping from <Server> names to the actual servers is
create from a configuration file when the local WALS starts up. In
the example above, myFTP is just the name provided that somehow
identifies the process that will perform FTP.
An example of lexus:
locate(doc39:lexus) returns doc39:lexus, doc39:lexus@mead.com
Dean: Among other things, the locate service can apply heuristics to the GID
to figure out who to call for more information. It could also call
some directory service to find out more information.
Dean: I came up with a new way to point out some of the properties of this
scheme. The Global IDs a uninterpreted bytes to WALS, whereas the
location information is uninterpreted bytes to servers using WALS. So
when storing a reference to an external document, Xanadu would store
the location information without trying to parse it, and would simply
hand that information back to WALS when it wanted the document.
Dean: Great stuff!
Mitra: Second that!
