2 ms·

I don't understand the OP's case for ULID over UUIDv7. > The main differences between UUIDv7 and ULID are: > * UUIDv7 > * UUIDv7 will work until 4,147AD wher

I don't understand the OP's case for ULID over UUIDv7. > The main differences between UUIDv7 and ULID are: > * UUIDv7 > * UUIDv7 will work until 4,147AD whereas ULID will work until 10,889AD Is the first bullet point a typo, missing something? So we're just left with the second one.... is that really a concern for anyone? Maybe the first bullet point was supposed to say that UUIDv7 explicitly exposes the fact that it's a UUIDv7, as the OP does mention that as another significant difference. To me that, and the fact that it is a UUID, seems enough reason to choose UUID7, when they are mostly otherwise pretty similar? If it's true UUIDv7 spec isn't finalized yet though, it would be nice if they'd finalize it.... ah. It appears to be a "Proposed Standard". I have trouble figuring out what's what in IETF standard-making terminology (starting with "everything's an RFC"!), but wikipedia suggests "Actual practice has been that full progression through the sequence of standards levels is typically quite rare, and most popular IETF protocols remain at Proposed Standard." So sounds like it can be considered a standard. I wonder why eg postgres hasn't implemented it yet in a built-in thing.

dwaite 4y ago
> I have trouble figuring out what's what in IETF standard-making terminology As one might expect, they have a best current practice for that: https://datatracker.ietf.org/doc/html/rfc2026 https://datatracker.ietf.org/doc/html/rfc2026 You have internet drafts and RFCs, where RFCs are assigned numbers and are immutable. Internet Drafts are time limited and typically used for work in progress. You have two tracks - informational (for things which are intended to document things but not be standards, including vendors documenting extensions to protocols) and standards track, which has maturity levels like proposed standard. You could say the goal of both tracks is interoperability, while standards track is motivated by having everyone's comments be heard and respected (to the degree possible). Labels like "proposed standard" are basically meant to mark the maturity in the standards process. A future revision might clarify or change the RFC, or the proposed standard might be replaced by something different. A more material example of this progression: HTTP/1.1 was released as: 1. RFC 2068 (proposed standard, January 1997) 2. RFC 2616 (draft standard, June 1999) 3. Reworked through the BIS process into several RFCs (7230-7235, proposed standards, June 2014) 4. Replaced by RFC 9110 and 9112 (and friends) (Internet Standard, STD 97, June 2022) But note these are all revisions of HTTP/1.1 - HTTP/2 and HTTP/3 have developed independently and have their own maturity levels. This is one of the ways that standards differ from software. There have been several documents about HTTP/1.1, all of which aimed to provide maximal backward compatibility with previous deployments, and to clarify and prescribe behavior where there were implementation, interoperability and operational difficulties identified. None of them were HTTP/1.2.

dwaite 4y ago

> I have trouble figuring out what's what in IETF standard-making terminology As one might expect, they have a best current practice for that: https://datatracker.ietf.org/doc/html/rfc2026 https://datatracker.ietf.org/doc/html/rfc2026 You have internet drafts and RFCs, where RFCs are assigned numbers and are immutable. Internet Drafts are time limited and typically used for work in progress. You have two tracks - informational (for things which are intended to document things but not be standards, including vendors documenting extensions to protocols) and standards track, which has maturity levels like proposed standard. You could say the goal of both tracks is interoperability, while standards track is motivated by having everyone's comments be heard and respected (to the degree possible). Labels like "proposed standard" are basically meant to mark the maturity in the standards process. A future revision might clarify or change the RFC, or the proposed standard might be replaced by something different. A more material example of this progression: HTTP/1.1 was released as: 1. RFC 2068 (proposed standard, January 1997) 2. RFC 2616 (draft standard, June 1999) 3. Reworked through the BIS process into several RFCs (7230-7235, proposed standards, June 2014) 4. Replaced by RFC 9110 and 9112 (and friends) (Internet Standard, STD 97, June 2022) But note these are all revisions of HTTP/1.1 - HTTP/2 and HTTP/3 have developed independently and have their own maturity levels. This is one of the ways that standards differ from software. There have been several documents about HTTP/1.1, all of which aimed to provide maximal backward compatibility with previous deployments, and to clarify and prescribe behavior where there were implementation, interoperability and operational difficulties identified. None of them were HTTP/1.2.