Name services was: Persistent caches - was: ...

John Cowan wrote:
>Foo.  All that the DNS does is provide a bunch of /etc/hosts servers
>with machinery for delegating requests from one to another.  (Yes, I'm
>oversimplifying for effect; so are you.)
>
>FPIs now allow delegation mechanisms, so nothing prevents us from setting
>up a bunch of FPI root servers that know how to delegate down the FPI
>tree.   All that's really needed is a simple server-to-server protocol,
>a well-known port, and some commitment.  Just what DNS has, in fact.


Well, it seemed to be fun for Paul Mackapetris and friends when they did
it the first time so let's do it again!

But seriously if, as below, you were to make an FPI directory service,
then you could in fact use DNS for the hierachical part. You would just have
to get a top level .fpi directory over which you had total control (a pact
with ICANN).
The existing DNS server infrastructure could distribute the information.

>> If the social conditions (control, persistence) are things
>> this community really likes, then it would be quite simple to define a
URI
>> scheme fpi: which would fix this.  That could easily become a W3C
activity
>> - so long as they could be justified as giving something which existing
>> URI schemes don't.
>
>What they have (and I know the mechanism has been broken for a long time,
>and still is, but that *can* be fixed) is a registrar that's committed:
>
> 1) to hand out names on request (this is the broken part) and
> 2) not to hand out the same FPI-prefix twice (this is the good part).


A serious possible working group would be one to try to define a set of
rules for a new space. The Librray of Congess folks would like this,
I inderstand.  This would need careful design.  You need commitments
from the domain holder to allow other sites to archive information
in case of disataster, and an automatic release of any constraint
on other archives sites from mirroring material should the
company/organization
die. There would also be a commitment to non-reuse etc.
The trick is to make it decentralized - not another fee collection
scheme.

>The DNS registrars are committed to
>just the opposite: if you don't pay your US$50 a year or whatever, they
>can and will take your domain name away and assign it to someone else.
>The domain 'spam.org', for example, has had four owners that I know of.


This is indeed a problem. However, at w3.org we feel that we can probably
manage the $50/year.  We also, if we ever fold, will find places
such as the Smithsonian to take over our mirror sites.  It woul dnice if
there
we a "persistent license" of some sort which we could define now to grant
that in advance in the case of our untimely demise.

Here is a solution to the $50 problem.  There is a set of top level domains
which use common era years. Within the .com.2000 domain you can only
register
a subdomain within the year 2000. There is a one-time fee. From then on the
domain
is yours. Noone can take it away from you.

This is effectively the soltoin we use on our site - we have top level
directories such as 2000.
You can't move anything in that space.

>This makes complete hash of any kind of naming scheme, since the new owners
>inherit no sort of commitment to keep the old names in being.  Imagine the
>bibliographic chaos that would result if publishers had to pay "maintenance
>fees" to keep their ISBN prefixes, and if they didn't, the ISBN authority
>would happily reassign those prefixes to some other publisher!
>You could never again depend solely on the ISBN of a book to identify it,
>but would have to know as of what date the reference was made, and refer
>to a historical database mapping ISBN prefixes to publishers.


The last time I pointed that out, someone (who?) told me the awful fact that
actually some ISBN numbers are recycled
after a time.

Tim BL

! || John Cowan <jcowan@reutershealth.com>
>Schliesst euer Aug vor heiliger Schau,  || http://www.reutershealth.com
>Denn er genoss vom Honig-Tau,           || http://www.ccil.org/~cowan
>Und trank die Milch vom Paradies.            -- Coleridge (tr. Politzer)
>

Received on Saturday, 20 May 2000 08:38:18 UTC