uuid
uuid copied to clipboard
ramsey
Have you seen the updated RFC 4122 draft?
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
There are 3 new UUID formats
https://www.ietf.org/id/draft-peabody-dispatch-new-uuid-format-03.html#name-new-formats
@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.
@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.
That does sound like good news and I am grateful for all your hard work.
We will be OK as long as your library can retrospectively work with the non standard version 6 data we are about to generate. Would hate to be forced to change all our uuids in a year or two because they are regarded as invalid v6 versions by the new algorithms.
On Thu, 08 Sep 2022, 17:59 Ben Ramsey, @.***> wrote:
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.
— Reply to this email directly, view it on GitHub https://github.com/ramsey/uuid/issues/385#issuecomment-1240913728, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAD77E632WQKNPN27MBE47DV5IENPANCNFSM5CLOS6IQ . You are receiving this because you commented.Message ID: @.***>
If I clone and branch the library and re-name the non standard v6 to v8 in the library, will that keep me RFC compliant? I am about 3 weeks away from a point of no return in my development so any change will have to be made soon.
On Thu, 08 Sep 2022, 17:59 Ben Ramsey, @.***> wrote:
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.
— Reply to this email directly, view it on GitHub https://github.com/ramsey/uuid/issues/385#issuecomment-1240913728, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAD77E632WQKNPN27MBE47DV5IENPANCNFSM5CLOS6IQ . You are receiving this because you commented.Message ID: @.***>
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