[Uuidrev] Re: new work for uuidrev

[Jim Fenton <[e-mail]>]

I was planning to huddle with Michael and the ADs at IETF in Vancouver the end of July. I was unaware there is any time urgency to this. Is there any?

One thing that might be useful in the interim is a new charter in the style of the existing charter listing the things to be added or changed and motivations for doing so.

-Jim

> On Jun 6, 2024, at 9:08 PM, Ben <ben=[e-mail]> wrote:
> 
> 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]
> 
> --
> Uuidrev mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]