[Uuidrev] Re: new work for uuidrev

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

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