# Re: URN: vs alternatives

Keith Moore (moore@cs.utk.edu)
Sun, 26 Nov 1995 11:35:06 -0500

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Daniel LaLiberte: "URN: vs alternatives"
- Previous message: Jon Knight: "Re: URN: vs alternatives"
- In reply to: Jon Knight: "Re: URN: vs alternatives"
- Next in thread: Renato Iannella: "Re[2]: URN: vs alternatives"

    Message-Id: <199511261635.LAA10659@wilma.cs.utk.edu>

    From: Keith Moore <moore@cs.utk.edu>

    To: Jon Knight <J.P.Knight@lut.ac.uk>

    Subject: Re: URN: vs alternatives

    In-Reply-To: Your message of "Sun, 26 Nov 1995 13:11:51 GMT."

                 <Pine.SUN.3.91.951126130224.6883F-100000@weeble.lut.ac.uk>

    Date: Sun, 26 Nov 1995 11:35:06 -0500

> In a parallel discussion going on over in the IETF mailing list at the
> moment, Paul Vixie and other DNS gurus have pointed out that the DNS is
> not a true directory service. I think this is something that the URN design
> should bear in mind. I can see two scenarios here:
>
> 1) You have a URN given to which you want to resolve to a single URC.
> This is just like the DNS FQDN -> IP address mapping and so DNS may be
> appropriate.

Yes, this is the scenario for which I would use DNS.

> 2) You want to know what URN for a certain document written by a
> particular person that has been registered by a particular organisation.
> Now you could start guessing the DNS-like elements in the URN and in the
> early days when the namespace is small this will probably work most of the
> time.

If you're assigning URNs and you want them to be persistent over several
decades, you don't organize your URNs as a hierarchy of human-meaningful
elements. So DNS wouldn't even work in the short term for this case.

Even a directory may not make an effective resource discovery tool
for many subject areas. Effective resource discovery often requires
tools which are tuned to a particular discipline or subject domain.

It might turn out that the most important function that URNs provide
is to serve as a substrate for good resource discovery tools.

Keith

- Next message: Daniel LaLiberte: "URN: vs alternatives"
- Previous message: Jon Knight: "Re: URN: vs alternatives"
- In reply to: Jon Knight: "Re: URN: vs alternatives"
- Next in thread: Renato Iannella: "Re[2]: URN: vs alternatives"