# URLs should contain types [AND DATES]

Clifford Neuman (bcn@ISI.EDU)
Mon, 24 May 93 09:43:17 PDT

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Dirk Herr-Hoyman: "Re: URLs, URIs, and references"
- Previous message: Larry Masinter: "Some URLs look like URNs already"
- In reply to: Peter Deutsch: "Re: URLs should contain types [AND DATES]"
- Next in thread: Terry Winograd: "Re: URLs should contain types [AND DATES]"
- Maybe reply: Terry Winograd: "Re: URLs should contain types [AND DATES]"
- Maybe reply: Terry Winograd: "Re: URLs should contain types [AND DATES]"

    Date: Mon, 24 May 93 09:43:17 PDT

    Message-Id: <9305241643.AA05715@tgo.isi.edu>

    From: Clifford Neuman <bcn@ISI.EDU>

    To: peterd@bunyip.com

    In-Reply-To: Peter Deutsch's message of Mon, 24 May 1993 02:46:24 -0400 <9305240646.AA02863@expresso.bunyip.com>

    Subject: URLs should contain types [AND DATES]

From: Peter Deutsch <peterd@bunyip.com>
Date: Mon, 24 May 1993 02:46:24 -0400

I really like your analogy, and would point out that this
example offers a great illustration of why you should
instead have written on that piece of paper something like:

"URN:NIC-WHOIS:PD45:::".

(or to keep with the analogy):

"Joe's Secretary, (514) 875-8611"

Which you might recognize as a URN that references a
server, keyed on a user handle, that can get Joe's record
upon demand. It should be fair to demand that this server
be able to tell me how to talk to Joe, no matter where he
is right now.

Now, whenever you want to call this person in the future,
you or your client software merely has to utter something
like "Oh magic server, that I know so well, please make
this URN into a URL" (or whatever else the protocol
interaction is going to be to dereference a URN) and then
use the resulting URL to access him at his then-current
location. Despite historical evidence to the contrary,
deploying such a system is simply not brain surgery. It
just hasn't been done yet. Still, I'd argue that it's not
that far away at this point.

Actually, it has been done. A Prospero link does not directly encode
the access method for an object. Instead, when an object is to be
accessed, a query is generated and sent to the object's custodian
(secretary in the above example) requesting the list of valid access
methods for the object and the parameters needed by each. The most
appropriate method is then selected from the set returned. "External"
links do directly encode a set of access methods, but only when the
object's custodian does not run Prospero.

~ Cliff

- Next message: Dirk Herr-Hoyman: "Re: URLs, URIs, and references"
- Previous message: Larry Masinter: "Some URLs look like URNs already"
- In reply to: Peter Deutsch: "Re: URLs should contain types [AND DATES]"
- Next in thread: Terry Winograd: "Re: URLs should contain types [AND DATES]"
- Maybe reply: Terry Winograd: "Re: URLs should contain types [AND DATES]"
- Maybe reply: Terry Winograd: "Re: URLs should contain types [AND DATES]"