Search code examples
javapythonuuid

is namespace mandatory in a uuid5 implementation?

I'm trying to test various implementations of uuid5 with java and using python as a reference implementation since it's provided by the corelibs. however, it looks like python's uuid5 requires a namespace uuid passed as the first parameter. "None" will not work. however, Java's com.fasterxml.uuid.Generators nameBasedGenerator will accept a "null" for namespace. Which is correct? Is there a concept of a "global" or "default" namespace for uuid5 generation.

Solution

  • Is there a concept of a "global" or "default" namespace for uuid5 generation.

    There is no such concept in the UUID RFC. The namespace represents the naming system from which the names you are using will be drawn. There is no universal naming system, so it makes no sense to talk about a "global" namespace. There are however some standard namespace UUIDs. They are documented in RFC 4122 Appendix C

    Python's uuid5 requires a namespace uuid passed as the first parameter. None will not work. However, Java's com.fasterxml.uuid.Generators nameBasedGenerator will accept a null for namespace

    The com.fasterxml.uuid.Generators API is not a standard Java API. The standard Java API for UUIDs is java.util.UUID but it doesn't support type 5 UUID generation.

    Which is correct?

    I looked at the code of com.fasterxml.uuid.Generators. If a null namespace is provided, it skips the step of concatenating the namespace UUID with the name. This doesn't accord with type 3 / 5 algorithm set out in RFC 4122 Section 4.3, so technically it is not correct.

    However, this deviation from the RFC shouldn't break anything. It won't generate UUID collisions at a higher rate than you would normally expect for type 3 / 5 UUIDs. I would be inclined to call this a harmless (albeit non-standard) extension.

    So ...

    Is namespace mandatory in a uuid5 implementation?

    The RFC doesn't state that the namespace is mandatory, or what to do if it is not provided. UUID generation APIs in general, and this API's behavior in particular are beyond the scope of the RFC as currently written.