The criticism is that the hierarchical design is
essentially (fiddley bits omitted)
<hierarchical authority> : <opaque string>
This looks nice but could be better. Let's assume for
now that the hierarchical authority has some divider like /
so we could have something like
IANA / EDU / MIT / LCS / AMANDA : UHFGUHDWPUDEHESYSTSHKJS
but more likely it would be more like (internally in fact)
IANA / EDU /MIT / LCS / AMANDA : NOTES / 1993 / JAN / GRUNDGE4
Now I am concerened that one might want to move the colon
around,. In fact I'll give the game away by telling you that
I am going to propose that the / and the : be merged. But
I haven't yet, so read on.
Looking atthe above example, can you really determine
where you would want to define a "naming authority"
and where an "opaque string"? Should MIT, or MIT/LCS,
or MIT/LCS/AMANDA* be the naming authority?
What happens when LCS splits into 126 parts, which
group into 6 subdivisions, all of which want to be
a naming authority? And then collapses back into one?
So much for the problem. The answer is clear. Look
at domain names. In particular, look at MX records
and mail addresses. Suppsoe (which I don't)
I have a mail address of
timbl@as.cn.cern.ch
You can't tell and don't want to know where the MX record
is -- is the authority cern.ch or cn.cern.ch? It doesn't
matter and it can change.
Look at what Carl and Marshall have done with DNS and phone numbers
to see the flexibility which this gives.
So,
I propose that the / and the : be merged into one
form of visible hierarchical structure.
There. I proposed it, as I promoised. I submit that
otherwise the URN scheme imposes too much structure and will
overconstrain future implementations -- in short, it will be broken.
We end up with a URN being (in essence, fiddly bits omitted)
peices :: void
| piece delimiter pieces
just like everything else.
__________________________________________________
Fit the second.
What protocol should we DEFINE to implement URNs?
None. Any URN name space which is linked to one protocol
is broken, and is more of a URL.
___________________________________________________
Fit the third
How we could implement one real protocol to actually try it out?
Use DNS for the top level of the hierarchy using the MX record
kludge. (That is, that you can ask for appropriate MX
records for a given DNS name even if the DNS name does not exist
in the hierarchy).
One possibility is to add an IX record. This I am told
would mean recompiling all DNS. It would be nice because
it would allow the existing domians to contain information just
like they contain mail addresses and hosts.
The second possibility is actually to use MX records in
a separate tree, like to find document
aaa1.notes.sept.timbl.as.cn.cern.ch
you would look for an MX record for
aaa1.notes.sept.timbl.as.cn.cern.ch.ix
This is actually doable experimentally now.
What you would get back would be a bunch of [I|M]X
record pointing to whois++ or http or z39.99
servers which would handle what you want.
In time, recommmendations could be made as to the protocols
to be used, whwreas during experimentation more than one
protocol could be used.
If an MX record is returned with a URI for a resolution
service whose URL scheme you don't recognise, you
don't crash, you just ignore it, mitra.
Note:
1. There is nothing to stop someone making
a better protocol than the IX method, and
nothing to stop both running together,
and nothing to stop one being
later decided on by the market or the
IESG. And nothing to stop a transition scheme
to a new better one later in 2056.
2. The same applies to the second level retrieval
protocol, defined by the URL in the IX
record.
3. The naming authority need not correspond
to the same level in the tree as the IX record --
the management and allocation of names are
independent functions. As someone said recently.
(Much though it is convenient to have just one protocol,
it is essential to be *able* to have two. At each level.)
Will someone please implement this? :-)
Whatddya think?
Tim Berners-Lee
CERN
____________________________________________________________
*Parts of the name are all ficticious and any resemblance
to any person organization, domain, byte etc alive or dead is
entirely coincidental.