Re: Unique handle generation

[George Belotsky <george@register.com>]

On Wed, Mar 14, 2001 at 01:58:52PM -0500, Hollenbeck, Scott wrote:
> >-----Original Message-----
> >From: George Belotsky [mailto:george@register.com]
> >Sent: Wednesday, March 14, 2001 1:27 PM
> >To: Hollenbeck, Scott
> >Cc: 'Patrik Fältström'; ietf-provreg@cafax.se
> >Subject: Re: Unique handle generation
> >
> >
> >An opaque identifier has plenty of uses (and provides some security,
> >too).
> >
> >A vehicle license plate, for example, provides identification even if
> >you know nothing about its format.  With sufficient authorization, you
> >can get answers to queries such as 'who does this vehicle belong to',
> >etc.
> >
> >Opaque identifiers have many uses, and are in fact frequently used.
> >We just have to determine if such identifiers meet our requirements.
> >If they do, then there are great advantages in using them -- most
> >prominently the elimination of the need to maintain a registry of
> >handles (or parts thereof).
> >
> >George.
> 
> OK, so what can you tell me about the object referred to by this sample UUID
> created using the uuidgen utility (23c67e00-71b6-11c9-9dfc-08002b0ecef1) vs.
> this identifier suggested by Patrik (RIPE-PAF2001)?  In the absence of
> context the UUID tells me _nothing_, including who to ask for more info.
> With Patrik's format I at least know who to ask for more info.
> 
> Considering your license plate example, in the US a vehicle license plate
> includes not only an opaque identifier, but the name of the state,
> territory, or other issuing entity that identifies the administrator of a
> license plate repository.  This administrator is the one that 1) assigned an
> identifier that's unique within the repository, and 2) holds the keys to
> obtaining additional information.  Strangely enough, this example appears to
> mirror Patrik's suggested format...
> 
> <Scott/>

This once again gets back to what the handle is for.  To illustrate, I
have listed three basic variants below.

         (1) Handles are used to search for objects.
         (2) Handles are used to quickly look up objects, regardless of
             their location.
         (3) Handles are used only to request operations on objects whose
             location is already known.


Variant (1) is the most difficult to implement -- especially if wildcards
and boolean searches are used.  These kinds of operations are
typically done on documents -- a handle would have to be huge to
contain enough meaningful information.  A large, centralized database
with a complex search engine is required for this kind of operation.

Variant (2) is easier: DNS does it.  Patrick's format would support
this level of functionality.  A distributed shared database is
sufficient, and complex search capabilities are not required.

Variant (3) is where digest-style handles would really be useful.
Searching for objects would be done by other means (e.g. via whois).
Once an object was found, operations (such as deletions, transfers,
etc.) could be requested on it.  Note that the original 'owner' of an
object would have the handle already, and would know the location.
Thus, operations such as transfers and deletions need no more than
Variant (3).

In general, Variant (3) is the simplest -- it needs no shared database
at all to ensure the uniqueness of handles.  It seems that the
decision to be made is whether the added functionality of Variant (2)
is warranted, given its significantly greater complexity and
possibility for error.  If it is, then the digest handle would not
work by itself, and a scheme like Patrick's (or DNS names) is
required.  On the other hand, if Variant (3) functionality is all that
is needed, then digest handles have several advantages, as I discussed
in previous posts.

George.



-- 
-----------------------------
George Belotsky
Senior Software Architect
Register.com, inc.
george@register.com
212-798-9127 (phone)
212-798-9876 (fax)