[Uuidrev] Re: new work for uuidrev

[Ben <[e-mail]>]

Hello all,

So what is the plan? Do we recharter now? Do we recharter in 2025? I 
think we have enough discussion points to publish another RFC and we 
don't have eternal life, so... I (and others likely too) want to know if 
we can start to work on something. At least for me, I want to have 
things officially published as soon as possible, because some of these 
things are documentated like shit or not documentated at all.

Thanks in advance

Ben

Kyzer Davis (kydavis) schreef op 2024-05-20 16:03:
> Yep, using the variant to signal this is one such approach we could
> take.
> 
> That topic has been discussed on our old GitHub issue tracker a few
> times.
> 
> The remaining unused variant can easily be split into two parts as to
> not hog the only remaining UUID Variant. e.g 0xE (0b1110) and 0xF
> (0b1111)
> 
> A variable length/extended UUID could leverage either (I also believe
> we can make it work with the existing IETF variant/versions but I
> digress.)
> 
> I am sure there are pros/cons to using existing, 0xE or 0xF that we
> would need to think through, however, I cast my vote for the 0xF
> Variant since I think it will make programmatically parsing UUIDs
> easier. e.g Var 0x0-0xE are 128 bits while Var 0xF are 128+. This also
> allows “Max UUID” to stay as the upper bound for 128 bit UUIDs.
> 
> Within F variant we can have a new sub-versioning system with more
> bits, in a better place and even a new sub-variant system if we feel
> further bit segmentation is required.
> 
> See below for some back of the envelope 0xF proposals where X are
> current 128 UUID bits and M (sub-variant) or N (sub-version) slotted
> at position 129+ and YYYY…YYYY is extended UUID data beyond
> sVar/sVer.
> 
> ### Just Sub-Versions (N):
> 
> - 256 sub-Versions (0x00-0xFF):
> 
> xxxxxxxx-xxxx-xxxx-Fxxx-xxxxxxxxxxxx-NN-yyyy…yyyy
> 
> - 65,536 Sub-Versions (0x0000-0xFFFF):
> 
> xxxxxxxx-xxxx-xxxx-Fxxx-xxxxxxxxxxxx-NNNN-yyyy…yyyy
> 
> ### Sub-Variants (M) and Sub-Versions (N):
> 
> - 256 Sub-Variant / 256 sub-Versions
> 
> xxxxxxxx-xxxx-xxxx-Fxxx-xxxxxxxxxxxx-MMNN-yyyy…yyyy
> 
> - 65,536 Sub-Variant / 65,536 Sub-Versions:
> 
> xxxxxxxx-xxxx-xxxx-Fxxx-xxxxxxxxxxxx-MMMM-NNNN-yyyy…yyyy
> 
> Thanks,
> 
> Kyzer Davis
> 
> From: connor horman <[e-mail]>
> Sent: Friday, May 17, 2024 5:33 PM
> To: Kyzer Davis (kydavis) <kydavis=[e-mail]>
> Cc: Michael Richardson <[e-mail]>; [e-mail]
> Subject: [Uuidrev] Re: new work for uuidrev
> 
> 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]