Re: report: URN Architecture Meeting at University of Tennessee, Oct 30-31

> From: msm@ansa.co.uk
> 
> I may be missing something, but this wasn't an open invitation meeting, 
> right?  

No, it was an invitational meeting, and an attempt to get the authors
of various proposals together in one room.  It's easier for a handful
of people to understand each other, than it is to reach mutual 
understanding in a group the size of the URI working group.  

We're not claiming that our work represents widespread consensus, but we 
do hope that we can improve on our earlier proposals by cooperating rather
than competing.

> Since most of us on the mailing lists weren't given 
> the opportunity to present our views, don't you think you might be seen 
> as setting up an exclusive club to do the URN work?

Please be assured, we will submit our work to the IETF, and (assuming
the IESG sees fit to charter a working group to look at it) there will 
be plenty of opportunity for others to present their views, or even
alternate proposals.

> Not the DNS limitation again.   Please consider putting some 
> extensibility in to the proposal, please please.

Perhaps our report glosses over a subtle point or two.

We fully expect that there will be several different URN lookup
services, and that some of these will use other protocols than DNS.
For example, clients may want to consult a "proxy" or "cache" or
"firewall" resolution service instead of the DNS-based one, or
to consult a "fallback" resolution service should the DNS one fail.

Nevertheless, there is a lot of interest in a DNS-based URN registry,
so we're making an effort to build one that works as well as it can.
The DNS-based registry looks up the naming authority, not the entire 
URN, so we won't have a DNS record for each URN.  And the purpose of
the new top-level domain was to encourage the creation of stable
resource names, without requiring everyone who wants to create URNs 
to use them.

Despite the problems with DNS, which we acknowledge, it does have the
advantages of very wide deployment and 10+ years operational experience.
Many of the problems with DNS are being addressed.  A new distributed
database would come with its own set of bugs, which would have to be
shaken down, but which might not become apparent until the new system 
also acheived wide deployment.

Finally, the URNs we propose are not tied to any particular lookup 
scheme.  This is an explicit design choice.  If (e.g.) DNS proves to 
be an unsatisfactory naming authority registry, the URNs themselves
won't become invalid -- we'll just implement another registry using 
some other protocol.  After all, while we'd like these URNs to last
many decades, we'd be very surprised to find ourselves using the identical
DNS protocols that we use today (or, for that matter, any of the other 
protocols in use today) even ten years from now.

Keith Moore
(speaking for myself only, but using first-person-plural when I 
*think* I understand what the group believes.)

Received on Wednesday, 8 November 1995 22:24:30 UTC