Skip to content
This repository has been archived by the owner on Jul 9, 2024. It is now read-only.

uuid6/uuid6-ietf-draft

Repository files navigation

Final

RFC 9562

Title:      Universally Unique IDentifiers (UUIDs) 
Author:     K. Davis,
            B. Peabody,
            P. Leach
Status:     Standards Track
Stream:     IETF
Date:       May 2024
Mailbox:    [email protected],
            [email protected],
            [email protected]
Pages:      46
Obsoletes:  RFC 4122

I-D Tag:    draft-ietf-uuidrev-rfc4122bis-14.txt

URL:        https://www.rfc-editor.org/info/rfc9562

DOI:        10.17487/RFC9562

Updates

Name:     draft-ietf-uuidrev-rfc4122bis
Revision: 14
Title:    Universally Unique IDentifiers (UUID)
Date:     2023-11-06
Group:    uuidrev
Pages:    58
URL:      https://www.ietf.org/archive/id/draft-ietf-uuidrev-rfc4122bis-14.txt
Status:   https://datatracker.ietf.org/doc/draft-ietf-uuidrev-rfc4122bis/
HTML:     https://www.ietf.org/archive/id/draft-ietf-uuidrev-rfc4122bis-14.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-uuidrev-rfc4122bis
Diff:     https://author-tools.ietf.org/iddiff?url2=draft-ietf-uuidrev-rfc4122bis-14

New UUID Formats

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

High Level Overview

  1. UUID version 6: A re-ordering of UUID version 1 so it is sortable as an opaque sequence of bytes. Easy to implement given an existing UUIDv1 implementation.

    time_high|time_mid|time_low_and_version|clk_seq_hi_res|clk_seq_low|node

  2. UUID version 7: An entirely new time-based UUID bit layout sourced from the widely implemented and well known Unix Epoch timestamp source.

    unix_ts_ms|ver|rand_a|var|rand_b

  3. UUID version 8: A free-form UUID format which has no explicit requirements except maintaining backward compatibility.

    custom_a|ver|custom_b|var|custom_c

  4. Max UUID: A specialized UUID which is the inverse of the Nil UUID from RFC4122.

    FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF


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

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

  • Global and Local Uniqueness (collision resistance mechanisms)
  • Unguessability
  • Sorting/Ordering techniques
  • Storage and Opacity best practices
  • Big Endian vs Little Endian bit layout
  • Any and all UUID security concerns!

Out of Scope Topics (Rolled into a new Draft that can be found here: New UUID Encoding Techniques)

Out of Scope Topics


Out of Scope Topics (as as the result of discussion threads)

Out of Scope Topics (for backwards compatibility)


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.
    • Older drafts are available for view here or on the IETF Datatracker.
  • 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.
    • Reviewing is the pre-Draft 01 Research efforts is encouraged before diving into discussion threads.
    • 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.

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.