Re: Stab in the dark
Keith Moore <moore@cs.utk.edu>
Errors-To: listmaster@www0.cern.ch
Date: Thu, 17 Mar 1994 05:18:39 --100
Message-id: <199403170412.XAA01188@wilma.cs.utk.edu>
Errors-To: listmaster@www0.cern.ch
Reply-To: moore@cs.utk.edu
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: Keith Moore <moore@cs.utk.edu>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: Stab in the dark
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 1266
> The attached code is a very rough sketch of a possible solution to
> the URN->UR*->URL scenario which relies on the DNS, HTTP and HTML.
> I'm not suggesting this is The Answer as far as URNs are concerned.
> An Answer, perhaps? :-)
it's okay as a proof-of-concept. I don't think it's quite ready
for production, yet, though.
> In attempting to resolve a URN of the form
>
> urn://urn.mrrl.lut.ac.uk/martin/top
>
> it does a DNS TXT lookup on the domain component, e.g.
>
> urn.mrrl.lut.ac.uk. 86400 TXT http://www.mrrl.lut.ac.uk/urn
>
> Because I'm lazy, the first http URL returned is taken as the URL
> of the server which is willing to perform the URN resolution.
certainly you'd want the client to be able to pick more intelligently
(trying other servers if attempts to use the first one failed, and
perhaps attempting to locate a nearby server first)
> 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.
Keith