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

Mitra (mitra@pandora.sf.ca.us)
Fri, 29 Apr 1994 15:18:36 -700 (PST)

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

    Date: Fri, 29 Apr 1994 15:18:36 -700 (PST)

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

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

    To: Peter Deutsch <peterd@bunyip.com>

    In-Reply-To: <9404291726.AA12952@expresso.bunyip.com>

    Message-Id: <Pine.3.89.9404291100.F14421-0100000@pandora.sf.ca.us>

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. What I'm hearing is something like
Starting from a "urn:fred:12345"
Ask DNS for TXT record for "fred.uri.int"
if success
then
interpret text record to decide server
case "whois"
contact whois server
case "http"
contact http server
case "prospero"
contact prospero server
else
ask DNS with "gethostbyname" for fred.uri.int
contact "fred.uri.int" on default port with default protocol.
endif

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.
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.

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 :-)

- Mitra

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