Date: Wed, 23 Feb 94 06:38:06 -0600
Message-Id: <9402231238.AA06149@joe.uwex.edu>
To: uri@bunyip.com
From: hoymand@joe.uwex.edu (Dirk Herr-Hoyman)
Subject: Re: URN to URC scenario
I said bravo the 1st time Mitra posted this and I'll say it again. Bravo.
Not only does this summarize what I think is a good technical proposal, it
also a nice crisp document.
>1) A client program, running on a users workstation, receives a
>hypertext document, menu, or search result etc containing a number of
>URNs.
>
>2) The user selects one of the URNs
>
>3) The client locates, a URN->URC resolution service.
>
>4) The client contacts the URN->URC resolution service, and
>retrieves a number of URLs for this document, along with meta
>information about those URLs (e.g. cost and format) and about the URN
>itself.
>
>5) The user, or the client, pick the "best" URL
>
>6) The client either retrieves the URL itself (e.g. via its access
>library) or if the URL is for a access method it doesnt speak, via a
>gateway service.
>
>7) The client either displays the object, or if its in a format it doesnt
>handle, launches an appropriate viewer.
>
What I like about this approach is that it is quickly implementable,
without overloading the existing DNS. Presumably the URN server name would
get cached in DNS, so there wouldn't be a lot of load there.
I feel the URN->URC lookup is important because it will scale up in terms
of metadata. We don't know and can't dictate what metadata there will be,
and this proposal just provides for a mechanism, without specifying much
more. The URL, just becomes one bit of metadata, with other metadata
available too.
If we can agree on this scenario, I would certainly like to see Mitra add
this to the pantheon of URI documents.