RE: Unique handle generation

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

>-----Original Message-----
>From: Patrik Fältström [mailto:paf@cisco.com]
>Sent: Wednesday, March 14, 2001 1:31 AM
>To: George Belotsky; Hollenbeck, Scott
>Cc: ietf-provreg@cafax.se
>Subject: Re: Unique handle generation
>
>
>At 21.14 -0500 01-03-13, George Belotsky wrote:
>>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.
>
>I think you make life much too complicated.

I agree, too.  One of things that I don't like about digests used this way
is that a registry has to maintain _three_ different identifiers for an
object like a domain name:

1. The name itself,
2. A combination of human-readable elements used as digest algorithm input,
and
3. A digest (128 bits (16 octets) for MD5, or 160 bits (20 octets) for
SHA-1, or more for newer algorithms -- fewer bits or weaker algorithms don't
offer much collision protection)

I know that George suggested that the human-readable form doesn't need to be
stored by a registry, but putting an opaque digest into a whois response (as
an example) seems useless to me.  Take the digest out of the surrounding
context and you have a meaningless string of characters.

If I'm reading this right, the real sticking point that we're continuing to
debate is local part uniqueness, primarily if a repository ever has to join
with all of the objects and identifiers from another repository.  I might be
wrong, but I think this is a pretty rare corner case that we don't really
need to optimize for.  I think a simple approach is best, and if collisions
ever do occur they are best handled on a case-by-case basis -- which means
that an object identifier could change if a new local part is needed to
avoid a collision when integrating repositories.  However, if the identifier
is going to change anyway as a result of the repository change, maybe this
isn't a major issue.

<Scott/>