Subject: [URN] URN Resolution in deployable networks

From: Justin Couch <[email-masked]>
Date: Tue, 08 Dec 1998 16:26:27 +0800

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: John Curran <[email-masked]>
Date: Tue, 08 Dec 1998 08:51:44 -0500

At 04:26 PM 12/08/1998 +0800, Justin Couch wrote:
>scheme.

Hmm...   I have to admit that I disagree with your assessment,
but it's definitely a matter of perspective.

>use a WINS service.

All of the above are "local" system services to handle resolution of tokens...
Just as the DNS spec for host resolution doesn't talk about NIS (but you can 
certain define NIS to perform this resolution function prior to DNS), there
is 
no reason for the URN resolution specification to highlight any local
alternative 
configuration that may specify that certain classes of URN are first locally 
resolved by their very nature.

This isn't a shortcoming in the DNS resolution scheme; it simply means
that URN's have not been around long enough to have people start stitching 
it into their own favorite resolution systems.

/John

---

From: Justin Couch <[email-masked]>
Date: Tue, 08 Dec 1998 21:21:19 +0800

> but it's definitely a matter of perspective.

Cool, that's what I'm looking for. Also, I suppose I didn't really quite
word it well enough. I find no problems with the DNS resolution scheme
(actually I like it a _lot_). Where I am finding general URN
shortcomings is in the client side "API" scheme of deciding how to do
the resolution. For example, like there are a bunch of POSIX calls to
say "get the IP address of machine x.y.z" which then looks at
NIS/DNS/local to do that resolution, there would be a set of "get
resouce urn:a:b:c" which then looks at NIS/DNS/local for resolution.
This is what I'm currently interested in exploring.
 
> there is

Agreed. It's definitely not what I'm after. As I noted above, probably
me phrasing it wrong.

> it into their own favorite resolution systems.

Yup, agreed. I'm one of those coming along looking at the next level of
usage above just one resolver and attempting to find out where to head.
As I understand the nature of this WG, it deals with URN resolution in
general, of which the DNS scheme is the obvious first start. However, it
is also of use for non-DNS schemes, and higher level "requirements" such
as what I am trying to chase down. Is that correct? If not, please point
me in the right direction as I'm still finding my feet here (list
traffic isn't high enough to get a general feel of the types/level of
discussion, even after being subscribed for almost two months).

-- 
Justin Couch
Senior Software Engineer                           VRML-Java Worker
ADI Ltd, Systems Group.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 08 Dec 1998 16:59:10 -0500

If you have a small ad-hoc network, then you could easily have a DNS
server. End of problem. Your DNS server will have to know if the
Internet is available or not.

---

From: Justin Couch <[email-masked]>
Date: Wed, 09 Dec 1998 10:33:20 +0800

> Internet is available or not.

That just doesn't work for a lot of situations. Our networks are
constructed on the fly. A couple of guys sit down in the back of an
aircraft or a shed somewhere, run a capble between the two of them and
then swap stuff. In this case, every machine must have a DNS installed
on it because you never know the topology of the network. Also, this
means you need to go through all sorts of nasty things like simulating
root servers so that you can look up urn.net and many other sysadmin
style tasks. These users will be quicker to put two rounds between your
eyes at 100m than to start a computer, so the system has _real_ simple.
All I need to get right is to work out how to decide how to resolve a
URN in situations where we don't have DNS. DNS is not the solution to
every problem in the world unfortunately.

---

From: Michael Mealling <[email-masked]>
Date: Tue, 8 Dec 1998 23:43:31 -0500 (EST)

> every problem in the world unfortunately.

I have to agree with Justin here. Karen did some work on computing
requirements of disaster situations and came to some of the same
conclusions.

In the absence of anything else I would suggest you take a look at
the WIRE stuff that Lewis Girod came up with that uses HTTP redirect
extensions:
draft-girod-urn-res-using-wire-00.txt
draft-girod-w3-id-res-ext-00.txt

It might not be what you need but it is an alternative to NAPTR
that can work within very tightly constrained networks. You might
also check out Keith Moore's RCDS stuff. Can you provide a link, Keith?

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions	|          www.lp.org          |  [email-masked]

---

From: Justin Couch <[email-masked]>
Date: Wed, 09 Dec 1998 12:22:04 +0800

> also check out Keith Moore's RCDS stuff. Can you provide a link, Keith?

Yes please. Would love to see some of this stuff.

As a summary of everything (I've had a few offline starters too) it
seems that there are a few groups working on these higher level goals
(deciding which resolution service to use for a URN) and alternate
resolving schemes. However, there doesn't seem to be any coordinated
approach at this stage to developing a per-platform solution (eg Unix
setup, win32 setup etc). Generally I feel this is because there is not
enough useage hence everyone is in experimental stages.   Also, no-one
appears to be doing it in Java so it looks as though we're at least on
our own at this stage. 

My current plan of action is to keep talking with various people offline
to see what we can come up with. This work will be done in conjunction
with the VRMLC UMEL group. I'll let you all know how we get on over
time....

-- 
Justin Couch
Senior Software Engineer                          VRML-Java Mystery
ADI Ltd, Systems Group.

---

From: "John C. Mallery" <[email-masked]>
Date: Wed, 9 Dec 1998 20:58:22 -0500

1. Define a priviledged IP address, probably 10.x.x.x as the root URN resolver.
The analogy is to an subnet gateway.

2. Use the revised HTTP resolution extension.

3. Drive on.

---

From: "John C. Mallery" <[email-masked]>
Date: Wed, 9 Dec 1998 20:58:22 -0500

3. Drive on.