[Uuidrev] Re: new work for uuidrev

["Kyzer Davis (kydavis)" <[e-mail]>]

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] <mailto:[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] <mailto:[e-mail]> > 
Sent: Friday, May 17, 2024 3:46 PM
To: [e-mail] <mailto:[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] <mailto:[e-mail]> >   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide




-- 
Uuidrev mailing list -- [e-mail] <mailto:[e-mail]> 
To unsubscribe send an email to [e-mail] <mailto:[e-mail]>