Draft 00: Layout grid for UUIDv7 with both usual and Crockford's Base32 encoding
sergeyprokhorenko opened this issue · 7 comments
Change Proposal Template
Source (Select one.)
- IETF Published Draft
- Work in Progress Draft
Change Reason (Select all that apply.)
- Typos and grammatical issues
- Bad Reference
- IETF Verbiage modification (MAY, MUST, SHOULD, SHOULD NOT, etc)
- New Text for additional context
- Underlying XML Format Update
- ASCII diagram updates (artwork, code samples, etc.)
Draft Number, Full Section, Name
Draft 04, 5.2. UUID Version 7
Current Text:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unix_ts_ms |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unix_ts_ms | ver | rand_a |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|var| rand_b |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rand_b |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: UUIDv7 Field and Bit Layout
unix_ts_ms:
48 bit big-endian unsigned number of Unix epoch timestamp as per Section 6.1.
ver:
4 bit UUIDv7 version set as per Section 4
rand_a:
12 bits pseudo-random data to provide uniqueness as per Section 6.2 and Section 6.6.
var:
The 2 bit variant defined by Section 4.
rand_b:
The final 62 bits of pseudo-random data to provide uniqueness as per Section 6.2 and Section 6.6.
Proposed Text:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
┌─────────┬─────────┬─────────┬─────────┬─────────┬─────────┬─────────┬─────────┐
│T T T T T T T T T T T T T T T T T T T T│T T T T T T T T T T T T-T T T T T T T T│
├───────┴─┬─────┴───┬───┴─────┬─┴───────┼───────┴─┬─────┴───┬───┴─────┬─┴───────┤
│T T T T T T T T-E E E E V C C C C C C C│C C C C-A A C C C C C C C C C C C C U U┤
├───────┴─┬─────┴───┬───┴─────┬─┴───────┼───────┴─┬─────┴───┬───┴─────┬─┴───────┤
│U U U U U U U U U U U U U U U U R R R R│R R R R R R R R R R R R R R R R R R R R│
├───────┴─┬─────┴───┬───┴─────┬─┴───────┼───────┴─┬─────┴───┬───┴─────┬─┴───────┤
│R R R R R R R R-Z Z M M M M M M M M M M│M M M M M M M M M M M M M M M M M M M M│
└───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┘
Figure 3: UUIDv7 Segment and Bit Layout
T - timestamp as per Section 6.1 incremented on counter overflow
E - 4 bit UUIDv7 version set as per Section 4
A - 2 bit variant as per Section 4
V - zero initialized counter (guarding against counter rollovers) as per Section 6.2 or randomly initialized counter
C - randomly initialized counter as per Section 6.2
U - randomly initialized counter and/or node identifier (N) as per Section 6.3 and/or pseudo-random data
R - pseudo-random data as per Section 6.2 and Section 6.6
Z - zero bits for Crockford's Base32 encoding or application specific metadata attached to UUID (optional, detachable and any length)
M - application specific metadata attached to UUID (optional, detachable and any length) as per Section 6.9 (UUID formats defined by this specification for use as identifiers or left parts of identifiers)
Other Supporting information below:
Vertical strokes separate 4 bits per character for usual encoding and 5 bits per character for Crockford's Base32 encoding
The length of the segments is subject to further discussion.
The numbering of bits from zero confuses me, but it is kept for compatibility.
I'm confused. Why is this 160 bits? Is this for a new RFC? If so, why is this being submitted as a change proposal to the current draft? (My apologies if I've missed some conversation about this. I've been on a bit of a self-imposed hiatus and haven't been paying as much attention to this project.)
@broofa, This is a layout grid for UUID (128 bits) + 32 bits of application specific metadata attached to UUID (optional, detachable and any length) as per Section 6.9 (UUID formats defined by this specification for use as identifiers or left parts of identifiers). The length of UUID itself did not change. The length of the grid (40 bits) is convenient for both usual and Crockford's Base32 encoding. It is divisible by 4 and 5.
§6.9 says that such composite identifiers (UUID + left parts) are allowed. That doesn't mean we should be detailing what they look like as part of the spec.
Basically this seems like a thinly veiled attempt to reintroduce longer UUIDs and Base32 encoding back into the spec - two topics that have been explicitly deemed out of scope. 😞
@broofa, It is not true. The following is said about these topics: "being rolled into a new Draft that can be found here: New UUID Encoding Techniques". And we're just discussing this new Draft
@broofa, yeah, this is not for the UUIDv6/7/8 discussion.
I just have not rolled that WIP Draft-00 into it's own repo yet. It is on the to do...
For the moment it resides here because the out of scope discussions already reside here. I'll tag this one OOS just for transparency.
@kyzer-davis, Please clarify your intentions and intentions of @bradleypeabody regarding all these "Drafts". The stigma of OOS is discouraging, and it raises fears that the innovative results of the intellectual efforts of the participants will be thrown into the trash to the delight of conservative opponents.
@sergeyprokhorenko, I transferred this issue and everything else to the new draft repo for this topic:
https://github.com/uuid6/new-uuid-encoding-techniques-ietf-draft
I will note that in order to ensure that both drafts can exist without any co-dependencies; I am not specifying any UUIDv6/7/8 info in this draft. Else I get into the scenario where the other draft holds up progress of the work in this draft because we reference UUIDv7 which is not adopted as an official spec yet.
As such I have opted to use a UUIDv4 value for illustrative purposes in draft-00.
This can change if the other draft is officially opted of course; wish us luck in July.