re URN, URL, URI etc.

[Terry Allen]

Eliot 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

Yes.  and (in the long run) you might want to use different resolution 
services for different URN name spaces, as you determine what works best
for you in practice.

| 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

for FPI URNs.

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

(I think it would be more like urn:iso:stds:fpi ... and I think you have
to escape the slashes, too, which makes ISO 9070 identifiers more 
attractive, but that's beside the point.)

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

Yes.  Although first it may consult your local (cache) resolution service
(entity manager!) to see if you already have a copy.

| 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

The client already knows the FPI (assuming it can deencode it from the
URN).  I would think it would send the URN instead. 

| FPI in its table and returns the URL of the resource to the client,
| assuming it finds it.

I would think the resolver looks up the URN and returns the URL.

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

Yes.

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

The relevant document, "URN Namespace Definition Mechanisms",
ftp://ftp.ietf.org/internet-drafts/draft-ietf-urn-nid-req-06.txt,
is, I'm happy to say, in Last Call and apparently ready to become
an RFC.  When you register a URN name space, you're supposed to
answer some questions, including in relevant part

Process for identifier resolution:
	If a namespace is intended to be accessible for global
	resolution, it must be registerd in an RDS (Resolution
	Discovery System, see [RFC2276]) such as NAPTR.  Resolution
	then proceeds according to standard URI resolution processes,
	and the mechanisms of the RDS.  What this section should
	outline is the requirements for becoming a recognized resolver 
	of URNs in this namespace (and being so-listed in the RDS	
	registry).

	Answers may include, but are not limited to:
	. the namespace is not listed with an RDS; this is not	  
	  relevant
	. resolution mirroring is completely open, with a mechanism
	  for updating an appropriate RDS
	. resolution is controlled by entities to which assignment	  
	  has been delegated

so Eliot's summary is correct.  Note that this doesn't preclude you
(or anyone else) from providing other mechanisms of resolution.  In
the case of FPIs, were ISO to register a name space form them, it would
presumably either set up the resolution service itself, delegate it to
so responsible and capable organization such as GCA ..., or delegate
resolution of parts of the FPI name space to the owners of the
relevant FPIs.  Or some combination.

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

I would think not too hard.  

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

Nope.  Note this wrinkle:  in some contexts you don't have to resolve
the URNs over the Internet at all.   For example, for CBL my socat
looks like this:


-- SGML Open catalog for CBL Version  1.1 --
-- Terry Allen  9 September 1998 --
-- Copyright 1998 Veo Systems, Inc. --

SYSTEM "urn:x-veosystems:dtd:cbl:1.1:catalog:1.0" "catalog.dtd"
SYSTEM "urn:x-veosystems:dtd:cbl:1.1:catentry:1.0" "catentry.dtd"
SYSTEM "urn:x-veosystems:dtd:cbl:1.1:irequest:1.0" "irequest.dtd"

(I had expected to use PUBLIC for the URNs, but nsgmls doesn't
work that way, for reasons I have not investigated.)

Thanks for studying the issue, Eliot!


regards, Terry

Terry Allen				Veo Systems, Inc.
Business Language Designer	        2440 W. El Camino Real
tallen[at]sonic.net                     Mountain View, Calif., 94040
Common Business Library - available at  http://www.veosystems.com/

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)