# Re: Seperating URC format and URN->URC resolution

Peter Deutsch (peterd@bunyip.com)
Fri, 29 Apr 1994 20:45:37 -0400

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Peter Deutsch: "Re: Yet more URI/URC"
- Previous message: Peter Deutsch: "Re: Seperating URC format and URN->URC resolution"
- Maybe in reply to: Mitra: "Seperating URC format and URN->URC resolution"
- Next in thread: Mitra: "Re: Seperating URC format and URN->URC resolution"
- Reply: Mitra: "Re: Seperating URC format and URN->URC resolution"

    Message-Id: <9404300045.AA13678@expresso.bunyip.com>

    From: Peter Deutsch <peterd@bunyip.com>

    Date: Fri, 29 Apr 1994 20:45:37 -0400

    In-Reply-To: Mitra's message as of Apr 29, 15:18

    To: Mitra <mitra@pandora.sf.ca.us>

    Subject: Re: Seperating URC format and URN->URC resolution

Hi again,

[ Mitra wrote: ]

> On Fri, 29 Apr 1994, Peter Deutsch wrote:
> > Now, if there _is_ a TXT record, it might indicate several
> > optional servers, it might indicate an optional port
> > number for special handling, it might indicate the address
> > of a specific publisher agent for this particular user at
> > this site and so on, but even without any of this we can make a
> > first stab at resolution.
>
> Peter - this sounds very vague - could you give an example of the
> connections a client might make, and the choices it would make, I think
> this is getting very complicated - aka slow, but dont really understand
> what you are suggesting. . . .

I agree I wasn't all that clear. I should have chosen a
better example. Let's try this again.

If the URN looks like:
URN:myurnsrvr.bunyip.com.srv.int:"ID=WAR_and_Peace"

Then, this tells you what server to ask for the
dereference, plus the string to send it to perform the
dereference. Note that this is _not_ a URL and thus we
don't necessarily know what protocol to speak when you get
there at this point. I think you will either agreed upon
this out of band, or have a mechanism for looking it up on
the fly (eg. a subroutine that understands the TXT record
technique, or whatever).

Now, if you happen to know that any URN served by
bunyip.com requires WHOIS++, you don't need to query for
the TXT record, you just go to "myurnsrvr.bunyip.com" and
perform a WHOIS++ query, get back the result and you
should have the URL you wanted. You could presumably also
ask this server other questions, such as author name, etc
for a particular URN and you thus have URN->URC
resolution, as well.

If you _don't_ know what protocol to use, then you need to
have a mechanism to find out and call the routine that
understands this before performing the dereference itself.

So, assuming the client has something like:

URN:myurnsrvr.bunyip.com.srv.int:"ID=WAR_and_Peace"

and you want to dereference this to a URL, then the code
could look something like this:

/* ------------------------------------------------------------*\

-- subroutine to dereference a URN --

Assumes the following routines:

resolver_protocol_to_use() - returns ID of protocol to use
for this URN server, or ERROR
connect_to_address() - because I was too lazy to
show a full connect...
process_query() - send opaque string on connection
using appropriate protocol
proxy_srvr() - send URN to well-known proxy
for processing

sample call:

servername = "myurnsrvr.bunyip.com.srv.int";
deref_URN(servername);

All this assumes the processing routine properly constructs
the URN structure from the query by magic and of course, any
comments on my C indenting style should be directed to
/dev/null... :-)

\* ------------------------------------------------------------*/

struct URN *deref_URN (char *servername) {

if (protocol = resolver_protocol_to_use(servername)) {
if (address = gethostbyname(servername) == NULL) {
fprintf (stderr, "Sorry, not a legal servername\n");
return(NULL);
}
if ((ptr = connect_to_address(address, protocol)) == NULL) {
fprintf (stderr, "Sorry, can't dereference URN!\n");
return(NULL);
}
else {
return(process_query(ptr, protocol));
}
}
else {
return(proxy_srvr(servername, protocol));
}

}

Of course, real code would need a lot more hand-holding...

Note that in the case where you _don't_ already have the
address of Bunyip's server, you'd need A DNS lookup
(perhaps half a dozen UDP packets, depending upon caching,
depth of FQDN, etc) plus one dereference query. Where
you've already cached this result, or are using other
techniques to find the server, there's only the
dereference itself to worry about.

Now, if you _don't_ know the protocol, you could try for a
TXT record (and thus have to return to DNS again and see
if one is registered. If not, you're out of luck but if
so, you can then either resolve it or send it to a proxy
server for resolution on your behalf. This would require
an additional lookup from DNS but otherwise the scenario
remains unchanged and you then don't need to have a client
that speaks every resolution protocol. Heck, there may
even be money to be made here for a subscription URN
dereferencing service...

I hope this example makes what I intended a little more
clear.

. . .
>
> I have two problems with this - but both could be worked around if this
> is really what is wanted.
>
> a) it takes at least one more connection to DNS for the default case,
> which is an unneccessary extra delay.

Actually, only where the server information is needed and
I don't see how you can avoid that at least once. With
caching, alternative resource discovery, etc it may not
need more than a single dereferencing query once you've
established the location of a server for a particular URN
server, modulo caching timeouts and such.

> b) a client writer has to implement *ALL* the protocols above, in order
> to know that they can resolve any URN they are presented with.

Or have a pointer to a proxy server which will know them
on your behalf. I think this would be a suitable
"departmental service", or something operated by
connectivity providers for their users, as they operate
archies now. Of course, if Darwinian selection chooses a
winner fairly quickly, this might not even be needed.

> I could live with this, but only if there we put together gateways
> between a default protocol and whatever protocol the resolver uses
> natively, I dont know about other client writers, but sticking all these
> in makes the job harder, and the clients bigger, and I'm only going to be
> able to use the common subset of the functionality anyway. Any client
> writers figuring that they'd implement all of these, please speak up :-)

I assume that if we offer you a frontend onto a generic
service as part of "Son of Archie(tm)" presumably we can
address this particular concern. It may speak Gopher, HTTP
or WHOIS++ (or all three... :-) In any event, I don't see
this as something that every client needs to be worried
about in the long run. Either one protocol will be chosen,
or proxies will exist. I suspect we'll see if I'm being
too optimistic about this soon enough...

- peterd

    --
    -----------------------------------------------------------------------------
       "What do thay got, a whole lot of sand? We got a hot crustacean band!
            Each little clam here, know how to jam here! Under the Sea!"
    -----------------------------------------------------------------------------

- Next message: Peter Deutsch: "Re: Yet more URI/URC"
- Previous message: Peter Deutsch: "Re: Seperating URC format and URN->URC resolution"
- Maybe in reply to: Mitra: "Seperating URC format and URN->URC resolution"
- Next in thread: Mitra: "Re: Seperating URC format and URN->URC resolution"
- Reply: Mitra: "Re: Seperating URC format and URN->URC resolution"