xml-dev - Re: re URN, URL, URI

["W. Eliot Kimber" <eliot@dns.isogen.com>]

At 06:55 AM 10/22/98 -0700, Terry Allen wrote:

>| DOUBT 1 :- URNs at this point are not widely used since there is no
>| generally available resolution service. In case a resolution infrastructure
>| comes up in time :-
>
>There is a generally available resolution mechanism, through DNS, but
>it has not implemented except on a test basis so far as I know.  URNs,
>of course, may be useful within more constrained contexts.  Note that 
>URN resolution won't happen for you without some effort on your part.

In thinking about URN resolution and how it might work in practice, my
conclusion is that if, for example, the DNS-based approach were implemented
in generally-available places, then as part of your client configuration
you would define what URN-resolution servers you want to use, just as you
define DNS servers when you configure your IP network set up. Your client
would then use these servers to determine what server or servers handle a
particular URN name space.  The browser would also have to know now to
communicate with resolvers for particular URN name spaces, but this could
be handled through simple plug-ins.

For example, say I set up a URN namespace resolver on drmacro.com and an
FPI resolution server on planetsizedbrains.com.  A typical URN resolution
session might go something like this:

1. On your client, declare "urnres.drmacro.com" as your URN namespace resolver

2. Your browser sees a URI like:
"urn:fpi:+//IDN%20me.com//DOCUMENT%20mydoc//EN" and tries to resolve it to
a resource.

3. Your client sees that the URI is in fact a URN (as indicated by the
"urn:" prefix). It looks in its own configuration tables to see if any URN
namespace resolvers are defined. It finds urnres.drmacro.com.

4. It sends the URN to urnres.drmacro.com using the DNS extensions outlined
in RFC 2168.  The URN namespace resolver looks up the namespace name "fpi"
in its table and finds "fpires.planetsizedbrains.com".  It returns this
location to the client [at this point I'm not sure if the client or the URN
resolver does the next part, but I think the intent is for clients to at
least expect to be able to handle this part.]

5. The client sends the FPI to fpires.planetsizedbrains.com, using whatever
protocol the resolver uses (but not HTTP).  The FPI resolver looks up the
FPI in its table and returns the URL of the resource to the client,
assuming it finds it.

6. The client uses normal HTTP communication to attempt to resolve the
returned URL to a resource.

If I understand the URN mechanism, each URN namespace is responsible for
defining the protocol for how resolution is done, i.e., the functional
equivalent of HTTP.  If I understand how these things are generally done,
you would expect to define a socket-based service on some conventional port
[but I'm really out of my depth at this point].

Viewed this way, it doesn't seem like it should be that big a deal to set
up useful URN resolvers and services for resolving specific URN name
spaces.  The biggest barrier seems to be support on the client side for
handling URNs to begin with.  As various URN name spaces became more widely
used and conventions develop, browsers would come with more built-in
configurations for different name spaces, relieving users of the need to do
the configuration themselves.  I would expect browsers to provide a plug-in
architecture for adding support for specific URN name spaces--how hard can
it be?

Am I totally off my nut here? Have I missed some critical detail that makes
URN resolution harder than it appears to be by this analysis?

I can't speak for Oasis, but it has already started exploring providing a
Web-based FPI resolver--seems like there might be some resources there that
could fund developing extensions to say Mozilla and a DNS server to provide
the client/server binding you need for full URN resolution.  It can't
represent more than a week of programming time for someone who knows what
they're doing (Joe Alfonso, where are you?).

Note that in the case of pure FPIs in an XML context, the same
infrastructure described above could still be used. The client would know
that anything that is a public identifier that starts with "ISO", "+//" or
"-//" is a public identifier and can use the same mechanism to look up the
resolver for FPIs (assuming that a URN name space for FPIs has been
registered or defined by convention).  Or they might provide a mechanism
for configuring FPI resolver services directly.

Cheers,

E.
--
<Address HyTime=bibloc>
W. Eliot Kimber, Senior Consulting SGML Engineer
ISOGEN International Corp.
2200 N. Lamar St., Suite 230, Dallas, TX 75202.  214.953.0004
www.isogen.com
</Address>

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