Re: Unique handle generation

[George Belotsky <george@register.com>]

Scott:

Here is an overview of the algorithm I had in mind, so that
it is easier to understand the changes that I am suggesting.


   (1) A human-readable object handle is created.  This
       is done UUID-style, by concatenating several
       atomic units.  The creating repository may be
       one of these, but it does not have to be.
       The end result is something like this.

       Scott+Hollenbeck+verisign.com+scottshomepage.com+Mar.13.2001

   
   (2) A digest function is applied to the human-readable handle.
       The system stores the resulting  digest, and not the readable 
       form itself.

   (3) The readable form is returned to the user.  Now, there are
       two equivalent representations: the digest (which is used
       by default), and the readable form (which can be used 
       by the 'owner', or anyone else that the 'owner' gives it to).
       This is the essence of [5] and [6] as I suggested; not 
       contradictory, but complimentary. 


George.


On Tue, Mar 13, 2001 at 08:50:29PM -0500, Hollenbeck, Scott wrote:
> > -----Original Message-----
> > From: George Belotsky [mailto:george@register.com]
> > Sent: Tuesday, March 13, 2001 3:04 PM
> > To: Hollenbeck, Scott
> > Cc: ietf-provreg@cafax.se
> > Subject: Re: Unique handle generation
> > 
> > 
> > On Tue, Mar 13, 2001 at 02:26:18PM -0500, Hollenbeck, Scott wrote:
> 
> [snip]
> 
> > > [4] An object identifier MUST contain information that unambiguously
> > > identifies both the object and the object's administrative 
> > repository at
> > > time of creation.
> > 
> >   We should probably reduce the scope of this one.  How about 
> > the version
> >   below?
> > 
> >   An object identifier MUST contain information that unambiguously
> >   identifies the object.
> 
> The text that's there was originally suggested by Patrik.  Patrik, are you
> OK with George's suggested change?
> 
> > > 
> > > [5] Object identifier format SHOULD be easily parsed and 
> > understood by
> > > humans.
> > 
> >   Some scope reduction here, too.
> > 
> >   [5] Object identifier SHOULD have an opaque, fixed length format 
> >       (e.g. 128 bit digest).
> 
> I don't like this one.  For one I think it conflicts with what you've
> suggested for [6] (how is an opaque digest easily parsed and understood by
> humans?), and secondly it introduces a formatting suggestion when you just
> suggested that we remove a different formatting suggestion from [4].  If you
> want to reduce the scope of [4] by removing mention of one format, why
> should we introduce a different format?
> 
> >   [6] An identifier that is easily parsed and understood by 
> > humans, and 
> >       is equivalent to the identifier in [5], MUST be made 
> > available to
> >       the object's owner at the time of object creation.
> 
> I don't like the word "owner" here, though I think I understand what you're
> getting at.  How about this instead:
> 
> [x] The format of an object identifier SHOULD be easily parsed and
> understood by humans.
> 
> [y] An object's identifier MUST be generated and returned as part of the
> protocol response when an object is created.
> 
> <Scott/>

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