[governance] Re: It's Time to Stop ICANN's Top-Level Domain (TLD)
Stephane Bortzmeyer
bortzmeyer at internatif.org
Mon Nov 8 09:57:33 EST 2010
On Sat, Nov 06, 2010 at 05:00:49PM -0700,
Karl Auerbach <karl at cavebear.com> wrote
a message of 66 lines which said:
> A stable identifier needs certain kinds of stability:
I agree with your three criteria, but they are too vague to allow a
serious discrimination between systems. For instance:
> - Client stability (the name has the same meaning no matter who asks)
...
> But DNS names are increasingly failing on the client and location
> stability requirements. For example "google.com" resolves
> differently depending where the client is.
This is clearly false: google.com does not have the same IP address
depending where you are but it has the same meaning and it brings you
to the same content. For the normal use of an URL (name to resource),
http://www.google.com/ is client-stable.
> - Temporal stability (if the name has meaning, then the meaning
> remains the same no matter when the question of meaning is asked)
...
> For long term purposes we either need DNS zones in which once a name
> and record is created it becomes immutable and permanent, or we need
> another naming system.
This is clearly impossible. Temporal stability depend on *social*
practices (stable - on the long term - organizations with sensible
policies like the Library of Congress or the Bibliothèque Nationale de
France) not on *technical* rules. *Any* system of identifiers can have
changes if it is not carefully managed. Typical reasons for name rot
in the DNS are *non-technical* ones such as UDRP, expiration, sloppy
administration, etc.
Unlike what some snakeoil vendors (such as the International DOI
Fundation) pretend, there is no such thing as a stable naming
system. Stability is entirely in the practice, not in the standard.
> I have thought that perhaps I ought to start plopping a GUID/UUID
> string into everything I write. That way there would be at least a
> stable name embedded into the content itself:
>
> ee1a7c75-19a0-44f3-8cb9-627c20af8298
Then use RFC 4151 which is a much more elegant solution (summary: a
"tag" URI is made of a domain name *and* a date; therefore, it is
always valid even if BigCompany hijacks your domain with an UDRP;
small problem, it is not resolvable; you cannot easily have stability
*and* resolvability).
____________________________________________________________
You received this message as a subscriber on the list:
governance at lists.cpsr.org
To be removed from the list, send any message to:
governance-unsubscribe at lists.cpsr.org
For all list information and functions, see:
http://lists.cpsr.org/lists/info/governance
Translate this email: http://translate.google.com/translate_t
More information about the Governance
mailing list