Use of i-numbers (was RE: Consolidated Delegate Proposal)

[Drummond Reed]

>Martin wrote:
>
>I think this is the intention, though it does show an interesting 
>inconsistency between the use of XRIs and the use of i-numbers. I 
>currently have three URL-based identifiers all pointing at the same 
>server and the same Yadis document, yet those identifiers are distinct. 
>However, in the comparable XRI case, it would appear that those 
>identifiers would all be considered to be the same.

If they point to the exact same XRDS document with the same i-number as the
CanonicalID, that would establish all three URLs and the CanonicalID
i-number as synonyms (yes, it is possible to have URLs and XRIs that are
synonyms). In XRI Resolution 2.0 Working Draft 11 we are adding a new
BackRef element that will enable an XRDS document to back reference any type
of identifier that points to it, such as a URL, so you can machine-verify
the back reference if you want.

If you wanted to keep the three URLs as distinct, separate identities, point
them at three different XRDS documents with different i-numbers.

>I wonder how easy it is to get hold of new i-numbers. If they are 
>basically "throw-away" cheap, then I'm able to decide for myself how to 
>distribute my mappings to separate them. However, if these i-numbers are 
>going to be "expensive" (for some sense of the word) to aquire, I've got 
>less freedom in this respect. Drummond?

The short answer is that delegated i-numbers (and this is the federated
identifier meaning of the term "delegation") are as "throw-away" cheap as
URL (at the path level), third-level DNS names, or any other form of
delegated identifier. The "cost" is all in resolution, i.e., someone
somewhere maintaining a registry that will point you to the XRDS document if
you resolve it. 

=Drummond