From: Martin Hamilton <M.T.Hamilton@lut.ac.uk>
Message-Id: <199402261240.MAA16298@lust.mrrl.lut.ac.uk>
Subject: Re: URN to URC scenario
To: peterd@bunyip.com (Peter Deutsch)
Date: Sat, 26 Feb 1994 12:40:47 +0000 (GMT)
In-Reply-To: <9402252354.AA17216@expresso.bunyip.com> from "Peter Deutsch" at Feb 25, 94 06:54:18 pm
Peter D:
$ Looking at the examples, the format seems to eliminate the
$ distinction between naming authority, publisher ID and
$ resource ID that Chris and I postulated in our original
$ proposal. I think there's a problem with that.
I don't think there is necessarily a problem, e.g. if we had URNs
of the form...
urn://naming-authority:publisher/resource-id
these could map to a domain, say
publisher.naming-authority.urn[.int]
Perhaps this also gives us a good way out of the debate on what
attributes URNs should have - let's say the as-yet-hypothetical
urn domain is administered by (say) the IANA, which delegates
naming authorities on a once only basis. So, e.g. nobody can
reuse isbn.urn[.int] :-)
Futhermore, I think it would be handy to have "mutable" URNs (i.e.
long lived, but not permanent, names) can be assigned by anybody,
without having to register as a publisher and/or naming authority.
This sort of URN might look something like this...
urn://domain:foo.bar.com/resource-id
(or simply)
urn://foo.bar.com/resource-id
And resolve to a domain name
foo.bar.com
I'm assuming these domain names are subject to a TXT lookup in
the DNS, which leads to URLs for the publisher's URN->???
server(s).
Finally, I guess I should say that these are meant to be minimal
URNs, without any versioning or language info!
Would that be acceptable?
Martin