XRI canonical id question

[Drummond Reed]

>> On 10-Oct-06, at 11:00 AM, Drummond Reed wrote:
>> 
>> Again, this is why I recommend RPs don't even store the i-name, but  
>> instead
>> store their own display name for the user. The display name and the  
>> i-number
>> (CanonicalID) never need to change, whereas an i-name may be  
>> reassigned.
>
>Dick wrote:
>
>why would an i-name be reassigned?

Just like a domain name, an i-name registration can lapse and be returned
back into the name pool, where it can be registered by a different
registrant.

>why would an i-number not be reassigned?

I-numbers are functionally URNs. They are assigned once by a registry
(globally or at any level of delegation) and never reassigned. Even if the
registration lapses, it can only be renewed by the original registrant (or
their trustee).

I-numbers are one of the most unique features of XRI registries. See the
XDI.org Global Services Specifications at http://gss.xdi.org for much more
than you ever wanted to know about the policies around persistent identifier
management. Good lawyers took as many years as the technologists to come up
with this stuff ;-)

>who owns the i-number?

The original registrant - forever. Even if they die, they can appoint one or
more trustees to continue to own/manage the registration.

>I thought that who is authorative for an i-name was managed by a  
>registry that was separate from the i-broker, and that mechanism  
>provided the separation of identifier management from IdP.

It does. The same way domain name registrations are portable from one DNS
registrar to another, global i-name and i-number registration are portable
across IdPs (in XDI.org XRI infrastructure they are called i-brokers).

The role of the IdP/i-broker, like the role of a DNS registrar, is to
perform transactions with the registry on the registrant's behalf, i.e.,
register, update, delete, and transfer registrations.

=Drummond