Subject: questions about URNs, URN-Net etc.

From: Michael Derr <[email-masked]>
Date: Tue, 13 Jun 2000 11:40:31 +0200

Dear IETF-URN WG,

I am contacting you to ask for your comments about some general as well
as specific questions on URNs. I am working on the possibility of
URN-implementations and applications for scientific electronic
resources.
In my opinion some problems are not completely clear. Because of
your experience with the development process of URNs I would like to
ask you specifically:

- is the URN-Net a proposal for a global resolution system and a
service for the future or do there already exist realizations of this
URN-NET-system?

  If the URN-Net is a proposal, what do you think about the possibility
  of realizing such a project and what might be the reasons in possibly
  preventing the development of an URN-Net?

  What is the present technological infrastructure or method of
  retrieving a resource using URNs?

- as far as I know some institutions build up their own resolution
system (because of lack of a global resolution system). Nevertheless
these
institutions have  intentions to register their namespace:
Why is it important to do that right now - for a URN-NET in the
future?

  How many registered namespaces are in use today? And finally who is
  (will) going to manage and maintain the URN-NET and the registration
  service for <NIDs> (IETF/IANA)?

- there seem to be two alternatives to let the browser know how to
handle  a "urn:<foo>": solution via plug-in and second solution via
proxy
server.

  Do you have any experience with these two alternatives and what is
  probably the current best solution? Are there any other
  possibilities?

  Is there an actual development for the next browser generation which
  enable to handle the new protocol "urn:"?
  I have tested the prototype browser  AMAYA (developed by W3C) for
  this purpose. AMAYA does not support the URN-protocol.

I'm interested in any feedback.

best regards

 Michael

---

From: Alexei Novikov <[email-masked]>
Date: Tue, 13 Jun 2000 14:20:06 +0400

> URN-implementations and applications for scientific electronic
Hi Michael,
Are you going to implement something like urn:hep-ph:0006103 for
arXive.org data ?

>   probably the current best solution? Are there any other

Squid Web caching server can do URN resolution using requests to the
external N2L program (actually was able as its URN support is messed
right now). Probably this can be a best solution at least for the
European research community as it is already using caches.

        Alexei.

---

From: Michael Mealling <[email-masked]>
Date: Tue, 13 Jun 2000 07:26:19 -0400

> service for the future or do there already exist realizations of this

It exists but is currenlty in flux as it is suposed to 'start from
scratch' as soon as the URN namespace registration process was
setup. That was done a few months ago and so the URN.NET stuff
is being re-setup under aegis of the IANA. NOTE: its also being
moved to the urn.arpa domain instead of urn.net...

>   preventing the development of an URN-Net?

As we are in the midst of a re-deployment these are good questions.
The DNS servers are available and working. One of the largest
hurdles is making sure that browsers can handle the URN URI scheme.
I have some plugins (see wwww.usrlocalsrc.org) but they're for
IE only right now (and require intimate knowledge of VC++ to build).
Any version of Netscape lower than Netscape 6 on Unix cannot
use protocol plugins so that is one hurdle....

>   retrieving a resource using URNs?

At present the URI resolution via DNS (urn.arpa) stuff is the
only mechanism we have....

> Why is it important to do that right now - for a URN-NET in the

I suppose its only important to do that now if your URNs will
make it outside your institution. That way if others see them they
can find out what they are....

>   service for <NIDs> (IETF/IANA)?

At present there is only 1 registered one. The reason is that the
namespace registration process has only been setup for a few months.
I personally have two in the middle of the process and I know of
one more that is also in that process. Others are still figuring out
how to design their namespace...

The entity tha twill manage the urn-net service and registration
process is the IANA....

> proxy server.

The current best solution is a plugin. We are currently
writing one which is under an Apache style open source license.
The proxy option is 'ok' but not stellar in my opinion because it
does not give the client any knowledge about the URN that it can use.

>   this purpose. AMAYA does not support the URN-protocol.

Nope. If you could see my desktop you would see the libwww code that
I'm currently hacking to make that happen. As soon as I have
a skeleton I will see about checking that code in so others can
help develop it. One of the largest hurdles is figuring out how to
do the NAPTR DNS record requests in a cross platform manner.
I think I have a solution but it'll be a few weeks before I can
surface any real code....

> I'm interested in any feedback.

Great. This was a good way to get a development status out to the
community. I really hope we can get some open source style development
going on. Especially in the area of browser support....

-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: Yves Arrouye <[email-masked]>
Date: Tue, 13 Jun 2000 21:03:32 -0700

> European research community as it is already using caches.

I should also be able to dig up a C library doing URN resolution and a patch
for Apache's proxy that will do that. The code was written in 1998 though,
so it may not run as is. E-mail me if you are interested.

YA

---

From: Martin Hamilton <[email-masked]>
Date: Wed, 14 Jun 2000 12:16:08 +0100

-----BEGIN PGP SIGNED MESSAGE-----

Content-Type: text/plain; charset=us-ascii

Michael Mealling writes:

| Any version of Netscape lower than Netscape 6 on Unix cannot
| use protocol plugins so that is one hurdle....

Hi folks.  Just to be clear on this - if the browser is fetching a
proxy autoconfig script, it is possible to supply it with the name and
port number of a machine to speak proxy HTTP to for URN resolution,
e.g. something like this should do the trick

  function FindProxyForURL(url, host)
  {

     ... other stuff

     if(url.substring(0,4) == "urn:")
       return "PROXY 1.2.3.4:5678";

     ... other stuff

  }

This is trying to say "URLs prefixed with 'urn:' should be requested
via proxy HTTP through the server at IP address 1.2.3.4 and port 5678.
Note that you have to make this accessible with the MIME content type
application/x-ns-proxy-autoconfig.  You can use a domain name rather
than an IP address, but Netscape stupidly tries to look it up for
every URL requested.  Doh!

Works with the Netscape 4.x family, but doesn't appear to with IE -
though I haven't tried 5.5 :-)  Could just be differences in their
JavaScript/autoconfig support of course...

| The current best solution is a plugin. We are currently writing one
| which is under an Apache style open source license.  The proxy option
| is 'ok' but not stellar in my opinion because it does not give the
| client any knowledge about the URN that it can use.

I wouldn't write the proxy approach off altogether - e.g. as Alexei
says proxies are heavily used in Europe.  The proxy cache service I
help to run has recently been shipping some 80m URLs/day (or around
800GB of content), with peak rates of ~155Mbit/s.  We have usage based
charging to thank for its success!

Admittedly, ISPs tend to use transparent proxying, to avoid having to
get browser configs right.  In academia explicit configuration is
pretty common, and you gotta start somewhere...  The proxy doesn't
need to be a Squid server (proxy cache with a bit of built-in URN
support), of course.

Cheers,

Martin

---

From: Martin Hamilton <[email-masked]>
Date: Wed, 14 Jun 2000 16:16:46 +0100

-----BEGIN PGP SIGNED MESSAGE-----

Michael Mealling writes:

| Yep. This is their standard behavior. The code was basically:
| if the protocol is urn: then use the general HTTP proxy. The URN
| handler code was all of about 15 lines long....

BTW one to watch out for (with Netscape) is that if you have a
manually configured proxy for HTTP URLs, stuff with the "urn:" prefix
will be passed to it.  But... if you autoconfigure, your autoconfig
script has to actually include a case to deal with URNs or they'll be
dropped on the floor.

This does lead to the interesting possibility that some well meaning
parties could set up testbed public URN resolvers.  The people who are
writing the proxy-autoconfig scripts (my counterparts elsewhere) would
in turn simply have to add a couple of extra lines to their configs,
and lo - all their Netscape users are URN enabled.  If/when URNs
really take off, a more scaleable approach would be necessitated, but
in the meantime...  (classic Internet design philosophy alert :-)

| BTW, now that we're talking about development stuff: since we're
| moving the urn.net stuff to urn.arpa, I have this urn.net domain
| just hanging around. I could possibly turn it into a little
| promo and development site...

IMHO it would be handy to have a place with links to the specs,
registrations, and whatever software is out there.

Cheers,

Martin

---

From: Michael Mealling <[email-masked]>
Date: Wed, 14 Jun 2000 11:16:40 -0400

> script has to actually include a case to deal with URNs or they'll be

But its still the same proxy? I.e. can I, using autoconfigure,
set a URN proxy to be one host and the HTTP proxy to be another host?

> in the meantime...  (classic Internet design philosophy alert :-)

hehe... We actually had one once. I doubt it I could find the code.
I'm sure the cache stuff in Apache has gotten to the point where
it might be an easy hack...

> registrations, and whatever software is out there.

I'll check and see what I have to do to get it setup...

- MM

---

From: Michael Richardson <[email-masked]>
Date: Wed, 14 Jun 2000 12:01:54 -0400

>>>>> "Martin" == Martin Hamilton <[email-masked]> writes:
    Martin> I wouldn't write the proxy approach off altogether - e.g. as
    Martin> Alexei says proxies are heavily used in Europe.  The proxy cache
    Martin> service I help to run has recently been shipping some 80m
    Martin> URLs/day (or around 800GB of content), with peak rates of
    Martin> ~155Mbit/s.  We have usage based charging to thank for its
    Martin> success!

  The various notes about Squid as a URN resolver on the squid forums seem to
peter out with the realization that the best one could do is to redirect
the client to an actual resource, (meaning they'll bookmark that page)...

  Or has this situation improved?

  My interest is in using the URN:IETF's on all our internal references and
have our local corporate proxy return documents from our private RFC
archive.
  It seems to me that what is required is that cache's that don't know
where to find a local copy of a URN should in fact pass the URN to the
next layer cache.

   :!mcr!:            |  Solidum Systems Corporation, http://www.solidum.com
   Michael Richardson |For a better connected world,where data flows faster<tm>
 Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html
        mailto:[email-masked]       mailto:[email-masked]

---

From: Michael Mealling <[email-masked]>
Date: Wed, 14 Jun 2000 12:04:49 -0400

>   Or has this situation improved?

It depends. If your cache actually returns the object then the
client actually bookmarks the URN instead of the redirected URL.
If you rely completely on 301 and 302 redirects to a URL that
the cache holds then yes, your still stuck with that case.

What I would like to see is a 303 HTTP code where the cache can
return multiple locations to the client. That way the client can
cache the fact that it knows that the URN resolves to more than one
URL. Then the cache can order the list based on what it already has
in its cache....

> where to find a local copy of a URN should in fact pass the URN to the

Yep. Which is simply staged caching (which has potential problems if
done incorrectly). The best thing is to realize that the URN specs
say it is perfectly resonable to ask a local cache (which isn't
authoritative, just local) first and then ask the resolution service.
In that case your local cache would be configured to look in its
local URN:IETF repository and return that. Hmm... that would require
something in the cacheing mechanism to be able to communicate that
the item(s) returned weren't authoritative...

-MM

---

From: Justin Couch <[email-masked]>
Date: Thu, 15 Jun 2000 08:47:27 +0800

> it might be an easy hack...

The apache source tree still has the urn.cgi code there. I compiled
1.3.12 at home on the weekend and it was part of the download bundle.

--
Justin Couch                                   Author, Java Hacker
Software Architect                                [email-masked]
rbuzz.net                           http://www.vlc.com.au/~justin/
Java3D FAQ                                 http://www.j3d.org/faq/
-------------------------------------------------------------------
"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?"      -Subcomandante Marcos
-------------------------------------------------------------------

---

From: Justin Couch <[email-masked]>
Date: Thu, 15 Jun 2000 08:49:19 +0800

> where to find a local copy of a URN should in fact pass the URN to the

And hence you have a classic URN resolution system that uses multiple
resolvers. If the cache can't find it, tell the client and then the
client goes to the next resolver and asks it (eg direct to DNS).

---

From: Michael Mealling <[email-masked]>
Date: Wed, 14 Jun 2000 07:52:27 -0400

> JavaScript/autoconfig support of course...

Yep. This is their standard behavior. The code was basically:
if the protocol is urn: then use the general HTTP proxy. The URN
handler code was all of about 15 lines long....

> need to be a Squid server (proxy cache with a bit of built-in URN

Sure. My uber preferred solution is something where the cache and
client know its a URN and both end up cacheing appropriate parts
of the information.

BTW, now that we're talking about development stuff: since we're
moving the urn.net stuff to urn.arpa, I have this urn.net domain
just hanging around. I could possibly turn it into a little
promo and development site...

-MM

---

From: Martin Hamilton <[email-masked]>
Date: Thu, 15 Jun 2000 10:19:00 +0100

Michael Mealling writes:

| But its still the same proxy? I.e. can I, using autoconfigure,
| set a URN proxy to be one host and the HTTP proxy to be another host?

Hi!  Yep, that's the advantage of proxy autoconfiguration - the URN
(proxy) resolver can be running on any port of any machine on the
Internet, just so long as it speaks HTTP.  Which leads us to... :-)

FWIW the resolver simply has to be able to deal with HTTP requests
received from the browser which look like this:

  GET urn:nid:nss HTTP/1.0

If it wanted to, it could return a temporary or permanent HTTP
redirect, a page of HTML, whatever...

Cheers,

Martin

---

From: Justin Couch <[email-masked]>
Date: Thu, 15 Jun 2000 17:52:24 +0800

> received from the browser which look like this:

Strictly speaking that is not correct as the GET needs to tell it "how"
to resolve it. That is, does it resolve N2L, N2Ls, N2R etc etc. This is
of course the THTTP spec for which there is an existing RFC (can't
remember the number off-hand).

---

From: Martin Hamilton <[email-masked]>
Date: Thu, 15 Jun 2000 12:15:12 +0100

Justin Couch writes:

| Strictly speaking that is not correct as the GET needs to tell it "how"
| to resolve it. That is, does it resolve N2L, N2Ls, N2R etc etc. This is
| of course the THTTP spec for which there is an existing RFC (can't
| remember the number off-hand).

Hi!  That's true if we're talking N2L &c, but bear in mind that we're
working at the browser level here.  If you type "urn:foo:bar" into
Netscape (with a proxy configured for "urn:"), it'll go off and send a
"GET urn:foo:bar HTTP/1.0" to the proxy.  That's all it knows how to.

What the proxy returns is it's own business, but HTML would probably
not be a bad idea... :-)

Cheers,

Martin