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

Peter Deutsch (peterd@bunyip.com)
Fri, 29 Apr 1994 13:26:38 -0400

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

    Message-Id: <9404291726.AA12952@expresso.bunyip.com>

    From: Peter Deutsch <peterd@bunyip.com>

    Date: Fri, 29 Apr 1994 13:26:38 -0400

    In-Reply-To: Alexander Dupuy's message as of Apr 27, 22:45

    To: dupuy@smarts.com (Alexander Dupuy), rdaniel@acl.lanl.gov,

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

Hi all,

[ You wrote: ]

> > On Wed, 27 Apr 1994 rdaniel@acl.lanl.gov wrote:
. . .
> 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.

No argument from me on this one. I've heard this suggestion
circulate before and agree that it is a good one. One
observation - we can make this an _extra_ feature, and for
those who can't or wont use technique, they can still use
the simple DNS technique to try. Eg:

URN:whois.bunyip.com.urn.srv.int:"PUB=Peterd;URN=War-And-Peace, the sequel"

In this case, you'd send your request to the whois server
on "whois.bunyip.com" and let it handle things. Because in
my opaque ID string I've indicated what's coming in, the
server can figure out what's needed and handle it
appropriately.

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.

A couple of other thing s I'd point out. One is that the
added load on the top level DNS servers with this
technique can actually be a lot less than we imagine,
assuming that caching is going on at the level of
"urn.srv.int". Once your machine has found a server for
that, presumably you wont be going back to the root that
often.

A second observation (and it's really one for people more
involved with DNS) is that if we had a centroids mechanism
for DNS, we could simply ask for parent pointers rather
than continually hitting the roots. This would be a much
bigger task than getting some structure into TXT records,
but it is certainly worth considering.

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

On the contrary, I've posted several times that I think we
need to remain flexible on this point, too. FWIW, I
personally think that we will end up with several
complementary resource discovery mechanisms (and that's
really all the DNS proposal is about). This is one of
several techniques we have which might indicate where the
resolution might take place but another might be, for
example, that we finally deploy a real Yellow Pages
service and ask it when we need to look up the naming
authority entry. This in turn would specify the location
of one or more resolution servers for that authority and
we're at off to the races.

Implementing this second solution is actually closer than
it looks, since there are several candidate protocols for
this. WHOIS++ has some nice features for this task, but as
I've already stated this is only one of many candidates.
I've no deep attachment to it, other than the fact that I
think it satisfies many of the perceived designed criteria
and is developing in the context of the IETF so we have
some assurances that it is possible to make needed changes
without having to persuade a small group of gatekeepers.

I admire the work done by the various protocol developers
but would feel happier if such a vital part of the
Internet infrastructure were developed in a more open
forum and those tasked with maintaining it don't feel
quite the same pressure to balance their own needs against
that of the entire Internet community.

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

I think the thing to keep in mind here is that we are
talking about a specific resolution technique to find
specific servers. If this were to be the _only_ such
technique I'd have a lot of problems but since it will
clearly be possible to set up additional resource
discovery services that bypass DNS if you wish, I think
these criticisms should be noted, addressed and we simply
move on. If it turns out to ne the only technique people
use, great. If in practice the DNS technique is never used,
there will then be no significant loss or impact.

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

Actually, as I'm hearing this one, the criticism is that
DNS is already somewhat shakey on its legs and the
additional load of a URN->URL service may push it over the
edge. This is coming from some people who spend their time
keeping DNS going, so their concerns must be addressed,
although in response I've heard other people who spend
their lives keeping DNS going who say in effect "So? We
can fix it when it breaks."

To me this all illustrates the value of simply starting to
deploy some data ASAP and see what happens. We've now
received a contract from the Canadian government to build
a new information service and will hopefully be in a
position to serve some real URLs and other data relatively
soon. I'll be keeping this list posted as we get closer
but we certainly look to be serving data from multiple
index collections by the summer.

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

<Phew!> In other words, the DNS TXT records serve as a
resource location device. If a client doesn't need it, it
wont be used. If a client needs it, it will allow then
client to automatically find an appropriate server to send
some questions. It's not more complicated than that and
it's only one part (albeit an important part) of the task
we're working on.

- 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: Seperating URC format and URN->URC resolution"
- Previous message: Peter Deutsch: "Re: Yet more URI/URC"
- Maybe in reply to: Mitra: "Seperating URC format and URN->URC resolution"
- Next in thread: Michael Mealling: "Re: Seperating URC format and URN->URC resolution"
- Reply: Michael Mealling: "Re: Seperating URC format and URN->URC resolution"
- Reply: Mitra: "Re: Seperating URC format and URN->URC resolution"