[URN] Java URN Framework Impl Available (V0.2)

[Justin Couch <[e-mail]>]

Long promised, finally delivered...

This is the second release of a URN/URI implementation in Java.

The first release was oriented purely around the UMEL requirements and
(I don't think was notified to this list). Now, having undergone an
extensive re-write, it now is a much more general implementation. 

While you're downloading (then read on):

http://www.vlc.com.au/~justin/java/urn/urn_0.2.zip
http://www.vlc.com.au/~justin/java/urn/urn_0.2.tar.Z

ftp://ftp.vlc.com.au/pub/urn_0.2.zip
ftp://ftp.vlc.com.au/pub/urn_0.2.tar.Z

(BTW, this is the _only_ documentation, apart from the javadoc, that
comes with the classes. Don't delete this email!)

As you may have gathered from my questions over the past few weeks, the
implementation today is more interested in being a framework for
gathering multiple RDS implementations and dealing with the associated
high level management problems this generates rather than one particular
implementation. Therefore, using the wonderful :) plug & pray
architecture of the code, you can quickly test different implementations
of the same RDS without recoding your application. It's actually built
so that you can change most of the parameters on the fly within your
code (eg changing system properties without restarting the app) with a
moderate level of optomisation built in. 

The design has been heavily influenced by the java.net.URL class and
general Java coding philosphy. That is, there are many ways to acheive
the same end. For example, adding an RDS can use either a factory
producer, a system property or a default package name. The order for
querying RDSs may be either through a file or a system property. etc
etc. I'm trying to take a holistic view to URN/URL/URI/URC rather than
just trying to bolt bits to the outside of the current java language
stuff. Hence you'll see a new URL class there that replaces the standard
Java one (although currently the method signatures look identical!). At
this stage, I'm only partly holistically implemented.

At this stage, the code is going out, not for application use, but for
concept testing. That is, am I barking up the right tree? Most of the
design decisions have been based on educated guesses as I can't find any
scrawlings on dealing with most of the issues relating to dealing with
multiple RDS's. I intend to write up something about it over the next
week, but haven't yet (blood level getting high in the caffine system).
Also, I feel that its raised some questions that I'll be directing at
specific people.

With the code is a very, very simple resolver for a very small case for
the vrml NID and uses a file based definition of the resolution that can
be done (it doesn't do I2R, only I2L). The idea is that you use this as
a guide to implementing your own. I do intend to implement other
resolvers based on DNS and JINI, but that comes at some time later after
I have the basic framework complete. For example, I haven't started
implementing the ResourceConnection stuff yet.

To run the test code (after the usual classpath setup) try the
following:


java -Durn.resolve.pkgs=org.vrml.umel.net.resolve \
-Durn.resolve.order=file URNTest

which should produce a bunch of ugly text output.


For the mop up: The package will definitely change from its current. I'm
split as to whether I should do something like org.ietf.uri.net or use
one of several different company based packages. 

Licensing - Ha, what's that. If the code works, use it. Ignore anything
in the file. It's a mess and every one says something different. If you
do use it and do some debugging/mods, I'd love to know about it. If you
implement RDS's that you'd like to contribute to the public domain cause
let me know too! Once I get close to a V1.0 there'll be something like
BSD or LGPL put onto it. 

Finally, don't spread this too wide at the moment. It's early days yet.
Many changes, many bugs (I've only half tested most of the code). As
always, happy to answer questions (I'll be here between Christmas and
New Years - no holidays for me this year).


Enjoy!

-- 
Justin Couch
Senior Software Engineer                           VRML-Java Author
ADI Ltd, Systems Group.
[e-mail]                    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
-------------------------------------------------------------------




Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id LAA11667 for urn-ietf-out; Tue, 22 Dec 1998 11:10:10 -0500 (EST)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [209.41.144.2]) by services.bunyip.com (8.8.5/8.8.5) with ESMTP id LAA11662 for <[e-mail]>; Tue, 22 Dec 1998 11:10:08 -0500 (EST)
Received: (from daemon@localhost) by mocha.bunyip.com (8.8.5/8.8.5) id LAA24143 for urn-ietf@services; Tue, 22 Dec 1998 11:10:07 -0500 (EST)
Received: from fire.adisys.com.au ([203.20.100.67]) by mocha.bunyip.com (8.8.5/8.8.5) with ESMTP id LAA24140 for <[e-mail]>; Tue, 22 Dec 1998 11:10:03 -0500 (EST)
Received: (from nobody@localhost) by fire.adisys.com.au (8.8.8/8.7.3) id AAA18866 for <[e-mail]>; Wed, 23 Dec 1998 00:09:40 +0800 (WST)
X-Authentication-Warning: fire.adisys.com.au: nobody set sender to <[e-mail]> using -f
Received: from hawk(193.10.80.9) by fire via smap (V2.0) id xma018862; Wed, 23 Dec 98 00:09:38 +0800
Received: from ccis.adisys.com.au (beardie [193.10.80.73]) by ccis.adisys.com.au (8.8.8/8.8.8) with ESMTP id AAA14355 for <[e-mail]>; Wed, 23 Dec 1998 00:11:34 +0800 (WST)
Message-ID: <[e-mail]>
Date: Tue, 22 Dec 1998 23:13:19 +0800
From: Justin Couch <[e-mail]>
Organization: ADI Ltd Systems Group
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: IETF URN WG <[e-mail]>
Subject: [URN] Java URN Framework Impl Available (V0.2)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
Reply-To: Justin Couch <[e-mail]>
Errors-To: [e-mail]

Long promised, finally delivered...

This is the second release of a URN/URI implementation in Java.

The first release was oriented purely around the UMEL requirements and
(I don't think was notified to this list). Now, having undergone an
extensive re-write, it now is a much more general implementation. 

While you're downloading (then read on):

http://www.vlc.com.au/~justin/java/urn/urn_0.2.zip
http://www.vlc.com.au/~justin/java/urn/urn_0.2.tar.Z

ftp://ftp.vlc.com.au/pub/urn_0.2.zip
ftp://ftp.vlc.com.au/pub/urn_0.2.tar.Z

(BTW, this is the _only_ documentation, apart from the javadoc, that
comes with the classes. Don't delete this email!)

As you may have gathered from my questions over the past few weeks, the
implementation today is more interested in being a framework for
gathering multiple RDS implementations and dealing with the associated
high level management problems this generates rather than one particular
implementation. Therefore, using the wonderful :) plug & pray
architecture of the code, you can quickly test different implementations
of the same RDS without recoding your application. It's actually built
so that you can change most of the parameters on the fly within your
code (eg changing system properties without restarting the app) with a
moderate level of optomisation built in. 

The design has been heavily influenced by the java.net.URL class and
general Java coding philosphy. That is, there are many ways to acheive
the same end. For example, adding an RDS can use either a factory
producer, a system property or a default package name. The order for
querying RDSs may be either through a file or a system property. etc
etc. I'm trying to take a holistic view to URN/URL/URI/URC rather than
just trying to bolt bits to the outside of the current java language
stuff. Hence you'll see a new URL class there that replaces the standard
Java one (although currently the method signatures look identical!). At
this stage, I'm only partly holistically implemented.

At this stage, the code is going out, not for application use, but for
concept testing. That is, am I barking up the right tree? Most of the
design decisions have been based on educated guesses as I can't find any
scrawlings on dealing with most of the issues relating to dealing with
multiple RDS's. I intend to write up something about it over the next
week, but haven't yet (blood level getting high in the caffine system).
Also, I feel that its raised some questions that I'll be directing at
specific people.

With the code is a very, very simple resolver for a very small case for
the vrml NID and uses a file based definition of the resolution that can
be done (it doesn't do I2R, only I2L). The idea is that you use this as
a guide to implementing your own. I do intend to implement other
resolvers based on DNS and JINI, but that comes at some time later after
I have the basic framework complete. For example, I haven't started
implementing the ResourceConnection stuff yet.

To run the test code (after the usual classpath setup) try the
following:


java -Durn.resolve.pkgs=org.vrml.umel.net.resolve \
-Durn.resolve.order=file URNTest

which should produce a bunch of ugly text output.


For the mop up: The package will definitely change from its current. I'm
split as to whether I should do something like org.ietf.uri.net or use
one of several different company based packages. 

Licensing - Ha, what's that. If the code works, use it. Ignore anything
in the file. It's a mess and every one says something different. If you
do use it and do some debugging/mods, I'd love to know about it. If you
implement RDS's that you'd like to contribute to the public domain cause
let me know too! Once I get close to a V1.0 there'll be something like
BSD or LGPL put onto it. 

Finally, don't spread this too wide at the moment. It's early days yet.
Many changes, many bugs (I've only half tested most of the code). As
always, happy to answer questions (I'll be here between Christmas and
New Years - no holidays for me this year).


Enjoy!

-- 
Justin Couch
Senior Software Engineer                           VRML-Java Author
ADI Ltd, Systems Group.
[e-mail]                    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
-------------------------------------------------------------------



Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id LAA26666 for urn-ietf-out; Mon, 21 Dec 1998 11:19:01 -0500 (EST)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [209.41.144.2]) by services.bunyip.com (8.8.5/8.8.5) with ESMTP id LAA26649 for <[e-mail]>; Mon, 21 Dec 1998 11:18:58 -0500 (EST)
Received: (from daemon@localhost) by mocha.bunyip.com (8.8.5/8.8.5) id LAA19269 for urn-ietf@services; Mon, 21 Dec 1998 11:18:58 -0500 (EST)
Received: from ns.datafusion.net (datafusion.net [208.224.117.2]) by mocha.bunyip.com (8.8.5/8.8.5) with ESMTP id LAA19266 for <[e-mail]>; Mon, 21 Dec 1998 11:18:55 -0500 (EST)
Received: from ns.datafusion.net (root@localhost) by ns.datafusion.net (8.7.5/8.7.3) with ESMTP id IAA07734 for <[e-mail]>; Mon, 21 Dec 1998 08:18:55 -0800 (PST)
Received: from datafusionnt1.DATAFUSION.NET (datafusionnt1.datafusion.net [10.1.1.10]) by ns.datafusion.net (8.7.5/8.7.3) with ESMTP id IAA07730 for <[e-mail]>; Mon, 21 Dec 1998 08:18:55 -0800 (PST)
Received: by datafusionnt1 with Internet Mail Service (5.5.1960.3) id <Y0VD9V3P>; Mon, 21 Dec 1998 08:18:56 -0800
Message-ID: <0D611E39F997D0119F9100A0C931315C2E0EAE@datafusionnt1>
From: Ron Daniel <[e-mail]>
To: "'Justin Couch'" <[e-mail]>, IETF URN WG <[e-mail]>
Subject: RE: [URN] Looking for URC specs
Date: Mon, 21 Dec 1998 08:18:55 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
Reply-To: Ron Daniel <[e-mail]>
Errors-To: [e-mail]

There is no URC work in the IETF. The RDF work in the W3C
is the closest thing to it.

Ron

> -----Original Message-----
> From:	Justin Couch [SMTP:[e-mail]]
> Sent:	Friday, December 18, 1998 10:46 PM
> To:	IETF URN WG
> Subject:	[URN] Looking for URC specs
> 
> Can someone please point me in the direction of URC work. I couldn't
> find any docs in the IETF drafts directory nor anything in the RFC
> list. 
> 
> -- 
> Justin Couch
> Senior Software Engineer                           VRML-Java Magic
> ADI Ltd, Systems Group.
> [e-mail]                    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
> -------------------------------------------------------------------



Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id BAA19763 for urn-ietf-out; Mon, 21 Dec 1998 01:31:50 -0500 (EST)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [209.41.144.2]) by services.bunyip.com (8.8.5/8.8.5) with ESMTP id BAA19758 for <[e-mail]>; Mon, 21 Dec 1998 01:31:48 -0500 (EST)
Received: (from daemon@localhost) by mocha.bunyip.com (8.8.5/8.8.5) id BAA18084 for urn-ietf@services; Mon, 21 Dec 1998 01:31:47 -0500 (EST)
Received: from JR (209-239-196-98.oak.jps.net [209.239.196.98]) by mocha.bunyip.com (8.8.5/8.8.5) with SMTP id BAA18081 for <[e-mail]>; Mon, 21 Dec 1998 01:31:43 -0500 (EST)
Date: Mon, 21 Dec 1998 01:31:43 -0500 (EST)
From: JR <[e-mail]>
To: <[e-mail]>
Message-Id: <[e-mail]>
Subject: [URN] advert: adults only: Golf, Gambling and Girls
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
Reply-To: JR <[e-mail]>
Errors-To: [e-mail]

10 day tours to Asia.  First class gambling - better than Vegas.  
World class golf - courses designed by the best Americans.
The girls - the girls are fantastic; warm, friendly, beautiful and eager to meet and date 
you.
For more information, go to http://www.wilson3gtours.com or call 415-951-2465.



Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id AAA19250 for urn-ietf-out; Mon, 21 Dec 1998 00:56:51 -0500 (EST)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [209.41.144.2]) by services.bunyip.com (8.8.5/8.8.5) with ESMTP id AAA19245 for <[e-mail]>; Mon, 21 Dec 1998 00:56:49 -0500 (EST)
Received: (from daemon@localhost) by mocha.bunyip.com (8.8.5/8.8.5) id AAA17930 for urn-ietf@services; Mon, 21 Dec 1998 00:56:48 -0500 (EST)
Received: from JR (209-239-207-98.oak.jps.net [209.239.207.98]) by mocha.bunyip.com (8.8.5/8.8.5) with SMTP id AAA17927 for <[e-mail]>; Mon, 21 Dec 1998 00:56:42 -0500 (EST)
Date: Mon, 21 Dec 1998 00:56:42 -0500 (EST)
From: JR <[e-mail]>
To: <[e-mail]>
Message-Id: <[e-mail]>
Subject: [URN] advert: adults only: Golf, Gambling and Girls
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
Reply-To: JR <[e-mail]>
Errors-To: [e-mail]

10 day tours to Asia.  First class gambling - better than Vegas.  
World class golf - courses designed by the best Americans.
The girls - the girls are fantastic; warm, friendly, beautiful and eager to meet and date 
you.
For more information, go to http://www.wilson3gtours.com or call 415-951-2465.



Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id CAA18848 for urn-ietf-out; Sat, 19 Dec 1998 02:43:33 -0500 (EST)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [209.41.144.2]) by services.bunyip.com (8.8.5/8.8.5) with ESMTP id CAA18843 for <[e-mail]>; Sat, 19 Dec 1998 02:43:30 -0500 (EST)
Received: (from daemon@localhost) by mocha.bunyip.com (8.8.5/8.8.5) id CAA14779 for urn-ietf@services; Sat, 19 Dec 1998 02:43:27 -0500 (EST)
Received: from fire.adisys.com.au ([203.20.100.67]) by mocha.bunyip.com (8.8.5/8.8.5) with ESMTP id CAA14776 for <[e-mail]>; Sat, 19 Dec 1998 02:43:23 -0500 (EST)
Received: (from nobody@localhost) by fire.adisys.com.au (8.8.8/8.7.3) id PAA17260 for <[e-mail]>; Sat, 19 Dec 1998 15:43:06 +0800 (WST)
X-Authentication-Warning: fire.adisys.com.au: nobody set sender to <[e-mail]> using -f
Received: from hawk(193.10.80.9) by fire via smap (V2.0) id xma017256; Sat, 19 Dec 98 15:42:40 +0800
Received: from ccis.adisys.com.au (beardie [193.10.80.73]) by ccis.adisys.com.au (8.8.8/8.8.8) with ESMTP id PAA24010 for <[e-mail]>; Sat, 19 Dec 1998 15:44:33 +0800 (WST)
Message-ID: <[e-mail]>
Date: Sat, 19 Dec 1998 14:46:22 +0800
From: Justin Couch <[e-mail]>
Organization: ADI Ltd Systems Group
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: IETF URN WG <[e-mail]>
Subject: [URN] Looking for URC specs
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
Reply-To: Justin Couch <[e-mail]>
Errors-To: [e-mail]

Can someone please point me in the direction of URC work. I couldn't
find any docs in the IETF drafts directory nor anything in the RFC list. 

-- 
Justin Couch
Senior Software Engineer                           VRML-Java Magic
ADI Ltd, Systems Group.
[e-mail]                    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
-------------------------------------------------------------------



Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id LAA22461 for urn-ietf-out; Mon, 14 Dec 1998 11:20:25 -0500 (EST)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [209.41.144.2]) by services.bunyip.com (8.8.5/8.8.5) with ESMTP id LAA22456 for <[e-mail]>; Mon, 14 Dec 1998 11:20:23 -0500 (EST)
Received: (from daemon@localhost) by mocha.bunyip.com (8.8.5/8.8.5) id LAA02410 for urn-ietf@services; Mon, 14 Dec 1998 11:20:03 -0500 (EST)
Received: from cnri.reston.va.us (ns.CNRI.Reston.VA.US [132.151.1.1]) by mocha.bunyip.com (8.8.5/8.8.5) with ESMTP id LAA02406 for <[e-mail]>; Mon, 14 Dec 1998 11:19:56 -0500 (EST)
Received: from weyr.cnri.reston.va.us (weyr [132.151.1.174]) by cnri.reston.va.us (8.9.1a/8.9.1) with SMTP id LAA05447; Mon, 14 Dec 1998 11:19:35 -0500 (EST)
Received: by weyr.cnri.reston.va.us (SMI-8.6/SMI-SVR4) id LAA24402; Mon, 14 Dec 1998 11:19:44 -0500
From: "Fred L. Drake" <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Mon, 14 Dec 1998 11:19:44 -0500 (EST)
To: "Martin J. Duerst" <[e-mail]>
Cc: IETF URN WG <[e-mail]>
Subject: RE: [URN] URN Resolution in deployable networks
In-Reply-To: <[e-mail]>
References: <0D611E39F997D0119F9100A0C931315C2E0E7E@datafusionnt1> <[e-mail]> <[e-mail]>
X-Mailer: VM 6.53 under 21.0 "Irish Goat" XEmacs Lucid
X-Organization: Corporation for National Research Initiatives
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
Reply-To: "Fred L. Drake" <[e-mail]>
Errors-To: [e-mail]

Martin J. Duerst writes:
 > 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.

  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.

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

  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.

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

  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.

 > 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

  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

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



Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id BAA00224 for urn-ietf-out; Sun, 13 Dec 1998 01:08:55 -0500 (EST)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [209.41.144.2]) by services.bunyip.com (8.8.5/8.8.5) with ESMTP id BAA00219 for <[e-mail]>; Sun, 13 Dec 1998 01:08:53 -0500 (EST)
Received: (from daemon@localhost) by mocha.bunyip.com (8.8.5/8.8.5) id BAA00322 for urn-ietf@services; Sun, 13 Dec 1998 01:08:43 -0500 (EST)
Received: from sh.w3.mag.keio.ac.jp (sh.w3.mag.keio.ac.jp [133.27.194.41]) by mocha.bunyip.com (8.8.5/8.8.5) with ESMTP id BAA00319 for <[e-mail]>; Sun, 13 Dec 1998 01:08:40 -0500 (EST)
Received: from enoshima (ppp0ppp55.sfc.keio.ac.jp [133.27.13.76]) by sh.w3.mag.keio.ac.jp (8.9.0/3.6W-W3C/Keio) with SMTP id PAA14251; Sun, 13 Dec 1998 15:08:31 +0900 (JST)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3-J (32)
Date: Sat, 12 Dec 1998 08:00:43 +0900
To: "Fred L. Drake" <[e-mail]>
From: "Martin J. Duerst" <[e-mail]>
Subject: RE: [URN] URN Resolution in deployable networks
Cc: IETF URN WG <[e-mail]>
In-Reply-To: <[e-mail]>
References: <0D611E39F997D0119F9100A0C931315C2E0E7E@datafusionnt1> <0D611E39F997D0119F9100A0C931315C2E0E7E@datafusionnt1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
Reply-To: "Martin J. Duerst" <[e-mail]>
Errors-To: [e-mail]

At 12:51 98/12/08 -0500, Fred L. Drake wrote:

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

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


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

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:[e-mail]   http://www.w3.org



Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id WAA06545 for urn-ietf-out; Wed, 9 Dec 1998 22:12:07 -0500 (EST)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with ESMTP id WAA06540 for <[e-mail]>; Wed, 9 Dec 1998 22:12:01 -0500 (EST)
Received: (from daemon@localhost) by mocha.bunyip.com (8.8.5/8.8.5) id WAA00250 for urn-ietf@services; Wed, 9 Dec 1998 22:11:53 -0500 (EST)
Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by mocha.bunyip.com (8.8.5/8.8.5) with ESMTP id WAA00247 for <[e-mail]>; Wed, 9 Dec 1998 22:11:41 -0500 (EST)
Received: (from jcma@localhost) by life.ai.mit.edu (8.9.1/AI2.7/ai.master.life:2.2) id WAA06519; Wed, 9 Dec 1998 22:11:41 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a2bb294dacfc096@[208.254.158.205]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 9 Dec 1998 20:58:22 -0500
To: Justin Couch <[e-mail]>
From: "John C. Mallery" <[e-mail]>
Subject: Re: [URN] URN Resolution in deployable networks
Cc: Michael Richardson <[e-mail]>, IETF URN WG <[e-mail]>
Sender: [e-mail]
Precedence: bulk
Reply-To: "John C. Mallery" <[e-mail]>
Errors-To: [e-mail]

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.



Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id VAA05415 for urn-ietf-out; Wed, 9 Dec 1998 21:01:49 -0500 (EST)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with ESMTP id VAA05410 for <[e-mail]>; Wed, 9 Dec 1998 21:01:46 -0500 (EST)
Received: (from daemon@localhost) by mocha.bunyip.com (8.8.5/8.8.5) id VAA00828 for urn-ietf@services; Wed, 9 Dec 1998 21:01:39 -0500 (EST)
Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by mocha.bunyip.com (8.8.5/8.8.5) with ESMTP id VAA00823 for <[e-mail]>; Wed, 9 Dec 1998 21:00:43 -0500 (EST)
Received: (from jcma@localhost) by life.ai.mit.edu (8.9.1/AI2.7/ai.master.life:2.2) id UAA03720; Wed, 9 Dec 1998 20:59:52 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a2bb294dacfc096@[208.254.158.205]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 9 Dec 1998 20:58:22 -0500
To: Justin Couch <[e-mail]>
From: "John C. Mallery" <[e-mail]>
Subject: Re: [URN] URN Resolution in deployable networks
Cc: Michael Richardson <[e-mail]>, IETF URN WG <[e-mail]>
Sender: [e-mail]
Precedence: bulk
Reply-To: "John C. Mallery" <[e-mail]>
Errors-To: [e-mail]

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.



Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id AAA19359 for urn-ietf-out; Wed, 9 Dec 1998 00:19:04 -0500 (EST)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with ESMTP id AAA19354 for <[e-mail]>; Wed, 9 Dec 1998 00:19:01 -0500 (EST)
Received: (from daemon@localhost) by mocha.bunyip.com (8.8.5/8.8.5) id AAA07463 for urn-ietf@services; Wed, 9 Dec 1998 00:18:54 -0500 (EST)
Received: from fire.adisys.com.au ([203.20.100.67]) by mocha.bunyip.com (8.8.5/8.8.5) with ESMTP id AAA07460 for <[e-mail]>; Wed, 9 Dec 1998 00:18:50 -0500 (EST)
Received: (from nobody@localhost) by fire.adisys.com.au (8.8.8/8.7.3) id NAA03182; Wed, 9 Dec 1998 13:18:40 +0800 (WST)
X-Authentication-Warning: fire.adisys.com.au: nobody set sender to <[e-mail]> using -f
Received: from hawk(193.10.80.9) by fire via smap (V2.0) id xma003178; Wed, 9 Dec 98 13:18:24 +0800
Received: from ccis.adisys.com.au (beardie [193.10.80.73]) by ccis.adisys.com.au (8.8.8/8.8.8) with ESMTP id NAA03780; Wed, 9 Dec 1998 13:20:03 +0800 (WST)
Message-ID: <[e-mail]>
Date: Wed, 09 Dec 1998 12:22:04 +0800
From: Justin Couch <[e-mail]>
Organization: ADI Ltd Systems Group
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: [URN] URN Resolution in deployable networks
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
Reply-To: Justin Couch <[e-mail]>
Errors-To: [e-mail]

Michael Mealling wrote:

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

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.
[e-mail]                    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
-------------------------------------------------------------------



Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id XAA18859 for urn-ietf-out; Tue, 8 Dec 1998 23:51:03 -0500 (EST)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with ESMTP id XAA18851 for <[e-mail]>; Tue, 8 Dec 1998 23:50:59 -0500 (EST)
Received: (from daemon@localhost) by mocha.bunyip.com (8.8.5/8.8.5) id XAA07372 for urn-ietf@services; Tue, 8 Dec 1998 23:50:51 -0500 (EST)
Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by mocha.bunyip.com (8.8.5/8.8.5) with ESMTP id XAA07369 for <[e-mail]>; Tue, 8 Dec 1998 23:50:44 -0500 (EST)
Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id XAA24648; Tue, 8 Dec 1998 23:43:31 -0500 (EST)
From: Michael Mealling <[e-mail]>
Message-Id: <[e-mail]>
Subject: Re: [URN] URN Resolution in deployable networks
In-Reply-To: <[e-mail]> from Justin Couch at "Dec 9, 98 10:33:20 am"
To: [e-mail]
Date: Tue, 8 Dec 1998 23:43:31 -0500 (EST)
Cc: [e-mail], [e-mail]
X-Mailer: ELM [version 2.4ME+ PL31H (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
Reply-To: Michael Mealling <[e-mail]>
Errors-To: [e-mail]

Justin Couch said this:
> Michael Richardson wrote:
> >   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.
> 
> 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.
> 

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          |  [e-mail]



Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id WAA18096 for urn-ietf-out; Tue, 8 Dec 1998 22:31:04 -0500 (EST)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with ESMTP id WAA18091 for <[e-mail]>; Tue, 8 Dec 1998 22:31:02 -0500 (EST)
Received: (from daemon@localhost) by mocha.bunyip.com (8.8.5/8.8.5) id WAA07120 for urn-ietf@services; Tue, 8 Dec 1998 22:30:55 -0500 (EST)
Received: from fire.adisys.com.au ([203.20.100.67]) by mocha.bunyip.com (8.8.5/8.8.5) with ESMTP id WAA07117 for <[e-mail]>; Tue, 8 Dec 1998 22:30:51 -0500 (EST)
Received: (from nobody@localhost) by fire.adisys.com.au (8.8.8/8.7.3) id LAA01800; Wed, 9 Dec 1998 11:30:04 +0800 (WST)
X-Authentication-Warning: fire.adisys.com.au: nobody set sender to <[e-mail]> using -f
Received: from hawk(193.10.80.9) by fire via smap (V2.0) id xma001796; Wed, 9 Dec 98 11:29:39 +0800
Received: from ccis.adisys.com.au (beardie [193.10.80.73]) by ccis.adisys.com.au (8.8.8/8.8.8) with ESMTP id LAA25239; Wed, 9 Dec 1998 11:31:19 +0800 (WST)
Message-ID: <[e-mail]>
Date: Wed, 09 Dec 1998 10:33:20 +0800
From: Justin Couch <[e-mail]>
Organization: ADI Ltd Systems Group
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: Michael Richardson <[e-mail]>
CC: IETF URN WG <[e-mail]>
Subject: Re: [URN] URN Resolution in deployable networks
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
Reply-To: Justin Couch <[e-mail]>
Errors-To: [e-mail]

Michael Richardson wrote:

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

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.

-- 
Justin Couch
Senior Software Engineer                           VRML-Java Worker
ADI Ltd, Systems Group.
[e-mail]                    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
-------------------------------------------------------------------



Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id WAA17895 for urn-ietf-out; Tue, 8 Dec 1998 22:09:04 -0500 (EST)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with ESMTP id WAA17890 for <[e-mail]>; Tue, 8 Dec 1998 22:09:01 -0500 (EST)
Received: (from daemon@localhost) by mocha.bunyip.com (8.8.5/8.8.5) id WAA07008 for urn-ietf@services; Tue, 8 Dec 1998 22:08:54 -0500 (EST)
Received: from morden.sandelman.ottawa.on.ca (ietf-177-97.mtg.ietf.org [198.67.177.97]) by mocha.bunyip.com (8.8.5/8.8.5) with ESMTP id WAA07005 for <[e-mail]>; Tue, 8 Dec 1998 22:08:44 -0500 (EST)
Received: from morden.sandelman.ottawa.on.ca (localhost [127.0.0.1]) by morden.sandelman.ottawa.on.ca (8.8.8/8.7.3) with ESMTP id QAA01163; Tue, 8 Dec 1998 16:59:14 -0500 (EST)
Message-Id: <[e-mail]>
To: Justin Couch <[e-mail]>
cc: IETF URN WG <[e-mail]>
Subject: Re: [URN] URN Resolution in deployable networks 
In-reply-to: Your message of "Tue, 08 Dec 1998 16:26:27 +0800." <[e-mail]> 
Date: Tue, 08 Dec 1998 16:59:10 -0500
From: Michael Richardson <[e-mail]>
Sender: [e-mail]
Precedence: bulk
Reply-To: Michael Richardson <[e-mail]>
Errors-To: [e-mail]

  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.



Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id MAA07924 for urn-ietf-out; Tue, 8 Dec 1998 12:51:38 -0500 (EST)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with ESMTP id MAA07919 for <[e-mail]>; Tue, 8 Dec 1998 12:51:35 -0500 (EST)
Received: (from daemon@localhost) by mocha.bunyip.com (8.8.5/8.8.5) id MAA04408 for urn-ietf@services; Tue, 8 Dec 1998 12:51:28 -0500 (EST)
Received: from cnri.reston.va.us (ns.CNRI.Reston.VA.US [132.151.1.1]) by mocha.bunyip.com (8.8.5/8.8.5) with ESMTP id MAA04405 for <[e-mail]>; Tue, 8 Dec 1998 12:51:24 -0500 (EST)
Received: from weyr.cnri.reston.va.us (weyr [132.151.1.174]) by cnri.reston.va.us (8.9.1a/8.9.1) with SMTP id MAA11762 for <[e-mail]>; Tue, 8 Dec 1998 12:51:19 -0500 (EST)
Received: by weyr.cnri.reston.va.us (SMI-8.6/SMI-SVR4) id MAA25303; Tue, 8 Dec 1998 12:51:27 -0500
From: "Fred L. Drake" <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Tue, 8 Dec 1998 12:51:27 -0500 (EST)
To: IETF URN WG <[e-mail]>
Subject: RE: [URN] URN Resolution in deployable networks
In-Reply-To: <0D611E39F997D0119F9100A0C931315C2E0E7E@datafusionnt1>
References: <0D611E39F997D0119F9100A0C931315C2E0E7E@datafusionnt1>
X-Mailer: VM 6.53 under 21.0 "Irish Goat" XEmacs Lucid
X-Organization: Corporation for National Research Initiatives
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
Reply-To: "Fred L. Drake" <[e-mail]>
Errors-To: [e-mail]

Ron Daniel writes:
 > 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.

  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.	     <[e-mail]>
Corporation for National Research Initiatives
1895 Preston White Dr.	    Reston, VA  20191



Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id KAA06099 for urn-ietf-out; Tue, 8 Dec 1998 10:51:18 -0500 (EST)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with ESMTP id KAA06094 for <[e-mail]>; Tue, 8 Dec 1998 10:51:15 -0500 (EST)
Received: (from daemon@localhost) by mocha.bunyip.com (8.8.5/8.8.5) id KAA03828 for urn-ietf@services; Tue, 8 Dec 1998 10:51:08 -0500 (EST)
Received: from ns.datafusion.net (datafusion.net [208.224.117.2]) by mocha.bunyip.com (8.8.5/8.8.5) with ESMTP id KAA03825 for <[e-mail]>; Tue, 8 Dec 1998 10:51:04 -0500 (EST)
Received: from ns.datafusion.net (root@localhost) by ns.datafusion.net (8.7.5/8.7.3) with ESMTP id HAA11346 for <[e-mail]>; Tue, 8 Dec 1998 07:51:10 -0800 (PST)
Received: from datafusionnt1.DATAFUSION.NET (datafusionnt1.datafusion.net [10.1.1.10]) by ns.datafusion.net (8.7.5/8.7.3) with ESMTP id HAA11342 for <[e-mail]>; Tue, 8 Dec 1998 07:51:10 -0800 (PST)
Received: by datafusionnt1 with Internet Mail Service (5.5.1960.3) id <W7YY79QT>; Tue, 8 Dec 1998 07:51:10 -0800
Message-ID: <0D611E39F997D0119F9100A0C931315C2E0E7E@datafusionnt1>
From: Ron Daniel <[e-mail]>
To: "'Justin Couch'" <[e-mail]>, IETF URN WG <[e-mail]>
Subject: RE: [URN] URN Resolution in deployable networks
Date: Tue, 8 Dec 1998 07:51:09 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
Reply-To: Ron Daniel <[e-mail]>
Errors-To: [e-mail]

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 [phone] 
[e-mail]
http://www.datafusion.net

  

> -----Original Message-----
> From:	Justin Couch [SMTP:[e-mail]]
> 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.
> [e-mail]                    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
> -------------------------------------------------------------------



Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id JAA04854 for urn-ietf-out; Tue, 8 Dec 1998 09:18:24 -0500 (EST)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with ESMTP id JAA04849 for <[e-mail]>; Tue, 8 Dec 1998 09:18:21 -0500 (EST)
Received: (from daemon@localhost) by mocha.bunyip.com (8.8.5/8.8.5) id JAA03182 for urn-ietf@services; Tue, 8 Dec 1998 09:18:15 -0500 (EST)
Received: from fire.adisys.com.au ([203.20.100.67]) by mocha.bunyip.com (8.8.5/8.8.5) with ESMTP id JAA03179 for <[e-mail]>; Tue, 8 Dec 1998 09:18:10 -0500 (EST)
Received: (from nobody@localhost) by fire.adisys.com.au (8.8.8/8.7.3) id WAA23209; Tue, 8 Dec 1998 22:18:02 +0800 (WST)
X-Authentication-Warning: fire.adisys.com.au: nobody set sender to <[e-mail]> using -f
Received: from hawk(193.10.80.9) by fire via smap (V2.0) id xma023203; Tue, 8 Dec 98 22:17:38 +0800
Received: from ccis.adisys.com.au (beardie [193.10.80.73]) by ccis.adisys.com.au (8.8.8/8.8.8) with ESMTP id WAA09110; Tue, 8 Dec 1998 22:19:16 +0800 (WST)
Message-ID: <[e-mail]>
Date: Tue, 08 Dec 1998 21:21:19 +0800
From: Justin Couch <[e-mail]>
Organization: ADI Ltd Systems Group
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: John Curran <[e-mail]>
CC: IETF URN WG <[e-mail]>
Subject: Re: [URN] URN Resolution in deployable networks
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
Reply-To: Justin Couch <[e-mail]>
Errors-To: [e-mail]

John Curran wrote:

> Hmm...   I have to admit that I disagree with your assessment,
> 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
> 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.

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

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

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.
[e-mail]                    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
-------------------------------------------------------------------



Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id IAA04609 for urn-ietf-out; Tue, 8 Dec 1998 08:55:16 -0500 (EST)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with ESMTP id IAA04604 for <[e-mail]>; Tue, 8 Dec 1998 08:55:14 -0500 (EST)
Received: (from daemon@localhost) by mocha.bunyip.com (8.8.5/8.8.5) id IAA03012 for urn-ietf@services; Tue, 8 Dec 1998 08:55:07 -0500 (EST)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mocha.bunyip.com (8.8.5/8.8.5) with ESMTP id IAA03009 for <[e-mail]>; Tue, 8 Dec 1998 08:55:04 -0500 (EST)
Received: from cpq3500.ne.mediaone.net (jcurran.ne.mediaone.net [24.128.41.38]) by po1.bbn.com (8.8.6/8.8.6) with SMTP id IAA21061; Tue, 8 Dec 1998 08:54:57 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: jcurran@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 
Date: Tue, 08 Dec 1998 08:51:44 -0500
To: Justin Couch <[e-mail]>
From: John Curran <[e-mail]>
Subject: Re: [URN] URN Resolution in deployable networks
Cc: IETF URN WG <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
Reply-To: John Curran <[e-mail]>
Errors-To: [e-mail]

At 04:26 PM 12/08/1998 +0800, Justin Couch wrote:
>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.

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

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

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



Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id EAA01736 for urn-ietf-out; Tue, 8 Dec 1998 04:23:10 -0500 (EST)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with ESMTP id EAA01731 for <[e-mail]>; Tue, 8 Dec 1998 04:23:07 -0500 (EST)
Received: (from daemon@localhost) by mocha.bunyip.com (8.8.5/8.8.5) id EAA02317 for urn-ietf@services; Tue, 8 Dec 1998 04:23:00 -0500 (EST)
Received: from fire.adisys.com.au ([203.20.100.67]) by mocha.bunyip.com (8.8.5/8.8.5) with ESMTP id EAA02314 for <[e-mail]>; Tue, 8 Dec 1998 04:22:55 -0500 (EST)
Received: (from nobody@localhost) by fire.adisys.com.au (8.8.8/8.7.3) id RAA20352 for <[e-mail]>; Tue, 8 Dec 1998 17:22:50 +0800 (WST)
X-Authentication-Warning: fire.adisys.com.au: nobody set sender to <[e-mail]> using -f
Received: from hawk(193.10.80.9) by fire via smap (V2.0) id xma020348; Tue, 8 Dec 98 17:22:46 +0800
Received: from ccis.adisys.com.au (beardie [193.10.80.73]) by ccis.adisys.com.au (8.8.8/8.8.8) with ESMTP id RAA28226 for <[e-mail]>; Tue, 8 Dec 1998 17:24:25 +0800 (WST)
Message-ID: <[e-mail]>
Date: Tue, 08 Dec 1998 16:26:27 +0800
From: Justin Couch <[e-mail]>
Organization: ADI Ltd Systems Group
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: IETF URN WG <[e-mail]>
Subject: [URN] URN Resolution in deployable networks
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
Reply-To: Justin Couch <[e-mail]>
Errors-To: [e-mail]

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.
[e-mail]                    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
-------------------------------------------------------------------