Subject: Re: [mmox] Global Object Identification

From: Tommi Laukkanen <[email-masked]>
Date: Sat, 4 Jul 2009 15:31:26 +0300

Hello

I gather from this and previous discussions that there are two wide
spread systems for global object indetification:

1) Handle System (from CNRI) - Global identifier to service resolving
network in analogy with DNS. Adding your data type to the network has
a cost. How does the cost scale with number of objects?

2) Extensible Resource Identifier (XRI) - The url for XRD document
containing service locations can be calculated from XRI identifier.

I guess these two approaches are in theory the two viable ways to do
global identifiers. Either build global resolving / register network
or include enough information in the identifier to resolve url
directly from it.

Are there other viable implementations? If not should we dive deeper
in comparing these two alternatives?

-tommi

---

From: Mike Dickson <[email-masked]>
Date: Sun, 05 Jul 2009 12:01:57 -0500

Cost for the handle system is non-linear. Similar to DNS.  Once you
register a domain how many things get put under it is your own business.
The cost for the registration is pretty minimal.  Primarily to fund the
maintenance of the root servers.

I like the handle system because its been around for a while, proven to
scale reasonably well, etc.  There's support for metadata on the objects
referenced also so it also partly addresses what "type" of thing is
being referenced and what can/should be done with it.

Mike

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 05 Jul 2009 10:50:01 -0700

Mike Dickson wrote:
> scale reasonably well, etc.  

So, the metric I use for scaling, when talking about Internet standards, is many 
millions of independent users and at least many thousands of independent 
administrations, all participating in the same system.

In other words, a single integrated service that is operated by a very large 
number of independent groups and that is used by a couple of orders of magnitude 
more of independent groups and people.

I know there are large handle systems, but I don't know of any that satisfy 
these criteria.  (By "don't know" I am asking to be educated; I truly don't know 
that much about the range of installations for handle.)

For a system that does not already satisfy this requirement, the burden is to 
explain why the world should believe that the system will be able to.  And 
again, I mean that as a serious request, not an implied criticism or dismissal.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Mike Dickson <[email-masked]>
Date: Sun, 05 Jul 2009 14:04:35 -0500

> administrations, all participating in the same system.

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. 

http://www.handle.net/factsheet.html

> more of independent groups and people.

Given the details in the fact sheet I'd say the handle system satisfies
that criteria. If you don't believe so I'd like to understand what you
think is missing.  

BTW, I don't actually work on/with the handle system.  I was aware of it
and it's the best example I know of that handles very large scale
resource resolution across the web.

> again, I mean that as a serious request, not an implied criticism or dismissal.

Well, as I said I think as the fact sheet indicates IMO it already does.
if you don't think so it would be valuable to hear why. And to put
forward and alternative that you think is representative of your
requirements.

Mike

---

From: Jon Watte <[email-masked]>
Date: Sun, 05 Jul 2009 14:41:13 -0700

> http://www.handle.net/factsheet.html

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 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.

Meanwhile, resolving a handle to an actual object or service means that 
you first have to resolve the handle, and then turn that around and 
resolve a URL anyway.

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...

Sincerely,

jw

-- 

  Revenge is the most pointless and damaging of human desires.

---

From: Mike Dickson <[email-masked]>
Date: Sun, 05 Jul 2009 17:33:42 -0500

> likelihood, several orders of magnitude).

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

> (including cell phones, Nintendo DS, and friends) all can fetch a URL 

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.

> DNS business, the longevity of a handle provider is rather less assured 

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. 

Mike

---

From: Jon Watte <[email-masked]>
Date: Mon, 06 Jul 2009 11:12:26 -0700

> Companies merge all the time and how name spaces migrate or merge is a

My question to you is: Do you think that it is a technical problem to 
keep a DNS domain alive, if there were an incentive to do so? My 
assertion is that it isn't. Thus, if you structure your URL well 
(typically use a custom DNS for all your asset URLs) then they can 
survive for as long as you want them to.

http://assets.jonwattesvirtualworldserver.net/uuid/abf3-dd4c-baadf00d-123456789abcdef0

Assuming I want to pay the $10/year for 
"jonwattesvirtualworldserver.net" then this will survive forever.

Admittedly, my main concern with the handle system is not technical, but 
the fact that it costs $100 to get started, and then $50/year, which is 
5x-10x more than it costs with a DNS based solution (both solutions need 
additional web hosting, too).

Sincerely,

jw

--

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 06 Jul 2009 13:16:21 -0700

d/
-- 

   Dave Crocker

---

From: Christian Scholz <[email-masked]>
Date: Mon, 06 Jul 2009 23:30:49 +0200

> http://assets.jonwattesvirtualworldserver.net/uuid/abf3-dd4c-baadf00d-123456789abcdef0 

I think here there is also the general topic of data portability which 
is important. If I own some stuff I might want to take it with me which 
might mean to change URLs. As long as an asset is always copied into a 
context IMHO there shouldn't be a problem with URLs.

Now it is a policy decision if you always copy it or just use it by 
reference (which IMHO makes no difference in non-copyability btw) but if 
you use the latter you already have that problem on the web today. On 
social networks though more stuff seems to be copied (or actually 
re-uploaded all the time) so even if the first place you put it goes 
down the others still have it (and you yourself should be able to copy 
your own stuff around as you wish to anyway).

> additional web hosting, too).

I agree here. As long as this is not a free service it won't get 
traction and we actually see this with XRI. Besides that you'd need to 
explain all this to people and too many levels of indirection are not 
too easy to understand in general.

The question IMHO is if we need to care today if they will be popular 
tomorrow as long they are URIs. Then it should be easily replaceable 
without even changing any specs.

-- Christian

-- 
COM.lounge GmbH
http://comlounge.net
Hanbrucher Strasse 33, 52064 Aachen
Amtsgericht Aachen HRB 15170
Geschäftsführer: Dr. Ben Scheffler, Christian Scholz

email: [email-masked]
fon: +49-241-4007300
fax: +49-241-97900850

personal email: [email-masked]
personal blog: http://mrtopf.de/blog
personal podcasts: http://openweb-podcast.de, http://datawithoutborders.net

---

From: Tommi Laukkanen <[email-masked]>
Date: Tue, 7 Jul 2009 08:45:37 +0300

To my understanding Handle Systems main problem is how costly it is to
scale it to accommodate all objects in global metaverse which could be
several order of magnitudes more than DNS system needs to support
currently.Handle System could also be too centralized in business
sense giving monopoly like status for the body governing it.

DNS based solution like XRI on the other hand has the problem of
building identifiers with information content. If this information
changes say, the object is sold to company XYZ from company ABC, then
the company ABC then has to agree to host the identity of the object
they sold as long as needed. This could be worked a round by creating
specific identify provider service domains so that the domain name
would not reflect ownership but just the identity provider.

-tommi

---

From: Jon Watte <[email-masked]>
Date: Tue, 07 Jul 2009 09:23:35 -0700

> would not reflect ownership but just the identity provider.

... Which is more or less what the Handle system does ...
And round and round we go :-)

Sincerely,

jw

--

---

From: Mike Dickson <[email-masked]>
Date: Tue, 07 Jul 2009 11:37:48 -0500

> And round and round we go :-)

Indeed :-)

It seems to me the key issue is one of requirements.  If you believe
that global asset identifiers require stable ids that are persistent
over time, then you'll likely lean to handles or inventing something
similar.  That extra capability has costs associated with it, however
it's achieved.

I personally think the stable id thing is important.  One reason that
haven't seen discussed is the ability to support different sorts of
access to the data being referenced.  If I'm a content developer I may
want a way to know that an object is an original versus a copy. That is,
since you can provide some control over how assets in the handle repo
get updated you can insure to some degree that the handle references the
real thing and not a copy someone made.  There are other ways to insure
that of course (watermarks, etc).  It's a use case though that I think
needs to be explored when deciding what mechanism to use to refer to
assets.

Mike

---

From: Tommi Laukkanen <[email-masked]>
Date: Sat, 11 Jul 2009 08:38:21 +0300

What would be the procedure to write down a summary of topics
discussed like this global identification issue. Is there a wiki page
somewhere for this list or should we work on a document. Where would
this document be stored then? Can we arrange polls or votes to get
clear picture how opinions are divided?

regards,
Tommi Laukkanen