Message-Id: <9404291920.AA13100@expresso.bunyip.com>
From: Peter Deutsch <peterd@bunyip.com>
Date: Fri, 29 Apr 1994 15:20:33 -0400
In-Reply-To: Tim Berners-Lee's message as of Apr 28, 9:58
To: timbl@www0.cern.ch, mitra@pandora.sf.ca.us (Mitra)
Subject: Re: URN syntax
Hi all,
[ Tim wrote: ]
> > Just for the record - as one of the people who proposed that the URN
> > format should be hierarchical with NO seperation between
> > publisher/naming authority and opaque string, I have been convinced by
> > PeterD of the error-of-my-ways, and now think only that the
> > publisher-i/naming-authority field should be hierarchical, so formats
> > along the lines of.
>
> What was Peter's argument? Maybe he can convince me too.
I'll try to be brief ("Yeah, Right!" I hear you cry... ;-)
Actually, I'm not arguing that an ID should not be
hierarchial. Rather, I'm arguing that it should be
separated from the naming authority and defined as an
opaque string at this level. Once assigned by an
authority, it can in fact be hierarchial, but the outside
world need not know anything about this hierarchy and I
think it preferable that it does not.
The argument for separating them out is basically that I
believe we would then have much greater flexibility in
defining the two parts. This will allow us to tune the
specifications for each to best perform the various tasks
we're facing here.
Now, the main tasks I see facing us with the naming
authority part are to allow distributing the assignment of
authority and to permit rapid and effective resolution
from URN->URL (and URN->URC). The purpose of the ID
portion is to allow rapid searching and dereference of the
ID and to allow us to easily maintain multiple registries
of IDs for multiple publishers using a single naming
authority (and perhaps even in some case supporting
authorities that have no specific publishers associated
with them, as will be the case, for example, when
retrofitting MD5 checksums to ftp).
Now, DNS seems to serve us well here for distributing
authority (that is its basic model) and seems to offer a
fairly effective resolution strategy, as well. Thus, I
endorse Mitra's proposal of using DNS-like structure (and
by implication, DNS) for the naming portion of the URN
(although when we get down to specific syntax, I argue
that "flipping" the address around is a "Bad Idea (tm)"
and we should make them straight-forward DNS-like entries
to ease user pain and improve their chances of adoption).
As an aside, it might also make it easier for the naive
user to guess at a particular URN, something I do
regularly with URLs now with some success. This topic was
discussed a while ago on the list and I'm sure will come
up again once we agree on the architectural issues and get
around to deployment issues.
Returning to the issue of opaque IDs, if the ID is opaque
one group can then opt to make them WAIS docIDs, another to
make them WHOIS++ queries, and another to make them simply
sequentially assigned sequences of digits. Nobody has to
decide in advance, and nobody has to negotiate with anyone
else for feature or syntax changes that might conflict
with someone else's existing requirements. Note that this
is a _separate_ issue from choosing the appropriate query
protocol. In our system today we send out what seems to be
gopher selectors for catalogue entries, which are in fact
used internally as WAIS docIDs, since that's the internal
search engine. Sincve Gopher is supposed to treat the
selectors as opaque strings we're the only people who have
to know about this and I'd like to keep it that way for
URNs, as well.
The bottom line is that I don't want to do anything that
limits flexibility here and I don't want to set ourselves
up for a repeat of the "/ and ?" argument we had over
URLs. Tim, you had a legitimate concern about breaking
established code but it seems to me that Mark was right to
say that we'd agreed on opacity to allow flexibility and
it made _his_ life a lot harder to go with your choices.
This time around I'd like to agree in advance that opacity
is a goal and thus avoid a repeat of this problem.
To sum up, I argue (and I'm not sure if this is the
argument I used to persuade Mitra, there _was_ a lot of
beer circulating that night :-) that if we keep the ID
portion opaque and separate we can develop it separately
from the constraints that might be imposed on the naming
authority portion for reasons of authority distribution or
resolution.
Now, are you convinced, or do you need more beer? :-)
- peterd
--
-----------------------------------------------------------------------------
"What do thay got, a whole lot of sand? We got a hot crustacean band!
Each little clam here, know how to jam here! Under the Sea!"
-----------------------------------------------------------------------------