New UUID formats have been approved

https://www.ietf.org/archive/id/draft-peabody-dispatch-new-uuid-format-01.html

by delduca • 2 years ago

70 33 2 years ago

rjh294• 2 years ago

In retrospect it is super obvious that you'd want a time-ordered UUID with a random offset. I wonder how they managed to screw up 5 iterations of UUID that were basically useless to most developers.

lytedev• 2 years ago

Basically useless

And yet, implemented across an incredible number of systems! Is it cargo culting? Was it "good enough"? Why do you think these "basically useless" mechanisms are/were so widely adopted and used?

userbinator• 2 years ago

In my experience, the vast majority of the time UUIDs are "implemented", they are just 16 randomly generated bytes; the important part is that they are unique.

rjh294• 2 years ago

Probably distributed computing was not common at the time, so a truly universally unique identifier was not needed. And UUIDs were not used as database keys so they did not need to be time ordered.

I still think they were quite naive. I mean, using MAC addresses in the UUID? Not great for privacy.

b33j0r2• 2 years ago

It’s the evolution of the internet. When is the last time you heard someone say WAN instead of cloud?

Lexicographically-sortable and universally-unique are the two desirable properties. Indexable would have saved mongo’s fate, if added up-front.

The funny thing is, no one was stopping us from using cuid or blid. I use ulids all the time for primary keys, and the query properties are simply exactly as advertised.

Annoying for monotonic to even be optional.

MiguelX4133• 2 years ago

Why would someone ever use “WAN” and “cloud” in an interchangeable manner?

cqqxo4zV46cp• 2 years ago

“5 iterations”.

That’s…not how it works. You’ve literally just taken “UUID6” and made a bunch of incorrect assumptions.

rjh294• 2 years ago

Explain.

j-pb3• 2 years ago

Imho the UUID format is a hopeless cause anyways. You don't want to waste any bits in a 128bit identifier on version metadata, UUID uses 4. With the birthday paradox that effectively decreases the collision resistance by a factor of 4. (2^64 vs. 2^62 elements for a collision probability of 0.5)

HelloNurse• 2 years ago

2^62 things are still a fairly large number for plausible systems.

tommiegannert2• 2 years ago

I don't follow. You (correctly) say UUID is 128 bits, but then talk about 64 bits being prone to collision.

EPWN3D• 2 years ago

I have no idea why it bothers me so much, but it bugs the shit out of me when people create temporary directories by creating a directory and stapling a UUID on the end of a base name, as opposed to the APIs that exist for that explicit purpose.

MiguelX4133• 2 years ago

What is that API called?

stanleydrew• 2 years ago

I was a bit confused because this document is a draft and I couldn't find any mention of "approval." But here's a link to the published RFC that obsoletes the original UUID RFC 4122:

https://www.rfc-editor.org/rfc/rfc9562

falcor84• 2 years ago

Thanks, that's what I was looking for.

@dang, could you please update the link to this?

cesarb• 2 years ago

The metadata about the linked document (https://www.ietf.org/archive/id/draft-peabody-dispatch-new-u...) is at https://datatracker.ietf.org/doc/draft-peabody-dispatch-new-... which shows that this is indeed a very old draft.

The linked document is version 01 of the draft, that draft went up to version 04 before being replaced by draft-ietf-uuidrev-rfc4122bis (https://datatracker.ietf.org/doc/draft-ietf-uuidrev-rfc4122b...), which then went up to version 14 before finally being approved as RFC 9562.

Sytten• 2 years ago

Lots of typos in this document:

The format for the 16-octet, 128-bit UUIDv6 is shown in Figure 2

Figure 2 is a uuidv7

UUIDv8 SHOULD only be utilized if an implementation cannot utilize UUIDv1, UUIDv6, or UUIDv8

Probably meant this say or uuidv7

Hopefully this has been fixed...

mudhad• 2 years ago

UUIDv8 SHOULD only be utilized if an implementation cannot utilize UUIDv1, UUIDv6, or UUIDv8

Did they mean UUIDv7 for the last one?

theandrewbailey• 2 years ago

I'm glad I wasn't the only one who noticed that. As written, it makes no sense.

clwg• 2 years ago

I'm curious as to why they initially chose the Gregorian calendar for dates and then stuck with it for the v6 implementation.

drtgh• 2 years ago

The clocks of systems using this UUIDs may at some point use an external NTP server for synchronization, and may cause problems without something being designed to check this (e.g. older and overflow time stamps).

Take care.

New UUID formats have been approved

Related Stories