Where do UUID namespaces come from?

The UUID specification defines 4 predefined namespaces which it describes as "potentially interesting" - meaning among other things, "if other people have generated UUIDs in this namespace you can verify them":

• 6ba7b810-9dad-11d1-80b4-00c04fd430c8 for DNS
• 6ba7b811-9dad-11d1-80b4-00c04fd430c8 for URL
• 6ba7b812-9dad-11d1-80b4-00c04fd430c8 for ISO OID
• 6ba7b814-9dad-11d1-80b4-00c04fd430c8 for X.500 DN

Where did these come from?

Specifically;

• If I'm generating my own namespace UUID do I need to avoid 开发者_开发技巧anything in particular?
• I'm aware how big the UUID space is, but does this have any implication on collisions?
• Why have they chosen the 4th octet to increase as a kind of UUID 'version number'?
• Do my questions imply that I'm missing something fundamental about UUIDs?

First, to be clear, this whole discussion is limited to version 3 & 5 UUIDs. In my (anecdotal) experience, version 4 (random) UUIDs are most commonly used.

4122's namespaced UUID generation algorithm ambiguously begins:

Allocate a UUID to use as a "name space ID"

There is no other mention of "name space ID" allocation, and neither I nor python have found any standardized spaces beyond the four listed in RFC 4122.

So the answer to your first question,

• If I'm generating my own namespace UUID do I need to avoid anything in particular?

You only need to avoid the four standard namespaces.

The next question,

• I'm aware how big the UUID space is, but does this have any implication on collisions?

Has two parts:

1. Will UUIDs within your namespace collide? Verbatim from 4122:

   The UUIDs generated from two different names in [your] namespace should be different (with very high probability).

2. Will your namespace UUID collide with other namespaces? I couldn't find a direct answer, since there's no standard for "name space ID" allocation, but the argument in section 4.1.1 seems relevant:

   Interoperability, in any form, with variants other than the one defined here is not guaranteed, and is not likely to be an issue in practice.

• Why have they chosen the 4th octet to increase as a kind of UUID 'version number'?

This one's a bit of a mystery. Luckily, we have a spec for UUIDs, so we can mine them for some insight.

Note that the (0-index) 8th octet starts with 8 in all cases, so we're dealing with RFC 4122 variant UUIDs. Phew.

Now check octet 6 for the version: 1, we're dealing with version 1 time-based UUIDs.

This answer has a handy algorithm for extracting python datetimes from version 1 UUIDs. Applying the algorithm yields a time in February 4th, 1998. I have yet to find meaning in this date. Incrementing the 3rd octet adds the smallest encodable time interval (100ns) to the date.

• Do my questions imply that I'm missing something fundamental about UUIDs?

Nope. There is very little discussion of UUID namespaces, since random UUIDs are so easy.

If I'm generating my own namespace UUID do I need to avoid anything in particular?

No. Your namespace UUID can be any UUID generated in any of the normal ways. So, for example, you would probably want to generate a version 1 or version 4 UUID to use as your namespace UUID. This can be done with the uuidgen program on Linux or OS X. Or you can easily generate a version 1 or version 4 UUID online.