Re: UUID version 6 proposal, initial feedback

[Brad Peabody <[e-mail]>]

> For very specialized use cases (e.g., where 16 binary bytes is too
> long), I'm not sure it makes sense to create a fully general
> specification which is so abstract that it becomes hard to use, since
> you have to customize it for a particular application.
>
> Past a certain point, you might as well say that you want to
> standardize "b-trees" --- and that's something which belongs in an
> algorithms book, and not an I-D or an RFC.
>
In practical terms, the issue I'm concerned about is that there are 
various points where software from different projects needs to 
communicate UUIDs to each other and so it turns from a general thing 
into something very specific. In this link I mentioned earlier 
https://github.com/uuidjs/uuid/issues/303#issuecomment-575992079 it's 
all about how UUIDs work with Postgres as primary keys.

The text encoding is particularly relevant, since hexes with dashes is 
not a particularly practical format (too long) for a many use cases.  So 
if you have a column in a database of type 'UUID' (or some other similar 
ID type) and then issue an update statement - there needs to be known 
text format and it would be great if it were more compact.   And if it 
were standardized then eventually various databases would implement it.  
The sorting is also a thing - see below.

But I do get what you mean on shorter IDs with less uniqueness guarantee 
- a spec isn't need to just generate a random opaque string that you're 
just going to have to check a database for to ensure you don't have a 
duplicate.

> Again, I'd urge you to consider that you should build on *top* of the
> standard UUID spec, since there are already implementations that will
> do the right thing as far as time-based and random-based UUID's (the
> latter will provide all the unguessability you need) and then just
> create a library which *transforms* the UUID into a convenient
> encoding form that makes it be convenient for key-indexing, or a more
> compact text encoding, etc.
>
> There are already very good implementations for UUID generation, and
> if you create something which re-invents the wheel at a spec level, it
> will cause people to reinvent the wheel (possibly badly) at the
> implementation level.

I think a part of the issue here is that since there is an existing UUID 
spec people then try to use it for things like database keys, and then 
run into these various rough edges:

- hex text format too long

- sorting is extra work for no benefit, having the raw bytes sort 
naturally in time sequence (for UUIDs with a timestamp) would seem to be 
a better way

- there is no official form of UUID that has a timestamp and then random 
data - the spec says to use the MAC address of the machine (version 1) 
which can be a security issue; and version 4 is not time-ordered.

So that's more info on the motivation and, at least from my perspective, 
the practical concerns that are driving this.

It would certainly be less of a change to just propose an update to the 
UUID spec that puts the date in a sequence that sorts as raw bytes and 
says feel free to use random data from a properly seeded CSPRNG instead 
of a MAC address if you're willing to have X collision probability in 
exchange for not having your MAC address there.  And also says btw hex 
encoding is big, so feel free also to use base32 or base64 according to 
what you want for your app. It would be great if these things had good 
names too so that when someone goes to implement this in a new database 
column type they can be referred to with sane names that match the 
spec.  Those points might be all it would take. And that was more or 
less my original intention with coming up with the original "UUID 
version 6" concept.

At the end of the day I guess the main driving use case is as a database 
primary key (and then also being able to easily use that PK in the same 
human readable form in things like URLs or written in documents), but 
the above sillyness ("rough edges") make this difficult with the current 
specification.