uuid6/new-uuid-encoding-techniques-ietf-draft

New UUID Encoding Techniques

Updates

Draft 00 Work in Progress:

• HTML Draft 00
• Plaintext Draft 00

---

New UUID Encoding Techniques

This is the GitHub repo for the IETF draft surrounding the topic of new UUID encoding techniques. Various discussion will need to occur to arrive at a standard and this repo will be used to collect and organize that information.

Note: This was split out of the New UUID Format draft for UUIDv6, UUIDv7, UUIDv8 and Max UUID; some discussions may link to comments on that repo.

High Level Overview

1. Extend URN as a method to describe the length of new UUID along with the encoding technique of the new UUID.

   urn:uuid:{uuid_value}:{uuid_length}:{uuid_encoding}

2. Allow other encoding techniques beyond the default "hex and dashes" format.

3. Allow UUIDs larger than 128 bits. e.g 160 bit UUID

   8-4-4-4-12-{variable_length}

---

RFC Scope

In order to keep things on track the following topics have been decided as in-scope or out of scope for this particular RFC. For more information on any of these items refer to the XML, TXT, HTML draft, research and the issue tracker for a particular discussion (follow hyperlinks below.)

In Scope Topics - UUID Generation

• URN Modifications
• Alternative text encoding techniques (Crockfords Base32, Base64, etc)
• Variable length UUIDs | UUID Long

In Scope Topics - UUID Best Practices as it relates to the previous topics

• Global and Local Uniqueness (collision resistance mechanisms)
• Unguessability
• Any and all UUID security concerns!

---

Scoping In Progress

• Variant Bit E Usage

---

Out of Scope Topics (for backwards compatibility)

• Changing the default 8-4-4-4-12 UUID text layout
• Changing anything about RFC4122's UUID versions 1 through 5

---

Contributing

• The XML draft in the root folder is the most recent working draft for re-submission to the IETF.
  • An HTML and Textual (.txt) RFC representation will be provided in the root folder to ease reader input and discussion.
• The RFC Draft utilize an XML formatted document that follows RFC7742 markup. All XML changes MUST follow this format and pass conversion to .txt and .html via https://xml2rfc.tools.ietf.org/
• Utilize the issue tracker to discuss topics, solutions, problems, typos and anything else.
  • Where possible contribute to an existing Discussion Thread vs creating a new thread.
  • New threads that propose alternative text SHOULD utilize Proposed Draft Change GitHub issue template to ensure proper information is captured for the draft authors.
  • Be civil!
• Pull requests will be accepted as long as the text is concise, clear and objective.
  • PRs will not be accepted for changes to the decision made for the draft without full discussion.
  • PRs MUST include the updated .xml and xml2rfc generated .txt and .html documents.
  • Draft versions are frozen until submission to the IETF; at which point new work constitutes a new draft version.
• For any examples UUIDv4 73e94fe0-e951-4153-aaf3-50e4e6089d9d MUST be used as the common UUID for describing modifications.

---

Prototyping

Remember first and foremost that this specification is still a draft. Breaking changes are to be expected. Prototypes SHOULD only be implemented to verify or discredit topics of the draft text.

• Prototype Implementations are available via this repro.

new-uuid-encoding-techniques-ietf-draft's Issues

Draft 00: Layout grid for UUIDv7 with both usual and Crockford's Base32 encoding

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.

Discussion: Alternate Text Encoding Methods (Crockford's Base32, etc)

I think the 'base32hex' encoding, decribed in the section 7 of the RFC-4648, should be used instead of creating a new one. I know that the algorithm is the same with a different alphabet, but the 'base32hex' already exists for the same purpose.

Discussion: Variable Length UUIDs | UUID Long

All things Variable Length UUIDs!

Biggest Question up front: Should this be in scope for this RFC Draft?

If so as per @broofa

• If a UUID is larger than 16 bytes, how is it padded?
• ... what are the extra bits / bytes used for?
• ... can a UUID have a fractional-byte length? (e.g. 173 bits) ... how would that be parsed?
• What does the string-form of a non-standard length UUID look like? a.k.a "Where do the hyphens go?"
• What does it mean for a uuid to have length < 16 bytes?
• As an implementor, when scanning a UUID field, how do I know how many bytes/bits to read? I.e. how does a UUID indicate it's length? This is important, if for no other reason than to know where the next field in the data starts.
• What does variable field length imply for other, existing RFC versions? "Why can't those now be longer?"

Discussion: UUID URN Extension

All things UUID URN as a way to convey extra information about the underlying UUID value.

The current problem that needs solved, which are introduced via alternate encoding and a longer UUID length is as I described earlier:

• How does a system advertise Length of the UUID since it could be 128+ (UUID Long).
• How does a system advertise the Encoding of the UUID since it could be variable (if more than one encoding type is allowed by the spec which it is as per my WIP Draft 00.)

Key things to keep in mind:

• Both advertisement methods should be decoupled from the underlying UUID as it would be obfuscated by the encoding.
• Both Methods should be usable at the same time. e.g I could have a UUIDv4 160-bit UUID long encoded as Crockford's base 32.
• The method selected MUST be backwards compatible with existing UUID format, length and encoding from RFC4122.

---

Edit: The main goal of the proposed URN extension in early draft-00 for this spec is to extend the already allocated IANA UUID URN and describe length and encoding in a way that decouples it from the UUID and is compatible with all UUIDs and URNs out there today.

---

See my previous comment for rational behind placement of current values in UUID URN:
#2 (comment)