In XDI, we use UUIDs to generate Cloud Numbers, e.g.:
[=]!:uuid:06d1ef2b-5499-401a-ac88-89f637f83803
The ones we have registered so far in the Neustar OTE registry are all "type 4" UUIDs as specified by the RFC:
This means that 6 out of the 128 bits are constant, while all others are random.
The consequence is that the first bold character indicated above will always be 4.
And the second bold character indicated above will always be >= 8.
In order to map old I-Numbers to Cloud Numbers, we currently "double" them, e.g.:
[=]!:uuid:86128447-0cac-f315-8612-84470cacf315
This approach seems to violate the UUID RFC. As an alternative we could:
1. Use a "magic number" that is constant and identifies old I-Numbers, e.g:
[=]!:uuid:86128447-0cac-f315-1234-567890abcdef
2. With a "variant" of option 1, our UUIDs could actually have the constant 6 bits of "type 4" UUIDs:
[=]!:uuid:86128447-0cac-4321-fedc-f315ba987650
3. Or we could use some other information from the registry and encode it in the UUID, e.g. the I-Number's registration date:
[=]!:uuid:86128447-0cac-f315-2007-011312300000
4. Or we somehow add additional new, unrelated "type 4" Cloud Numbers to the registry that would live side by side with the old I-Numbers.
I believe only this last approach would be an "allowed" use of UUIDs with regard to the RFC.
But it would also mean an additional engineering task primarily on the Neustar side of things.
The other approaches all have the problem that they are either not fully random, or that they don't have the required constant 6 bits.
In any case, our requirements here are that the mapping between old I-Numbers and new Cloud Numbers must be
bidirectional and unambiguous, and that old I-Numbers in the registry do not change.
---------------------------------
Another place in XDI where we are not using UUIDs right now, but where we could use them, is for members of a collection in certain situations.
For example, in XDI Discovery we currently represent a collection of URIs as follows:
Here, the member identifier (the long SHA-512 value) is derived from the literal value.
I was planning to do something similar for storing verified phone numbers and e-mail addresses in the Respect Network Member Graph.
Instead of doing that, we could use "type 3" or "type 5" UUIDs, which are also derived from the hash of a string.
But I think in this case the way we are currently doing it is just fine.
Markus