Re: [mmox] Global Object Identification

Mike Dickson <> Sun, 05 July 2009 22:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 102273A691D for <>; Sun, 5 Jul 2009 15:33:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.234
X-Spam-Status: No, score=-106.234 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MBGQ6eRI8WWF for <>; Sun, 5 Jul 2009 15:33:26 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 04B2728C146 for <>; Sun, 5 Jul 2009 15:33:25 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AC6C538096; Sun, 5 Jul 2009 22:33:49 +0000 (UTC)
Received: from [] ( []) by (Postfix) with ESMTPSA id 1175F1001A; Sun, 5 Jul 2009 22:33:49 +0000 (UTC)
From: Mike Dickson <>
To: Jon Watte <>
In-Reply-To: <>
References: <> <> <1245446801.9567.12.camel@mdickson-laptop> <> <1245601755.7174.3.camel@mdickson-laptop> <> <> <1246813317.4532.48.camel@mdickson-laptop> <> <1246820675.4532.55.camel@mdickson-laptop> <>
Content-Type: text/plain
Organization: Bladesystems Infrastructure R&D
Date: Sun, 05 Jul 2009 17:33:42 -0500
Message-Id: <1246833222.4532.83.camel@mdickson-laptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.26.1
Content-Transfer-Encoding: 7bit
Cc: "" <>, Dave CROCKER <>
Subject: Re: [mmox] Global Object Identification
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Massively Multi-participant Online Games and Applications <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 05 Jul 2009 22:33:27 -0000

On Sun, 2009-07-05 at 21:41 +0000, Jon Watte wrote:
> Mike Dickson wrote:
> > I can't think of alot of "systems" that would satisfy your definition
> > (other than perhaps the current web infrastructure w/DNS).  That being
> > said the factsheet from the handle site has some details. 
> >
> >
> >   
> If I want my web servers to scale, I can easily buy all kinds of 
> acceleration hardware -- edge-mounted CDNs, load balancers, caching 
> proxies, 1000-core Java accelerators, you name it!
> If I want my DNS to scale, there are several solutions I can buy to 
> scale it to whatever load I need.
> I can't find any product that will allow me to accelerate handle 
> resolution. This, to me, is evidence that resolving URLs is at least an 
> order of magnitude better supported than handles (and, in most 
> likelihood, several orders of magnitude).

I'm not the best person to defend the technology. The proxy
service is however a standard servlet thingy so all the normal ways you
scale this type of app apply.  

> I believe that, if you need a unique ID for something, then using 
> DNS+URL is the best way. You can legislate what you get at the end of 
> that URL -- an XRD document, for example. Thus, code to deal with an 
> entity becomes trivial, because every software stack in existence 
> (including cell phones, Nintendo DS, and friends) all can fetch a URL 
> and parse XML.

Queries to the handle proxy server are formatted as standard url's.
There are mechanism to request return values in RDF/XML, RDF/N3, and
JSON. The handle server was in fact designed for the web. All the use
cases above that you mention would seem to apply. 

I think perhaps you're over simplifying some of the steps however.  Your
DNS+URL example still assumes some piece of software outside of the DNS
has to resolve the URL down to a piece of likely non-static XML that
gets returned.  That's exactly what the handle system is trying to do.  

I suppose there's some value in XRD vis its use in OAuth and OpenID. I
just don't want to see a viable option (the handle service) discarded
without a look to see how it might apply.

> The main reason for Handles to exist is that a document may "move." 
> However, that "move" only matters if the domain of that object can't 
> move with you. With modern DNS, that's basically a non-problem. Either 
> put up a sub-domain for your coroprate, organization or vanity domain, 
> or outsource it to someone who will stay around. Handle providers must 
> also stay around, and given that the business is much smaller than the 
> DNS business, the longevity of a handle provider is rather less assured 
> IMO...

I'm not at all convinced that your DNS example is a non-problem.
Companies merge all the time and how name spaces migrate or merge is a
real problem. 


> Sincerely,
> jw