Date: Wed, 27 Apr 1994 22:45:55 +0500
From: dupuy@smarts.com (Alexander Dupuy)
Message-Id: <9404280245.AA24153@brainy.smarts.com>
To: rdaniel@acl.lanl.gov, mitra@pandora.sf.ca.us
Subject: Re: Seperating URC format and URN->URC resolution
> On Wed, 27 Apr 1994 rdaniel@acl.lanl.gov wrote:
> > Mitra's scenario currently locates the URI server(s) for a particular
> > publisher and gives us their IP address. However, this is not quite
> > enough. We have to know how to talk with the server we find at that
> > address. In order to support a range of alternatives in the experimentation
> > phase, how about we standardize on a well-known (to us :-) port and a
> > trivial service on that port which gives the client a list of ports and
> > services that can really do the URN->URL mapping. Browsers can look at the
> > list to see if they know how to speak the supported protocol(s) on that
> > URI server. Later on when we have standardized on a protocol, we can bump
> > up the version number of the trivial service and have it do the real thing.
>
> The big problem with this is speed, setting up a connection to a service
> is a non-trivial exercise, with around a 1 second penalty (which is why
> Prospero uses UDP).
On several occasions, I (and others) have suggested that Mitra's scenario be
modified so that instead of getting IP addresses for URI servers, you would
get TXT records containing a URL for the URI server itself (or if you prefer,
TXT records containing [IP address,protocol,port] tuples). Then you could use
the TXT records to select lookup via whois++, prospero, http+, or whatever
(we'd need to add a URL prefix for whois++, but that's easy).
This has all the flexibility of your scheme, without the speed penalty.
However, despite what everyone keeps saying about the importance of
flexibility and the need for multiple URN formats and user-level access
protocols (e.g. ref [1] below) everyone but me seems to be convinced that
there should only be one URN->URC resolution protocol, and some subset of
whois++ will (probably) be it.
They have also complained that TXT records are not universally supported
(there were apparently some buggy BIND releases), and that TXT records are DNS
specific, which I think are valid criticisms (although you can embed a string
in X.500 or whatever directory protocol you like just as easily as in a TXT
record in DNS).
Other complaints are that TXT records are too complicated for people to
administer, which I don't think is a valid criticism, considering everything
else you need to do in order to publish and support a URN; and finally, that
DNS is an inappropriate mechanism for URN->URC resolution, which is really a
criticism some other proposal that they are confusing with this one.
Using TXT records to hold URLs in this way is not trying to resolve the
original URN; it is just using DNS to hold a pointer to something more than
just the IP address of the URN-URC server, namely a description of the
protocol to use to talk to each URN->URC server and the port to contact.
@alex
[1] Peter Deutsch wrote:
> I'd like to repeat a point I've made before. I strongly
> believe that there will not be a single URN format, any
> more than there is currently a single user level access
> protocol, nor should there be. I think that some of the
> desireable characteristics of a URN are conflicting and
> incompatible and some judgement will be needed to select
> the most appropriate format for a given application.