uuid6-ietf-draft VS uuid7-csharp

https://github.com/uuid6/uuid6-ietf-draft/issues/27

Why not UUIDv7?

What if a new UUID version could be designed that would take the randomness of UUID4 and combine it with a timestamp prefix? This would make the UUID increase overall, but not locally – due to the random postfix. The random part ensures uniqueness when a high generation rate is necessary and also makes the UUIDs hard to predict – it’s not possible to guess the previous, or next UUID. It’s fairly simple to devise a custom UUID scheme, but fortunately, there is a new Internet-Draft (at the time of writing) defining new pseudo-sequential UUID versions that aim to solve exactly this issue: draft-peabody-dispatch-new-uuid-format-04. The current state and progress can be viewed at IETF Datatracker.

Brad Peabody did the original -00 draft, which was discussed as an FYI at an IEFT meeting in March 2020. See [1], around 50 lines from the bottom.

Kyzer Davis has since submitted two further revisions -01 and -02 in April and October 2021. See history in [2].

The current -02 draft is due to expire in April 2022. Presumably Kyzer Davis will try to get it discussed before then.

The GitHub repo tracking these drafts is https://github.com/uuid6/uuid6-ietf-draft/.

[1] https://datatracker.ietf.org/meeting/107/materials/minutes-1...

[2] https://datatracker.ietf.org/doc/draft-peabody-dispatch-new-...

At the moment anyway, that XML link won't render per an XML parsing error. For anyone who wants a quick look at what these XML docs look like here's one for UUID6 [0].

[0] https://github.com/uuid6/uuid6-ietf-draft/blob/master/draft-...

3. IDs don't use L and O because those can be confused for other characters

I've found it very handy in my travels.

[1] https://github.com/stevesimmons/uuid7-csharp?tab=readme-ov-f...

To summarise the differences:

* UUIDv6 - sortable, with a layout matching UUIDv1 for backward compatibility, except the time chunks have been reordered so the uuid sorts chronologically

* UUIDv7 - sortable, based on nanoseconds since the Unix epoch. Simpler layout than UUIDv6 and more flexibility about the number of bits allocated to the time part versus sequence and randomness. The nice aspect here is the uuids sort chronologically even when created by systems using different numbers of time bits.

* UUIDv8 - more flexibility for layout. Should only be used if UUIDv6/7 aren't suitable. Which of course makes them specific to that one application which knows how to encode/decode them.

UUIDv7 is thus the better choice in general.

(I recently wrote Python and C# implementations - https://github.com/stevesimmons/uuid7 and https://github.com/stevesimmons/uuid7-csharp)