Discussion: UUID URN Extension

[kyzer-davis]

All things UUID URN as a way to convey extra information about the underlying UUID value.

The current problem that needs solved, which are introduced via alternate encoding and a longer UUID length is as I described earlier:

• How does a system advertise Length of the UUID since it could be 128+ (UUID Long).
• How does a system advertise the Encoding of the UUID since it could be variable (if more than one encoding type is allowed by the spec which it is as per my WIP Draft 00.)

Key things to keep in mind:

• Both advertisement methods should be decoupled from the underlying UUID as it would be obfuscated by the encoding.
• Both Methods should be usable at the same time. e.g I could have a UUIDv4 160-bit UUID long encoded as Crockford's base 32.
• The method selected MUST be backwards compatible with existing UUID format, length and encoding from RFC4122.

---

Edit: The main goal of the proposed URN extension in early draft-00 for this spec is to extend the already allocated IANA UUID URN and describe length and encoding in a way that decouples it from the UUID and is compatible with all UUIDs and URNs out there today.

---

See my previous comment for rational behind placement of current values in UUID URN:
#2 (comment)

[kyzer-davis]

Tossing in my 2 cents:

• An Extended UUID URN is just one method that could be used to describe the encoding/length of the UUID.
• As Sergy and Brad have specified. One could send this data as JSON + the UUID:

{
    "new_uuid": {
        "uuid": "73e94fe0-e951-4153-aaf3-50e4e6089d9d",
        "length": "128",
        "encoding": "base16hd"
    }
}

As such the draft should also specify something like this as an alternative to URN if an implementation desires.

[sergeyprokhorenko]

I think the JSON description of the UUID should:

• have its own identifier;
• describe encoding method and the structure of the UUID, the sequence and parameters of each segment, including segment type and length, time stamp precision, incrementability, initialization value type, sources of time, leap seconds, node name and randomness data, etc.;
• be passed as a parameter to the UUID generation and parsing functions, as well as to descriptions of types of fields in database tables;
• be transmitted and stored separately from each UUID in order to reduce memory consumption and improve performance;
• use the key naming convention and constant values described in this standard;
• describe attached UUID metadata on par with regular UUID segments.

With such a detailed and flexible description of the UUID, there is no need to specify the version and variant.

I also think we need a naming convention for functions for generating, parsing, changing the encoding, hash function (to 128 bits) and other UUID manipulations.

We should drop the requirement that the length of UUID segments be divisible by 8, 4, 5, etc.

We should drop the requirement for millisecond accuracy, as it is not enough inside the data processing center. Maybe 10 microseconds would be better. Let the implementer decide.

We may recommend different JSON descriptions of the UUID for different purposes and circumstances as well as the default layout for most uses.

[kyzer-davis]

We should drop the requirement for millisecond accuracy, as it is not enough inside the data processing center. Maybe 10 microseconds would be better. Let the implementer decide.

Different draft spec; this topic is not valid for this document.

We should drop the requirement that the length of UUID segments be divisible by 8, 4, 5, etc.

Natural byte boundaries make sense as a general recommendation. But you are adding way more discussions to this thread than the original purpose. Remember to keep on topic, we are discussing URN extension only here.

With such a detailed and flexible description of the UUID, there is no need to specify the version and variant.

Another off topic: This specific spec will make no changes to UUID var/ver in it's current form.

---

Otherwise, yeah, nothing stopping you from doing the rest of the things you said.

The main goal of the proposed URN extension in this spec is to provide a "well-known with UUID" standards-based method of solve two problems below for features introduced by this draft spec:

• Advertise Length of the UUID since it could be 128+ (UUID Long)
• Advertise the Encoding of the UUID since it could be variable (if more than one encoding type is allowed by the spec.)

The point I was making is that the text should specify that it is valid for somebody to use JSON (or any data structure: XML, YAML, SDP, GPB, BSON, etc.) as an alternative to an Extended UUID URN for conveying the two points above. Anything else they want to convey in that alternative format is up to the implementation and beyond the scope of what the problems the UUID URN extension is trying to solve.

[sergeyprokhorenko]

@kyzer-davis, You set insignificant goals that do not require the development of a new standard at all. The already published draft is enough. After all, no one forbids adding metadata to the right of the UUID (for example, they already add a checksum) or showing the UUID in any encoding. Such insignificant goals will not inspire enthusiasts. Therefore, this venture is doomed.

But you overlooked the great potential of describing a detailed UUID structure (in JSON format) apart from the UUID itself and apart from the standard and the great potential of using that UUID structure description as a parameter to a function that generates a UUID.

[kyzer-davis]

you overlooked the great potential of describing a detailed UUID structure (in JSON format) apart from the UUID itself and apart from the standard and the great potential of using that UUID structure description as a parameter to a function that generates a UUID.

I think you misunderstand, I am not saying the idea has no merit at all. I just don't see a reason for it to be a part of the Draft for v6/7/8/max or within this draft which deals solely with documenting how implementers can utilize alternate encoding techniques and variable length/longer length UUIDs. After all, the reason we split these two topics out is due to scope creep of the original draft. If we keep adding topics the drafts will never be complete (and I have already been working on them for 2 years).

---

With that I will defer to others in the community for further feedback on your proposal:

• Is describing every segment of a UUID 1 through 5 and 6/7/8 in their final form as a JSON data structure; which can be passed to UUID Generators or UUID Parser, something of benefit and a problem that needs solving?
• If we get traction that it would be useful and solves some technical problems we have with UUID at the moment I am happy to discuss adding it to this spec or a spec of it's own.