Subject: Re: [dispatch] UUID Version 6 Proposal

From: Brad Peabody <[email-masked]>
Date: Mon, 2 Mar 2020 11:54:22 -0800

Thanks Dale.  This first draft was intended to clearly outline the 
problem, since the initial feedback I received on this idea from general 
mailing list could be summarized as "why do we need this".

I agree with your point though, it needs more detail.  I will make it my 
next step on this to outline the specific fields.  Even if I refer to 
RFC 4122 I think summarizing what goes where in this document makes good 
sense.

Best, Brad

On 2/28/20 7:52 PM, Dale R. Worley wrote:
> Brad Peabody <[email-masked]> writes:
>> I recently submitted a draft proposal to update the UUID specification.
>> https://datatracker.ietf.org/doc/draft-peabody-dispatch-new-uuid-format/
> The proposal sounds good to me.  But upon skimming the document, I don't
> see any single place where it asserts how this format of UUID is created
> -- what the fields are and how their values are determined.  You talk
> about it but you don't specify it.  Now I think you can do it by
> referring to the figure in section 4.1.2 of RFC 4122 and detailing
> exactly what goes in the fields it lists.
>
> Dale

----

On 2/29/20 1:08 AM, Rick van Rein wrote:

> I'm not convinced that more syntax is helpful; 128 bits suffice for
> global uniqueness, say cryptography and the net's experience.  A dense
> enough notation should make this usable, and I think effort would be
> better spent towards compression.  In the example above, the node
> identities might follow a variable-bits scheme to which the clock
> resolution responds or, as described above, the time/orderno may help to
> decide how many of the low bits count as a node identity.
>
This point went back and forth previously on the general mailing list.  
The conclusion I've come to is that if the binary layout changes in an 
incompatible way then it's not a UUID.  And while this is an option, 
it's undoubtedly going to add more time and complexity to the 
standardization process.  There are many existing non-UUID random value 
generation schemes out there (e.g. ULID https://github.com/ulid/spec). 
It's difficult to say which one(s) should or shouldn't be standardized.  
My perspective on this is that since we already have UUIDs as an RFC, 
and people are already using them as database keys and running into the 
problems outlined in the existing draft, why not propose an incremental 
change to resolve these issues.

There are lots of details in the binary layout that are pretty much moot 
when it comes to using the UUID after it is generated. Few if any UUID 
implementations look at the clock sequence or node fields as anything 
except opaque bytes.  So the changes I'm proposing to the binary data 
will be compatible with the vast majority of existing software.

It's true that the text representation is a big change.  But I don't 
think it is a fundamentally incompatible one.  Existing software storing 
UUIDs in binary can continue to function as-is, but then when some layer 
of the code wants to put the UUID in a URL they can do so in a standard 
and more compact way.  The rest the software can continue to function 
as-is.  Not so if the binary layout is changed in an incompatible way 
(such as using BER or providing variable lengths, etc.)