# Re: Re Revised URN

Larry Masinter (masinter@parc.xerox.com)
Tue, 17 May 1994 06:00:04 PDT

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Mitra: "Re: Fragments are Client side [Was: URN Requirements ]"
- Previous message: Karen R. Sollins: "Re multiple URNs for same resource"

    To: connolly@hal.com

    In-Reply-To: connolly@hal.com's message of Mon, 16 May 1994 21:35:32 -0700 <94May16.213539pdt.2760@golden.parc.xerox.com>

    Subject: Re: Re Revised URN

    From: Larry Masinter <masinter@parc.xerox.com>

    Message-Id: <94May17.060009pdt.2760@golden.parc.xerox.com>

    Date: 	Tue, 17 May 1994 06:00:04 PDT

> The right problem to attack is "How do we express references, and
> how do we resolve them?" Until I can compose documents that reference
> other documents in such a way that (1) the reference remains meaningful
> despite various inevitable changes in the world, (2) my reader
> can follow the references reliably, we have made no progress.

There are lots of problems and not much progress can be made arguing
what is 'the right problem'. Different people have different problems.
What we're looking for is a solution that will solve lots of problems
all at the same time.

I do think the more general problem you've outlined is a useful
problem to solve.

> For this reason, I think that defining a new namespace separate from the
> existing WWW Address namespace is folly. I see no reason not to
> simply claim a new URL prefix and go with that. Then we just
> update clients to grok things like:
>
> HREF="URN:/hal.com/connolly/draft1"
>
> You could do this today... just
> setenv urn_proxy http://urnserver.host.com/
> and use HTTP's "redirected" stuff for documents that move.

This is a great transition strategy! I'm not sure that it is a
desirable long-term steady state, but certainly it's a good way to
allow

> (or better yet, setenv urn_proxy prospero://prospero.isi.edu ...)

I doubt that the proxy stuff will work for anything other than http.

- Next message: Mitra: "Re: Fragments are Client side [Was: URN Requirements ]"
- Previous message: Karen R. Sollins: "Re multiple URNs for same resource"