Re: Unique handle generation

[George Belotsky <george@register.com>]

If the admin repository changes, #3 and #4 will contradict
each other.  The repository that created the object could
be part of the handle.  Then, if an object is deleted and
registered by some other repository, the handle will change
(which could be a good thing).

Transfers would not change the handle.

Also, there are advantages to converting the handles to 
digests, and then using those instead of handles.  It would
provide a measure of security (and perhaps privacy, if personal
information is part of the handle) for the user.  Also, the
handles would be stored and used in a consistent, fixed-length
format (e.g. 128 bits of opaque binary data).

While a digest would preclude search functionality (especially
across registries, registrars, etc.), this is probably too 
complex a task for a handle anyway.  Powerful search facilities
rely on a number of object attributes, can contain patterns and
have a complex boolean structure, etc.  Trying to fit all the 
needed information into a handle would make it very large,
complex, and thus difficult to remember.

In the above scenario, searches would return the digest form of the
handle as attributes of the found objects.  The opaque format would
prevent the originator of the request from potentially learning any
more information from the handle itself than their access privileges
allow.  The user on whose behalf the handle was created would still
have the readable version of the handle, and could choose who to give
(or not to give) this information to.

George.



On Sat, Mar 10, 2001 at 09:03:41AM -0500, Hollenbeck, Scott wrote:
> > -----Original Message-----
> > From: Patrik Fältström [mailto:paf@cisco.com]
> > Sent: Saturday, March 10, 2001 2:13 AM
> > To: Hollenbeck, Scott; ietf-provreg@cafax.se
> > Subject: RE: Unique handle generation
> > 
> > 
> > At 19.49 -0500 01-03-09, Hollenbeck, Scott wrote:
> > >The requirements draft currently states that every object 
> > must be associated
> > >with a unique identifier, but it doesn't specifically define 
> > the format of
> > >the identifier(s).  It's that "what the protocol should do" 
> > (in scope) vs.
> > >the "how the protocol should do it" (out of scope) thing again.
> > 
> > What do you mean by unique? Locally in the registrar? In the 
> > Registry? In the world? Should the handle change when an object is 
> > moved between registrars? Should the handle be able to not only 
> > identify the object but also where the object is?
> > 
> > I.e. a bit more specific requirements would help. It is the lack of 
> > answers to these questions the discussion on the syntax is so hard.
> 
> OK, I see your point.  In an earlier message you suggested some requirements
> for handles; let me try to capture those thoughts (and some mentioned by
> others) more precisely:
> 
> 1. Every object MUST have an associated handle.
> 
> 2. An object handle MUST be globally unique.
> 
> 3. An object's handle MUST NOT change during the lifetime of an object, even
> if administrative control of the object changes over time.
> 
> 4. An object handle MUST contain information that unambiguously identifies
> both the object and the object's administrative repository.
> 
> 5. Handle format SHOULD be easily parsed by humans.
> 
> Does anyone object to having these added to the requirements draft?
> 
> <Scott/>

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