[Uuidrev] Re: new work for uuidrev

[connor horman <[e-mail]>]

If there's available space, I might recommend a new variant for long-form
UUID. That way, if the original portion of the UUID is first, a binary
coding scheme could use the variant to distinguish between the two forms.

Variant value `E` seems to be fully reserved and unused (111x in general,
but 1111 is used by the MAX Sentinel UUID) and could take that
responsibility. The trade off is you'd also want a way to describe the
total size of the extra data if we're otherwise distinguishing between
"IETF" and "IETF Extended".

On Fri, 17 May 2024 at 16:33, Kyzer Davis (kydavis) <kydavis=
[e-mail]> wrote:

> Eh, use this list of topics from my original email instead:
>
> Specifically, there are 2-3 documents I would like to deliver in a
> recharter.
> ### 1. Historical UUIDs:
> - Which covers the non-IETF variants (Apollo, Microsoft and maybe OSF/DCE
> UUIDv2).
>
> - Mostly because these source documents are slowly being lost to time and
> writing them down in an RFC seems like the right thing to do.
>
> ### 2. Alternate Human-readable UUID Encoding:
> - This is one of the core items from the original "uuidv6" draft that was
> cut
> to keep the document focused.
>
> - We have had folks passionate that the "human readable form" of UUID can
> be
> better optimized while keeping the properties that we know and love.
>
> - After all, UUID is just 128 bits. We should easily be able to produce a
> way
> to encode that in as text, that is as striking as the 8-4-4-4-12 but is
> also
> more efficient than encoding a 128 bit value as a 288 bit value.
>
> ### 3. UUID Long/Variable Length UUIDs:
> - A topic that has come up time and time again while working on the
> uuidv6/7/8 was "In 202x is 128 bits enough"?
>
> - During rfc4122bis we saw with some of our SHA1 (and even v8 SHA256 work)
> that we had to truncate the hash, which could pose some long-term
> collision
> issues.
>
> - Further, in about every convo possible, everybody wanted "more entropy"
> or
> "more bits to encode data".
>         - UUID long would be "Any UUID longer than 128 bits" and we can
> define
> UUIDv1-8 definitions for UUID Long (and other general guidelines for the
> new
> bits)
>
> - I foresee great interest in a proper spec-based 256 bit UUIDv4 and
> likely
> some further interest in UUIDv5 and UUIDv7 as those are the other two
> items
> where people really wish they could have more random bits.
>
> ---
>
> For item #1: Ben and I are waiting for the green light to start compiling
> the
> information in a "RFC9562-like" format. I advised we wait for the
> recharter.
>
> For item #2 and #3: The original text from Brad and I's draft, which was
> split
> out to stop the scope creep, has been preserved in the following document,
> which has not yet been submitted to IETF:
> https://uuid6.github.io/new-uuid-encoding-techniques-ietf-draft/draft-00/
>
> Thanks,
>
> -----Original Message-----
> From: Michael Richardson <[e-mail]>
> Sent: Friday, May 17, 2024 3:46 PM
> To: [e-mail]
> Subject: [Uuidrev] new work for uuidrev
>
>
> In a few emails, I have heard two things that were outstanding:
>
> 1) documenting historical DCE/MS/IBM/.. uses of uuid.
> 2) creating a UUIDv2 that would be longer than 128-bits.
>
> Three things were mentioned, but I'm not sure what the third is.
>
> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
> --
> Uuidrev mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>