Re: [mmox] Global Object Identification

Mike Dickson <mike.dickson@hp.com> Tue, 07 July 2009 16:38 UTC

Return-Path: <mike.dickson@hp.com>
X-Original-To: mmox@core3.amsl.com
Delivered-To: mmox@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F56E28C4C4 for <mmox@core3.amsl.com>; Tue, 7 Jul 2009 09:38:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.504
X-Spam-Level:
X-Spam-Status: No, score=-106.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFmNhQspiorE for <mmox@core3.amsl.com>; Tue, 7 Jul 2009 09:38:20 -0700 (PDT)
Received: from g1t0029.austin.hp.com (g1t0029.austin.hp.com [15.216.28.36]) by core3.amsl.com (Postfix) with ESMTP id B3CAC28C4BF for <mmox@ietf.org>; Tue, 7 Jul 2009 09:38:20 -0700 (PDT)
Received: from g5t0012.atlanta.hp.com (g5t0012.atlanta.hp.com [15.192.0.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by g1t0029.austin.hp.com (Postfix) with ESMTPS id AC1A3385F0; Tue, 7 Jul 2009 16:38:00 +0000 (UTC)
Received: from [192.168.1.139] (conr-adsl-209-169-71-194.consolidated.net [209.169.71.194]) by g5t0012.atlanta.hp.com (Postfix) with ESMTPSA id E52AE10009; Tue, 7 Jul 2009 16:37:59 +0000 (UTC)
From: Mike Dickson <mike.dickson@hp.com>
To: Jon Watte <jwatte@gmail.com>
In-Reply-To: <4A537687.2050304@gmail.com>
References: <ad15b9430906190018g6e585f0ei8fc83c073056a7bd@mail.gmail.com> <c7bcbd620906210956l1a05fb81xb3dea005c902a564@mail.gmail.com> <ad15b9430907040531j18caf370y2a9b400ace86394a@mail.gmail.com> <1246813317.4532.48.camel@mdickson-laptop> <4A50E7C9.1090208@bbiw.net> <1246820675.4532.55.camel@mdickson-laptop> <4A511DF9.9000508@gmail.com> <1246833222.4532.83.camel@mdickson-laptop> <4A523E8A.8000400@gmail.com> <4A526D09.6000701@comlounge.net> <ad15b9430907062245g768c0e2y1438bd4425489dbb@mail.gmail.com> <4A537687.2050304@gmail.com>
Content-Type: text/plain
Organization: Bladesystems Infrastructure R&D
Date: Tue, 07 Jul 2009 11:37:48 -0500
Message-Id: <1246984668.4532.118.camel@mdickson-laptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.26.1
Content-Transfer-Encoding: 7bit
Cc: "mmox@ietf.org" <mmox@ietf.org>, Dave CROCKER <dcrocker@bbiw.net>
Subject: Re: [mmox] Global Object Identification
X-BeenThere: mmox@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mike.dickson@hp.com
List-Id: Massively Multi-participant Online Games and Applications <mmox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mmox>, <mailto:mmox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmox>
List-Post: <mailto:mmox@ietf.org>
List-Help: <mailto:mmox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmox>, <mailto:mmox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Jul 2009 16:38:21 -0000

On Tue, 2009-07-07 at 16:23 +0000, Jon Watte wrote:
> Tommi Laukkanen wrote:
> > 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.
> >   
> 
> ... Which is more or less what the Handle system does ...
> 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