# Re: Additional requirements for URCs?

Daniel W. Connolly (connolly@hal.com)
Mon, 15 Aug 1994 17:57:22 -0500

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Ingo Herz: "Ich habe Urlaub..."
- Previous message: Jon P. Knight: "Re: Additional requirements for URCs?"
- In reply to: Mitra: "Re: Additional requirements for URCs?"
- Next in thread: Jon P. Knight: "Re: Additional requirements for URCs?"
- Reply: Jon P. Knight: "Re: Additional requirements for URCs?"

    Message-Id: <9408152257.AA24793@ulua.hal.com>

    To: Mitra <mitra@pandora.sf.ca.us>

    Subject: Re: Additional requirements for URCs?

    In-Reply-To: Your message of "Mon, 15 Aug 1994 11:18:32."

                 <Pine.SCO.3.89.99.940815111735.6142B-100000@pandora.sf.ca.us>

    Date: Mon, 15 Aug 1994 17:57:22 -0500

    From: "Daniel W. Connolly" <connolly@hal.com>

In message <Pine.SCO.3.89.99.940815111735.6142B-100000@pandora.sf.ca.us>, Mitra
writes:
>On Mon, 15 Aug 1994, Michael Mealling wrote:
>> That's one of the major reasons I don't want URNs tied to DNS. If you just
>> make it a PubID devoid of FQDNs then anyone can assign withing a namespace.
>> I very much want to see an 'alt' namespace where any tom,dick or harry can
>> publish his recipe for marijuana brownies.....
>
>
>Yes - but who assigns the namespaces? You cant do that with a flat model
>(it doesnt scale), and if we are going to use a hierarchy, then we might
>as well use DNS for it.

If the names are really independent of the lookup servers, then you
can use what amount to random numbers, if you like. For example, use
DCE uuid's, or 128bit truly random numbers (generated ala PGP keys).

That's the ideal for a democratic publishing model. There are drawbacks:
it's a pain to implement a lookup service with reasonable performance,
and the names aren't mnemonic at all.

TimBL mentioned to me that somebody (can't remember who...) suggested
you use these great big random numbers for document ID's, and you
slice up the ID->Location mapping into, say 111 parts stored on 111
servers, and use the ID as a hash key. If the name mod 111 is 17, you
go to server 17 to lookup the location of the document. The number of
servers could start out at 3, then 7, ... and grow as more servers come
online.

To find the mapping servers, you could use DNS the way SMTP and the
fax services use it: You write out the document id like:

4.5.6.4.3.4.5.4.5.8.5.3.7.9
^ least significant digit first

and do a DNS lookup. At first, there are, say, 7 dns entries like:

1.* --> big-URN-server.hal.com
2.* --> big-URN-server.internic.net
...

Of course, by the time we have 10^6 URN servers, i.e.:

1.4.2.4.6.6 -> tiny-URN-server.little.tiny.org

DNS starts to break down.

It's an interesting idea, though.

Dan

- Next message: Ingo Herz: "Ich habe Urlaub..."
- Previous message: Jon P. Knight: "Re: Additional requirements for URCs?"
- In reply to: Mitra: "Re: Additional requirements for URCs?"
- Next in thread: Jon P. Knight: "Re: Additional requirements for URCs?"
- Reply: Jon P. Knight: "Re: Additional requirements for URCs?"