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.
