W3C home > Mailing lists > Public > uri@w3.org > September 2001

Re: toward domain names in the public interest

From: Dan Connolly <connolly@w3.org>
Date: Wed, 26 Sep 2001 08:45:41 -0500
Message-ID: <3BB1DC05.58834B3A@w3.org>
To: Martin Duerst <duerst@w3.org>
CC: uri@w3.org
Martin Duerst wrote:
> 
> Hello Dan,
> 
> I'm rather sceptical about the signatories system,
> in particular about the renewal after five years.

Er... yeah... it's intended to be a permanent
allocation, but authentication credentials
can't last forever.

Suppose, 12 years into the use of ietf.org,
the domain gods get a domain transfer request...
some other contractor is to operate ietf.org.
How do they tell whether to transfer the
public trust to the new domain operator?


> Ideally, our technology including uris should
> become invisible to end users. Imagine that
> in 5 or 50 years, there is a lot of software
> around that relies on some namespaces at www.w3.org,

Do you mean "relies on being able to dereference/access
some stuff at www.w3.org" or "being confident
that nobody has re-used those addresses for some other
reason"?

> but this is mostly unknown, because it 'just works'.
> How do you make sure that at the time needed, you
> can drum up enough people? Everybody would be
> affected if the domain name went out of service,
> but nobody cares enough to worry to send in their
> vote.
> 
> Also, assume that in 50 years, only 999 people
> depended on www.w3.org, but it was really important
> for them. Why should the domain go out of service?

To prevent misuse. It's nice if services
can remain running, but it's absolutely critical
that names burned into old software don't get reassigned.


> For at least some things, we need a system that
> is more stable with less administrative overhead
> than your proposal.

Ah... then you agree it's potentially a good idea?
Yes, I'd like to see something more scalable too.

> [...]

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
Received on Wednesday, 26 September 2001 09:45:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:03 UTC