Message-Id: <9310290230.AA05002@expresso.bunyip.com>
From: Peter Deutsch <peterd@bunyip.com>
Date: Thu, 28 Oct 1993 22:30:10 -0400
In-Reply-To: Mitra's message as of Oct 28, 18:36
To: mitra@path.net (Mitra), marca@ncsa.uiuc.edu
Subject: Single protocol for UR*?
[ Mitra wrote: ]
> Peter
>
> I'm glad you made this proposal, and think it a reasonable contender.
> Certainly better than having half a dozen different protocols.
People seem to be taking my proposal more seriously than I
expected, but if there really is a desire for a single
protocol at this point, I believe what I wrote will work
and would stand by it.
> I'd ask you to flesh out some details for it to be considered.
>
> 1) Is their software available to do this, (not a kit, but a real
> peice of portable - publicly available code). Not that I'm asking you
> to give away your code, but if its available it makes it a better contender :-)
We released the first draft of _our_ server a couple of
months ago, with full source, as have a couple of other
people. We support the basic protocol, although not all the
options, nor do we do centroids (yet). We use a modified
WAIS search engine which allows separate attribute and
value searches.
Our code is freely available. The only restriction we
place on this is that it not be used in commercial
products without a release from us. We encourage people to
use it and are not out to make any money off of it, we
just don't want to make anyone else a lot of money without
at least a nod in our direction. If you want to use any of
it in a product, let us know and we'll work it out.
We do hope to provide on-going support for this code,
within our limited resources. We've applied for a grant
from a Canadian government funded group to allow us to
continue working on it and we're waiting to hear from them
now. We expect further releases no matter what happens
here, but outside funding will certainly accelerate things.
> 2) Exactly what extensions to DNS would be needed to make this work, I'm
> presuming it could be handled by C calls to DNS routines, since we cant
> expect every client to implement the DNS. I dont quite understand your
> detailed proposal, but it might be that we can do this by just adding
> information to the DNS - and making standard "gethostbyname" calls.
I'm not sure _any_ extensions are needed, since we might
conceivable encode the needed information in a text
record, or as subdomain names, but I do recall a posting
from John Postel this week (Today? Blue? I've completely
lost track) suggesting that additions to DNS should take
the form of another type and this would probably the way
to go.
Thus, we'd probably want to define some form of "URL" type
or "Naming_authority" type, or some such that would encode
the hostname, port and protocol type for further queries.
If this is needed at all, I suspect it would be fairly
simple to work up, and as I suggested it would encode
something that looked like a URL pointing to the server to
start asking questions. At this point, I cede the floor to
somebody who actually knows something about DNS. Anybody?
> 3) How would whois++ return something looking like either Mike, My, or
> Ole's nested templates, Previous whois++ documents didnt look like
> they could handle this.
I must confess that I've lost track of the current URC/M/T
proposals, but I don't think I've seen anything go by that
we couldn't accomodate. After all, WHOIS++ assumes that
data is a series of tagged attribute-value pairs. What I've
seen of the URC thread seems to make similar assumptions.
If there are deeper problems, you guys can point them out
and we'll work on them.
> 4) What extensions would be needed to handle calls such as
> "Register this URL as a location for this URN"
There is a write option in WHOIS++ but if someone wanted
to put in a record in _our_ server, it would be done by
editing the file of templates and then reindexing the file
with the wais indexer. Still, this is an implementation
issue, not a limitation of the protocol, which does
support writes as an option.
> It would be really good to see similar responses from Rob (DNS) and
> Marca (HTTP), including a detailed example of a sample interaction
> from the time a client receives a URN to the time it can call a
> access library (e.g. a call to Prospero to return a gopher item).
I can give you the protocol queries you'd need, they're
trivial. If you want the specific C code I will take a
step back here and go talk to Alan, Bill and maybe Kevin
Gamiel, who worked on our server or its documentation. I
seem to recall that somewhere in there is a routine that
takes a valid query and returns the result, but I just
asked Alan and he can't recall for sure, either. It
certainly wouldn't be killer code to write if it doesn't
already exist.
> Personally I'd committ to do development work with whatever consensus
> we could reach on a scheme to use.
>
> I think that other networks - e.g.
> Gopher could easily implement gateways, for example a Gopher URN->URL
> mapping service that talked Gopher to a Gopher client, and did the
> whole lookup and retrieval to return a Gopher menu of URL's (with
> meta information converted into Gopher).
I agree that gateways would be easy using the scheme I
proposed, assuming you have a routine that can take a
string and return a query. If there are no serious
objections in the next week or so to this off-hand
proposal, this may all come together faster than I thought.
Wow!
- peterd
--