Astrid Holm

My whole argument concerns a specific decision: random identifiers are fine for a message identifier and poor for a database key, and the two cases are constantly conflated. The collision arithmetic explains the difference. A 128-bit random value has enough entropy that collisions are irrelevant at any scale a single system will reach. Insert one into a B-tree index, though, and every insert lands at a random position across the whole keyspace, so the index takes random page reads instead of appending to the right-hand edge. That is a storage effect rather than a correctness one, and it shows up as write latency long before anything breaks. The versions differ in where the bits come from. The first derives from a timestamp and a node identifier, which leaks both when a value was made and where it was made, and the node field is a hardware address. v3 and v5 hash a namespace and a name, so the same name always gives the same identifier, which is useful for content addressing and useless where you need uniqueness. v4 is random. v7 leads with a millisecond timestamp and fills the rest with randomness, which keeps uniqueness while restoring insert locality. v6 is the same idea with the timestamp reordered. v8 is left for application-defined schemes. Nil is a reserved value that must not be generated. RFC 9562 superseded the earlier specification and settled the bit layouts, so older notes on version numbering are worth discarding. I cover parsing as well, because the three forms, hyphenated, braced and unhyphenated, all appear in real files and validators disagree about which are legal.