[Uuidrev] Re: new work for uuidrev

[Ben <[e-mail]>]

Hi Jim,

There is not any time urgency that I'm aware of either, but in my 
opinion I would suggest to start some process, unless there is reason to 
wait for something of course.

I think I'm okay with some interim charter. Having a list of things and 
their motivation sounds good to me and could help in the future.

Ben

Jim Fenton schreef op 2024-06-06 12:29:
> 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]