Re: Stab in the dark

browne@cs.utk.edu
Thu, 17 Mar 1994 16:08:58 --100


>On Thu, 17 Mar 1994, Jon Knight wrote:
>> > Then
>> > the rest of the URN is appended - in the example this gives us
>> >
>> > http://www.mrrl.lut.ac.uk/urn/martin/top
>>
>> Yikes!! I see no reason that a URN should be constrained to contain
>> any part of an eventual URL (or likewise, why a URL should have to
>> contain any part of any of the URNs that might point to it.)
>> And I can see some very good reasons NOT to impose this constraint.
>>

>Martin showed me this last night and I was under the impression that the
>URL <http://www.mrrl.lut.ac.uk/urn/martin/top> wasn't an eventual URL that
>the URN was pointing at but was the URL of the URC which contained
>multiple URLs which you then followed to get to the resource. I can't
>really see why the system couldn't tack more or less anything from the end
>of the URN onto the URL stem returned from the DNS to point to the URC; surely
>this would be up to the administrators of that URC to decide? What's the
>good reasons that this won't work?

This was my impression also, or rather that the prefix returned by
DNS would be the address of a URN to URT lookup service (URT as in
<a href="http://www.gatech.edu/urm.paper"> Michael Mealling's URI
paper</a>, and that the opaque string part of the URN would
be tacked onto this address to form the URL for doing the lookup.
Ideally, the URT returned by the lookup would be interpreted by
the client and used to decide (possibly in cooperation with
the user) exactly what files to retrieve. URTs could also be
cached by the client.

In the discussion that follows below, I am assuming the URN
syntax described in Weider and Deutsch's
<a href="ftp://ds.internic.net/internet-drafts/draft-ietf-uri-resource-names-01.txt">
Uniform Resource Names</a> Internet draft, i.e.,

<URN:Encoding_Scheme:Naming_Authority_Scheme:Naming_Authority_ID:opaque_string>

for example,

<URN:ASCII:IANA:merit.edu:1929642>
or
<URN:ASCII:IANA:www.mrrl.lut.ac.uk:/martin/top>

I like the idea of using DNS to do the URN to URN-to-URT-lookup-server
lookup. I like it because it uses an existing namespace to
resolve URN naming authority identifiers, which I think would
be less confusing and faster than developing a new namespace
and implementing another DNS-like distributed database
(although perhaps some would argue it would be more confusing to
use the same namespace for two things).
Is using DNS in this way workable, do you think?
I would be in favor of having the client do the DNS lookup
rather than a server.

************************************************************************
Shirley Browne Research Associate 107 Ayres Hall
browne@cs.utk.edu Computer Science Dept. University of Tennessee
(615) 974-5886 Fax (615) 974-8296 Knoxville, TN 37996-1301
*************************************************************************