Have just one new UUID version rather than three(?)

[broofa]

Playing Devil's Advocate: One of my first impressions of this proposal is that introducing three new versions seems "excessive".

Collectively, these three versions introduce a number of much-needed improvements. However I'm not entirely clear on what purpose the multiple versions serve. 'Seems like this is unnecessarily complicating the development of this spec.

For example, I would suggest the spec for version 7 provides the most value at present. It supports Unix timestamps, db-friendly byte-ordering, arbitrary sub-second resolution, and prohibits the use of MAC addresses, all of which are great. I.e. This is pretty obviously what most applications that need timestamp UUIDs should be using moving forward.

Meanwhile version 6 has nothing to recommend it over version 1 other than the reordering of time_* fields. I assume the nominal use case for this is to make it trivial to migrate version 1 uuids to a more db-friendly form? But I don't think that actually works because v6 currently prohibits the use of MAC addresses in the node field. Thus, converting from v1 -> v6 will be necessarily non-deterministic. (The node field will have to be set randomly in order to remain in compliance with this spec, since there's no way of knowing for sure that the v1 node is not a MAC Address.)

For anyone wanting to convert v1 uuids to v6 across a large, distributed system, that's going to be a huge issue.

As for version 8... well, I confess I don't really understand the use case for this yet. My first impression is that it's so abstract as to be almost meaningless. Technically, you could have a single timestamp bit ("The Boolean Epoch"?!?) with 121 bits of random data and still conform to the spec, no? I suppose (???) there's some value in allowing for arbitrary timestamp epoch/resolution/random bit construction of uuids but a spec that starts with, "The only explicitly defined bits are the Version and Variant leaving 122 bits for implementation specific time-based UUIDs" doesn't seem like much of a spec. It's more just a hand-wavy catchall that's going to invite people to create ad-hoc, proprietary sub-versions.

"It's a version 8 UUID, but we [Blargle Fargle Inc.] set bits 73-78 to b110011 for our PulsyWulsy™ blood oximeter product."

See also #29.

[edo1]

Meanwhile version 6 has nothing to recommend it over version 1 other than the reordering of time_* fields.

For now, the best practice is to use v4 in the generic cases, and use v5 in those rare cases when a reproducible identifier is required. IMHO UUID v1 has design flaws and shouldn't be used at all. So reinventing it as v6 seems like a bad idea to me.

As for version 8... well, I confess I don't really understand the use case for this yet. My first impression is that it's so abstract as to be almost meaningless.

Definitely

For example, I would suggest the spec for version 7 provides the most value at present. It supports Unix timestamps, db-friendly byte-ordering, arbitrary sub-second resolution, and prohibits the use of MAC addresses, all of which are great. I.e. This is pretty obviously what most applications that need timestamp UUIDs should be using moving forward.

Agree

[kyzer-davis]

Providing some history of the drafts:

• UUIDv6 started as a bit modification of UUIDv1 in Brad's pre-draft and IETF draft 00.
• Before draft 01, Brad and I met and came up with UUIDv7 as the better version improving on anything we can but felt UUIDv6 still makes sense and would be the easiest to implement if systems already using UUIDv1. Plus there are already a good number of folks doing this bit modification already in various libraries. We figured we might as well detail it and make it official. It is already written out so I don't see a reason to remove it.
• UUIDv7 is still the one with the most work occurring and will likely be the focus for future draft iterations.
• Lastly, during creation of draft 01 I theorized UUIDv6 or even UUIDv7 wouldn't satisfy everybody (see our issue tracker lately in the past few days!). So I proposed we relax everything and create UUIDv8 which is "122 bits to do whatever you want with when creating a time-based sortable unique identifier." We can continue discussion of UUIDv8 in #31

Edit: fixed unclosed quotes

[edo1]

UUIDv7 is still the one with the most work occurring and will likely be the focus for future draft iterations.

I understand. This is the reason why issue #29 was created

It is already written out so I don't see a reason to remove it.

I believe, RFC should describe best practices, not all possible ways. IMHO all new projects should abandon v6 in favor of v7. Thus, v6 will be de facto deprecated at the time the RFC is published.

Of course, this is just an opinion. I cannot insist.

[broofa]

@kyzer-davis Thanks for the backstory. That's helpful.

there are already a good number of folks doing this bit modification already

First of all, the number of folks doing this is a minute fraction of the eventual audience this spec will impact. RFCs should be inspired by existing work, but they should be designed for the audience they will eventually impact. If there are flaws in the prior art that inform an RFC, those flaws should be addressed by the RFC... and I believe there are real flaws here.

Specifically, these folks that are doing v1->v6 "modifications", are they doing anything more than swapping the timestamp fields around? If so, they are at risk of generating non-compliant version 6 UUIDs.

• Version 1 node may be a MAC address
• Version 6 node may NOT be a MAC address
• MAC addresses are not easily distinguishable from random values, and vice-versa.
• Thus, the only way to guarantee a v6 uuid derived from a v1 uuid is valid (does not violate the "no MAC addresses!" prohibition) is to assign a new, random node value as part of the modification.

Assigning a new node value is effectively generating a new uuid, however (albeit with the same timestamp). Hence the argument that @edo1 and I are making, which is that these users would be better served by generating v7 UUIDs.

[kyzer-davis]

@broofa, I think your last comment in this issue is now sufficiently covered in Draft 03 text. Re-reading this thread reminds me a bit of our longer discussion over on #52 so this one could be served as a duplicate.

Either way, let me know if you think otherwise or if we can close this one out when we merge that PR.

[broofa]

I need to review the latest edits, but I think we can close this out. I'll raise any new concerns in review comments or other existing issues.