Message-Id: <199410141931.UAA20333@lust.mrrl.lut.ac.uk>
To: paf@nada.kth.se (Patrik Faltstrom)
Subject: Re: Uniform Resource Names - almost draft
In-Reply-To: Your message of "Thu, 13 Oct 1994 19:38:33 BST."
<aac32be60a0210041f94@[130.237.225.201]>
Date: Fri, 14 Oct 1994 20:31:47 +0100
From: Martin Hamilton <martin@mrrl.lut.ac.uk>
Patrik Faltstrom writes:
| 1) You are not able to include the actual handle name (the URN) in
| a centroid, so you will not get all information you want, i.e.
| no servers-to-ask response.
Won't the URN attributes from the template appear in the centroid ?
| 2) The implementor of a Whois++ server is forced to use the URN as
| a handle, which is not the case every time. Me myself is using the
| handle as a direct index into the database, so the handle can change
| when the database is rebuilt.
Fair enough ! I suggested it because the handle specifier seems to
be the only way of bypassing the search mechanism. I was really
thinking about overloading the handle rather than forcing
implementors to make URNs the handles of their templates. A URN
lookup can be detected easily because it always starts with something
like...
handle="URN:
or
handle=URN\:
But perhaps the URN lookup is so important that it deserves a special
whois++ specifier of its own ?
| The best thing is, I think, to store a "template URN" which have an
| attribute named "URN" and one or more URL-attributes.
|
| By doing this one does not have to explicitly handle the
| template URN in the server or queries for URNs.
|
| A query should look like:
|
| URN="IANA:rfc:1490"
|
| The drawback (you have to search for a specific attribute and then
| later get the handle) might not be more expensive. In my server there
| is no difference in CPU cycles when searching for a certain attribute
| and a handle, part from that the Handle might be a unique index which
| in fact can make the search a little bit faster.
Isn't it a bit dangerous to assume that server implementations will
deliver search results within the resource/time constraints expected
of lookups ? For instance, it would be nice if the server could
handle lookups without forking, a la BIND...
Cheerio,
Martin