[Uuidrev] Re: new work for uuidrev

[Orie Steele <[e-mail]>]

Chartering will be easier with a set of developed drafts to frame the work.

I would suggest not waiting to develop drafts, you can share them for
feedback on this list.

We can use the new documents as initial milestones for the charter.

A few things we cannot do until we have a new charter are adopt documents
or send them to IESG for publication, or host official wg meetings,
although we can do side meetings.

I'd also like to understand if there will be a continuous stream of
documents, or if only a few milestones are planned.

If you wish, you can also work together to revise the charter, and
establish support for it, on this list.

I would prefer a charter with a narrow set of deliverables, and clear
indication to recharter when they are complete.

I don't think we need to "leave room" for doing unplanned work, unless we
think the group will be a long lived working group with continuous
operations.

Regards,

OS, ART AD


On Thu, Jun 6, 2024, 6:29 AM Jim Fenton <[e-mail]> wrote:

> 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]
>
> --
> Uuidrev mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>