Message-Id: <9402252354.AA17216@expresso.bunyip.com>
From: Peter Deutsch <peterd@bunyip.com>
Date: Fri, 25 Feb 1994 18:54:18 -0500
In-Reply-To: Larry Masinter's message as of Feb 25, 11:42
To: Larry Masinter <masinter@parc.xerox.com>, uri@bunyip.com
Subject: Re: URN to URC scenario
Hi Larry,
[ You wrote: ]
> > If we separate out architecture from implementation,
. . .
> The proposal that urns use DNS is an implementation proposal, and I
> was speaking to that. The only architectural concern I have is that
> if you use organization NAMES in URNs you run some risk that someone
> else later will want the same name.
But isn't that the point of having naming authorities?
It's not about whether we use names, numbers of five bit
Baudot codes, but who has authority for issuing the bits.
It seems to me that _someone_ must undertake the task of
registry, or duplication will result.
Now, we may end up having specific naming authorities
which do allow duplication (MD5 checksums come to mind)
and this potential duplication becomes part of the
tradeoff that we've accepted to get other features we want
(in the case of MD5, we can reverse implement onto every
anonFTP archive and Gopher site tomorrow at basically zero
cost, which is a big win) but in general I think it is a
bottom line requirement that whatever we use, it permit
multiple naming authority schemes to be practical.
> Here are some examples that I think fit within the proposal and
> might be workable:
> internet/rfcs/1024 For RFCs, I think this will work.
> prentice-hall/books/2014 For a publisher
> xerox/parc/reports/p931204 For a tech report from an organization
>From what I've read (and looking at your examples), the
proposal to use DNS seems to be aimed at simplifying the
task of locating appropriate URN servers (assuming one
exists), which I agree is an important requirement but
only one of the things we need to do here.
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.
Is there an implied "Larry's scheme:" prefix for each of
these examples or do you in fact feel that the distinction
between naming authority and named object is not needed?
To me the resource discovery step, although important, is
only one of the tasks we have before us and it is clear
that DNS is only one of the mechanisms through which
people will be finding servers (and an imperfect one at
that).
I can live without a specific publisher ID, if in fact one
is subsumed into the otherwise opaque string (as is done
in ISBN, for example) or is inappropriate (as in MD5
checksums) but I would have trouble with any scheme which
doesn't allow us to readily identify the type of naming
going on so we can figure out what's possible and what's
not and so we can make changes later if we want. it's not
clear from your examples that this is allowed for in the
current DNS-based proposals. Instead, there seems to be an
assumption that using DNS for resource discovery means
folding DNS into the entire URN naming scheme, as well,
with all its attendant problems.
> but I'm not so sure about organization names that are abbreviations
> or are likely to be reused:
. . .
> A scheme where URNs use organization NUMBERS rather than NAMES might
> avoid the problem of registered business names, trademarks, etc. This
> is the tack taken for the ISO public identifiers, is used in ISBN
> numbers (although in a way that doesn't scale) and it has some other
> definite advantages.... you're less likely to get bogus URNs if the
> hierarchy is numeric. . . .
I'm not sure I see why. Besides, if we have a
readability/transcribability requirement (they're baaaccckkk! :-)
then it might be argued that numbers aren't as readable as
character strings.
> . . . It would definitely be the case that you
> couldn't just `start using' a URN top-level name without registering
> it with IANA (in order to get a number assigned) but I think that has
> some real appeal.
As I've indicated before, I think we're going to have
schemes which require the acquisition of a right to a
string, and we're going to have schemes which do not. For
those that require it, it will be an administrative
requirement that _somebody_ hands these things out.
> If we accept a hierarchical syntax xxx/yyy/zzz/name for URNs, I can
> still see the following proposals:
>
> a) URNs can be alphabetic at any level (current proposal)
> b) (a) with the constraint that no `abbreviations' are allowed
> c) the top level of the URN hierarchy is numeric, with numbers
> assigned by IANA
I'm not comfortable with such a requirement. One person's
abbreviation is another person's name. I think the
registrar for the scheme should be involved in such
decisions, not the URN architects.
> d) URNs are numeric except for the leaf level. Each level of the
> hierarchy must run its own IANA-equivalent for assigning
> numbers to sub-naming authorities.
> e) URNs are completely numeric (like ISO public identifiers)
Eeew, I don't like numerical-only schemes. I beleive URNs
need to be at least somewhat user-friendly and numbers are
not as friendly as alphanumeric strings.
>
> I'm personally leaning toward (d). Other opinions?
See above... :-)
- peterd
--
---------------------------------------------------------------------------
"The future belongs to neither the conduit or content players, but
those who control the filtering, searching and sense-making tools
we will rely on to navigate through the expanses of cyberspace."
- Paul Saffo, (_Wired_: March,1994)
---------------------------------------------------------------------------