Re: Unique handle generation

[Michael Mealling <michael@bailey.dscga.com>]

On Mon, Mar 12, 2001 at 04:31:29PM -0500, George Belotsky wrote:
> MM has brought up a valid limitation of UUID-style identifiers for
> doing lookups. Unfortunately, MM's observation also applies to any
> constant identifier -- not just UUIDs.  If the handle contains
> information on its location, and its location changes, the handle must
> also change.

There's a subtle but important point here. There are two functions
we're talking about: identifier assignment and resolution. You
can optimize the namespace for one or the other. For example, you
could design the namespace so that assignment is done by concatinating
a registry ID and a local ID but resolution is flat. This allows
each entity to have their own name creation policy and still have
uniqueness. Resolution is then flat. Conversely you can optimize
for resolution and federate the lookup process. 

> If we wanted to store handles, so that we can access the objects
> later no matter where they got moved to in the meantime, then
> MM's point becomes a serious consideration.

Its a consideration but its not impossible to solve. The audience
of this list is used to dealing with large databases of things like
this. Its just that this particular database becomes a shared 
resource that everyone depends on. That causes politics and policy
to jump into the process....

> On the other hand, if the handles were used to specify operations on
> objects where the caller already knew the location(s), then we are
> still fine.  Examples of such operations are transfers, deletions,
> changes to contact information, etc.
>
> MM, can you think of a solution to this problem?  It may be possible
> to use DNS for resolving handles, but this gets back to most of the
> drawbacks of operating a handle registry.

This is a very valid point. Just because the unique object identifier
is not easily resolvable by itself does not invalidate it. You just
have to have some other information along for the ride that lets you
know who currently has that object (or a pointer to it). Imagine
some construct similar to this

e75ad859-83db-4225-a564-120f2fd0d5a9@RIPE 

or more generally:
<objectid>@<administrative ID>

This is what you use in 99% of the cases in the protocol. Both
sides are globally unique so you can be sure that if RIPE
no longer has the thing it will still have the same name of
e75ad859-83db-4225-a564-120f2fd0d5a9 no matter where it moved
to. The RIPE service could even give you a referal to where it
thinks it got moved to....

Now, if you want to build an adjunct service to find an object id without
an administative ID then that's a slower, more exhaustive search.
But it could be done because it would be an atypical query and thus
one that could be done as a low priority process...

Now that I think about it I guess this was Bill's point just repackaged..

-MM

> On Mon, Mar 12, 2001 at 03:08:25PM -0500, Michael Mealling wrote:
> > On Tue, Mar 13, 2001 at 04:01:33AM +0800, William Tan wrote:
> > > > Yup... Thats pretty much my take as well.
> > > > #1 has not worked well
> > > > #2 is ... operationally challenging ... :)
> > > > #3 might be the most fun to work on.
> > > 
> > > I'm for the idea of uuid-like hashes.  Readability has to be sacrificed, I
> > > don't see any way out.  However, handles may be hidden from the end users,
> > > so it might not be an issue after all.
> > 
> > You not only sacrifice readability but you also sacrifice delegated resolution. 
> > A flag namespace such as UUIDs would require either a single large
> > database or a lookup would have to be sent to every potential object
> > holder to see who had it....
> > 
> > -MM
> > 
> > -- 
> > --------------------------------------------------------------------------------
> > Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
> > Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
> > Network Solutions	|          www.lp.org          |  michaelm@netsol.com
> 
> -- 
> -----------------------------
> George Belotsky
> Senior Software Architect
> Register.com, inc.
> george@register.com
> 212-798-9127 (phone)
> 212-798-9876 (fax)

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions	|          www.lp.org          |  michaelm@netsol.com