[
Lists Home |
Date Index |
Thread Index
]
- From: Jerome McDonough <jmcdonou@library.berkeley.edu>
- To: "Kent Sievers" <ksievers@novell.com>, <xml-dev@ic.ac.uk>
- Date: Tue, 08 Jun 1999 13:19:22 -0700
At 12:34 PM 6/8/1999 -0600, Kent Sievers wrote:
>Clearly, if we had a DNS server that was capable of mapping the URN of a
name space to a URL then the requirements would be met of having both a
unique identifier and a way of getting information about the namespace.
>
>Is someone stepping forward to do this sort of thing? .
>
>Imagine something like a DNS server, or maybe imagine subverting existing
DNS servers--I don't know how well adapted or scalable they are in their
current incarnations.
>
Basically, you're talking about URN resolution, and a variety of people are
working on the problem. Justin Couch is writing a java package for dealing
with URNs in conjunction with the IETF's working group on the topic. See
http://www.vlc.com.au/~justin/java/ for more information and to have a look
at his code. Some folks at MIT have proposed extending HTTP to support URNs
more directly; see http://www.w3.org/People/Frystyk/draft-ietf-http-wire.txt.
A lot of the focus for URN resolution has been on the THTTP convention
proposed
by Ron Daniel (RFC 2169). Justin's package includes a basic THTTP resolver,
and I've also hacked together a THTTP server for experimental work here at
Berkeley (which I haven't released, because the UI truly, truly sucks).
Most of the URN crowd has been reluctant to put URN resolution on to DNS.
While DNS has the advantage of being a pre-existing, proven system, it is
already slightly strained, and putting URN resolution on it would add a
very significant burden once URNs are more widely adopted. For more
information on this, see Ron Daniel and Michael Mealling's discussion
in the introduction to RFC 2169. My take on looking over the URN Working
Group's documents is that the default assumption by the IETF
is that client software will first turn to DNS and ask where it can find a
resolver
for a particular URN namespace (DNS will use NAPTR records to identify
resolvers
for particular URN name spaces) and then go to the resolver identified by DNS
to resolve particular URNs. So if you have a URN like
urn:urn-ns:ns-identifier
in hand, client software will query DNS to find out where a URN resolver
for the urn-ns URN namespace lives and what protocol it needs to use to
communicate with it, and then will query the URN resolver using that protocol
as to where the resource identified by ns-identifier lives. So, we can use
DNS to establish globally where the resolver for a namespace lives and what
protocol it speaks, and then let clients contact that resolver directly
for resolving individual URNs.
In short, yes people are working on the problem, and if you don't mind
being a bit bleeding edge, there's code you can start playing with available.
Jerome McDonough -- jmcdonou@library.Berkeley.EDU | (......)
Library Systems Office, 386 Doe, U.C. Berkeley | \ * * /
Berkeley, CA 94720-6000 (510) 642-5168 | \ <> /
"Well, it looks easy enough...." | \ -- / SGNORMPF!!!
-- From the Famous Last Words file | ||||
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)
|