# Re: URN Proposals: What they have in common

Dirk.vanGulik (Dirk.vanGulik@jrc.it)
Mon, 17 Jul 1995 22:59:48 +0200

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Roy Fielding: "Re: I-D: How Roy would Implement URNs and URCs Today"
- Previous message: Roy Fielding: "Re: How paf is implementing URNs and URCs today"
- Maybe in reply to: Michael Mealling: "URN Proposals: What they have in common"

    Date: Mon, 17 Jul 1995 22:59:48 +0200

    From: "Dirk.vanGulik" <Dirk.vanGulik@jrc.it>

    Message-Id: <9507172059.AA25847@ jrc.it>

    To: uri@bunyip.com, Michael.Mealling@oit.gatech.edu

    Subject: Re: URN Proposals: What they have in common

Summary of a long email following:

URNs are nearly there. But what is needed is a good
excuse for a real live application which solves
some of the worlds problems tomorrow. IMHO they
are most needed in cataloguing indexing etc.
-
Then they make only sense as a key/handle
for meta data thus lets focus on that and show
the world one or two working examples.
-
So give me a URN def... and I give you
a resolver and an example where URNs
get resolved into meta data, among which
is possible a URL or one or more URI's if
it applies to the resource you tried to
resolve.
-
As a side effect, you will have a more effective
Aliweb type of search engine as well.
-
Sorry if anything of this sounds overly
pedantic, but I lack the subtly in this language.

-- long version:

> From owner-uri@bunyip.com Mon Jul 17 19:03:12 1995
> From: Michael.Mealling@oit.gatech.edu (Michael Mealling)
> Subject: URN Proposals: What they have in common

With a lot of cutting and pasting, Michael Mealling,
once wrote:

> I was pleasantly suprised at how similar they are. Here is a brief
> synopsis of basically what every has already said:
I very much agree ! Thanks for making this point, it might just
help to focus.

> I believe that if we all were to "give up" a little we could fold about
> 4 of the proposals together (that is all except the handle proposal).

Isofar as what a URN should look like, I could not agree more; and really
it does not matter all that much because most schemes can be extended
or evolved into something like 'better practice' anyway. (like
DNS names which now tend to have sensible aliases like dns.site
,www.institute.site.... or relay.site etc..)

What does need to be sorted out is *what* URNs are. The charter is, and
cannot be that helpfull. Neither should it IMHO. In RFC 1737 point 2 for
example, it is specified that it should be global, unique, scalable...

And that is good. That really is the major concerns to get URNs right,
and it prevents people like me from taking shortcuts when we apply them
to some application where we need something like it, but not need quite all
that.

But if the world wants to see real live applications, or if some exsisting
development is to show that it uses URN's, then there needs to be a drive.
This drive can only come from what a URN really is, i.e. what you do with it.

I think there are only two or three 'meanings' or 'uses' of a URN which
have enough 'market push' behind them to make them happen:

-o As a simple direct, unique, etc, mapping/pointer of a fairly
low level resource, say a site, a document, a mailserver. Such
just fullfills exactly the points of the RFC 1737 and stops just there.

-o As a fancy URL, giving some extra information on something which
has esentially already a single URL, but might have some several
versions and is mainly to enhance our searching. With a little
meddling one could squeeze it into some header format as well.

-o As a 'handle' to a collection of metadata concerning one or
more resources which can be obtained at will; one of the bits
of metadata might be a URL or some URI's.

The first use is just there because it is simple to implement, might help
a little when resources move etc, but I do not see much of a market
push at all and I cannot easily see a quick working example which
is more than a proof of principle.

The second and third point are different; the do coincide with a
marked need for having means to handle meta data on resources; to
catalogue, manage, index, cache and heaven knows what more. It might
be good to realize that this need is there on a very low, almost
hardware level; i.e. to find a 'resource' in the sense of a printer,
up to say finding documents, articles, software, right up to finding
meta services, organizations and other 'entities' which have a more
organizational ring to it.

Of course, this second point really could live with the HTML working
group, or in the Mime area, service location area (low level) and
other info/metadata concerned groups and URNs could play no part of
it and in fact all this, or at least a lot of meta/library information
stuff has no place in the URN area.

Likewise, point one could be moved down to service location on
a really mundane level. (like in draft-ietf-srvloc-protocol-6)

However a prime area of use for giving resources a unique identifier
is for cataloging, tracking and indexing... and for all that
I would like to stress that IMHO the URN is only a facilitating
unique number most of the time; for which things like scalability
and global uniqueness are not required all the time by most
implementors; it just gives you some ease of mind if you
bother to comply during the implementation phase and possibly
keeps some hot breath out of your neck.

I would like stress again that the actual URN definition does not
really matter for this kind of use; often anything unique will
do quite nicely in the acutal implementation.

If there would be a good way of 'resolving' a URN into its'
meta data; with content negotiation if you only want to
have a URL, and the meta data could, certainly in the
early phase, be as loose as say the Aliweb set or the
things you see in the header of a mail msg or news msg,
then I think we will see some examples to play with really
fast.

If on top of that there would be an http version of the resolver
whihc defaults to http forwarding (status 302 kinda)
resolving; a demonstration can be set up in a very usefull
way allowing searches to yeild a urn and showing that a
click on the urn actually brings you to the right location.

If nessesarry ther is an example of a search engine which
yields URN's as result pointers, rather than URLs.

The 'fake' URN is, http://urn.jrc.it:4500/search-engine.41883.urn
or if that one is down http://elect6.jrc.it:4500/search-engine.41883.urn
which both 'forward' you in a hidden way to a page on http://ewse.jrc.it/
and http://elect6:1080/. The search result pages again point you
out to 4500 and the demon there resolves and forwards you somewhere
else. On some browsers you can see this happening at the status line.

Hope this helps.

Dirk-Willem van Gulik

- Next message: Roy Fielding: "Re: I-D: How Roy would Implement URNs and URCs Today"
- Previous message: Roy Fielding: "Re: How paf is implementing URNs and URCs today"
- Maybe in reply to: Michael Mealling: "URN Proposals: What they have in common"