The Internet community has suffered from recent conflict over Top-Level Domains (TLD) in the Internet's Domain Name System (DNS), and the Internet Corporation for Assigned Names and Numbers' (ICANN) administration of them. The intensity of this conflict is partly due to the inflated value of domain names, particularly at the top and second levels. That inflated value derives partly from the historical conflation of two logically separate functions into the DNS:

1. translation of handles for services available on the Internet into Internet Protocol (IP) numbers for routing purposes, and
   
   
2. directory lookup (DL) of somewhat mnemonic and guessable names for services.

Most of the commercial value of domain names derives from their suitability as names in the DL function. But, domain names are actually used mostly as handles. DNS is currently the sole provider of handles for the Internet, while Google, Yahoo, and other independent agencies compete to provide useful DL services for a variety of types of names, some assigned and some derived from Web content. Those who only desire handles are forced to compete with powerful corporations who covet domain names for their value in DL services.

I propose to deflate the value of domain names by providing numerical and non-mnemonic handles through an independent service, separate from DNS and all other DLs. The new service will provide handles promiscuously to all who ask for them, either free of charge or for a tiny administrative fee to cover costs. With this new service, DNS will compete separately for its value as a handle resolution service and as a DL name resolution service. I expect that, in the new regime, DNS domains will have a very low commercial as well as technical value, and will eventually be completely superseded. But I do not propose to attack the use of DNS by any means other than attractive competition.

Without the market inefficiency due to bundling of handles with names in DNS, I expect ICANN's administration of DNS to provoke much less conflict, because its potential for unintended harm will be much less.

• scooped me a year ago with his article, . Essentially all of the ideas in my proposal are there. Now that I've seen Frankston's article, I will try to extend his ideas instead of repeating them.
  
  
• I posted a to
  
  
• I've been pitching a few people who seem likely to be favorable with a .
  
  
• I am working on documents describing and justifying the proposal more thoroughly. ``Open Network Handles Implemented in DNS'' is published as an Intenet Draft. ``A Proposal to Separate Handles from Names on the Internet'' is submitted for publication. Both are available in the archive of CS reports.
  
  I think that there's some useful prose scattered around in the other drafts. But I haven't succeeded in focusing them well on particular audiences, partly because I haven't figured out what audiences I need to pitch. Help, anyone?
  
  
  1. "A Proposal to Separate Handles from Names on the Internet" in
     
     
     • 
       
       
     Also available from . A shorter version is submitted for journal publication.
     
     
  2. "Open Network Handles Implemented in DNS" in
     
     
     
     
     This one is published as a real Internet Draft (the plain text form, derived from the nroff/ms source). That's why it's in the ID plain text format. It's supposed to be concrete. I'd especially appreciate technical critique uncovering my misunderstandings of the security extensions to DNS (DNSSEC). The LaTeX version (from which the HTML, DVI, PDF, and PostScript are derived) is essentially the same, but pagination and formating differ. It is archived in .
     
     
  3. "Open Network Handles---Definitions and Specifications" in
     
     
     
     
     An earlier draft was called "Requirements" instead of "Definitions and Specifications." I changed because of the specific meaning of "requirements" in the RFC literature. You may dig out older drafts from file detritus and the RCS directory.
     
     I (odonnell@cs.uchicago.edu) welcome all comments, but, if you are among those offended by lots of pedantic detail, please cut me a bit of slack for now. There really are lots of technical subtleties that need to be worked out with excessive care at the beginning. I'll try to make the presentation more palatable later. If you know of prior work that I should read, either for standard terminology, or ideas that have already been worked out, or just to be fair about credit, please send citations ASAP.
     
     
  4. "Open Network Handles---Design Notes" in
     
     
     
     
     In version 0.1, this is just a slightly structured list of observations and questions. I think that I will make the most progress by sketching a design now, and backing out the specifications and questions from the prototype design.
     
     
  5. "Open Network Handles---Rough Design Prototype" in
     
     
     
     
     I think that this one is worth reading and critiquing pretty carefully, even in version 0.1. The design is pretty thoroughtly sketched out, except for some tricky details about handle reassignment. I'm pretty confident that implementation and design details can be pieced together from DNS for the discovery part, and systems like PGP and GPG for the authentication part. Perhaps this is worthy to be cleaned up an made into an Internet Draft.
     
     
  6. "Routes, Addresses, Handles, and Names in Networked Communications" in
     
     
     • , with for Figure 1.
     • . Figure 1 is not showing up in the PDF.
     • , for Figure 1.
     
     
     This is an attempt at a conceptual overview of the value of four different types of reference tokens in a network, and three different levels of resolution.
     
     
  7. "Open Network Handles---Abstract Protocol" in
     
     
     
     
     This is still pretty rough, but it's getting close to something objectively evaluatable. "Abstract" means that I specify what messages need to be implemented, and what information they need to carry, but not the format or syntax.
     
     
  
  
  
• We (cs.uchicago.edu) have a local mirror of all Internet Drafts and RFCs at /stage/rfc.