Subject: RE: [URN] URN Resolution in deployable networks

From: Ron Daniel <[email-masked]>
Date: Tue, 8 Dec 1998 07:51:09 -0800

Hi Justin,

You are correct that the NAPTR approach for resolving URNs
does not handle all cases. Its intent is to be one of the last
resolution mechanisms that is tried, not the first. For
example, when I was at Los Alamos our experimental URN
resolver would first look at the incoming URNs. If they
were from a 'known' scheme like SICIs, the resolver would talk
to a system running at thte library. (For Handles, we talked
with a system running at CNRI). Only if those systems did not
know the URN, or if it was from a different namesapce, did we
fall back to using the NAPTR routines.

What NAPTR tres to provide is a fallack method of discovering a
resolver. But it does assume certain things, like being
connected to the Internet. It also makes certain implementation
choices, like use of DNS rather than starting another system from
scratch. Some other consequences flow from that choice, such as not
having access control over the rewrite rules.

It may be that one or more of those choices are inappropriate for
your system. However, you may be able to reuse other parts of
the URN architecture, such as the resolution services.

Best regards,

Ron Daniel Jr.
DATAFUSION, Inc.
139 Townsend Street, Ste. 100
San Francisco, CA  94107
415.222.0100 fax 415.222.0150 
[email-masked]
http://www.datafusion.net

> -----Original Message-----
> From:	Justin Couch [SMTP:[email-masked]]
> Sent:	Tuesday, December 08, 1998 12:26 AM
> To:	IETF URN WG
> Subject:	[URN] URN Resolution in deployable networks
> 
> Folks,
> 
> I'm looking into the usage of URNs in smaller scale settings than the
> Internet and at least think I'm finding shortcomings in the general
> scheme. However, perhaps I am also looking for alternative schemes or
> completely in the wrong direction. I'm not really sure, so I'll
> explain
> away:
> 
> We're building deployable systems for various military uses in the
> Special Forces and also civilian emergency service arenas. A typical
> characteristic of this is that the devices are usually notebook or
> smaller (Anything down to a Palmpilot) but have networking capability
> at
> least part of the time. For example there may be two or three
> notebooks
> in the middle of the bush somewhere all connected in a mini-lan. One
> of
> these may be acting as a typical server situation which holds a small
> database or other resource. These networks are typically built on the
> fly and by "dumb" users (your average soldier with minimal computer
> training).
> 
> All of this lends itself perfectly to the idea of of using URNs for
> naming various resources that need to be accessed. The code doesn't
> need
> to be recompiled, the user doesn't need to know what the server
> machine
> is (ie configure the application on the fly) and life is pretty rosy
> for
> the developers too as we can use a consistent scheme across many
> different resources
> 
> However, this sort of situation seems not be addressed by the current
> URN DNS resolution schemes. For example, under the DNS scheme, it
> assumes that you have a network all the time, where URNs may not
> necessarily point to a network based resource (eg palmpilot). There
> needs to be some other resource fetch scheme to determine where to
> first
> start resolving names.
> 
> For example, if we were running a unix box we could look at
> resolv.conf
> and determine that we should be doing a lookup of a urn scheme first
> from NIS or /etc/hosts before going to DNS. On a SMB machine we could
> use a WINS service. If you look at the implementation I did for the
> UMEL
> working group over at the VRML consortium, this just uses a local
> bindings file for resolution but doesn't handle a generic "check DNS"
> capability.
> 
> So the question is, are there any higher level efforts currently
> underway that provide the meta-resolution service for URNs? Related to
> this, are there any other efforts relating to URN resolution in other
> areas other than DNS (NIS or WINS for example)? If not, is anyone
> interested in looking at this problem with us?
> 
> -- 
> Justin Couch
> Senior Software Engineer                           VRML-Java Author
> ADI Ltd, Systems Group.
> [email-masked]                    http://www.vlc.com.au/~justin/
> -------------------------------------------------------------------
> "Look through the lens, and the light breaks down into many lights.
>  Turn it or move it, and a new set of arrangements appears... is it
>  a single light or many lights, lights that one must know how to
>  distinguish, recognise and appreciate? Is it one light with many
>  frames or one frame for many lights?"      -Suocomandante Marcos
> -------------------------------------------------------------------

---

From: "Fred L. Drake" <[email-masked]>
Date: Tue, 8 Dec 1998 12:51:27 -0500 (EST)

> fall back to using the NAPTR routines.

  Perhaps this is a good chance for me to describe the mechanisms
we've used in the Grail Internet browser
(http://grail.cnri.reston.va.us/grail).  For those who aren't familiar 
with Grail (just about everybody ;), I'll just mention that it is a
graphical browser that is intended to allow experimentation with a
number of things, including Web-related protocols (including URN
resolution).
  Grail provides an extension architecture for URI schemes.  Each
scheme is implemented as a separate module.  For example, HTTP is
implemented in a module called "protocols.httpAPI".  Support for CNRI
Handles (hdl:), Digital Object Identifiers (doi:), and IETF documents
(ietf:) are included with the browser; additional modules that
conform to a documented interface can be added to an installed copy of 
Grail.
  One aspect of Grail's support for URNs which may be somewhat
problematical is that there is no distinction between URN schemes and
URL schemes.  This means that URN:hdl:foo is the same as hdl:foo.  I
don't expect that this is likely to be a significant problem in the
near future; have others dealt with this issue in their
implementations?
  I'm always interested in hearing about possible improvements to
Grail, although the resources available to deal with problems tends to 
be fairly low (Grail was not developed in association with the Handle
system, and I'm not part of the Handle group here at CNRI), but I try
to fix any problems that I can to make Grail more useful.  If there
are likely to be any problems with Grail's system for scheme
extensibility, especially in the area of URN support, I'd be most
interested in learning more about it.

  -Fred

--
Fred L. Drake, Jr.	     <[email-masked]>
Corporation for National Research Initiatives
1895 Preston White Dr.	    Reston, VA  20191

---

From: "Martin J. Duerst" <[email-masked]>
Date: Sat, 12 Dec 1998 08:00:43 +0900

> conform to a documented interface can be added to an installed copy of 

This looks like each scheme implementation is completely independent
of each other. If this is true, it may not help implement new schemes.
If there is a library of common functions e.g. for parsing URIs,
great, if not, I guess it would help adding one.

"httpAPI" seems to imply that Grail has to be recompiled/relinked for
each additional URN. This would be a huge development problem. Of
course, if Grail is in Java or something similar, then it's a different
thing.

Also, the basic approach seems to be "one specific way of resolving
for each schema", which is probably more appropriate for URLs than
for URNs (where as far as I understand, the idea seems to be to
move avay from specifics of resolution to more general resolution
that may be more flexible to deploy).

> near future; have others dealt with this issue in their

It may be that it's not a problem in the near future, but because
the standards are written the other way round, and there is no
check in the registration procedures as far as I know, there
is a high probability that it will be a problem somewhere sooner
or later.

Regards,   Martin.

#-#-#  Martin J. Du"rst, World Wide Web Consortium
#-#-#  mailto:[email-masked]   http://www.w3.org

---

From: "Fred L. Drake" <[email-masked]>
Date: Mon, 14 Dec 1998 11:19:44 -0500 (EST)

> great, if not, I guess it would help adding one.

  Grail is written in Python, and functions for parsing "typical"
URL-like strings are available in the Python standard library, but any
parsing of scheme-specific data would need to be added.  If the data
is similar to that of ftp: or http:, it would be trivial to handle.
It is always possible to at least pick off the NID using the existing
functions.

 > course, if Grail is in Java or something similar, then it's a different

  Grail is written in Python, so adding modules can be done at
runtime.  For example, if you come across a new scheme, foobar:, you
can go find (or write) a handler, foobarAPI.py, and place the file in
either of two directories (depending on permissions), and then access
foobar: resources.  All without restarting Grail.

 > that may be more flexible to deploy).

  Given a general resolution package, I think it would be easy to
create a resolver for Grail (esp. if people actually use the URN:
prefix).  Perhaps it's time for me to look further into NAPTR and
accessing DNS directly from Python.

 > is a high probability that it will be a problem somewhere sooner

  This is of some concern.  I'll have to think about how to change the 
implementation to deal with the separation better.
  Thank you for your comments!

  -Fred