RE: Unique handle generation

[Patrik Fältström <paf@cisco.com>]

At 12.42 -0500 01-03-08, Brian W. Spolarich wrote:
>  > One record will point out a person (as an example). A person have a
>>  lifetime of say 120 years. We need to find a handle which can have
>>  the unique identifier for at least 120 years.
>
>   This is a great discussion, but I find myself asking the question:
>is this our problem to solve at the moment?  Creating globally-unique
>identifiers which will live a very, very long time is a pretty tall
>order.
>
>   Perhaps we're trying to "boil the ocean" with this?

Yes and no.

We do have some problems with handles in todays internet:

  + They are not changed after an object is changed
  - They are not globally unique
  - One can not find an object only knowing the handle

The second issue is especially problematic because objects have been 
mirrored between the registries, so the same handle _might_ be the 
same record (but different copies), but can also be refering to two 
different objects in two different registries.

>   I kind of like the digest-based approach (although perhaps SHA-1
>would be a better choice than MD5).  The user can identify themselves
>via some relatively static information such as complete name,
>city and country of birth, date of birth, etc. and this results in
>a digest that should be guaranteed to be unique.  The user can
>easily reconstitute this identifier by supplying the source information,
>which they should know fairly well.
>
>   Its not clear to me however how this scheme would facilitate easy
>referencing of entities, so perhaps that's where this concept falls down.

I think this an interesting approach, but I like many others would 
like to have an agreement on what requirements we have on the 
handles. That is something which I claim is not boiling the ocean... 
(hit me if I am wrong).

My suggestion for requirements on objects:

  - The handle should not change during the lifetime of an object
  - It must be possible to move an object from one registrar to another
    without deleting one object and then creating a new one
  - One must be able to have one "person" object somewhere, which then
    can be referenced from several places (this means that a handle, or
    what I proposed: serverid + localid, identify a record, and one
    can then use the handle to find a record (what registry).

If we do it this way, separating serverid and localid, and call them 
concatenated "the handle", that means that we don't have to say 
anything at all about how the localid is created -- AND, it is also 
the format which for example RIPE already is using. "RIPE" is the 
serverid, and then it's up to RIPE to allocate the localid.

But, back to requirements.

      paf