Have you seen the updated RFC 4122 draft?
prehmis opened this issue · comments
It seems in April 2021 the draft was updated extensively.
Was wondering if the new proposed changes have any affect on your implementation of UUIDv6? Especially because the new draft proposes restrictions on the node bits which technically can render some V1 to V6 conversions invalid if the V1 UUID did not adhere to the V6 node bits restrictions?
As we are soon taking a system live which makes use of your v6 UUIDs, I was wondering if we need to make any changes to ensure the generated UUIDs comply with the new draft?
https://datatracker.ietf.org/doc/html/draft-peabody-dispatch-new-uuid-format
Oeps.. Used our App account to post my question..
There are 3 new UUID formats
https://www.ietf.org/id/draft-peabody-dispatch-new-uuid-format-03.html#name-new-formats
Thank you. I am familiar with them. 🙂
@ramsey I see the new proposal has been updated and now has a version 7 with the advice "Implementations SHOULD utilize UUID version 7 over UUID version 1 and 6 if possible"
Is your version 6 still in accordance with the newly proposed version 6 and do you have plans to add version 7 (and 8?) to your library?
My UUID 6 implementation is from a very early draft. I plan on implementing the new UUID 6, 7, and 8, but I don’t have a timeline.
Thank you for the feedback. I can only assume that the official V6 will not be backwards compatible with your V6.
We are about 4 weeks away from going live with a big project that incorporates your version 6 UUID as primary keys. How do you propose we proceed? We still have some time to make modifications, as I really do not want to have to change UUIDs of production data.
I am not worried about our UUIDs being validated by other systems, but more with the possibility that once the official v6 is supported by your code, we can no longer distinguish between the old v6 UUIDs and the new v6 UUIDs.
Is there anything I can do code wise? Contribute in some way or manner?
@ramsey when you eventually implement the new version 6, how can we distinguish the non-standard version 6 from the new version 6, seeing they both use the same version number? Can this be done via the variant bits?
I don't think there are significant-enough changes between the non-standard one and the standard one to warrant a need to distinguish them.
The variant bits for RFC 4122 RFCs are all the same, so those can't be used to distinguish a non-standard UUID from a standard UUID.
The new RFC does add a v8 UUID that is for the purpose of doing non-standard things, though, but that won't help in this situation.
Quick update, @pluk77 ...
I'm deprecating Ramsey\Uuid\Nonstandard\UuidV6 and adding Ramsey\Uuid\Rfc4122\UuidV6 (see the 4.x branch), and I'll be adding classes for UuidV7 and UuidV8 this week.
@ramsey Thank you for settling my mind. I am glad to read the following in the docs which I read as: I do not have to convert my non-standard v6 UUIDs (as they will break my referential integrity) and they will work side by side with the standard compliance v6 in the future. Which is a huge relieve!
Prior to version 4.0.0, ramsey/uuid provided a solution for this with the ordered-time codec. Use of the ordered-time codec is still valid and acceptable. However, you may replace UUIDs generated using the ordered-time codec with version 6 UUIDs. If you perform this conversion, the bytes and string representation of your UUIDs will change. This will break any software that expects your identifiers to be fixed.
@pluk77, I've just released version 4.5.0, which includes support for version 7 UUIDs. I would recommend upgrading and using version 7 UUIDs rather than version 6. 😄
More details here: https://uuid.ramsey.dev/en/4.5.0/rfc4122/version7.html