[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: Dave Crocker <dcrocker@brandenburg.com>
Cc: Christopher Ambler <cambler-ietf@iodesign.com>, ietf-provreg@cafax.se
From: George Belotsky <george@register.com>
Date: Thu, 8 Mar 2001 10:54:47 -0500
Content-Disposition: inline
In-Reply-To: <5.1.0.10.2.20010308224327.02c21940@brandenburg.com>; from dcrocker@brandenburg.com on Thu, Mar 08, 2001 at 10:44:26PM +1100
Sender: owner-ietf-provreg@cafax.se
User-Agent: Mutt/1.2.5i
Subject: Re: Unique handle generation

Excellent point, Dave.

Let's try to come up with some answers to what a handle is for.  A
number of people (e.g. Martin, Patrick) have made very useful suggestions
regarding handles.  From the overall discussion, it seems that:

          (i)   Handles should be easy to remember/readable;
          (ii)  Handles should identify objects uniquely;
          (iii) It's probably a bad idea for the handles to change.

It appears that a handle is really useful for lookups, rather than
searches.  Making the information contained in the handle itself
meaningful for some operation (other than memorization by the user)
is probably too ambitious a goal.  The likely use for handles is
automated exchanges between systems (e.g. transfer of registrar), and
some user-initiated operations, where the handle would be supplied
directly by a human (e.g. transfer of registrar, again).

Searches for objects would return handles as just another object
attribute, as would other lookup mechanisms (e.g. whois).

A common UUID calculation algorithm would satisfy both requirements
(ii) and (iii), above, but not requirement (i).  Therefore, it is
appropriate to generate the handle as a concatenation of several
(readable) attributes, such as email address, name, timestamp,
identifier of the generating server, etc (both myself and others
have suggested this).

** It does not really matter if some of the attributes placed into
** a handle change later -- as long as the handle remains unique, and
** is easy to remember.

After the handle is generated, it may be a good idea to store it as a
digest (e.g. MD5 hash) on the server.  The handle' owner can still
use the human-readable form, while automated exchanges between systems
will use the digest only.

George. 



On Thu, Mar 08, 2001 at 10:44:26PM +1100, Dave Crocker wrote:
> At 05:43 AM 3/8/2001, Christopher Ambler wrote:
> >That depends on what you want the handle for.
> 
> This is a key question and I do not believe it has been answered.
> 
> What is/are the specific use(s) for the proposed handle?
> 
> d/
> 
> 
> >----- Original Message -----
> >From: "George Belotsky" <george@register.com>
> >To: <ietf-provreg@cafax.se>
> >Subject: Unique handle generation
> >
> > > Since unique handle creation is still an open issue, could we not
> > > borrow/adapt a UUID generating algorithm for making such handles?
> 
> ----------
> Dave Crocker   <mailto:dcrocker@brandenburg.com>
> Brandenburg InternetWorking   <http://www.brandenburg.com>
> tel: +1.408.246.8253;   fax: +1.408.273.6464
> 

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

Home | Date list | Subject list