Message-Id: <9405170050.AA03109@ulua.hal.com>
To: mitra@pandora.sf.ca.us (Mitra)
Subject: Re: Re Revised URN
In-Reply-To: Your message of "Mon, 16 May 1994 22:14:19 GMT."
<Cpx1rw.JCw@pandora.sf.ca.us>
Date: Mon, 16 May 1994 19:50:25 -0500
From: "Daniel W. Connolly" <connolly@hal.com>
In message <Cpx1rw.JCw@pandora.sf.ca.us>, Mitra writes:
>
>Do you mean that hte requirement should be dropped, or that it should be
>kept with a caveat that it might not be correct.
>
>In particular, I would like it asserted that the correct situation is
>that a resource has one, and only one, URN, but that applications should
>acknowledge that in the real word, incorrect situations can occur.
Given that assertion, what's a "incorrect situation"? One where the
two names resolve to "the same thing"? There are situations where
this is perfectly reasonable: One author may publish a URN for
"my current favorite article" and another may publish a URN
for "July 15th's Mr. Fun", and the two URNs may resolve to the
same cartoon.
For the record: I think that the "URN->URL mapping problem" is
not the right problem. Once you've got a URL, you still have to go get
the "resource." And you've got security, scalability, and reliability
issues to deal with there.
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.
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.
(or better yet, setenv urn_proxy prospero://prospero.isi.edu ...)
Anyway, back to the relationship between names and resources...
I'd be happy with either of the two assertions:
* Two resources are by definition the same if and only if they
have the same URN.
* Two resources are the same if (but not only if) they
consist of the same octet-stream and content-type.
Given the first assertion, you may have two different names that resolve
to the same bytes/events/intellectual-content/whatever, but there
is nothing "incorrect" about this; it's a case of two resources that
have this one property in common, but they may have other properties
that differ (for example, they may have different maintainers, different
prices, or they may reference different bytestreams next month...)
Given the second assertion, you may have two different names for
the same resource. It's a different use of the terminolgy, really.
Still: I don't see how we define any situations as "incorrect."
What I see as essential is:
* We define a Well-Defined Reference to be enough
information to uniquely determine an octet-stream.
* Given a name scheme:string, the scheme shall determine
whether the string is a well-defined reference, and if not,
it shall specify what parameters are necessary to make
a well-defined reference from the string.
For example, the name:
ftp://foo.com/dir/file
is not a well-defined reference. That file may contain different
octet-streams at different times. But the spcification for the ftp:
scheme would say that if you had a particular time in mind, that
would complete the reference. So you could ask the system to resolve
ftp://foo.com/dir/file;as-of="199495961234Z"
Then we can certainly say what "correct" behaviour is, and we can
instigate techniques to detect faults.
We would also want to be able to express references like "give me
the contents of ftp://ds.internic.net/rfc/rfc822.txt at any time"
because we know that it doesn't change. References like "give me
http://foo.com/dir/file in any format" are not well-defined by
the above definition, and so it will be difficult to instigate
fault-detection mechanisms. In this case, the client would have
no choice but to trust the server.
But there are authentication mechanisms that could fill the gap,
such as "give me http://foo.com/dir/file in any format, as long
as fred@foo.com PGP-signed it."
Anyway... for a more organized version of my thoughts, please see:
file:/u/connolly/develop/web/drafts/formalism.html
$Id: formalism.html,v 1.1 1994/04/25 17:48:29 connolly Exp $
Dan