rfc9562.original.xml   rfc9562.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.2 (Ruby 3.0.2 <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
) --> -ietf-uuidrev-rfc4122bis-14" number="9562" submissionType="IETF" category="std"
<?rfc strict="yes"?> consensus="true" obsoletes="4122" updates="" tocDepth="3" tocInclude="true" sort
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft Refs="true" symRefs="true" xml:lang="en" version="3">
-ietf-uuidrev-rfc4122bis-14" category="std" consensus="true" submissionType="IET
F" obsoletes="4122" tocDepth="3" tocInclude="true" sortRefs="true" symRefs="true
" version="3">
<!-- xml2rfc v2v3 conversion 3.18.2 -->
<front> <front>
<title abbrev="UUID">Universally Unique IDentifiers (UUID)</title> <title abbrev="UUIDs">Universally Unique IDentifiers (UUIDs)</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-uuidrev-rfc4122bis-14"/> <seriesInfo name="RFC" value="9562"/>
<author initials="K. R." surname="Davis" fullname="Kyzer R. Davis"> <author initials="K." surname="Davis" fullname="Kyzer R. Davis">
<organization>Cisco Systems</organization> <organization>Cisco Systems</organization>
<address> <address>
<email>kydavis@cisco.com</email> <email>kydavis@cisco.com</email>
</address> </address>
</author> </author>
<author initials="B. G." surname="Peabody" fullname="Brad G. Peabody"> <author initials="B." surname="Peabody" fullname="Brad G. Peabody">
<organization>Uncloud</organization> <organization>Uncloud</organization>
<address> <address>
<email>brad@peabody.io</email> <email>brad@peabody.io</email>
</address> </address>
</author> </author>
<author initials="P." surname="Leach" fullname="P. Leach"> <author initials="P." surname="Leach" fullname="P. Leach">
<organization>University of Washington</organization> <organization>University of Washington</organization>
<address> <address>
<email>pjl7@uw.edu</email> <email>pjl7@uw.edu</email>
</address> </address>
</author> </author>
<date year="2023"/> <date year="2024" month="May"/>
<area>ART</area> <area>art</area>
<workgroup>uuidrev</workgroup> <workgroup>uuidrev</workgroup>
<keyword>uuid</keyword> <keyword>uuid</keyword>
<abstract>
<?line 274?>
<t>This specification defines the UUIDs (Universally Unique IDentifiers) and the <abstract>
UUID Uniform Resource Name (URN) namespace. UUIDs are also known as GUIDs (Glob <t>This specification defines UUIDs (Universally Unique IDentifiers)
ally Unique IDentifiers). (also known as Globally Unique IDentifiers (GUIDs)) and a Uniform
A UUID is 128 bits long and is intended to guarantee Resource Name namespace for UUIDs. A UUID is 128 bits long and is intended
uniqueness across space and time. UUIDs were originally used in the to
Apollo Network Computing System and later in the Open Software guarantee uniqueness across space and time. UUIDs were originally used
Foundation's (OSF) Distributed Computing Environment (DCE), and then in the Apollo Network Computing System (NCS), later in the Open Software
in Microsoft Windows platforms.</t> Foundation's (OSF's) Distributed Computing Environment (DCE), and then
<t>This specification is derived from the DCE specification with the in Microsoft Windows platforms.</t>
kind permission of the OSF (now known as The Open Group). <t>This specification is derived from the OSF DCE specification with the
Information from earlier versions of the DCE specification have been kind permission of the OSF (now known as "The Open Group"). Information
incorporated into this document. This document obsoletes RFC4122.</t> from earlier versions of the OSF DCE specification have been incorporated
into this document. This document obsoletes RFC 4122.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<?line 288?>
<section anchor="Background"> <section anchor="Background">
<name>Introduction</name> <name>Introduction</name>
<t>This specification defines the UUIDs (Universally Unique IDentifiers) a <t>This specification defines a Uniform Resource Name namespace for
nd the UUID Uniform Resource Name (URN) namespace. UUIDs are also known as GUIDs Universally Unique IDentifiers (UUIDs) (also known as Globally
(Globally Unique IDentifiers). Unique IDentifiers (GUIDs)). A UUID is 128 bits long and
A UUID is 128 bits long and requires no central requires no central registration process.</t>
registration process.</t>
<t>The use of UUIDs is extremely pervasive in computing. They comprise <t>The use of UUIDs is extremely pervasive in computing. They comprise
the core identifier infrastructure for many operating systems the core identifier infrastructure for many operating systems such as
such as Microsoft Windows and applications such as the Mozilla Web browser and i Microsoft Windows and applications such as the Mozilla Web browser;
n in many cases, they can become exposed in many non-standard ways.</t>
many cases, become exposed in many non-standard ways.</t>
<t>This specification attempts to standardize that practice as openly as <t>This specification attempts to standardize that practice as openly as
possible and in a way that attempts to benefit the entire Internet. possible and in a way that attempts to benefit the entire Internet. The i
The information here is meant to be a concise guide for those wishing nformation
to implement services using UUIDs either in combination with URNs <xref target=" here is meant to be a concise guide for those wishing to implement
RFC8141"/> or otherwise.</t> services using UUIDs either in combination with URNs <xref
<t>There is an ITU-T Recommendation and an ISO/IEC Standard <xref target=" target="RFC8141"/> or otherwise.</t>
X667"/> that are <t>There is an ITU-T Recommendation and an ISO/IEC Standard <xref
derived from <xref target="RFC4122"/>. Both sets of target="X667"/> that are derived from <xref target="RFC4122"/>. Both
specifications have been aligned and are fully technically sets of specifications have been aligned and are fully technically
compatible. compatible. Nothing in this document should be construed to override
Nothing in this document should be construed to override the DCE standards that the DCE standards that defined UUIDs.</t>
defined UUIDs.</t>
</section> </section>
<section anchor="motivation"> <section anchor="motivation">
<name>Motivation</name> <name>Motivation</name>
<t>One of the main reasons for using UUIDs is that no centralized <t>One of the main reasons for using UUIDs is that no centralized
authority is required to administer them (although two formats may leverage opti authority is required to administer them (although two formats may
onal leverage optional IEEE 802 Node IDs, others do not). As a
IEEE 802 node identifiers, others do not). As a result, generation result, generation on demand can be completely automated and used for a
on demand can be completely automated and used for a variety of variety of purposes. The UUID generation algorithm described here
purposes. The UUID generation algorithm described here supports very supports very high allocation rates of 10 million per second per machine
high allocation rates of 10 million per second per machine or more if or more, if necessary, so that they could even be used as transaction
necessary, so that they could even be used as transaction IDs.</t> IDs.</t>
<t>UUIDs are of a fixed size (128 bits), which is reasonably small <t>UUIDs are of a fixed size (128 bits), which is reasonably small
compared to other alternatives. This lends itself well to sorting, compared to other alternatives. This lends itself well to sorting,
ordering, and hashing of all sorts, storing in databases, simple ordering, and hashing of all sorts; storing in databases; simple
allocation, and ease of programming in general.</t> allocation; and ease of programming in general.</t>
<t>Since UUIDs are unique and persistent, they make excellent Uniform <t>Since UUIDs are unique and persistent, they make excellent URNs.
Resource Names. The unique ability to generate a new UUID without a The unique ability to generate a new UUID without a
registration process allows for UUIDs to be one of the URNs with the registration process allows for UUIDs to be one of the URNs with the
lowest minting cost.</t> lowest minting cost.</t>
<section anchor="update-motivation"> <section anchor="update-motivation">
<name>Update Motivation</name> <name>Update Motivation</name>
<t>Many things have changed in the time since UUIDs were originally crea <t>Many things have changed in the time since UUIDs were originally
ted. created. Modern applications have a need to create and utilize UUIDs
Modern applications have a need to create and utilize UUIDs as the primary as the primary identifier for a variety of different items in complex
identifier for a variety of different items in complex computational systems, computational systems, including but not limited to database keys,
including but not limited to database keys, file names, machine or system file names, machine or system names, and identifiers for event-driven
names, and identifiers for event-driven transactions.</t> transactions.</t>
<t>One area in which UUIDs have gained popularity is database keys. <t>One area in which UUIDs have gained popularity is database keys.
This stems from the increasingly distributed nature of modern applications. This stems from the increasingly distributed nature of modern
In such cases, "auto increment" schemes often used by databases do not work applications. In such cases, "auto-increment" schemes that are often
well, as the effort required to coordinate sequential numeric identifiers across used by databases do not work well: the effort required to
a network can easily become a burden. coordinate sequential numeric identifiers across a network can easily
The fact that UUIDs can be used to create unique, reasonably short values become a burden. The fact that UUIDs can be used to create unique,
in distributed systems without requiring coordination makes them a good reasonably short values in distributed systems without requiring
alternative, but UUID versions 1-5, which were originally defined by <xref targe coordination makes them a good alternative, but UUID versions 1-5,
t="RFC4122"/>, lack certain other desirable characteristics:</t> which were originally defined by <xref target="RFC4122"/>, lack
<ol spacing="normal" type="1"><li> certain other desirable characteristics, such as:</t>
<t>Non-time-ordered UUID versions such as UUIDv4 (described in <xref <ol spacing="normal" type="1">
target="uuidv4"/>) have poor database index <li>UUID versions that are not time ordered, such as UUIDv4 (described
locality. in
This means that new values created in succession are not close to each other i <xref target="uuidv4"/>), have poor database-index locality. This
n means that new values created in succession are not close to each
the index and thus require inserts to be performed at random other in the index; thus, they require inserts to be performed at
locations. random locations. The resulting negative performance effects on the
The resulting negative performance effects on common structures used for common structures used for this (B-tree and its variants) can be
this (B-tree and its variants) can be dramatic.</t> dramatic.</li>
</li> <li>The 100-nanosecond Gregorian Epoch used in UUIDv1 timestamps (desc
<li> ribed in
<t>The 100-nanosecond Gregorian epoch used in UUIDv1 (described in < <xref target="uuidv1"/>) is uncommon and difficult to
xref target="uuidv1"/>) timestamps is uncommon represent accurately using a standard number format such as that
and difficult to represent accurately using a standard number format such described in <xref target="IEEE754"/>.</li>
as <xref target="IEEE754"/>.</t> <li>Introspection/parsing is required to order by time sequence, as
</li> opposed to being able to perform a simple byte-by-byte comparison.
<li>
<t>Introspection/parsing is required to order by time sequence, as o
pposed to
being able to perform a simple byte-by-byte comparison.</t>
</li>
<li>
<t>Privacy and network security issues arise from using a MAC addres
s in the
node field of UUID version 1.
Exposed MAC addresses can be used as an attack surface to locate network inter
faces
and reveal various other
information about such machines (minimally manufacturer, potentially other
details). Additionally, with the advent of virtual machines and containers,
MAC address uniqueness is no longer guaranteed.</t>
</li>
<li>
<t>Many of the implementation details specified in <xref target="RFC
4122"/> involved trade
offs that are neither possible to specify for all applications nor
necessary to produce interoperable implementations.</t>
</li>
<li>
<t><xref target="RFC4122"/> did not distinguish between the requirem
ents for generating a UUID
and those for simply storing one, although they are often different.</t>
</li> </li>
<li>Privacy and network security issues arise from using a Media Acces
s Control (MAC)
address in the node field of UUIDv1. Exposed MAC addresses
can be used as an attack surface to locate network interfaces and
reveal various other information about such machines (minimally, the
manufacturer and, potentially, other details). Additionally, with the
advent of virtual machines and containers, uniqueness of the MAC addre
ss is
no longer guaranteed.</li>
<li>Many of the implementation details specified in <xref
target="RFC4122"/> involved trade-offs that are neither possible to
specify for all applications nor necessary to produce interoperable
implementations.</li>
<li><xref target="RFC4122"/> did not distinguish between the
requirements for generating a UUID and those for simply storing one,
although they are often different. </li>
</ol> </ol>
<t>Due to the aforementioned issues, many widely distributed database ap
plications <t>Due to the aforementioned issues, many widely distributed database
and large application vendors have sought to solve the problem of creating applications and large application vendors have sought to solve the
a better problem of creating a better time-based, sortable unique identifier
time-based, sortable unique identifier for use as a database key. This has for use as a database key. This has led to numerous implementations
led to numerous implementations over the past 10+ years solving the same problem in slightly different
over the past 10+ years solving the same problem in slightly different ways.</t> ways.</t>
<t>While preparing this specification, the following 16 different implem <t>While preparing this specification, the following 16 different
entations implementations were analyzed for trends in total ID length, bit
were analyzed for trends in total ID length, bit layout, lexical formatting/enco layout, lexical formatting and encoding, timestamp type, timestamp
ding, format, timestamp accuracy, node format and components, collision
timestamp type, timestamp format, timestamp accuracy, node format/components, handling, and multi-timestamp tick generation sequencing:</t>
collision handling, and multi-timestamp tick generation sequencing:</t>
<ol spacing="compact" type="1"><li> <ol spacing="compact" type="1">
<t><xref target="ULID"/> by A. Feerasta</t> <li><xref target="ULID"/></li>
</li> <li><xref target="LexicalUUID"/></li>
<li> <li><xref target="Snowflake"/></li>
<t><xref target="LexicalUUID"/> by Twitter</t> <li><xref target="Flake"/></li>
</li> <li><xref target="ShardingID"/></li>
<li> <li><xref target="KSUID"/></li>
<t><xref target="Snowflake"/> by Twitter</t> <li><xref target="Elasticflake"/></li>
</li> <li><xref target="FlakeID"/></li>
<li> <li><xref target="Sonyflake"/></li>
<t><xref target="Flake"/> by Boundary</t> <li><xref target="orderedUuid"/></li>
</li> <li><xref target="COMBGUID"/></li>
<li> <li><xref target="SID"/></li>
<t><xref target="ShardingID"/> by Instagram</t> <li><xref target="pushID"/></li>
</li> <li><xref target="XID"/></li>
<li> <li><xref target="ObjectID"/></li>
<t><xref target="KSUID"/> by Segment</t> <li><xref target="CUID"/></li>
</li>
<li>
<t><xref target="Elasticflake"/> by P. Pearcy</t>
</li>
<li>
<t><xref target="FlakeID"/> by T. Pawlak</t>
</li>
<li>
<t><xref target="Sonyflake"/> by Sony</t>
</li>
<li>
<t><xref target="orderedUuid"/> by IT. Cabrera</t>
</li>
<li>
<t><xref target="COMBGUID"/> by R. Tallent</t>
</li>
<li>
<t><xref target="SID"/> by A. Chilton</t>
</li>
<li>
<t><xref target="pushID"/> by Google</t>
</li>
<li>
<t><xref target="XID"/> by O. Poitrey</t>
</li>
<li>
<t><xref target="ObjectID"/> by MongoDB</t>
</li>
<li>
<t><xref target="CUID"/> by E. Elliott</t>
</li>
</ol> </ol>
<t>An inspection of these implementations and the issues described above
has <t>An inspection of these implementations and the issues described
led to this document which intends to adapt new UUIDs to address these issues.</ above has led to this document, in which new UUIDs are adapted to
t> address these issues.</t>
<t>Further, <xref target="RFC4122"/> itself was in need an overhaul to a <t>Further, <xref target="RFC4122"/> itself was in need of an overhaul t
ddress a number of topics such as but not limited to the following:</t> o
<ol spacing="normal" type="1"><li> address a number of topics such as, but not limited to, the
<t>Miscellaneous erratas. Mostly around bit layout clarifications wh following:</t>
ich lead to inconsistent implementations.</t>
</li> <ol spacing="normal" type="1">
<li> <li>Implementation of miscellaneous errata reports. Mostly around
<t>Decouple other UUID versions from UUIDv1 bit layout so that field bit-layout clarifications, which lead to inconsistent
s like "time_hi_and_version" do not need to be referenced within a non-time-base implementations <xref target="Err1957"/>, <xref target="Err3546"/>,
d UUID while also providing "UUIDv1 like" definition sections for UUIDv3, UUIDv4 <xref target="Err4975"/>, <xref target="Err4976"/>, <xref
, and UUIDv5.</t> target="Err5560"/>, etc.</li>
</li> <li>Decoupling other UUID versions from the UUIDv1 bit layout so that
<li> fields like "time_hi_and_version" do not need to be referenced
<t>Provide implementation best practices around many real-world scen within a UUID that is not time based while also providing
arios and corner cases observed by existing and prototype implementations.</t> definition sections similar to that for UUIDv1 for UUIDv3, UUIDv4, and
</li> UUIDv5.</li>
<li> <li>Providing implementation best practices around many real-world
<t>Update the document to address security best practices and consid scenarios and corner cases observed by existing and prototype
erations for the modern age as it pertains MAC addresses, hashing algorithms, se implementations.</li>
cure randomness, and other topics.</t> <li>Addressing security best practices and
</li> considerations for the modern age as it pertains to MAC addresses,
<li> hashing algorithms, secure randomness, and other topics.</li>
<t>Provide implementations a standard-based option for implementatio <li>Providing implementations a standard-based option for
n specific and/or experimental UUID designs.</t> implementation-specific and/or experimental UUID designs.</li>
</li> <li>Providing more test vectors that illustrate real UUIDs created as
<li> per the specification.</li>
<t>Provide more test vectors that illustrate real UUIDs created as p
er the specification.</t>
</li>
</ol> </ol>
</section> </section>
</section> </section>
<section anchor="terminology"> <section anchor="terminology">
<name>Terminology</name> <name>Terminology</name>
<section anchor="requirements_language"> <section anchor="requirements_language">
<name>Requirements Language</name> <name>Requirements Language</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
nterpreted as are to be interpreted as described in BCP&nbsp;14 <xref
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
only when, they appear in all capitals, as shown here.</t>
appear in all capitals, as shown here.</t> </section>
<?line -18?>
</section>
<section anchor="acronyms"> <section anchor="acronyms">
<name>Abbreviations</name> <name>Abbreviations</name>
<t>The following abbreviations are used in this document:</t> <t>The following abbreviations are used in this document:</t>
<dl indent="14"> <dl newline="false" spacing="normal" indent="14">
<dt>UUID</dt> <dt>ABNF</dt> <dd>Augmented Backus-Naur Form</dd>
<dd> <dt>CSPRNG</dt> <dd>Cryptographically Secure Pseudorandom Number Genera
<t>Universally Unique Identifier</t> tor</dd>
</dd> <dt>DBMS</dt> <dd>Database Management System</dd>
<dt>UUIDv1</dt> <dt>IEEE</dt> <dd>Institute of Electrical and Electronics Engineers</dd
<dd> >
<t>Universally Unique Identifier Version 1</t> <dt>ITU</dt> <dd>International Telecommunication Union</dd>
</dd> <dt>MAC</dt> <dd>Media Access Control</dd>
<dt>UUIDv2</dt> <dt>MD5</dt> <dd>Message Digest 5</dd>
<dd> <dt>MSB</dt> <dd>Most Significant Bit</dd>
<t>Universally Unique Identifier Version 2</t> <dt>OID</dt> <dd>Object Identifier</dd>
</dd> <dt>SHA</dt> <dd>Secure Hash Algorithm</dd>
<dt>UUIDv3</dt> <dt>SHA-1</dt> <dd>Secure Hash Algorithm 1 (with message digest of 160
<dd> bits)</dd>
<t>Universally Unique Identifier Version 3</t> <dt>SHA-3</dt> <dd>Secure Hash Algorithm 3 (arbitrary size)</dd>
</dd> <dt>SHA-224</dt> <dd>Secure Hash Algorithm 2 with message digest size o
<dt>UUIDv4</dt> f 224 bits</dd>
<dd> <dt>SHA-256</dt> <dd>Secure Hash Algorithm 2 with message digest size o
<t>Universally Unique Identifier Version 4</t> f 256 bits</dd>
</dd> <dt>SHA-512</dt> <dd>Secure Hash Algorithm 2 with message digest size o
<dt>UUIDv5</dt> f 512 bits</dd>
<dd> <dt>SHAKE</dt> <dd>Secure Hash Algorithm 3 based on the KECCAK algorith
<t>Universally Unique Identifier Version 5</t> m</dd>
</dd> <dt>URN</dt> <dd>Uniform Resource Names</dd>
<dt>UUIDv6</dt> <dt>UTC</dt> <dd>Coordinated Universal Time</dd>
<dd> <dt>UUID</dt> <dd>Universally Unique Identifier</dd>
<t>Universally Unique Identifier Version 6</t> <dt>UUIDv1</dt> <dd>Universally Unique Identifier version 1</dd>
</dd> <dt>UUIDv2</dt> <dd>Universally Unique Identifier version 2</dd>
<dt>UUIDv7</dt> <dt>UUIDv3</dt> <dd>Universally Unique Identifier version 3</dd>
<dd> <dt>UUIDv4</dt> <dd>Universally Unique Identifier version 4</dd>
<t>Universally Unique Identifier Version 7</t> <dt>UUIDv5</dt> <dd>Universally Unique Identifier version 5</dd>
</dd> <dt>UUIDv6</dt> <dd>Universally Unique Identifier version 6</dd>
<dt>UUIDv8</dt> <dt>UUIDv7</dt> <dd>Universally Unique Identifier version 7</dd>
<dd> <dt>UUIDv8</dt> <dd>Universally Unique Identifier version 8</dd>
<t>Universally Unique Identifier Version 8</t>
</dd>
<dt>URN</dt>
<dd>
<t>Uniform Resource Names</t>
</dd>
<dt>ABNF</dt>
<dd>
<t>Augmented Backus-Naur Form</t>
</dd>
<dt>CSPRNG</dt>
<dd>
<t>Cryptographically Secure Pseudo-Random Number Generator</t>
</dd>
<dt>MAC</dt>
<dd>
<t>Media Access Control</t>
</dd>
<dt>MSB</dt>
<dd>
<t>Most Significant Bit</t>
</dd>
<dt>DBMS</dt>
<dd>
<t>Database Management System</t>
</dd>
<dt>IEEE</dt>
<dd>
<t>Institute of Electrical and Electronics Engineers, Inc.</t>
</dd>
<dt>ITU</dt>
<dd>
<t>International Telecommunication Union</t>
</dd>
<dt>MD5</dt>
<dd>
<t>Message Digest 5</t>
</dd>
<dt>SHA</dt>
<dd>
<t>Secure Hash Algorithm</t>
</dd>
<dt>SHA-1</dt>
<dd>
<t>Secure Hash Algorithm 1 with message digest of 160 bits</t>
</dd>
<dt>SHA-224</dt>
<dd>
<t>Secure Hash Algorithm 2 with message digest size of 224 bits</t>
</dd>
<dt>SHA-256</dt>
<dd>
<t>Secure Hash Algorithm 2 with message digest size of 256 bits</t>
</dd>
<dt>SHA-512</dt>
<dd>
<t>Secure Hash Algorithm 2 with message digest size of 512 bits</t>
</dd>
<dt>SHA-3</dt>
<dd>
<t>Secure Hash Algorithm 3</t>
</dd>
<dt>SHAKE</dt>
<dd>
<t>Secure Hash Algorithm 3 based on KECCAK algorithm</t>
</dd>
<dt>UTC</dt>
<dd>
<t>Coordinated Universal Time</t>
</dd>
<dt>OID</dt>
<dd>
<t>Object Identifier</t>
</dd>
</dl> </dl>
</section> </section>
<section anchor="changelog" removeInRFC="true">
<name>Changelog</name>
<t>draft-14</t>
<ul spacing="compact">
<li>
<t>AD Review #2: IANA Subtype Modifications #170</t>
</li>
<li>
<t>AD Review #2: Specify Values for Variant/Subtype Column #171</t>
</li>
<li>
<t>AD Review #2: Grammar change at the end of 5.1 #172</t>
</li>
<li>
<t>SHA and Integer Verbiage clarifications #174</t>
</li>
<li>
<t>Disclaimer in nil/max that these do not fall into IETF variants #
175</t>
</li>
<li>
<t>Fix v1/v6 final UUID in test vector #176</t>
</li>
</ul>
<t>draft-13</t>
<ul spacing="compact">
<li>
<t>Request IANA Registry #144</t>
</li>
<li>
<t>Describe allocation logic of Namespace ID #161</t>
</li>
<li>
<t>Move citation of Namesapce ID up to first instance in v3/v5 #167<
/t>
</li>
<li>
<t>Further normalize Namespace verbiage #166</t>
</li>
<li>
<t>Fix Timestamp of Time-Based UUIDv8 Example #164</t>
</li>
<li>
<t>Change RFC8937 and RFC4086 to Informative References #163</t>
</li>
<li>
<t>Discuss why v3/v5 are bad for Database Usage #155</t>
</li>
</ul>
<t>draft-12</t>
<ul spacing="compact">
<li>
<t>Typos #148 #156</t>
</li>
<li>
<t>SECDIR Review #141</t>
</li>
<li>
<t>SECDIR Review 2 #142</t>
</li>
<li>
<t>OPSDIR Review #145</t>
</li>
<li>
<t>INDIR Review 2 #140</t>
</li>
<li>
<t>IESG Grammar #146</t>
</li>
<li>
<t>Revise 16-bit MAC Node Usage #149</t>
</li>
<li>
<t>Add MSB3 to Variant Table #153</t>
</li>
<li>
<t>Additional Update Motivations #157</t>
</li>
<li>
<t>Expand v8 Time-based Example to larger timestamp #159</t>
</li>
<li>
<t>Fix Randomized Node value's mcast bit in Appendix #151</t>
</li>
<li>
<t>Clarify "Name-Based" is the same as "Hash-Based" #154</t>
</li>
<li>
<t>Move UUIDv8 Examples out of Test Vectors #150</t>
</li>
<li>
<t>Simplify UUIDv8 Hash-based Example #147</t>
</li>
</ul>
<t>draft-11</t>
<ul spacing="compact">
<li>
<t>Normalize "name space" to "namespace" everywhere #137</t>
</li>
<li>
<t>IANA Review: Verbiage to update RFC4122 references #134</t>
</li>
<li>
<t>DNSDIR re-review: Better Define "a canonical sequence of octets"
#136</t>
</li>
<li>
<t>Crosspost: Typo in Approximate UUID timestamp calculations #135</
t>
</li>
<li>
<t>INTDIR Review #139</t>
</li>
</ul>
<t>draft-10</t>
<ul spacing="compact">
<li>
<t>ARTART Review and Feedback #130</t>
</li>
<li>
<t>Clarify Hash Space IDs listed are not the only options #132</t>
</li>
<li>
<t>Add example to timestamp fuzzing #133</t>
</li>
</ul>
<t>draft-09</t>
<ul spacing="compact">
<li>
<t>Late addition of IETF reference for CSPRNG guidance #123</t>
</li>
<li>
<t>DNSDIR Review: Typos! #122</t>
</li>
<li>
<t>DNSDIR Review: DNS Considerations Update #121</t>
</li>
<li>
<t>Error in UUIDv8 Name-based Test Vector #129</t>
</li>
<li>
<t>Improve consistency of layout field definitions #128</t>
</li>
</ul>
<t>draft-08</t>
<ul spacing="compact">
<li>
<t>Fix typos #113</t>
</li>
<li>
<t>Fix errata 6225 (again) #117 #118</t>
</li>
<li>
<t>AD Review: BCP 14 - <bcp14>SHOULD</bcp14> #114</t>
</li>
<li>
<t>AD Review: Add proper references to v1 and v6 #116</t>
</li>
<li>
<t>AD Review: Remove <bcp14>SHOULD</bcp14> in section 4 #120</t>
</li>
<li>
<t>Discuss "front-loaded rollover counter" for 32-bit epoch with Pad
ding method #115</t>
</li>
</ul>
<t>draft-07</t>
<ul spacing="compact">
<li>
<t>Even more grammar tweaks! #109</t>
</li>
<li>
<t>Remove unnecessary "32 bit" in UUIDv7 example #108</t>
</li>
<li>
<t>Change "fixed millisecond" -&gt; "millisecond by default" relatin
g to v7 #110</t>
</li>
<li>
<t>Revert Max UUID Naming #107</t>
</li>
<li>
<t>Author Changes</t>
</li>
</ul>
<t>draft-06</t>
<ul spacing="compact">
<li>
<t>More Grammar edits! #102</t>
</li>
<li>
<t>Tweak v7 description to de-emphasize optional components #103</t>
</li>
<li>
<t>Better Clarify Case in ABNF #104</t>
</li>
<li>
<t>Verbiage change in 6.2 #105</t>
</li>
</ul>
<t>draft-05</t>
<ul spacing="compact">
<li>
<t>Changed Max UUID to Max UUID to better complement Latin Nil UUID
verbiage. #95</t>
</li>
<li>
<t>Align Method 3 text with the 12 bits limitation #96</t>
</li>
<li>
<t>Make Version/version casing consistent across 5. UUID Layouts #97
</t>
</li>
<li>
<t>Cite MS COM GUID as little-endian #95</t>
</li>
</ul>
<t>draft-04</t>
<ul spacing="compact">
<li>
<t>Remove extra words #82, #88, and #93</t>
</li>
<li>
<t>Punctuation and minor style fixes #84</t>
</li>
<li>
<t>Change rounding mode of Method 4 Section 6.2 #90 (from #86)</t>
</li>
<li>
<t>Add verbal description of v7 generation to 5.7. UUID Version 7 #9
1</t>
</li>
<li>
<t>Remove Re-randomize Until Monotonic (Method 3) from Monotonicity
and Counters #92</t>
</li>
<li>
<t>Fix ambiguous text around UUIDv6 clock sequence #89</t>
</li>
<li>
<t>Move endianness statement from layout to format section #85</t>
</li>
<li>
<t>Further modified abstract to separate URN topic from UUID definit
ion #83</t>
</li>
<li>
<t>Provided three more UUID format examples #83</t>
</li>
<li>
<t>Added text further clarifying version construct is for the varian
t in this doc #83</t>
</li>
<li>
<t>Provided further clarification for local/global bit vs multicast
bit #83</t>
</li>
</ul>
<t>draft-03</t>
<ul spacing="compact">
<li>
<t>Revised IANA Considerations #71</t>
</li>
<li>
<t>Fix "integral numbers of octets" verbiage #67</t>
</li>
<li>
<t>Transpose UUID Namespaces to match UUID Hashspaces #70</t>
</li>
<li>
<t>Reference all Hash Algorithms. #69</t>
</li>
<li>
<t>Normalize SHA abbreviation formats #66</t>
</li>
<li>
<t>Add other Hash Abbreviations #65</t>
</li>
<li>
<t>Remove URN from title #73</t>
</li>
<li>
<t>Move Community Considerations to Introduction #68</t>
</li>
<li>
<t>Move some Normative Reference to Informative #74</t>
</li>
<li>
<t>Misc formatting changes to address IDNITS feedback</t>
</li>
<li>
<t>Downgrade <bcp14>MUST NOT</bcp14> to <bcp14>SHOULD NOT</bcp14> fo
r guessability of UUIDs #75</t>
</li>
<li>
<t>Misc. text formatting, typo fixes #78</t>
</li>
<li>
<t>Misc. text clarifications #79</t>
</li>
<li>
<t>Misc. <bcp14>SHOULD</bcp14>/<bcp14>MUST</bcp14> adjustments #80</
t>
</li>
<li>
<t>Method 3 and 4 added to monotonic section #81</t>
</li>
</ul>
<t>draft-02</t>
<ul spacing="compact">
<li>
<t>Change md5_high in SHA-1 section to sha1_mid #59</t>
</li>
<li>
<t>Describe Nil/Max UUID in variant table #16</t>
</li>
<li>
<t>Further Clarify that non-descript node IDs are the preferred meth
od in distributed UUID Generation #49</t>
</li>
<li>
<t>Appendix B, consistent naming #55</t>
</li>
<li>
<t>Remove duplicate ABNF from IANA considerations #56</t>
</li>
<li>
<t>Monotonic Error Checking missing newline #57</t>
</li>
<li>
<t>More Security Considerations Randomness #26</t>
</li>
<li>
<t>SHA-256 UUID Generation #50</t>
</li>
<li>
<t>Expand multiplexed fields within v1 and v6 bit definitions #43</t
>
</li>
<li>
<t>Clean up text in UUIDs that Do Not Identify the Host #61</t>
</li>
<li>
<t>Revise UUID Generator States section #47</t>
</li>
<li>
<t>Expand upon why unix epoch rollover is not a problem #44</t>
</li>
<li>
<t>Delete Sample Code Appendix #62</t>
</li>
</ul>
<t>draft-01</t>
<ul spacing="compact">
<li>
<t>Mixed Case Spelling error #18</t>
</li>
<li>
<t>Add "UUIDs that Do Not Identify the Host as well" reference to se
curity considerations #19</t>
</li>
<li>
<t>Out of Place Distributed node text #20</t>
</li>
<li>
<t>v6 clock_seq and node usage ambiguity #21</t>
</li>
<li>
<t>Figure 2 and 3 Fix Title #22</t>
</li>
<li>
<t>Move Namespace Registration Template to IANA Considerations #23</
t>
</li>
<li>
<t>Verify ABNF formatting against RFC5234 #24</t>
</li>
<li>
<t>Bump ABNF reference to RFC 5234 #25</t>
</li>
<li>
<t>Modify v8 <bcp14>SHOULD NOT</bcp14> to <bcp14>MUST NOT</bcp14> #2
7</t>
</li>
<li>
<t>Remove "time-based" constraint from version 8 UUID #29</t>
</li>
<li>
<t>Further clarify v7 field description #125 #30</t>
</li>
<li>
<t>Typo: Section 4.2, Version Field, "UUID from in this" #33</t>
</li>
<li>
<t>Create better ABNF to represent Hex Digit #39</t>
</li>
<li>
<t>Break Binary form of UUID into two lines. #40</t>
</li>
<li>
<t>Move octet text from section 4 to section 5 #41</t>
</li>
<li>
<t>Add forward reference to UUIDv1 and UUIDv4 in Section 2 #42</t>
</li>
<li>
<t>Erroneous reference to v1 in monotonicity #45</t>
</li>
<li>
<t>Add Label for "Monotonic Error Checking" paragraph to frame the t
opic #46</t>
</li>
<li>
<t>Remove IEEE paragraph from "uuids that do not identify the host"
#48</t>
</li>
<li>
<t>Grammar Review #52</t>
</li>
</ul>
<t>draft-00</t>
<ul spacing="compact">
<li>
<t>Merge RFC4122 with draft-peabody-dispatch-new-uuid-format-04.md</
t>
</li>
<li>
<t>Change: Reference RFC1321 to RFC6151</t>
</li>
<li>
<t>Change: Reference RFC2141 to RFC8141</t>
</li>
<li>
<t>Change: Reference RFC2234 to RFC5234</t>
</li>
<li>
<t>Change: Reference FIPS 180-1 to FIPS 180-4 for SHA-1</t>
</li>
<li>
<t>Change: Converted UUIDv1 to match UUIDv6 section from Draft 04</t
>
</li>
<li>
<t>Change: Trimmed down the ABNF representation</t>
</li>
<li>
<t>Change: http websites to https equivalent</t>
</li>
<li>
<t>Errata: Bad Reference to RFC1750 | 3641 #4</t>
</li>
<li>
<t>Errata: Change MD5 website to example.com | 3476 #6 (Also Fixes E
rrata: Fix uuid_create_md5_from_name() | 1352 #2)</t>
</li>
<li>
<t>Errata: Typo in code comment | 6665 #11</t>
</li>
<li>
<t>Errata: Fix BAD OID acronym | 6225 #9</t>
</li>
<li>
<t>Errata: Incorrect Parenthesis usage Section 4.3 | 184 #5</t>
</li>
<li>
<t>Errata: Lexicographically Sorting Paragraph Fix | 1428 #3</t>
</li>
<li>
<t>Errata: Fix 4.1.3 reference to the correct bits | 1957 #13</t>
</li>
<li>
<t>Errata: Fix reference to variant in octet 8 | 4975 #7</t>
</li>
<li>
<t>Errata: Further clarify 3rd/last bit of Variant for spec | 5560 #
8</t>
</li>
<li>
<t>Errata: Fix clock_seq_hi_and_reserved most-significant bit verbia
ge | 4976 #10</t>
</li>
<li>
<t>Errata: Better Clarify network byte order when referencing most s
ignificant bits | 3546 #12</t>
</li>
<li>
<t>Draft 05: B.2. Example of a UUIDv7 Value two "var" in table #120<
/t>
</li>
<li>
<t>Draft 05: <bcp14>MUST</bcp14> verbiage in Reliability of 6.1 #121
</t>
</li>
<li>
<t>Draft 05: Further discourage centralized registry for distributed
UUID Generation.</t>
</li>
<li>
<t>New: Further Clarity of exact octet and bit of var/ver in this sp
ec</t>
</li>
<li>
<t>New: Block diagram, bit layout, test vectors for UUIDv4</t>
</li>
<li>
<t>New: Block diagram, bit layout, test vectors for UUIDv3</t>
</li>
<li>
<t>New: Block diagram, bit layout, test vectors for UUIDv5</t>
</li>
<li>
<t>New: Add MD5 Security Considerations reference, RFC6151</t>
</li>
<li>
<t>New: Add SHA-1 Security Considerations reference, RFC6194</t>
</li>
</ul>
</section> </section>
</section>
<section anchor="format"> <section anchor="format">
<name>UUID Format</name> <name>UUID Format</name>
<t>The UUID format is 16 octets (128 bits) in size; the variant bits in co <t>The UUID format is 16 octets (128 bits) in size; the variant bits in
njunction with the version conjunction with the version bits described in the next sections
bits described in the next sections determine finer structure. While discussing determine finer structure. In terms of these UUID formats and layout, bit
UUID formats and layout, bit definitions start at 0 and end at 127 while octet d definitions start at 0 and end at 127, while octet definitions start at 0
efinitions start at 0 and end at 15.</t> and end at 15.</t>
<t>In the absence of explicit application or presentation protocol <t>In the absence of explicit application or presentation protocol
specification to the contrary, each field is encoded with the Most specification to the contrary, each field is encoded with the most
Significant Byte first (known as network byte order).</t> significant byte first (known as "network byte order").</t>
<t>Saving UUIDs to binary format is done by sequencing all fields in big-e <t>Saving UUIDs to binary format is done by sequencing all fields in
ndian format. big-endian format. However, there is a known caveat that Microsoft's
However there is a known caveat that Microsoft's Component Object Model (COM) GU Component Object Model (COM) GUIDs leverage little-endian when saving
IDs leverage little-endian when saving GUIDs. GUIDs. The discussion of this (see <xref target="MS_COM_GUID"/>) is outsi
The discussion of this <xref target="MS_COM_GUID"/> is outside the scope of this de
specification.</t> the scope of this specification.</t>
<t>UUIDs <bcp14>MAY</bcp14> be represented as binary data or integers. <t>UUIDs <bcp14>MAY</bcp14> be represented as binary data or integers.
When in use with URNs or as text in applications, any given UUID should When in use with URNs or as text in applications, any given UUID should
be represented by the "hex-and-dash" string format consisting of multiple be represented by the "hex-and-dash" string format consisting of
groups of upper or lowercase alphanumeric hexadecimal characters separated by si multiple groups of uppercase or lowercase alphanumeric hexadecimal
ngle dashes/hyphens. characters separated by single dashes/hyphens. When used with databases,
When used with databases please refer to <xref target="database_considerations"/ please refer to <xref target="database_considerations"/>.</t>
>.</t> <t>The formal definition of the UUID string representation is provided by
<t>The formal definition of the UUID string representation is provided by the following ABNF <xref target="RFC5234"/>:</t>
the following (ABNF) <xref target="RFC5234"/>.</t>
<sourcecode type="abnf"><![CDATA[ <sourcecode type="abnf"><![CDATA[
UUID = 4hexOctet "-" UUID = 4hexOctet "-"
2hexOctet "-" 2hexOctet "-"
2hexOctet "-" 2hexOctet "-"
2hexOctet "-" 2hexOctet "-"
6hexOctet 6hexOctet
hexOctet = HEXDIG HEXDIG hexOctet = HEXDIG HEXDIG
DIGIT = %x30-39 DIGIT = %x30-39
HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
]]></sourcecode> ]]></sourcecode>
<t>Note that the alphabetic characters may be all uppercase, all lowercase , or mixed case, as per <xref section="2.3" sectionFormat="comma" target="RFC523 4"/>. <t>Note that the alphabetic characters may be all uppercase, all lowercase , or mixed case, as per <xref section="2.3" sectionFormat="of" target="RFC5234"/ >.
An example UUID using this textual representation from the above ABNF is shown i n <xref target="sampleStringUUID"/>.</t> An example UUID using this textual representation from the above ABNF is shown i n <xref target="sampleStringUUID"/>.</t>
<figure anchor="sampleStringUUID"> <figure anchor="sampleStringUUID">
<name>Example String UUID format</name> <name>Example String UUID Format</name>
<artwork><![CDATA[ <artwork><![CDATA[
f81d4fae-7dec-11d0-a765-00a0c91e6bf6 f81d4fae-7dec-11d0-a765-00a0c91e6bf6
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The same UUID from <xref target="sampleStringUUID"/> is represented in
Binary (<xref target="sampleBinaryUUID"/>), Unsigned Integer (<xref target="samp <t>The same UUID from <xref target="sampleStringUUID"/> is represented in
leIntegerUUID"/>) and as a URN (<xref target="sampleURNUUID"/>) defined by <xref binary (<xref target="sampleBinaryUUID"/>), as an unsigned integer (<xref target
target="RFC8141"/>.</t> ="sampleIntegerUUID"/>), and as a URN (<xref target="sampleURNUUID"/>) defined b
y <xref target="RFC8141"/>.</t>
<figure anchor="sampleBinaryUUID"> <figure anchor="sampleBinaryUUID">
<name>Example Binary UUID</name> <name>Example Binary UUID</name>
<artwork><![CDATA[ <artwork><![CDATA[
111110000001110101001111101011100111110111101100000100011101000\ 111110000001110101001111101011100111110111101100000100011101000\
01010011101100101000000001010000011001001000111100110101111110110 01010011101100101000000001010000011001001000111100110101111110110
]]></artwork> ]]></artwork>
</figure> </figure>
<figure anchor="sampleIntegerUUID"> <figure anchor="sampleIntegerUUID">
<name>Example Unsigned Integer UUID (shown as a decimal number)</name> <name>Example Unsigned Integer UUID (Shown as a Decimal Number)</name>
<artwork><![CDATA[ <artwork><![CDATA[
329800735698586629295641978511506172918 329800735698586629295641978511506172918
]]></artwork> ]]></artwork>
</figure> </figure>
<figure anchor="sampleURNUUID"> <figure anchor="sampleURNUUID">
<name>Example URN UUID</name> <name>Example URN Namespace for UUID</name>
<artwork><![CDATA[ <artwork><![CDATA[
urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
]]></artwork> ]]></artwork>
</figure> </figure>
<t>There are many other ways to define a UUID format; some examples are de tailed below. <t>There are many other ways to define a UUID format; some examples are de tailed below.
Please note that this is not an exhaustive list and is only provided for informa tional purposes.</t> Please note that this is not an exhaustive list and is only provided for informa tional purposes.</t>
<ul spacing="compact">
<li> <ul spacing="normal">
<t>Some UUID implementations, such as those found in <xref target="Pyt <li>Some UUID implementations, such as those found in <xref
hon"/> and <xref target="Microsoft"/>, will output UUID with the string format, target="Python"/> and <xref target="Microsoft"/>, will output UUID
including dashes, enclosed in curly braces.</t> with the string format, including dashes, enclosed in curly braces.
</li>
<li>
<t><xref target="X667"/> provides UUID format definitions for use of U
UID with an OID.</t>
</li>
<li>
<t>The legacy <xref target="IBM_NCS"/> implementation produces a uniqu
e UUID format compatible with Variant 0xx of <xref target="table1"/>.</t>
</li> </li>
<li><xref target="X667"/> provides UUID format definitions for use of
UUID with an OID.</li>
<li><xref target="IBM_NCS"/> is a legacy implementation that produces a
unique UUID format compatible with Variant 0xx of <xref
target="table1"/>.</li>
</ul> </ul>
<section anchor="variant_field"> <section anchor="variant_field">
<name>Variant Field</name> <name>Variant Field</name>
<t>The variant field determines the layout of the UUID. That is, the <t>The variant field determines the layout of the UUID. That is, the
interpretation of all other bits in the UUID depends on the setting interpretation of all other bits in the UUID depends on the setting of
of the bits in the variant field. As such, it could more accurately the bits in the variant field. As such, it could more accurately be
be called a type field; we retain the original term for called a "type" field; we retain the original term for compatibility.
compatibility. The variant field consists of a variable number of The variant field consists of a variable number of the most
the most significant bits of octet 8 of the UUID.</t> significant bits of octet 8 of the UUID.</t>
<t><xref target="table1"/> lists the contents of the variant field, wher <t><xref target="table1"/> lists the contents of the variant field,
e where the letter "x" indicates a "don't-care" value.</t>
the letter "x" indicates a "don't-care" value.</t>
<table anchor="table1"> <table anchor="table1">
<name>UUID Variants</name> <name>UUID Variants</name>
<thead> <thead>
<tr> <tr>
<th align="left">Msb0</th> <th align="left">MSB0</th>
<th align="left">Msb1</th> <th align="left">MSB1</th>
<th align="left">Msb2</th> <th align="left">MSB2</th>
<th align="left">Msb3</th> <th align="left">MSB3</th>
<th align="left">Variant</th> <th align="left">Variant</th>
<th align="left">Description</th> <th align="left">Description</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">0</td> <td align="left">0</td>
<td align="left">x</td> <td align="left">x</td>
<td align="left">x</td> <td align="left">x</td>
<td align="left">x</td> <td align="left">x</td>
<td align="left">1-7</td> <td align="left">1-7</td>
<td align="left">Reserved, NCS backward compatibility and includes <td align="left">Reserved. Network Computing System (NCS) backward
Nil UUID as per <xref target="niluuid"/>.</td> compatibility, and
includes Nil UUID as per <xref target="niluuid"/>.</td>
</tr> </tr>
<tr> <tr>
<td align="left">1</td> <td align="left">1</td>
<td align="left">0</td> <td align="left">0</td>
<td align="left">x</td> <td align="left">x</td>
<td align="left">x</td> <td align="left">x</td>
<td align="left">8-9,A-B</td> <td align="left">8-9,A-B</td>
<td align="left">The variant specified in this document.</td> <td align="left">The variant specified in this document.</td>
</tr> </tr>
<tr> <tr>
<td align="left">1</td> <td align="left">1</td>
<td align="left">1</td> <td align="left">1</td>
<td align="left">0</td> <td align="left">0</td>
<td align="left">x</td> <td align="left">x</td>
<td align="left">C-D</td> <td align="left">C-D</td>
<td align="left">Reserved, Microsoft Corporation backward compatib ility.</td> <td align="left">Reserved. Microsoft Corporation backward compatib ility.</td>
</tr> </tr>
<tr> <tr>
<td align="left">1</td> <td align="left">1</td>
<td align="left">1</td> <td align="left">1</td>
<td align="left">1</td> <td align="left">1</td>
<td align="left">x</td> <td align="left">x</td>
<td align="left">E-F</td> <td align="left">E-F</td>
<td align="left">Reserved for future definition and includes Max U UID as per <xref target="maxuuid"/>.</td> <td align="left">Reserved for future definition and includes Max U UID as per <xref target="maxuuid"/>.</td>
</tr> </tr>
</tbody> </tbody>
skipping to change at line 975 skipping to change at line 403
defined here is not guaranteed but is not likely to be an issue in defined here is not guaranteed but is not likely to be an issue in
practice.</t> practice.</t>
<t>Specifically for UUIDs in this document, bits 64 and 65 of the UUID ( bits 0 and 1 of octet 8) <bcp14>MUST</bcp14> be set to 1 and 0 as specified in r ow 2 of <xref target="table1"/>. <t>Specifically for UUIDs in this document, bits 64 and 65 of the UUID ( bits 0 and 1 of octet 8) <bcp14>MUST</bcp14> be set to 1 and 0 as specified in r ow 2 of <xref target="table1"/>.
Accordingly, all bit and field layouts avoid the use of these bits.</t> Accordingly, all bit and field layouts avoid the use of these bits.</t>
</section> </section>
<section anchor="version_field"> <section anchor="version_field">
<name>Version Field</name> <name>Version Field</name>
<t>The version number is in the most significant 4 bits of octet 6 <t>The version number is in the most significant 4 bits of octet 6
(bits 48 through 51 of the UUID).</t> (bits 48 through 51 of the UUID).</t>
<t><xref target="table2"/> lists all of the versions for this UUID varia nt 10xx specified in this document.</t> <t><xref target="table2"/> lists all of the versions for this UUID varia nt 10xx specified in this document.</t>
<table anchor="table2"> <table anchor="table2">
<name>UUID variant 10xx versions defined by this specification</name> <name>UUID Variant 10xx Versions Defined by This Specification</name>
<thead> <thead>
<tr> <tr>
<th align="left">Msb0</th> <th align="left">MSB0</th>
<th align="left">Msb1</th> <th align="left">MSB1</th>
<th align="left">Msb2</th> <th align="left">MSB2</th>
<th align="left">Msb3</th> <th align="left">MSB3</th>
<th align="left">Version</th> <th align="left">Version</th>
<th align="left">Description</th> <th align="left">Description</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">0</td> <td align="left">0</td>
<td align="left">0</td> <td align="left">0</td>
<td align="left">0</td> <td align="left">0</td>
<td align="left">0</td> <td align="left">0</td>
<td align="left">0</td> <td align="left">0</td>
<td align="left">Unused</td> <td align="left">Unused.</td>
</tr> </tr>
<tr> <tr>
<td align="left">0</td> <td align="left">0</td>
<td align="left">0</td> <td align="left">0</td>
<td align="left">0</td> <td align="left">0</td>
<td align="left">1</td> <td align="left">1</td>
<td align="left">1</td> <td align="left">1</td>
<td align="left">The Gregorian time-based UUID specified in this d ocument.</td> <td align="left">The Gregorian time-based UUID specified in this d ocument.</td>
</tr> </tr>
<tr> <tr>
skipping to change at line 1026 skipping to change at line 455
<td align="left">1</td> <td align="left">1</td>
<td align="left">3</td> <td align="left">3</td>
<td align="left">The name-based version specified in this document that uses MD5 hashing.</td> <td align="left">The name-based version specified in this document that uses MD5 hashing.</td>
</tr> </tr>
<tr> <tr>
<td align="left">0</td> <td align="left">0</td>
<td align="left">1</td> <td align="left">1</td>
<td align="left">0</td> <td align="left">0</td>
<td align="left">0</td> <td align="left">0</td>
<td align="left">4</td> <td align="left">4</td>
<td align="left">The randomly or pseudo-randomly generated version specified in this document.</td> <td align="left">The randomly or pseudorandomly generated version specified in this document.</td>
</tr> </tr>
<tr> <tr>
<td align="left">0</td> <td align="left">0</td>
<td align="left">1</td> <td align="left">1</td>
<td align="left">0</td> <td align="left">0</td>
<td align="left">1</td> <td align="left">1</td>
<td align="left">5</td> <td align="left">5</td>
<td align="left">The name-based version specified in this document that uses SHA-1 hashing.</td> <td align="left">The name-based version specified in this document that uses SHA-1 hashing.</td>
</tr> </tr>
<tr> <tr>
skipping to change at line 1118 skipping to change at line 547
<tr> <tr>
<td align="left">1</td> <td align="left">1</td>
<td align="left">1</td> <td align="left">1</td>
<td align="left">1</td> <td align="left">1</td>
<td align="left">1</td> <td align="left">1</td>
<td align="left">15</td> <td align="left">15</td>
<td align="left">Reserved for future definition.</td> <td align="left">Reserved for future definition.</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>An example version/variant layout for UUIDv4 follows the table <t>An example version/variant layout for UUIDv4 follows the table
where M represents the version placement for the hexadecimal representation of 0 where "M" represents the version placement for the hexadecimal
x4 (0b0100) representation of 0x4 (0b0100) and the "N" represents the variant
and the N represents the variant placement for one of the four possible hexadeci placement for one of the four possible hexadecimal representation of
mal representation of variant 10xx: variant 10xx: 0x8 (0b1000), 0x9 (0b1001), 0xA (0b1010), 0xB
0x8 (0b1000), 0x9 (0b1001), 0xA (0b1010), 0xB (0b1011)</t> (0b1011).</t>
<figure> <figure>
<name>UUIDv4 Variant Examples</name> <name>UUIDv4 Variant Examples</name>
<artwork><![CDATA[ <artwork><![CDATA[
00000000-0000-4000-8000-000000000000 00000000-0000-4000-8000-000000000000
00000000-0000-4000-9000-000000000000 00000000-0000-4000-9000-000000000000
00000000-0000-4000-A000-000000000000 00000000-0000-4000-A000-000000000000
00000000-0000-4000-B000-000000000000 00000000-0000-4000-B000-000000000000
xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
]]></artwork> ]]></artwork>
</figure> </figure>
<t>It should be noted that the other remaining UUID variants found in <x ref target="table1"/> leverage different sub-typing/versioning mechanisms. <t>It should be noted that the other remaining UUID variants found in <x ref target="table1"/> leverage different sub-typing or versioning mechanisms.
The recording and definition of the remaining UUID variant and sub-typing combin ations are outside of the scope of this document.</t> The recording and definition of the remaining UUID variant and sub-typing combin ations are outside of the scope of this document.</t>
</section> </section>
</section> </section>
<section anchor="layout"> <section anchor="layout">
<name>UUID Layouts</name> <name>UUID Layouts</name>
<t>To minimize confusion about bit assignments within octets and among dif <t>To minimize confusion about bit assignments within octets and among
fering versions, the UUID record definition is provided as a grouping of fields differing versions, the UUID record definition is provided as a grouping
within a bit layout consisting of four octets per row. of fields within a bit layout consisting of four octets per row. The
The fields are presented with the most significant one first.</t> fields are presented with the most significant one first.</t>
<section anchor="uuidv1"> <section anchor="uuidv1">
<name>UUID Version 1</name> <name>UUID Version 1</name>
<t>UUID version 1 is a time-based UUID featuring a 60 bit timestamp <t>UUIDv1 is a time-based UUID featuring a 60-bit timestamp
represented by Coordinated Universal Time (UTC) as a count of 100- represented by Coordinated Universal Time (UTC) as a count of
nanosecond intervals since 00:00:00.00, 15 October 1582 (the date of 100-nanosecond intervals since 00:00:00.00, 15 October 1582 (the date
Gregorian reform to the Christian calendar).</t> of Gregorian reform to the Christian calendar).</t>
<t>UUIDv1 also features a clock sequence field which is used to help avo <t>UUIDv1 also features a clock sequence field that is used to help
id avoid duplicates that could arise when the clock is set backwards in
duplicates that could arise when the clock is set backwards in time time or if the Node ID changes.</t>
or if the node ID changes.</t> <t>The node field consists of an IEEE 802 MAC address, usually the
<t>The node field consists of an IEEE 802 MAC host address or a randomly derived value per Sections <xref
address, usually the host address or a randomly derived value per <xref target=" target="unguessability" format="counter" /> and <xref
unguessability"/> and <xref target="unidentifiable"/>.</t> target="unidentifiable" format="counter"/>.</t>
<figure> <figure>
<name>UUIDv1 Field and Bit Layout</name> <name>UUIDv1 Field and Bit Layout</name>
<artwork><![CDATA[ <artwork><![CDATA[
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| time_low | | time_low |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| time_mid | ver | time_high | | time_mid | ver | time_high |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|var| clock_seq | node | |var| clock_seq | node |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| node | | node |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<dl newline="true">
<dl spacing="normal" newline="true">
<dt>time_low:</dt> <dt>time_low:</dt>
<dd> <dd>The least significant 32 bits of the 60-bit starting
<t>The least significant 32 bits of the 60 bit starting timestamp. timestamp. Occupies bits 0 through 31 (octets 0-3).</dd>
Occupies bits 0 through 31 (octets 0-3).</t>
</dd>
<dt>time_mid:</dt> <dt>time_mid:</dt>
<dd> <dd>The middle 16 bits of the 60-bit starting timestamp. Occupies
<t>The middle 16 bits of the 60 bit starting timestamp. bits 32 through 47 (octets 4-5).</dd>
Occupies bits 32 through 47 (octets 4-5).</t>
</dd>
<dt>ver:</dt> <dt>ver:</dt>
<dd> <dd>The 4-bit version field as defined by <xref
<t>The 4 bit version field as defined by <xref target="version_field target="version_field"/>, set to 0b0001 (1). Occupies bits 48
"/>, set to 0b0001 (1). through 51 of octet 6. </dd>
Occupies bits 48 through 51 of octet 6.</t>
</dd>
<dt>time_high:</dt> <dt>time_high:</dt>
<dd> <dd>The least significant 12 bits from the 60-bit starting
<t>12 bits that will contain the most significant 12 bits from the 6 timestamp. Occupies bits 52 through 63 (octets 6-7).</dd>
0 bit starting timestamp.
Occupies bits 52 through 63 (octets 6-7).</t>
</dd>
<dt>var:</dt> <dt>var:</dt>
<dd> <dd>The 2-bit variant field as defined by <xref
<t>The 2 bit variant field as defined by <xref target="variant_field target="variant_field"/>, set to 0b10. Occupies bits 64 and 65 of
"/>, set to 0b10. octet 8.</dd>
Occupies bits 64 and 65 of octet 8.</t>
</dd>
<dt>clock_seq:</dt> <dt>clock_seq:</dt>
<dd> <dd>The 14 bits containing the clock sequence. Occupies bits 66
<t>The 14 bits containing the clock sequence. through 79 (octets 8-9). </dd>
Occupies bits 66 through 79 (octets 8-9).</t>
</dd>
<dt>node:</dt> <dt>node:</dt>
<dd> <dd>48-bit spatially unique identifier. Occupies bits 80 through
<t>48 bit spatially unique identifier. 127 (octets 10-15).</dd>
Occupies bits 80 through 127 (octets 10-15).</t>
</dd>
</dl> </dl>
<t>For systems that do not have UTC available, but do have the local
time, they may use that instead of UTC, as long as they do so <t>For systems that do not have UTC available but do have the local
consistently throughout the system. However, this is not recommended time, they may use that instead of UTC as long as they do so
since generating the UTC from local time only needs a time zone consistently throughout the system. However, this is not recommended
offset.</t> since generating the UTC from local time only needs a time-zone
<t>If the clock is set backwards, or might have been set backwards offset.</t>
(e.g., while the system was powered off), and the UUID generator can <t>If the clock is set backwards, or if it might have been set
not be sure that no UUIDs were generated with timestamps larger than backwards (e.g., while the system was powered off), and the UUID
the value to which the clock was set, then the clock sequence <bcp14>MUST</bcp14 generator cannot be sure that no UUIDs were generated with timestamps
> larger than the value to which the clock was set, then the clock
be changed. If the previous value of the clock sequence is known, it sequence <bcp14>MUST</bcp14> be changed. If the previous value of the
<bcp14>MAY</bcp14> be incremented; otherwise it <bcp14>SHOULD</bcp14> be set to clock sequence is known, it <bcp14>MAY</bcp14> be incremented;
a random or otherwise it <bcp14>SHOULD</bcp14> be set to a random or high-quality
high-quality pseudo-random value.</t> pseudorandom value.</t>
<t>Similarly, if the node ID changes (e.g., because a network card has <t>Similarly, if the Node ID changes (e.g., because a network card has
been moved between machines), setting the clock sequence to a random been moved between machines), setting the clock sequence to a random
number minimizes the probability of a duplicate due to slight number minimizes the probability of a duplicate due to slight
differences in the clock settings of the machines. If the value of differences in the clock settings of the machines. If the value of
the clock sequence associated with the changed node ID were known, then the clock sequence associated with the changed Node ID were known, then
the clock sequence <bcp14>MAY</bcp14> be incremented, but that is unlikely.</t> the clock sequence <bcp14>MAY</bcp14> be incremented, but that is unlikely.</t>
<t>The clock sequence <bcp14>MUST</bcp14> be originally (i.e., once in t he lifetime of <t>The clock sequence <bcp14>MUST</bcp14> be originally (i.e., once in t he lifetime of
a system) initialized to a random number to minimize the correlation a system) initialized to a random number to minimize the correlation
across systems. This provides maximum protection against node across systems. This provides maximum protection against Node
identifiers that may move or switch from system to system rapidly. IDs that may move or switch from system to system rapidly.
The initial value <bcp14>MUST NOT</bcp14> be correlated to the node identifier.< The initial value <bcp14>MUST NOT</bcp14> be correlated to the Node ID.</t>
/t>
<t>Notes about IEEE 802 derived nodes:</t> <t>Notes about nodes derived from IEEE 802:</t>
<ul spacing="compact"> <ul spacing="normal">
<li> <li>On systems with multiple IEEE 802 addresses, any available one
<t>On systems with multiple IEEE 802 addresses, any available one <b <bcp14>MAY</bcp14> be used.</li>
cp14>MAY</bcp14> be used.</t> <li>On systems with no IEEE address, a randomly or pseudorandomly
</li> generated value <bcp14>MUST</bcp14> be used; see Sections <xref
<li> target="unguessability" format="counter"/> and <xref
<t>On systems with no IEEE address, a randomly or pseudo-randomly ge target="unidentifiable" format="counter"/>.
nerated value <bcp14>MUST</bcp14> be used; see <xref target="unguessability"/> a
nd <xref target="unidentifiable"/>.</t>
</li>
<li>
<t>On systems utilizing a 64 bit MAC address the least significant,
right-most 48 bits <bcp14>MAY</bcp14> be used.</t>
</li>
<li>
<t>On systems utilizing an IEEE 802.15.4 16 bit address <bcp14>SHOUL
D</bcp14> instead utilize their 64 bit MAC address where least significant, righ
t-most 48 bits <bcp14>MAY</bcp14> be used. An alternative is to generate 32 bits
of random data and postfix at the end of the 16 bit MAC address to create a 48
bit value.</t>
</li> </li>
<li>On systems utilizing a 64-bit MAC address, the least significant,
rightmost 48 bits <bcp14>MAY</bcp14> be used.</li>
<li>Systems utilizing an IEEE 802.15.4 16-bit address
<bcp14>SHOULD</bcp14> instead utilize their 64-bit MAC address where
the least significant, rightmost 48 bits <bcp14>MAY</bcp14> be used. A
n
alternative is to generate 32 bits of random data and postfix at the
end of the 16-bit MAC address to create a 48-bit value.</li>
</ul> </ul>
</section> </section>
<section anchor="uuidv2"> <section anchor="uuidv2">
<name>UUID Version 2</name> <name>UUID Version 2</name>
<t>UUID version 2 is known as DCE Security UUIDs <xref target="C309"/> a <t>UUIDv2 is for DCE Security UUIDs (see <xref target="C309"/> and
nd <xref target="C311"/>. <xref target="C311"/>). As such, the definition of these UUIDs is
As such, the definition of these UUIDs is outside the scope of this specificatio outside the scope of this specification.</t>
n.</t>
</section> </section>
<section anchor="uuidv3"> <section anchor="uuidv3">
<name>UUID Version 3</name> <name>UUID Version 3</name>
<t>UUID version 3 is meant for generating UUIDs from "names" <t>UUIDv3 is meant for generating UUIDs from names that are
that are drawn from, and unique within, some "namespace" as per <xref target="na drawn from, and unique within, some namespace as per <xref
me_based_uuid_generation"/>.</t> target="name_based_uuid_generation"/>.</t>
<t>UUIDv3 values are created by computing an MD5 <xref target="RFC1321"/ <t>UUIDv3 values are created by computing an MD5 hash <xref
> target="RFC1321"/> over a given Namespace ID value (<xref
hash over a given namespace ID value (<xref target="namespaces"/>) concatenated target="namespaces"/>) concatenated with the desired name value after
with the desired name value both have been converted to a canonical sequence of octets, as defined
after both have been converted to a canonical sequence of octets, as defined by by the standards or conventions of its namespace, in network byte
the standards or conventions of its namespace, in network byte order. order. This MD5 value is then used to populate all 128 bits of the
This MD5 value is then used to populate all 128 bits of the UUID layout. UUID layout. The UUID version and variant then replace the respective
The UUID version and variant then replace the respective bits as defined by <xre bits as defined by Sections <xref target="version_field"
f target="version_field"/> and <xref target="variant_field"/>. An example of thi format="counter"/> and <xref target="variant_field"
s bit substitution can be found in <xref target="uuidv3_example"/>.</t> format="counter"/>. An example of this bit substitution can be found
<t>Information around selecting a desired name's canonical format within in <xref target="uuidv3_example"/>.</t>
a given namespace can be found in <xref target="name_based_uuid_generation"/>, <t>Information around selecting a desired name's canonical format
"A note on names".</t> within a given namespace can be found in <xref
<t>Where possible UUIDv5 <bcp14>SHOULD</bcp14> be used in lieu of UUIDv3 target="name_based_uuid_generation"/> under the heading "A note on names
. ".</t>
For more information on MD5 security considerations see <xref target="RFC6151"/> <t>Where possible, UUIDv5 <bcp14>SHOULD</bcp14> be used in lieu of
.</t> UUIDv3. For more information on MD5 security considerations, see <xref
target="RFC6151"/>.</t>
<figure> <figure>
<name>UUIDv3 Field and Bit Layout</name> <name>UUIDv3 Field and Bit Layout</name>
<artwork><![CDATA[ <artwork><![CDATA[
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| md5_high | | md5_high |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| md5_high | ver | md5_mid | | md5_high | ver | md5_mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|var| md5_low | |var| md5_low |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| md5_low | | md5_low |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<dl newline="true">
<dl spacing="normal" newline="true">
<dt>md5_high:</dt> <dt>md5_high:</dt>
<dd> <dd>The first 48 bits of the layout are filled with the most
<t>The first 48 bits of the layout are filled significant, leftmost 48 bits from the computed MD5 value. Occupies
with the most significant, left-most 48 bits bits 0 through 47 (octets 0-5).</dd>
from the computed MD5 value. Occupies bits 0 through 47 (octets 0-5).</t>
</dd>
<dt>ver:</dt> <dt>ver:</dt>
<dd> <dd>The 4-bit version field as defined by <xref
<t>The 4 bit version field as defined by <xref target="version_field target="version_field"/>, set to 0b0011 (3). Occupies bits 48
"/>, set to 0b0011 (3). through 51 of octet 6.</dd>
Occupies bits 48 through 51 of octet 6.</t>
</dd>
<dt>md5_mid:</dt> <dt>md5_mid:</dt>
<dd> <dd>12 more bits of the layout consisting of the least significant,
<t>12 more bits of the layout consisting of the least significant, rightmost 12 bits of 16 bits immediately following md5_high from
right-most 12 bits of 16 bits immediately following md5_high the computed MD5 value. Occupies bits 52 through 63 (octets 6-7).
from the computed MD5 value.
Occupies bits 52 through 63 (octets 6-7).</t>
</dd> </dd>
<dt>var:</dt> <dt>var:</dt>
<dd> <dd>The 2-bit variant field as defined by <xref
<t>The 2 bit variant field as defined by <xref target="variant_field target="variant_field"/>, set to 0b10. Occupies bits 64 and 65 of
"/>, set to 0b10. octet 8.</dd>
Occupies bits 64 and 65 of octet 8.</t>
</dd>
<dt>md5_low:</dt> <dt>md5_low:</dt>
<dd> <dd>The final 62 bits of the layout immediately following the var
<t>The final 62 bits of the layout immediately following the var fie field to be filled with the least significant, rightmost bits of
ld to be the final 64 bits from the computed MD5 value. Occupies bits 66
filled with the least-significant, right-most bits of the final 64 bits through 127 (octets 8-15)</dd>
from the computed MD5 value. Occupies bits 66 through 127 (octets 8-15)</t>
</dd>
</dl> </dl>
</section> </section>
<section anchor="uuidv4"> <section anchor="uuidv4">
<name>UUID Version 4</name> <name>UUID Version 4</name>
<t>UUID version 4 is meant for generating UUIDs from truly-random or <t>UUIDv4 is meant for generating UUIDs from truly random or
pseudo-random numbers.</t> pseudorandom numbers.</t>
<t>An implementation may generate 128 bits of random data which is <t>An implementation may generate 128 bits of random data that is used
used to fill out the UUID fields in <xref target="uuidv4fields"/>. The UUID vers to fill out the UUID fields in <xref target="uuidv4fields"/>. The UUID
ion version and variant then replace the respective bits as defined by
and variant then replace the respective bits as defined by <xref target="version Sections <xref
_field"/> target="variant_field" format="counter"/> and <xref target="version_fiel
and <xref target="variant_field"/>.</t> d" format="counter"/>.</t>
<t>Alternatively, an implementation <bcp14>MAY</bcp14> choose to randoml <t>Alternatively, an implementation <bcp14>MAY</bcp14> choose to
y generate the exact required number of bits for randomly generate the exact required number of bits for random_a,
random_a, random_b, and random_c (122 bits total), and then concatenate the vers random_b, and random_c (122 bits total) and then concatenate the
ion and variant in the required position.</t> version and variant in the required position.</t>
<t>For guidelines on random data generation see <xref target="unguessabi <t>For guidelines on random data generation, see <xref
lity"/>.</t> target="unguessability"/>.</t>
<figure anchor="uuidv4fields"> <figure anchor="uuidv4fields">
<name>UUIDv4 Field and Bit Layout</name> <name>UUIDv4 Field and Bit Layout</name>
<artwork><![CDATA[ <artwork><![CDATA[
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| random_a | | random_a |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| random_a | ver | random_b | | random_a | ver | random_b |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|var| random_c | |var| random_c |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| random_c | | random_c |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<dl newline="true">
<dl spacing="normal" newline="true">
<dt>random_a:</dt> <dt>random_a:</dt>
<dd> <dd>The first 48 bits of the layout that can be filled with random
<t>The first 48 bits of the layout that can be filled with random da data as specified in <xref target="unguessability"/>. Occupies bits
ta as specified in <xref target="unguessability"/>. Occupies bits 0 through 47 ( 0 through 47 (octets 0-5).</dd>
octets 0-5).</t>
</dd>
<dt>ver:</dt> <dt>ver:</dt>
<dd> <dd>The 4-bit version field as defined by <xref
<t>The 4 bit version field as defined by <xref target="version_field target="version_field"/>, set to 0b0100 (4). Occupies bits 48
"/>, set to 0b0100 (4). through 51 of octet 6.</dd>
Occupies bits 48 through 51 of octet 6.</t>
</dd>
<dt>random_b:</dt> <dt>random_b:</dt>
<dd> <dd>12 more bits of the layout that can be filled random data as per
<t>12 more bits of the layout that can be filled random data as per <xref target="unguessability"/>. Occupies bits 52 through 63 (octets
<xref target="unguessability"/>. Occupies bits 52 through 63 (octets 6-7).</t> 6-7).</dd>
</dd>
<dt>var:</dt> <dt>var:</dt>
<dd> <dd>The 2-bit variant field as defined by <xref
<t>The 2 bit variant field as defined by <xref target="variant_field target="variant_field"/>, set to 0b10. Occupies bits 64 and 65 of
"/>, set to 0b10. octet 8.</dd>
Occupies bits 64 and 65 of octet 8.</t>
</dd>
<dt>random_c:</dt> <dt>random_c:</dt>
<dd> <dd>The final 62 bits of the layout immediately following the var
<t>The final 62 bits of the layout immediately following the var fie field to be filled with random data as per <xref
ld to be target="unguessability"/>. Occupies bits 66 through 127 (octets
filled with random data as per <xref target="unguessability"/>. Occupies bits 66 8-15).</dd>
through 127 (octets 8-15).</t>
</dd>
</dl> </dl>
</section> </section>
<section anchor="uuidv5"> <section anchor="uuidv5">
<name>UUID Version 5</name> <name>UUID Version 5</name>
<t>UUID version 5 is meant for generating UUIDs from "names" <t>UUIDv5 is meant for generating UUIDs from "names" that are
that are drawn from, and unique within, some "namespace" as per <xref target="na drawn from, and unique within, some "namespace" as per <xref
me_based_uuid_generation"/>.</t> target="name_based_uuid_generation"/>.</t>
<t>UUIDv5 values are created by computing an SHA-1 <xref target="FIPS180 <t>UUIDv5 values are created by computing an SHA-1 hash <xref
-4"/> target="FIPS180-4"/> over a given Namespace ID value (<xref
hash over a given namespace ID value (<xref target="namespaces"/>) concatenated target="namespaces"/>) concatenated with the desired name value after
with the desired name value both have been converted to a canonical sequence of octets, as defined
after both have been converted to a canonical sequence of octets, as defined by by the standards or conventions of its namespace, in network byte
the standards or conventions of its namespace, in network byte order. order. The most significant, leftmost 128 bits of the SHA-1 value
The most significant, left-most 128 bits of the SHA-1 value is then used to popu are then used to populate all 128 bits of the UUID layout, and the
late all 128 bits of the UUID layout and the remaining 32 least significant, rig remaining 32 least significant, rightmost bits of SHA-1 output are
ht-most bits of SHA-1 output are discarded. discarded. The UUID version and variant then replace the respective
The UUID version and variant then replace the respective bits as defined by <xre bits as defined by Sections <xref target="version_field"
f target="version_field"/> and <xref target="variant_field"/>. An example of thi format="counter"/> and <xref target="variant_field"
s bit substitution and discarding excess bits can be found in <xref target="uuid format="counter"/>. An example of this bit substitution and discarding
v5_example"/>.</t> excess bits can be found in <xref target="uuidv5_example"/>.</t>
<t>Information around selecting a desired name's canonical format within <t>Information around selecting a desired name's canonical format
a given namespace can be found in <xref target="name_based_uuid_generation"/>, within a given namespace can be found in <xref
"A note on names".</t> target="name_based_uuid_generation"/> under the heading "A note on names
<t>There may be scenarios, usually depending on organizational security ".</t>
policies, where SHA-1 libraries may not be available or deemed unsafe for use. <t>There may be scenarios, usually depending on organizational
As such, it may be desirable to generate name-based UUIDs derived from SHA-256 o security policies, where SHA-1 libraries may not be available or may
r newer SHA methods. These name-based UUIDs <bcp14>MUST NOT</bcp14> utilize UUID be deemed unsafe for use. As such, it may be desirable to generate
v5 and <bcp14>MUST</bcp14> be within the UUIDv8 space defined by <xref target="u name-based UUIDs derived from SHA-256 or newer SHA methods. These
uidv8"/>. name-based UUIDs <bcp14>MUST NOT</bcp14> utilize UUIDv5 and
An illustrative example of UUIDv8 for SHA-256 name-based UUIDs is provided in th <bcp14>MUST</bcp14> be within the UUIDv8 space defined by <xref
e appendix <xref target="uuidv8_example_name"/>.</t> target="uuidv8"/>. An illustrative example of UUIDv8 for SHA-256
<t>For more information on SHA-1 security considerations see <xref targe name-based UUIDs is provided in <xref
t="RFC6194"/>.</t> target="uuidv8_example_name"/>.</t>
<t>For more information on SHA-1 security considerations, see <xref
target="RFC6194"/>.</t>
<figure> <figure>
<name>UUIDv5 Field and Bit Layout</name> <name>UUIDv5 Field and Bit Layout</name>
<artwork><![CDATA[ <artwork><![CDATA[
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sha1_high | | sha1_high |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sha1_high | ver | sha1_mid | | sha1_high | ver | sha1_mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|var| sha1_low | |var| sha1_low |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sha1_low | | sha1_low |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<dl newline="true">
<dl spacing="normal" newline="true">
<dt>sha1_high:</dt> <dt>sha1_high:</dt>
<dd> <dd>The first 48 bits of the layout are filled with the most
<t>The first 48 bits of the layout are filled significant, leftmost 48 bits from the computed SHA-1 value.
with the most significant, left-most 48 bits Occupies bits 0 through 47 (octets 0-5). </dd>
from the computed SHA-1 value.
Occupies bits 0 through 47 (octets 0-5).</t>
</dd>
<dt>ver:</dt> <dt>ver:</dt>
<dd> <dd>The 4-bit version field as defined by <xref
<t>The 4 bit version field as defined by <xref target="version_field target="version_field"/>, set to 0b0101 (5). Occupies bits 48
"/>, set to 0b0101 (5). through 51 of octet 6.</dd>
Occupies bits 48 through 51 of octet 6.</t>
</dd>
<dt>sha1_mid:</dt> <dt>sha1_mid:</dt>
<dd> <dd>12 more bits of the layout consisting of the least significant,
<t>12 more bits of the layout consisting of the least significant, rightmost 12 bits of 16 bits immediately following sha1_high from
right-most 12 bits of 16 bits immediately following sha1_high the computed SHA-1 value. Occupies bits 52 through 63 (octets 6-7).
from the computed SHA-1 value.
Occupies bits 52 through 63 (octets 6-7).</t>
</dd> </dd>
<dt>var:</dt> <dt>var:</dt>
<dd> <dd>The 2-bit variant field as defined by <xref
<t>The 2 bit variant field as defined by <xref target="variant_field target="variant_field"/>, set to 0b10. Occupies bits 64 and 65 of
"/>, set to 0b10. octet 8.</dd>
Occupies bits 64 and 65 of octet 8.</t>
</dd>
<dt>sha1_low:</dt> <dt>sha1_low:</dt>
<dd> <dd>The final 62 bits of the layout immediately following the var
<t>The final 62 bits of the layout immediately following the var fie field to be filled by skipping the two most significant, leftmost
ld to be bits of the remaining SHA-1 hash and then using the next 62 most
filled by skipping the 2 most significant, left-most bits of the remaining SHA-1 significant, leftmost bits. Any leftover SHA-1 bits are discarded
hash and unused. Occupies bits 66 through 127 (octets 8-15).</dd>
and then using the next 62 most significant, left-most bits.
Any leftover SHA-1 bits are discarded and unused. Occupies bits 66 through 127 (
octets 8-15).</t>
</dd>
</dl> </dl>
</section> </section>
<section anchor="uuidv6"> <section anchor="uuidv6">
<name>UUID Version 6</name> <name>UUID Version 6</name>
<t>UUID version 6 is a field-compatible version of UUIDv1 <xref target=" <t>UUIDv6 is a field-compatible version of UUIDv1 (<xref
uuidv1"/>, reordered for improved target="uuidv1"/>), reordered for improved DB locality. It is expected
DB locality. that UUIDv6 will primarily be implemented in contexts where UUIDv1 is us
It is expected that UUIDv6 will primarily be used in contexts where UUIDv1 is us ed.
ed. Systems that do not involve legacy UUIDv1 <bcp14>SHOULD</bcp14> use
Systems that do not involve legacy UUIDv1 <bcp14>SHOULD</bcp14> use UUIDv7 <xref UUIDv7 (<xref target="uuidv7"/>) instead.</t>
target="uuidv7"/> instead.</t> <t>Instead of splitting the timestamp into the low, mid, and high
<t>Instead of splitting the timestamp into the low, mid, and high sectio sections from UUIDv1, UUIDv6 changes this sequence so timestamp bytes
ns from are stored from most to least significant. That is, given a 60-bit
UUIDv1, UUIDv6 changes this sequence so timestamp bytes are stored from most timestamp value as specified for UUIDv1 in <xref target="uuidv1"/>,
to least significant. for UUIDv6 the first 48 most significant bits are stored first,
That is, given a 60 bit timestamp value as specified for UUIDv1 in <xref target= followed by the 4-bit version (same position), followed by the
"uuidv1"/>, remaining 12 bits of the original 60-bit timestamp.</t>
for UUIDv6, the first 48 most significant bits are stored <t>The clock sequence and node bits remain unchanged from their
first, followed by the 4 bit version (same position), followed by the remaining position in <xref target="uuidv1"/>.</t>
12 bits of the original 60 bit timestamp.</t> <t>The clock sequence and node bits <bcp14>SHOULD</bcp14> be reset to
<t>The clock sequence and node bits remain unchanged from their positio a pseudorandom value for each new UUIDv6 generated; however,
n in <xref target="uuidv1"/>.</t> implementations <bcp14>MAY</bcp14> choose to retain the old clock
<t>The clock sequence and node bits <bcp14>SHOULD</bcp14> be reset to a sequence and MAC address behavior from <xref target="uuidv1"/>. For
pseudo-random value for each new UUIDv6 generated; however, implementations <bcp more information on MAC address usage within UUIDs, see the <xref
14>MAY</bcp14> choose to retain the old clock sequence and MAC address behavior target="Security"/>.</t>
from <xref target="uuidv1"/>. For more information on MAC address usage within U <t>The format for the 16-byte, 128-bit UUIDv6 is shown in <xref
UIDs see the <xref target="Security"/>.</t> target="v6layout"/>.</t>
<t>The format for the 16-byte, 128 bit UUIDv6 is shown in <xref target="
v6layout"/>.</t>
<figure anchor="v6layout"> <figure anchor="v6layout">
<name>UUIDv6 Field and Bit Layout</name> <name>UUIDv6 Field and Bit Layout</name>
<artwork><![CDATA[ <artwork><![CDATA[
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| time_high | | time_high |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| time_mid | ver | time_low | | time_mid | ver | time_low |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|var| clock_seq | node | |var| clock_seq | node |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| node | | node |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<dl newline="true"> <dl spacing="normal" newline="true">
<dt>time_high:</dt> <dt>time_high:</dt>
<dd> <dd>The most significant 32 bits of the 60-bit starting timestamp.
<t>The most significant 32 bits of the 60 bit starting timestamp. Occupies bits 0 through 31 (octets 0-3).</dd>
Occupies bits 0 through 31 (octets 0-3).</t>
</dd>
<dt>time_mid:</dt> <dt>time_mid:</dt>
<dd> <dd>The middle 16 bits of the 60-bit starting timestamp. Occupies
<t>The middle 16 bits of the 60 bit starting timestamp. bits 32 through 47 (octets 4-5).</dd>
Occupies bits 32 through 47 (octets 4-5).</t>
</dd>
<dt>ver:</dt> <dt>ver:</dt>
<dd> <dd>The 4-bit version field as defined by <xref
<t>The 4 bit version field as defined by <xref target="version_field target="version_field"/>, set to 0b0110 (6). Occupies bits 48
"/>, set to 0b0110 (6). through 51 of octet 6.</dd>
Occupies bits 48 through 51 of octet 6.</t>
</dd>
<dt>time_low:</dt> <dt>time_low:</dt>
<dd> <dd>12 bits that will contain the least significant 12 bits from the
<t>12 bits that will contain the least significant 12 bits from the 60-bit starting timestamp. Occupies bits 52 through 63 (octets
60 bit starting timestamp. 6-7).</dd>
Occupies bits 52 through 63 (octets 6-7).</t>
</dd>
<dt>var:</dt> <dt>var:</dt>
<dd> <dd>The 2-bit variant field as defined by <xref
<t>The 2 bit variant field as defined by <xref target="variant_field target="variant_field"/>, set to 0b10. Occupies bits 64 and 65 of
"/>, set to 0b10. octet 8.</dd>
Occupies bits 64 and 65 of octet 8.</t>
</dd>
<dt>clock_seq:</dt> <dt>clock_seq:</dt>
<dd> <dd>The 14 bits containing the clock sequence. Occupies bits 66
<t>The 14 bits containing the clock sequence. through 79 (octets 8-9).</dd>
Occupies bits 66 through 79 (octets 8-9).</t>
</dd>
<dt>node:</dt> <dt>node:</dt>
<dd> <dd>48-bit spatially unique identifier. Occupies bits 80 through
<t>48 bit spatially unique identifier. 127 (octets 10-15).</dd>
Occupies bits 80 through 127 (octets 10-15).</t>
</dd>
</dl> </dl>
<t>With UUIDv6, the steps for splitting the timestamp into time_high and time_mid <t>With UUIDv6, the steps for splitting the timestamp into time_high and time_mid
are <bcp14>OPTIONAL</bcp14> are <bcp14>OPTIONAL</bcp14>
since the 48 bits of time_high and time_mid will remain in the same order. since the 48 bits of time_high and time_mid will remain in the same order.
An extra step of splitting the first 48 bits of the timestamp into the most An extra step of splitting the first 48 bits of the timestamp into the most
significant significant
32 bits and least significant 16 bits proves useful when reusing an existing 32 bits and least significant 16 bits proves useful when reusing an existing
UUIDv1 implementation.</t> UUIDv1 implementation.</t>
</section> </section>
<section anchor="uuidv7"> <section anchor="uuidv7">
<name>UUID Version 7</name> <name>UUID Version 7</name>
<t>UUID version 7 features a time-ordered value field derived from the w <t>UUIDv7 features a time-ordered value field derived from the widely
idely implemented and well-known Unix Epoch timestamp source, the number of millisecon
implemented and well known Unix Epoch timestamp source, the number of millisecon ds
ds
since midnight 1 Jan 1970 UTC, leap seconds excluded. since midnight 1 Jan 1970 UTC, leap seconds excluded.
UUIDv7 generally has improved entropy characteristics over UUIDv1 <xref target=" uuidv1"/> or UUIDv6 <xref target="uuidv6"/>.</t> Generally, UUIDv7 has improved entropy characteristics over UUIDv1 (<xref target ="uuidv1"/>) or UUIDv6 (<xref target="uuidv6"/>).</t>
<t>UUIDv7 values are created by allocating a Unix timestamp in milliseco nds in the most significant 48 bits and filling the remaining 74 bits, excluding the required version and variant bits, with random bits for each new UUIDv7 gen erated to provide uniqueness as per <xref target="unguessability"/>. Alternative ly, implementations <bcp14>MAY</bcp14> fill the 74 bits, jointly, with a combina tion of the following subfields, in this order from the most significant bits to the least, to guarantee additional monotonicity within a millisecond:</t> <t>UUIDv7 values are created by allocating a Unix timestamp in milliseco nds in the most significant 48 bits and filling the remaining 74 bits, excluding the required version and variant bits, with random bits for each new UUIDv7 gen erated to provide uniqueness as per <xref target="unguessability"/>. Alternative ly, implementations <bcp14>MAY</bcp14> fill the 74 bits, jointly, with a combina tion of the following subfields, in this order from the most significant bits to the least, to guarantee additional monotonicity within a millisecond:</t>
<ol spacing="normal" type="1"><li>
<t>An <bcp14>OPTIONAL</bcp14> sub-millisecond timestamp fraction (12 <ol spacing="normal" type="1">
bits at maximum) as per <xref target="monotonicity_counters"/> (Method 3).</t> <li>An <bcp14>OPTIONAL</bcp14> sub-millisecond timestamp fraction
</li> (12 bits at maximum) as per <xref target="monotonicity_counters"/>
<li> (Method 3).</li>
<t>An <bcp14>OPTIONAL</bcp14> carefully seeded counter as per <xref <li>An <bcp14>OPTIONAL</bcp14> carefully seeded counter as per <xref
target="monotonicity_counters"/> (Method 1 or 2).</t> target="monotonicity_counters"/> (Method 1 or 2).</li>
</li> <li>Random data for each new UUIDv7 generated for any remaining
<li> space.</li>
<t>Random data for each new UUIDv7 generated for any remaining space
.</t>
</li>
</ol> </ol>
<t>Implementations <bcp14>SHOULD</bcp14> utilize UUIDv7 instead of UUIDv 1 and UUIDv6 if <t>Implementations <bcp14>SHOULD</bcp14> utilize UUIDv7 instead of UUIDv 1 and UUIDv6 if
possible.</t> possible.</t>
<figure> <figure>
<name>UUIDv7 Field and Bit Layout</name> <name>UUIDv7 Field and Bit Layout</name>
<artwork><![CDATA[ <artwork><![CDATA[
0 1 2 3 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 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unix_ts_ms | ver | rand_a | | unix_ts_ms | ver | rand_a |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|var| rand_b | |var| rand_b |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rand_b | | rand_b |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<dl newline="true">
<dl spacing="normal" newline="true">
<dt>unix_ts_ms:</dt> <dt>unix_ts_ms:</dt>
<dd> <dd>48-bit big-endian unsigned number of the Unix Epoch timestamp in
<t>48 bit big-endian unsigned number of Unix epoch timestamp in mill milliseconds as per <xref target="timestamp_considerations"/>.
iseconds as Occupies bits 0 through 47 (octets 0-5).</dd>
per <xref target="timestamp_considerations"/>.
Occupies bits 0 through 47 (octets 0-5).</t>
</dd>
<dt>ver:</dt> <dt>ver:</dt>
<dd> <dd>The 4-bit version field as defined by <xref
<t>The 4 bit version field as defined by <xref target="version_field target="version_field"/>, set to 0b0111 (7). Occupies bits 48
"/>, set to 0b0111 (7). through 51 of octet 6.</dd>
Occupies bits 48 through 51 of octet 6.</t>
</dd>
<dt>rand_a:</dt> <dt>rand_a:</dt>
<dd> <dd>12 bits of pseudorandom data to provide uniqueness as per <xref
<t>12 bits pseudo-random data to provide uniqueness as per <xref tar target="unguessability"/> and/or optional constructs to guarantee
get="unguessability"/> additional monotonicity as per <xref
and/or optional constructs to guarantee additional monotonicity as target="monotonicity_counters"/>. Occupies bits 52 through 63
per <xref target="monotonicity_counters"/>. (octets 6-7).</dd>
Occupies bits 52 through 63 (octets 6-7).</t>
</dd>
<dt>var:</dt> <dt>var:</dt>
<dd> <dd>The 2-bit variant field as defined by <xref
<t>The 2 bit variant field as defined by <xref target="variant_field target="variant_field"/>, set to 0b10. Occupies bits 64 and 65 of
"/>, set to 0b10. octet 8.</dd>
Occupies bits 64 and 65 of octet 8.</t>
</dd>
<dt>rand_b:</dt> <dt>rand_b:</dt>
<dd> <dd>The final 62 bits of pseudorandom data to provide uniqueness as
<t>The final 62 bits of pseudo-random data to provide uniqueness as per <xref target="unguessability"/> and/or an optional counter to
per <xref target="unguessability"/> guarantee additional monotonicity as per <xref
and/or an optional counter to guarantee additional monotonicity as per <xref tar target="monotonicity_counters"/>. Occupies bits 66 through 127
get="monotonicity_counters"/>. (octets 8-15).</dd>
Occupies bits 66 through 127 (octets 8-15).</t>
</dd>
</dl> </dl>
</section> </section>
<section anchor="uuidv8"> <section anchor="uuidv8">
<name>UUID Version 8</name> <name>UUID Version 8</name>
<t>UUID version 8 provides an RFC-compatible format for experimental or <t>UUIDv8 provides a format for experimental
vendor-specific or vendor-specific use cases. The only requirement is that the
use cases. variant and version bits <bcp14>MUST</bcp14> be set as defined in
The only requirement is that the variant and version bits <bcp14>MUST</bcp14> be Sections <xref target="variant_field" format="counter"/> and <xref
set as target="version_field" format="counter"/>. UUIDv8's uniqueness will be
defined in <xref target="variant_field"/> and <xref target="version_field"/>. implementation specific and <bcp14>MUST NOT</bcp14> be assumed.</t>
UUIDv8's uniqueness will be implementation-specific and <bcp14>MUST NOT</bcp14> <t>The only explicitly defined bits are those of the version and
be assumed.</t> variant fields, leaving 122 bits for implementation-specific UUIDs. To
<t>The only explicitly defined bits are those of the version and variant be clear, UUIDv8 is not a replacement for UUIDv4 (<xref
fields, leaving 122 target="uuidv4"/>) where all 122 extra bits are filled with random
bits data.</t>
for implementation specific UUIDs. To be clear:
UUIDv8 is not a replacement for UUIDv4 <xref target="uuidv4"/> where all 122 ext
ra bits are
filled with random data.</t>
<t>Some example situations in which UUIDv8 usage could occur:</t> <t>Some example situations in which UUIDv8 usage could occur:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>An implementation would like to embed extra information
<t>An implementation would like to embed extra information within the UUID other than what is defined in this document.</li>
within the UUID other than what is defined in this document.</t> <li>An implementation has other application and/or language
</li> restrictions that inhibit the use of one of the current UUIDs.</li>
<li>
<t>An implementation has other application/language restrictions whi
ch
inhibit the use of one of the current UUIDs.</t>
</li>
</ul> </ul>
<t>The appendix, <xref target="ill_examples"/>, provides two illustrativ
e examples of custom UUIDv8 algorithms to address two example scenarios.</t> <t><xref target="ill_examples"/> provides two illustrative examples of
custom UUIDv8 algorithms to address two example scenarios.</t>
<figure> <figure>
<name>UUIDv8 Field and Bit Layout</name> <name>UUIDv8 Field and Bit Layout</name>
<artwork><![CDATA[ <artwork><![CDATA[
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| custom_a | | custom_a |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| custom_a | ver | custom_b | | custom_a | ver | custom_b |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|var| custom_c | |var| custom_c |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| custom_c | | custom_c |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<dl newline="true">
<dl spacing="normal" newline="true">
<dt>custom_a:</dt> <dt>custom_a:</dt>
<dd> <dd>The first 48 bits of the layout that can be filled as an
<t>The first 48 bits of the layout that can be filled as an implemen implementation sees fit. Occupies bits 0 through 47 (octets 0-5).
tation sees
fit. Occupies bits 0 through 47 (octets 0-5).</t>
</dd> </dd>
<dt>ver:</dt> <dt>ver:</dt>
<dd> <dd>The 4-bit version field as defined by <xref
<t>The 4 bit version field as defined by <xref target="version_field target="version_field"/>, set to 0b1000 (8). Occupies bits 48
"/>, set to 0b1000 (8). through 51 of octet 6.</dd>
Occupies bits 48 through 51 of octet 6.</t>
</dd>
<dt>custom_b:</dt> <dt>custom_b:</dt>
<dd> <dd>12 more bits of the layout that can be filled as an
<t>12 more bits of the layout that can be filled as an implementatio implementation sees fit. Occupies bits 52 through 63 (octets 6-7).
n sees fit.
Occupies bits 52 through 63 (octets 6-7).</t>
</dd> </dd>
<dt>var:</dt> <dt>var:</dt>
<dd> <dd>The 2-bit variant field as defined by <xref
<t>The 2 bit variant field as defined by <xref target="variant_field target="variant_field"/>, set to 0b10. Occupies bits 64 and 65 of
"/>, set to 0b10. octet 8.</dd>
Occupies bits 64 and 65 of octet 8.</t>
</dd>
<dt>custom_c:</dt> <dt>custom_c:</dt>
<dd> <dd>The final 62 bits of the layout immediately following the var
<t>The final 62 bits of the layout immediately following the var fie field to be filled as an implementation sees fit. Occupies bits 66
ld to be through 127 (octets 8-15).</dd>
filled as an implementation sees fit.
Occupies bits 66 through 127 (octets 8-15).</t>
</dd>
</dl> </dl>
</section> </section>
<section anchor="niluuid"> <section anchor="niluuid">
<name>Nil UUID</name> <name>Nil UUID</name>
<t>The nil UUID is special form of UUID that is specified to have all <t>The Nil UUID is special form of UUID that is specified to have all
128 bits set to zero.</t> 128 bits set to zero.</t>
<figure> <figure>
<name>Nil UUID Format</name> <name>Nil UUID Format</name>
<artwork><![CDATA[ <artwork><![CDATA[
00000000-0000-0000-0000-000000000000 00000000-0000-0000-0000-000000000000
]]></artwork> ]]></artwork>
</figure> </figure>
<t>A Nil UUID value can be useful to communicate the absence of any othe
r UUID value in situations that otherwise require or use a 128 bit UUID. A Nil <t>A Nil UUID value can be useful to communicate the absence of any
UUID can express the concept "no such value here". Thus it is reserved for such other UUID value in situations that otherwise require or use a 128-bit
use as needed for implementation-specific situations.</t> UUID. A Nil UUID can express the concept "no such value here". Thus,
<t>Note that the Nil UUID value falls within the range of the Apollo NCS it is reserved for such use as needed for implementation-specific
variant as per the first row of <xref target="table1"/> rather than the variant situations.</t>
defined by this document.</t> <t>Note that the Nil UUID value falls within the range of the Apollo
NCS variant as per the first row of <xref target="table1"/> rather
than the variant defined by this document.</t>
</section> </section>
<section anchor="maxuuid"> <section anchor="maxuuid">
<name>Max UUID</name> <name>Max UUID</name>
<t>The Max UUID is a special form of UUID that is specified to have all <t>The Max UUID is a special form of UUID that is specified to have
128 bits all 128 bits set to 1. This UUID can be thought of as the inverse of
set to 1. This UUID can be thought of as the inverse of Nil UUID defined the Nil UUID defined in <xref target="niluuid"/>.</t>
in <xref target="niluuid"/>.</t>
<figure> <figure>
<name>Max UUID Format</name> <name>Max UUID Format</name>
<artwork><![CDATA[ <artwork><![CDATA[
FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF
]]></artwork> ]]></artwork>
</figure> </figure>
<t>A Max UUID value can be used as a sentinel value in situations where
a 128 bit UUID is required but a concept such as "end of UUID list" needs to be <t>A Max UUID value can be used as a sentinel value in situations
expressed, and is reserved for such use as needed for implementation-specific si where a 128-bit UUID is required, but a concept such as "end of UUID
tuations.</t> list" needs to be expressed and is reserved for such use as needed
<t>Note that the Max UUID value falls within the range of the "yet to be for implementation-specific situations.</t>
defined" future UUID variant as per the last row of <xref target="table1"/> rat <t>Note that the Max UUID value falls within the range of the "yet-to-be
her than the variant defined by this document.</t> defined" future UUID variant as per the last row of <xref
target="table1"/> rather than the variant defined by this
document.</t>
</section> </section>
</section> </section>
<section anchor="uuid_best_practices"> <section anchor="uuid_best_practices">
<name>UUID Best Practices</name> <name>UUID Best Practices</name>
<t>The minimum requirements for generating UUIDs are <t>The minimum requirements for generating UUIDs of each version are descr
described in this document for each version. ibed in this
Everything else is an implementation detail and it is document. Everything else is an implementation detail,
up to the implementer to decide what is appropriate for a given and it is up to the implementer to decide what is appropriate for a
implementation. Various relevant factors are covered given implementation. Various relevant factors are covered below to help
below to help guide an implementer through the different trade-offs among guide an implementer through the different trade-offs among differing
differing UUID implementations.</t> UUID implementations.</t>
<section anchor="timestamp_considerations"> <section anchor="timestamp_considerations">
<name>Timestamp Considerations</name> <name>Timestamp Considerations</name>
<t>UUID timestamp source, precision, and length was the topic of great d <t>UUID timestamp source, precision, and length were topics of great
ebate debate while creating UUIDv7 for this specification. Choosing the
while creating UUIDv7 for this specification. Choosing the right timestamp for right timestamp for your application is very important. This
your application is a very important topic. This section will detail some section will detail some of the most common points on this issue.</t>
of the most common points on this topic.</t>
<dl newline="true"> <dl spacing="normal" newline="true">
<dt>Reliability:</dt> <dt>Reliability:</dt>
<dd> <dd>Implementations acquire the current timestamp from a reliable
<t>Implementations acquire the current timestamp from a reliable sou source to provide values that are time ordered and continually
rce to increasing. Care must be taken to ensure that timestamp changes
provide values that are time-ordered and continually increasing. from the environment or operating system are handled in a way that
Care must be taken to ensure that timestamp changes from the environment is consistent with implementation requirements. For example, if it
or operating system are handled in a way that is consistent with implementation is possible for the system clock to move backward due to either
requirements. manual adjustment or corrections from a time synchronization
For example, if it is possible for the system clock to move backward due protocol, implementations need to determine how to handle such
to either manual adjustment or corrections from a time synchronization protocol, cases. (See "Altering, Fuzzing, or Smearing" below.)</dd>
implementations need to determine how to handle such cases. (See Altering, Fuzzi
ng,
or Smearing below.)</t>
</dd>
<dt>Source:</dt> <dt>Source:</dt>
<dd> <dd>UUIDv1 and UUIDv6 both utilize a Gregorian Epoch timestamp,
<t>UUID version 1 and 6 both utilize a Gregorian epoch timestamp whi while UUIDv7 utilizes a Unix Epoch timestamp. If other timestamp
le UUIDv7 sources or a custom timestamp Epoch are required, UUIDv8
utilizes a Unix Epoch timestamp. If other timestamp sources or a custom timestam <bcp14>MUST</bcp14> be used.</dd>
p
epoch are required, UUIDv8 <bcp14>MUST</bcp14> be used.</t>
</dd>
<dt>Sub-second Precision and Accuracy:</dt> <dt>Sub-second Precision and Accuracy:</dt>
<dd> <dd>Many levels of precision exist for timestamps: milliseconds,
<t>Many levels of precision exist for timestamps: milliseconds, micr microseconds, nanoseconds, and beyond. Additionally, fractional
oseconds, representations of sub-second precision may be desired to mix
nanoseconds, and beyond. various levels of precision in a time-ordered manner. Furthermore,
Additionally fractional representations of sub-second precision may be desired system clocks themselves have an underlying granularity, which is
to mix various levels of precision in a time-ordered manner. frequently less than the precision offered by the operating system.
Furthermore, system clocks themselves have an underlying granularity and With UUIDv1 and UUIDv6, 100 nanoseconds of precision are present,
it is frequently less than the precision offered by the operating system. while UUIDv7 features a millisecond level of precision by default
With UUID version 1 and 6, 100-nanoseconds of precision are present while within the Unix Epoch that does not exceed the granularity capable
UUIDv7 features millisecond level of precision by default within the Unix epoch in most modern systems. For other levels of precision, UUIDv8 is
that does not exceed the granularity capable in most modern systems. available. Similar to <xref target="monotonicity_counters"/>, with
For other levels of precision UUIDv8 is available. UUIDv1 or UUIDv6, a high-resolution timestamp can be simulated by
Similar to <xref target="monotonicity_counters"/>, with UUIDv1 or UUIDv6, keeping a count of the number of UUIDs that have been generated with
a high resolution timestamp can be simulated by keeping a count of the same value of the system time and using that count to construct th
the number of UUIDs that have been generated with the same value of e low
the system time, and using it to construct the low order bits of the order bits of the timestamp. The count of the high-resolution
timestamp. The count of the high resolution timestamp will range between zero a timestamp will range between zero and the number of 100-nanosecond
nd the number of intervals per system-time interval.</dd>
100-nanosecond intervals per system time interval.</t>
</dd>
<dt>Length:</dt> <dt>Length:</dt>
<dd> <dd>The length of a given timestamp directly impacts how many
<t>The length of a given timestamp directly impacts how many timesta timestamp ticks can be contained in a UUID before the maximum value
mp ticks can be contained in a UUID before the maximum for the timestamp field is reached. Take care to ensure that the
value for the timestamp field is reached. proper length is selected for a given timestamp. UUIDv1 and
Take care to ensure that the proper length is selected for a given UUIDv6 utilize a 60-bit timestamp valid until 5623 AD; UUIDv7 features
timestamp. a 48-bit timestamp valid until the year 10889 AD.</dd>
UUID version 1 and 6 utilize a 60 bit timestamp valid until 5623 AD and UUIDv7 f
eatures a 48
bit timestamp valid until the year 10889 AD.</t>
</dd>
<dt>Altering, Fuzzing, or Smearing:</dt> <dt>Altering, Fuzzing, or Smearing:</dt>
<dd> <dd>Implementations <bcp14>MAY</bcp14> alter the actual
<t>Implementations <bcp14>MAY</bcp14> alter the actual timestamp. So timestamp. Some examples include security considerations around
me examples include security providing a real-clock value within a UUID to 1) correct inaccurate
considerations around providing a real clock value within a UUID, to correct clocks, 2) handle leap seconds, or 3) obtain a millisecond value by
inaccurate clocks, to handle leap seconds, or instead of dividing a number of mi dividing by 1024 (or some other value) for performance reasons
croseconds by 1000 to obtain a millisecond value; dividing by 1024 (or some othe (instead of dividing a number of microseconds by 1000). This
r value) for performance reasons. This specification makes no specification makes no requirement or guarantee about how close the
requirement or guarantee about how close the clock value needs to be to the actu clock value needs to be to the actual time. If UUIDs do not need to
al be frequently generated, the UUIDv1 or UUIDv6 timestamp can simply
time. be the system time multiplied by the number of 100-nanosecond
If UUIDs do not need to be frequently generated, the UUIDv1 or UUIDv6 timestamp intervals per system-time interval.</dd>
can
simply be the system time multiplied by the number of 100-nanosecond
intervals per system time interval.</t>
</dd>
<dt>Padding:</dt> <dt>Padding:</dt>
<dd> <dd>When timestamp padding is required, implementations
<t>When timestamp padding is required, implementations <bcp14>MUST</ <bcp14>MUST</bcp14> pad the most significant bits (leftmost)
bcp14> pad the most significant with data. An example for this padding data is to fill the most
bits (left-most) bits with data. An example for this padding data is to fill the significant, leftmost bits of a Unix timestamp with zeroes to
most significant, complete the 48-bit timestamp in UUIDv7. An alternative approach for
left-most bits of a Unix timestamp with zeroes to complete the 48 padding data is to fill the most significant, leftmost bits with
bit timestamp in UUIDv7. An alternative approach for padding data is to fill the the number of 32-bit Unix timestamp rollovers after 2038-01-19.
most significant, left-most bits with the number of 32 bit Unix timestamp roll-
overs after 2038-01-19.</t>
</dd> </dd>
<dt>Truncating:</dt> <dt>Truncating:</dt>
<dd> <dd>When timestamps need to be truncated, the lower, least
<t>When timestamps need to be truncated, the lower, least significan significant bits <bcp14>MUST</bcp14> be used. An example would be
t truncating a 64-bit Unix timestamp to the least significant,
bits <bcp14>MUST</bcp14> be used. An example would be truncating a 64 bit Unix t rightmost 48 bits for UUIDv7.</dd>
imestamp
to the least significant, right-most 48 bits for UUIDv7.</t>
</dd>
<dt>Error Handling:</dt> <dt>Error Handling:</dt>
<dd> <dd>If a system overruns the generator by requesting too many UUIDs
<t>If a system overruns the generator by requesting too many UUIDs within a single system-time interval, the UUID service can return an
within a single system time interval, the UUID service can error or stall the UUID generator until the system clock catches
return an error, or stall the UUID generator until the system clock up and <bcp14>MUST NOT</bcp14> knowingly return duplicate values
catches up, and <bcp14>MUST NOT</bcp14> return knowingly duplicate values due to due to a counter rollover. Note that if the processors overrun the
a UUID generation frequently, additional Node IDs can be
counter rollover. allocated to the system, which will permit higher speed allocation
Note that if the processors overrun the UUID generation frequently, by making multiple UUIDs potentially available for each timestamp
additional node identifiers can be allocated to the system, which value. Similar techniques are discussed in <xref
will permit higher speed allocation by making multiple UUIDs target="distributed_shared_knowledge"/>.</dd>
potentially available for each time stamp value.
Similar techniques are discussed in <xref target="distributed_shared_knowledge"/
>.</t>
</dd>
</dl> </dl>
</section> </section>
<section anchor="monotonicity_counters"> <section anchor="monotonicity_counters">
<name>Monotonicity and Counters</name> <name>Monotonicity and Counters</name>
<t>Monotonicity (each subsequent value being greater than the last) is t <t>Monotonicity (each subsequent value being greater than the last) is
he backbone of time-based sortable UUIDs. Normally, time-based the backbone of time-based sortable UUIDs. Normally, time-based UUIDs
UUIDs from this document will be monotonic due to an embedded timestamp; however from this document will be monotonic due to an embedded timestamp;
, however, implementations can guarantee additional monotonicity via the
implementations can guarantee additional monotonicity via the concepts covered concepts covered in this section.</t>
in this section.</t> <t>Take care to ensure UUIDs generated in batches are also
<t>Take care to ensure UUIDs generated in batches are monotonic. That is, if one thousand UUIDs are generated for the same
also monotonic. That is, if one thousand UUIDs are generated for the same timestamp, there should be sufficient logic for organizing the
timestamp, there should be sufficient logic for organizing the creation order of creation order of those one thousand UUIDs. Batch UUID creation
those one thousand UUIDs. implementations <bcp14>MAY</bcp14> utilize a monotonic counter that
Batch UUID creation implementations <bcp14>MAY</bcp14> utilize a monotonic count increments for each UUID created during a given timestamp.</t>
er that <t>For single-node UUID implementations that do not need to create
increments for each UUID created during a given timestamp.</t> batches of UUIDs, the embedded timestamp within UUIDv6 and UUIDv7
<t>For single-node UUID implementations that do not need to create batch can provide sufficient monotonicity guarantees by simply ensuring that
es of timestamp increments before creating a new UUID. Distributed nodes are
UUIDs, the embedded timestamp within UUID version 6 and 7 can provide discussed in <xref target="distributed_shared_knowledge"/>.</t>
sufficient monotonicity guarantees by simply ensuring that timestamp increments <t>Implementations <bcp14>SHOULD</bcp14> employ the following methods
before creating a new UUID. Distributed nodes are discussed in for single-node UUID implementations that require batch UUID creation
<xref target="distributed_shared_knowledge"/>.</t> or are otherwise concerned about monotonicity with high-frequency UUID
<t>Implementations <bcp14>SHOULD</bcp14> employ the following methods fo generation.</t>
r single-node UUID implementations
that require batch UUID creation, or are otherwise concerned about monotonicity <dl spacing="normal" newline="true">
with high frequency UUID generation.</t> <dt>Fixed Bit-Length Dedicated Counter (Method 1):</dt>
<dl newline="true"> <dd>Some implementations allocate a specific number of bits in the
<dt>Fixed-Length Dedicated Counter Bits (Method 1):</dt> UUID layout to the sole purpose of tallying the total number of
<dd> UUIDs created during a given UUID timestamp tick. If present, a fixed
<t>Some implementations allocate a specific number of bits in the bit-length counter <bcp14>MUST</bcp14> be positioned
UUID layout to the sole purpose of tallying the total number of UUIDs created immediately after the embedded timestamp. This promotes sortability
during a given UUID timestamp tick. and allows random data generation for each counter increment.
A fixed bit-length counter, if present, <bcp14>MUST</bcp14> be positioned immedi With
ately after the this method, the rand_a section (or a subset of its leftmost bits)
embedded timestamp. This promotes sortability and allows random data generation of UUIDv7 is used as a fixed bit-length dedicated counter that is
for each counter increment. incremented for every UUID generation. The trailing random bits
With this method, the rand_a section (or a subset of its left-most bits) of UUID generated for each new UUID in rand_b can help produce unguessable
v7 UUIDs. In the event that more counter bits are required, the most
is used as fixed-length dedicated counter bits that are incremented for significant (leftmost) bits of rand_b <bcp14>MAY</bcp14> be used as
every UUID generation. additional counter bits.</dd>
The trailing random bits generated for each new UUID in rand_b can help produce
unguessable UUIDs. In the event more counter bits are required, the most signifi
cant
(left-most) bits of rand_b <bcp14>MAY</bcp14> be used as additional counter bits
.</t>
</dd>
<dt>Monotonic Random (Method 2):</dt> <dt>Monotonic Random (Method 2):</dt>
<dd> <dd>With this method, the random data is extended to also function
<t>With this method, the random data is extended to also function as as a counter. This monotonic value can be thought of as a "randomly
a counter. seeded counter" that <bcp14>MUST</bcp14> be incremented in the
This monotonic value can be thought of as a "randomly seeded counter" which least significant position for each UUID created on a given
<bcp14>MUST</bcp14> be incremented in the least significant position for each UU timestamp tick. UUIDv7's rand_b section <bcp14>SHOULD</bcp14> be
ID created utilized with this method to handle batch UUID generation during a
on a given timestamp tick. single timestamp tick. The increment value for every UUID
UUIDv7's rand_b section <bcp14>SHOULD</bcp14> be utilized with this method to ha generation is a random integer of any desired length larger than
ndle batch zero. It ensures that the UUIDs retain the required level of
UUID generation during a single timestamp tick. unguessability provided by the underlying entropy. The increment
The increment value for every UUID generation is a random integer value <bcp14>MAY</bcp14> be 1 when the number of UUIDs generated in
of any desired length larger than zero. It ensures the UUIDs retain the required a particular period of time is important and guessability is not an
level of unguessability provided by the underlying entropy. issue. However, incrementing the counter by 1 <bcp14>SHOULD
The increment value <bcp14>MAY</bcp14> be 1 when the number of UUIDs generated i NOT</bcp14> be used by implementations that favor unguessability, as
n a particular the resulting values are easily guessable.</dd>
period of time is important and guessability is not an issue. However, increment <dt>Replace Leftmost Random Bits with Increased Clock Precision (Metho
ing the counter by 1 d 3):</dt>
<bcp14>SHOULD NOT</bcp14> be used by implementations that favor unguessability, <dd><t>For UUIDv7, which has millisecond timestamp precision, it is
as the resulting possible to use additional clock precision available on the system
values are easily guessable.</t> to substitute for up to 12 random bits immediately following the
</dd> timestamp. This can provide values that are time ordered with
<dt>Replace Left-Most Random Bits with Increased Clock Precision (Meth sub-millisecond precision, using however many bits are appropriate
od 3):</dt> in the implementation environment. With this method, the additional
<dd> time precision bits <bcp14>MUST</bcp14> follow the timestamp as the
<t>For UUIDv7, which has millisecond timestamp precision, it is poss next available bit in the rand_a field for UUIDv7.</t>
ible <t>To calculate this value, start with the portion of the timestamp
to use additional clock precision available on the system to substitute expressed as a fraction of the clock's tick value (fraction of a
for up to 12 random bits immediately following the timestamp. This can provide millisecond for UUIDv7). Compute the count of possible values that
values that are time-ordered with sub-millisecond precision, using can be represented in the available bit space, 4096 for the UUIDv7
however many bits are appropriate in the implementation environment. rand_a field. Using floating point or scaled integer arithmetic,
With this method, the additional time precision bits <bcp14>MUST</bcp14> follow multiply this fraction of a millisecond value by 4096 and round down
the (toward zero) to an integer result to arrive at a number between 0
timestamp as the next available bit, in the rand_a field for UUIDv7. and the maximum allowed for the indicated bits, which sorts
</t> monotonically based on time. Each increasing fractional value will
<t>To calculate this value, start with the portion of the timestamp result in an increasing bit field value to the precision available
expressed as a fraction of clock's tick value (fraction of a millisecond with these bits.</t>
for UUIDv7). Compute the count of possible values that can be represented in <t>For example, let's assume a system timestamp of 1 Jan 2023
the available bit space, 4096 for the UUIDv7 rand_a field. 12:34:56.1234567. Taking the precision greater than 1 ms gives us a
Using floating point or scaled integer arithmetic, multiply this fraction of a m value of 0.4567, as a fraction of a millisecond. If we wish to
illisecond encode this as 12 bits, we can take the count of possible values
value by 4096 and round down (toward zero) to an integer result to arrive at a n that fit in those bits (4096 or 2<sup>12</sup>), multiply it by our
umber millisecond fraction value of 0.4567, and truncate the result to an
between 0 and the maximum allowed for the indicated bits integer, which gives an integer value of 1870. Expressed as
which sorts monotonically based on time. Each increasing fractional hexadecimal, it is 0x74E or the binary bits 0b011101001110. One can
value will result in an increasing bit field value, to the then use those 12 bits as the most significant (leftmost) portion of
precision available with these bits.</t> the random section of the UUID (e.g., the rand_a field in UUIDv7).
<t>For example, let's assume a system timestamp of 1 Jan 2023 12:34: This works for any desired bit length that fits into a UUID, and
56.1234567. applications can decide the appropriate length based on available
Taking the precision greater than 1ms gives us a value of 0.4567, as a clock precision; for UUIDv7, it is limited to 12 bits at maximum to
fraction of a millisecond. If we wish to encode this as 12 bits, we can reserve sufficient space for random bits.</t>
take the count of possible values that fit in those bits (4096, or 2 to the 12th <t>The main benefit to encoding additional timestamp precision is
power) that it utilizes additional time precision already available in the
and multiply it by our millisecond fraction value of 0.4567 and truncate the res system clock to provide values that are more likely to be unique; thus
ult to , it may simplify certain implementations. This technique can
an integer, which gives an integer value of 1870. Expressed as hexadecimal it is also be used in conjunction with one of the other methods, where
0x74E, or the binary bits 0b011101001110. One can then use those 12 bits this additional time precision would immediately follow the
as the most significant (left-most) portion of the random section of the UUID timestamp. Then, if any bits are to be used as a clock sequence,
(e.g., the rand_a field in UUIDv7). they would follow next.</t></dd>
This works for any desired bit length that fits into a UUID, and applications
can decide the appropriate length based on available clock precision, but for
UUIDv7, it is limited to 12 bits at maximum to reserve sufficient space for
random bits.</t>
<t>The main benefit to encoding additional timestamp precision
is that it utilizes additional time precision already available in the system cl
ock
to provide values that are more likely to be unique, and thus may simplify
certain implementations. This technique can also be used in conjunction with one
of the other methods, where this additional time precision would immediately
follow the timestamp, and then if any bits are to be used as clock sequence
they would follow next.</t>
</dd>
</dl> </dl>
<t>The following sub-topics cover topics related solely with creating re
liable <t>The following sub-topics cover issues related solely to creating reli
fixed-length dedicated counters:</t> able
<dl newline="true"> fixed bit-length dedicated counters:</t>
<dt>Fixed-Length Dedicated Counter Seeding:</dt>
<dd> <dl spacing="normal" newline="true">
<t>Implementations utilizing the fixed-length counter method randoml <dt>Fixed Bit-Length Dedicated Counter Seeding:</dt>
y initialize <dd>Implementations utilizing the fixed bit-length counter method
the counter with each new timestamp tick. randomly initialize the counter with each new timestamp tick.
However, when the timestamp has not increased, the counter is instead incremente However, when the timestamp has not increased, the counter is
d by the desired increment logic. instead incremented by the desired increment logic. When utilizing
When utilizing a randomly seeded counter alongside Method 1, the random value <b a randomly seeded counter alongside Method 1, the random value
cp14>MAY</bcp14> <bcp14>MAY</bcp14> be regenerated with each counter increment
be regenerated with each counter increment without impacting sortability. without impacting sortability. The downside is that Method 1 is
The downside is that Method 1 is prone to overflows if a counter of adequate prone to overflows if a counter of adequate length is not selected
length is not selected or the random data generated leaves little room for or the random data generated leaves little room for the required
the required number of increments. number of increments. Implementations utilizing fixed bit-length
Implementations utilizing fixed-length counter method <bcp14>MAY</bcp14> also ch counter method <bcp14>MAY</bcp14> also choose to randomly initialize
oose to a portion of the counter rather than the entire counter. For
randomly initialize a portion of the counter rather than the entire counter. For example, a 24-bit counter could have the 23 bits in
example, a 24 bit counter could have the 23 bits in least-significant, right-mos least significant, rightmost position randomly initialized. The
t, remaining most significant, leftmost counter bit is initialized as
position randomly initialized. The remaining most significant, left-most zero for the sole purpose of guarding against counter rollovers.
counter bit is initialized as zero for the sole purpose of guarding against
counter rollovers.</t>
</dd>
<dt>Fixed-Length Dedicated Counter Length:</dt>
<dd>
<t>Select a counter bit-length that can properly handle
the level of timestamp precision in use.
For example, millisecond precision generally requires a larger counter than a
timestamp with nanosecond precision.
General guidance is that the counter <bcp14>SHOULD</bcp14> be at least 12 bits b
ut no longer
than 42 bits.
Care must be taken to ensure that the counter length selected leaves
room for sufficient entropy in the random portion of the UUID after the counter.
This entropy helps improve the unguessability characteristics of UUIDs created
within the batch.</t>
</dd> </dd>
<dt>Fixed Bit-Length Dedicated Counter Length:</dt>
<dd>Select a counter bit-length that can properly handle the level
of timestamp precision in use. For example, millisecond precision
generally requires a larger counter than a timestamp with nanosecond
precision. General guidance is that the counter
<bcp14>SHOULD</bcp14> be at least 12 bits but no longer than 42
bits. Care must be taken to ensure that the counter length selected
leaves room for sufficient entropy in the random portion of the UUID
after the counter. This entropy helps improve the unguessability
characteristics of UUIDs created within the batch.</dd>
</dl> </dl>
<t>The following sub-topics cover rollover handling with either type of counter <t>The following sub-topics cover rollover handling with either type of counter
method:</t> method:</t>
<dl newline="true">
<dl spacing="normal" newline="true">
<dt>Counter Rollover Guards:</dt> <dt>Counter Rollover Guards:</dt>
<dd> <dd>The technique from "Fixed Bit-Length Dedicated Counter Seeding" ab
<t>The technique from Fixed-Length Dedicated Counter Seeding that de ove that
scribes describes allocating a segment of the fixed bit-length counter as a
allocating a segment of the fixed-length counter as a rollover guard is also rollover guard is also helpful to mitigate counter rollover issues.
helpful to mitigate counter rollover issues. This same technique can be used with monotonic random counter
This same technique can be used with monotonic random counter methods methods by ensuring that the total length of a possible increment in
by ensuring that the total length of a possible increment in the least significa the least significant, rightmost position is less than the total
nt, length of the random value being incremented. As such, the most
right most position is less than the total length of the random value being incr significant, leftmost bits can be incremented as rollover
emented. guarding.</dd>
As such, the most significant, left-most, bits can be incremented as rollover
guarding.</t>
</dd>
<dt>Counter Rollover Handling:</dt> <dt>Counter Rollover Handling:</dt>
<dd> <dd>Counter rollovers <bcp14>MUST</bcp14> be handled by the
<t>Counter rollovers <bcp14>MUST</bcp14> be handled by the applicati application to avoid sorting issues. The general guidance is that
on to avoid sorting issues. applications that care about absolute monotonicity and sortability
The general guidance is that applications that care about absolute monotonicity should freeze the counter and wait for the timestamp to advance,
and sortability should freeze the counter and wait for the timestamp to advance which ensures monotonicity is not broken. Alternatively,
which ensures monotonicity is not broken. implementations <bcp14>MAY</bcp14> increment the timestamp ahead of
Alternatively, implementations <bcp14>MAY</bcp14> increment the timestamp ahead the actual time and reinitialize the counter.</dd>
of the actual
time and reinitialize the counter.</t>
</dd>
</dl> </dl>
<t>Implementations <bcp14>MAY</bcp14> use the following logic to ensure
UUIDs featuring embedded <t>Implementations <bcp14>MAY</bcp14> use the following logic to
counters are monotonic in nature:</t> ensure UUIDs featuring embedded counters are monotonic in nature:</t>
<ol spacing="normal" type="1"><li>
<t>Compare the current timestamp against the previously stored times <ol spacing="normal" type="1">
tamp.</t> <li>Compare the current timestamp against the previously stored
</li> timestamp.</li>
<li> <li>If the current timestamp is equal to the previous timestamp,
<t>If the current timestamp is equal to the previous timestamp, incr increment the counter according to the desired method.</li>
ement the <li>If the current timestamp is greater than the previous timestamp,
counter according to the desired method.</t> re-initialize the desired counter method to the new timestamp and
</li> generate new random bytes (if the bytes were frozen or being used as
<li> the seed for a monotonic counter). </li>
<t>If the current timestamp is greater than the previous timestamp,
re-initialize
the desired counter method to the new timestamp and generate new random bytes
(if the bytes were frozen or being used as the seed for a monotonic counter).<
/t>
</li>
</ol> </ol>
<dl newline="true">
<dl spacing="normal" newline="true">
<dt>Monotonic Error Checking:</dt> <dt>Monotonic Error Checking:</dt>
<dd> <dd>Implementations <bcp14>SHOULD</bcp14> check if the currently
<t>Implementations <bcp14>SHOULD</bcp14> check if the currently gene generated UUID is greater than the previously generated UUID. If
rated UUID is greater this is not the case, then any number of things could have occurred,
than the previously generated UUID. If this is not the case then any number such as clock rollbacks, leap second handling, and counter
of things could have occurred, such as clock rollbacks, rollovers. Applications <bcp14>SHOULD</bcp14> embed sufficient logic
leap second handling, and counter rollovers. Applications <bcp14>SHOULD</bcp14> to catch these scenarios and correct the problem to ensure that the
embed sufficient next UUID generated is greater than the previous, or they should at le
logic to catch these scenarios and correct the problem to ensure that the next ast report
UUID generated is greater than the previous, or at least report an appropriate e an appropriate error. To handle this scenario, the general guidance
rror. is that the application <bcp14>MAY</bcp14> reuse the previous timestam
To handle this scenario, the p
general guidance is that application <bcp14>MAY</bcp14> reuse the previous times and increment the previous counter method. </dd>
tamp and
increment the previous counter method.</t>
</dd>
</dl> </dl>
</section> </section>
<section anchor="generator_states"> <section anchor="generator_states">
<name>UUID Generator States</name> <name>UUID Generator States</name>
<t>The (optional) UUID generator state only needs to be read from stable <t>The (optional) UUID generator state only needs to be read from
storage once at boot stable storage once at boot time, if it is read into a system-wide
time, if it is read into a system-wide shared volatile store (and shared volatile store (and updated whenever the stable store is
updated whenever the stable store is updated).</t> updated).</t>
<t>This stable storage <bcp14>MAY</bcp14> be used to record various port <t>This stable storage <bcp14>MAY</bcp14> be used to record various
ions of the UUID generation portions of the UUID generation, which prove useful for batch UUID
which prove useful for batch UUID generation purposes and monotonic error checki generation purposes and monotonic error checking with UUIDv6 and
ng with UUIDv6 and UUIDv7. UUIDv7. These stored values include but are not limited to last known
These stored values include but are not limited to last known timestamp, clock s timestamp, clock sequence, counters, and random data.</t>
equence, counters, and random data.</t>
<t>If an implementation does not have any stable store available, then <t>If an implementation does not have any stable store available, then
it <bcp14>MAY</bcp14> proceed with UUID generation as if this was the first UUID it <bcp14>MAY</bcp14> proceed with UUID generation as if this were the
created within a batch. first UUID created within a batch. This is the least desirable
This is the least desirable implementation because it will increase the frequenc implementation because it will increase the frequency of creation of
y values such as clock sequence, counters, or random data, which
of creation of values such as clock sequence, counters, or random data, which in increases the probability of duplicates. Further, frequent generation
creases the of random numbers also puts more stress on any entropy source and/or
probability of duplicates. Further, frequent generation of random numbers also p entropy pool being used as the basis for such random numbers.</t>
uts more stress on any entropy source and or entropy pool being used as the basi <t>An implementation <bcp14>MAY</bcp14> also return an application
s for such random numbers.</t> error in the event that collision resistance is of the utmost concern.
<t>An implementation <bcp14>MAY</bcp14> also return an application error The semantics of this error are up to the application and
in the event that collision resistance is of the utmost concern. implementation. See <xref target="collision_resistance"/> for more
The semantics of this error are up to the application and implementation. information on weighting collision tolerance in applications.</t>
See <xref target="collision_resistance"/> for more information on weighting coll <t>For UUIDv1 and UUIDv6, if the Node ID can never change (e.g., the
ision tolerance in applications.</t> network interface card from which the Node ID is derived is
<t>For UUIDv1 and UUIDv6, if the node ID can never change (e.g., the net inseparable from the system), or if any change also re-initializes the
work interface card clock sequence to a random value, then instead of keeping it in stable
from which the node ID is derived is inseparable store, the current Node ID may be returned.</t>
from the system), or if any change also re-initializes the clock <t>For UUIDv1 and UUIDv6, the state does not always need to be written
sequence to a random value, then instead of keeping it in stable to stable store every time a UUID is generated. The timestamp in the
store, the current node ID may be returned.</t> stable store can periodically be set to a value larger than any yet
<t>For UUIDv1 and UUIDv6, the state does not always need to be written t used in a UUID. As long as the generated UUIDs have timestamps less
o stable store every than that value, and the clock sequence and Node ID remain unchanged,
time a UUID is generated. The timestamp in the stable store can be only the shared volatile copy of the state needs to be updated.
periodically set to a value larger than any yet used in a UUID. As Furthermore, if the timestamp value in stable store is in the future
long as the generated UUIDs have timestamps less than that value, and by less than the typical time it takes the system to reboot, a crash
the clock sequence and node ID remain unchanged, only the shared will not cause a re-initialization of the clock sequence.</t>
volatile copy of the state needs to be updated. Furthermore, if the
timestamp value in stable store is in the future by less than the
typical time it takes the system to reboot, a crash will not cause a
re-initialization of the clock sequence.</t>
<t>If it is too expensive to access shared state each time a UUID is <t>If it is too expensive to access shared state each time a UUID is
generated, then the system-wide generator can be implemented to generated, then the system-wide generator can be implemented to
allocate a block of time stamps each time it is called; a per- allocate a block of timestamps each time it is called; a per-process
process generator can allocate from that block until it is exhausted.</t> generator can allocate from that block until it is exhausted.</t>
</section> </section>
<section anchor="distributed_shared_knowledge"> <section anchor="distributed_shared_knowledge">
<name>Distributed UUID Generation</name> <name>Distributed UUID Generation</name>
<t>Some implementations <bcp14>MAY</bcp14> desire to utilize multi-node, <t>Some implementations <bcp14>MAY</bcp14> desire the utilization of
clustered, applications multi-node, clustered, applications that involve two or more nodes
which involve two or more independently generating UUIDs that will be stored in a common
nodes independently generating UUIDs that will be stored in a common location. location. While UUIDs already feature sufficient entropy to ensure
While UUIDs already feature sufficient entropy to ensure that the chances that the chances of collision are low, as the total number of UUID
of collision are low, as the total number of UUID generating nodes increase; so generating nodes increases, so does the likelihood of a collision.</t>
does the likelihood <t>This section will detail the two additional collision resistance
of a collision.</t> approaches that have been observed by multi-node UUID implementations
<t>This section will detail the two additional collision resistance appr in distributed environments.</t>
oaches that have been observed by multi-node <t>It should be noted that, although this section details two methods
UUID implementations in distributed environments.</t> for the sake of completeness, implementations should utilize the
<t>It should be noted that, although this section details two methods fo pseudorandom Node ID option if additional collision resistance for
r the sake of completeness, distributed UUID generation is a requirement. Likewise, utilization
implementations should utilize the pseudo-random Node ID option if additional co of either method is not required for implementing UUID generation in
llision resistance for distributed UUID generation is a requirement. distributed environments.</t>
Likewise, utilization of either method is not required for implementing UUID gen
eration in distributed environments.</t> <dl spacing="normal" newline="true">
<dl newline="true">
<dt>Node IDs:</dt> <dt>Node IDs:</dt>
<dd> <dd>With this method, a pseudorandom Node ID value is placed within
<t>With this method, a pseudo-random Node ID value is placed within the UUID layout. This identifier helps ensure the bit space for a
the UUID given node is unique, resulting in UUIDs that do not conflict with
layout. any other UUID created by another node with a different node id.
This identifier helps ensure the bit-space for a given node is unique, resulting Implementations that choose to leverage an embedded node id
in UUIDs that do not conflict with any other UUID created by another node <bcp14>SHOULD</bcp14> utilize UUIDv8. The node id <bcp14>SHOULD
with a different node id. NOT</bcp14> be an IEEE 802 MAC address per <xref
Implementations that choose to leverage an embedded node id <bcp14>SHOULD</bcp14 target="Security"/>. The location and bit length are left to
> utilize implementations and are outside the scope of this specification.
UUIDv8. Furthermore, the creation and negotiation of unique node ids among
The node id <bcp14>SHOULD NOT</bcp14> be an IEEE 802 MAC address as per <xref ta nodes is also out of scope for this specification.</dd>
rget="Security"/>.
The location and bit length are left to implementations and are outside the
scope of this specification.
Furthermore, the creation and negotiation of unique node ids among nodes
is also out of scope for this specification.</t>
</dd>
<dt>Centralized Registry:</dt> <dt>Centralized Registry:</dt>
<dd> <dd>With this method, all nodes tasked with creating UUIDs consult a
<t>With this method all nodes tasked with creating UUIDs consult a c central registry and confirm the generated value is unique. As
entral registry applications scale, the communication with the central registry
and confirm the generated value is unique. As applications scale, the communicat could become a bottleneck and impact UUID generation in a negative
ion way. Shared knowledge schemes with central/global registries are
with the central registry could become a bottleneck and impact UUID generation outside the scope of this specification and are <bcp14>NOT
in a negative way. Shared knowledge schemes with central/global RECOMMENDED</bcp14>.</dd>
registries are outside the scope of this specification and is <bcp14>NOT RECOMME
NDED</bcp14>.</t>
</dd>
</dl> </dl>
<t>Distributed applications generating UUIDs at a variety of hosts <bcp1 4>MUST</bcp14> <t>Distributed applications generating UUIDs at a variety of hosts <bcp1 4>MUST</bcp14>
be willing to rely on the random number source at all hosts.</t> be willing to rely on the random number source at all hosts.</t>
</section> </section>
<section anchor="name_based_uuid_generation"> <section anchor="name_based_uuid_generation">
<name>Name-Based UUID Generation</name> <name>Name-Based UUID Generation</name>
<t>Although some prefer to use the word "hash-based" to describe UUIDs f <t>Although some prefer to use the word "hash-based" to describe UUIDs
eaturing hashing algorithms (MD5 or SHA-1), this document retains the usage of t featuring hashing algorithms (MD5 or SHA-1), this document retains the
he adjective "name-based" in order to maintain consistency with historical docum usage of the term "name-based" in order to maintain consistency with
ents and existing implementations.</t> previously published documents and existing implementations.</t>
<t>The requirements for name-based UUIDs are as follows:</t> <t>The requirements for name-based UUIDs are as follows:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>UUIDs generated at different times from the same name (using
<t>UUIDs generated at different times from the same name (using the the same canonical format) in the same namespace <bcp14>MUST</bcp14>
same canonical format) in the be equal.</li>
same namespace <bcp14>MUST</bcp14> be equal.</t> <li>UUIDs generated from two different names (same or differing
</li> canonical format) in the same namespace should be different (with
<li> very high probability).</li>
<t>UUIDs generated from two different names (same or differing canon <li>UUIDs generated from the same name (same or differing
ical format) in the same namespace canonical format) in two different namespaces should be different
should be different (with very high probability).</t> (with very high probability).</li>
</li> <li>If two UUIDs that were generated from names (using the same
<li> canonical format) are equal, then they were generated from the same
<t>UUIDs generated from the same name (same or differing canonical f name in the same namespace (with very high probability).</li>
ormat) in two different namespaces
should be different (with very high probability).</t>
</li>
<li>
<t>If two UUIDs that were generated from names (using the same canon
ical format) are equal, then they
were generated from the same name in the same namespace (with very
high probability).</t>
</li>
</ul> </ul>
<dl newline="true">
<dt>A note on names:</dt> <t>A note on names:</t>
<dd> <t indent="3">The concept of name (and namespace) should be broadly
<t>The concept of name (and namespace) should be broadly construed a construed and not limited to textual names. A canonical sequence of
nd not limited to textual names. A canonical sequence of octets is one that conf octets is one that conforms to the specification for that name
orms to the specification for that name form's canonical representation. A name form's canonical representation. A name can have many usual forms,
can have many usual forms, only one of which can be canonical. An implementer of only one of which can be canonical. An implementer of new namespaces
new namespaces for UUIDs needs to reference the specification for the canonical for UUIDs needs to reference the specification for the canonical
form of names in that space, or define such a canonical for the namespace if it form of names in that space or define such a canonical form for the
does not exist. namespace if it does not exist. For example, at the time of
For example, at the time of this specification, <xref target="RFC8499"/> domain writing, Domain Name System (DNS) <xref target="RFC9499"/> has three
name system (DNS) has three conveyance formats: common (www.example.com), presen conveyance formats: common (www.example.com), presentation
tation (www.example.com.) and wire format (3www7example3com0). (www.example.com.), and wire format (3www7example3com0). Looking at
Looking at <xref target="X500"/> distinguished names (DNs), the previous version <xref target="X500"/> Distinguished Names (DNs), <xref
of this specification allowed either text based or binary distinguished encodin target="RFC4122" format="default"/> allowed either text-based or
g rules (DER) based names as inputs. binary DER-based names as inputs. For Uniform Resource Locators
For <xref target="RFC1738"/> uniform resource locators (URLs), one could provide (URLs) <xref target="RFC1738"/>, one could provide a Fully Qualified
a fully-qualified domain-name (FQDN) with or without the protocol identifier (w Domain Name (FQDN) with or without the protocol identifier
ww.example.com) or (https://www.example.com). www.example.com or https://www.example.com. When it comes to Object
When it comes to <xref target="X660"/> object identifiers (OIDs) one could choos Identifiers (OIDs) <xref target="X660"/>, one could choose dot
e dot-notation without the leading dot (2.999), choose to include the leading do notation without the leading dot (2.999), choose to include the
t (.2.999) or select one of the many formats from <xref target="X680"/> such as leading dot (.2.999), or select one of the many formats from <xref
OID Internationalized Resource Identifier (OID-IRI) (/Joint-ISO-ITU-T/Example). target="X680"/> such as OID Internationalized Resource Identifier
While most users may default to the common format for DNS, FQDN format for a URL (OID-IRI) (/Joint-ISO-ITU-T/Example). While most users may default
, text format for X.500 and dot-notation without a leading dot for OID; name-bas to the common format for DNS, FQDN format for a URL, text format for
ed UUID implementations generally <bcp14>SHOULD</bcp14> allow arbitrary input wh X.500, and dot notation without a leading dot for OID, name-based
ich will compute name-based UUIDs for any of the aforementioned example names an UUID implementations generally <bcp14>SHOULD</bcp14> allow arbitrary
d others not defined here. input that will compute name-based UUIDs for any of the
Each name format within a namespace will output different UUIDs. aforementioned example names and others not defined here. Each name
As such, the mechanisms or conventions used for allocating names and ensuring th format within a namespace will output different UUIDs. As such, the
eir uniqueness within their namespaces are beyond the scope of this specificatio mechanisms or conventions used for allocating names and ensuring
n.</t> their uniqueness within their namespaces are beyond the scope of
</dd> this specification.</t>
</dl>
</section> </section>
<section anchor="namespaces"> <section anchor="namespaces">
<name>Namespace ID Usage and Allocation</name> <name>Namespace ID Usage and Allocation</name>
<t>This section and table, <xref target="namespaceIDs"/>, details the na
mespace IDs for some potentially interesting namespaces such those for <t>This section details the namespace
<xref target="RFC8499"/> domain name system (DNS), <xref target="RFC1738"/> unif IDs for some potentially interesting namespaces such as those for DNS
orm resource locators (URLs), <xref target="X660"/> object identifiers (OIDs), a <xref target="RFC9499"/>, URLs <xref target="RFC1738"/>, OIDs <xref
nd <xref target="X500"/> distinguished names (DNs).</t> target="X660"/>, and DNs <xref target="X500"/>.</t>
<t>Further, this section also details allocation, IANA registration and
other details pertinent to Namespace IDs. <t>Further, this section also details allocation, IANA registration,
IANA may use the table <xref target="namespaceIDs"/> as-is replacing "This Docum and other details pertinent to Namespace IDs.</t>
ent" replaced as required.</t>
<table anchor="namespaceIDs"> <table anchor="namespaceIDs">
<name>Namespace IDs</name> <name>Namespace IDs</name>
<thead> <thead>
<tr> <tr>
<th align="left">Namespace</th> <th align="left">Namespace</th>
<th align="left">Namespace ID Value</th> <th align="left">Namespace ID Value</th>
<th align="left">Name Reference</th> <th align="left">Name Reference</th>
<th align="left">Namespace ID Reference</th> <th align="left">Namespace ID Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">DNS</td> <td align="left">DNS</td>
<td align="left">6ba7b810-9dad-11d1-80b4-00c04fd430c8</td> <td align="left">6ba7b810-9dad-11d1-80b4-00c04fd430c8</td>
<td align="left"> <td align="left">
<xref target="RFC8499"/></td> <xref target="RFC9499"/></td>
<td align="left"> <td align="left">
<xref target="RFC4122"/>, This document</td> <xref target="RFC4122"/>, RFC 9562</td>
</tr> </tr>
<tr> <tr>
<td align="left">URL</td> <td align="left">URL</td>
<td align="left">6ba7b811-9dad-11d1-80b4-00c04fd430c8</td> <td align="left">6ba7b811-9dad-11d1-80b4-00c04fd430c8</td>
<td align="left"> <td align="left">
<xref target="RFC1738"/></td> <xref target="RFC1738"/></td>
<td align="left"> <td align="left">
<xref target="RFC4122"/>, This document</td> <xref target="RFC4122"/>, RFC 9562</td>
</tr> </tr>
<tr> <tr>
<td align="left">OID</td> <td align="left">OID</td>
<td align="left">6ba7b812-9dad-11d1-80b4-00c04fd430c8</td> <td align="left">6ba7b812-9dad-11d1-80b4-00c04fd430c8</td>
<td align="left"> <td align="left">
<xref target="X660"/></td> <xref target="X660"/></td>
<td align="left"> <td align="left">
<xref target="RFC4122"/>, This document</td> <xref target="RFC4122"/>, RFC 9562</td>
</tr> </tr>
<tr> <tr>
<td align="left">X500</td> <td align="left">X500</td>
<td align="left">6ba7b814-9dad-11d1-80b4-00c04fd430c8</td> <td align="left">6ba7b814-9dad-11d1-80b4-00c04fd430c8</td>
<td align="left"> <td align="left">
<xref target="X500"/></td> <xref target="X500"/></td>
<td align="left"> <td align="left">
<xref target="RFC4122"/>, This document</td> <xref target="RFC4122"/>, RFC 9562</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>Items may be added to this table using "Specification Required" polic
y as per <xref target="RFC8126"/>.</t> <t>Items may be added to this registry using the Specification Required
<t>For designated experts, generally speaking, Namespace IDs are allocat policy as per <xref target="RFC8126"/>.</t>
ed as follows:</t> <t>For designated experts, generally speaking, Namespace IDs are
<ul spacing="compact"> allocated as follows:</t>
<li>
<t>The first namespace ID value, for DNS, was calculated from a time <ul spacing="normal">
-based UUIDv1 and "6ba7b810-9dad-11d1-80b4-00c04fd430c8" used as a starting poin <li>The first Namespace ID value, for DNS, was calculated from a
t.</t> time-based UUIDv1 and "6ba7b810-9dad-11d1-80b4-00c04fd430c8", used as
</li> a starting point.</li>
<li> <li>Subsequent Namespace ID values increment the
<t>Subsequent namespace ID values increment the least-significant, r least significant, rightmost bit of time_low "6ba7b810" while
ight-most bit of time_low "6ba7b810" while freezing the rest of the UUID to "9da freezing the rest of the UUID to "9dad-11d1-80b4-00c04fd430c8".</li>
d-11d1-80b4-00c04fd430c8".</t> <li>New Namespace ID values <bcp14>MUST</bcp14> use this same
</li> logic and <bcp14>MUST NOT</bcp14> use a previously used Namespace ID
<li> value.</li>
<t>New namespace ID values <bcp14>MUST</bcp14> use this same logic a <li>Thus, "6ba7b815" is the next available time_low for a new
nd <bcp14>MUST NOT</bcp14> use a previously used Namespace ID value.</t> Namespace ID value with the full ID being
</li> "6ba7b815-9dad-11d1-80b4-00c04fd430c8".</li>
<li>
<t>Thus, "6ba7b815" is the next available time_low for a new Namespa <li>The upper bound for time_low in this special use, Namespace ID
ce ID value with the full ID being "6ba7b815-9dad-11d1-80b4-00c04fd430c8".</t> values, is "ffffffff" or "ffffffff-9dad-11d1-80b4-00c04fd430c8",
</li> which should be sufficient space for future Namespace ID values.</li>
<li>
<t>The upper bound for time_low in this special use, namespace ID va
lues, is "ffffffff" or "ffffffff-9dad-11d1-80b4-00c04fd430c8" which should be su
fficient space for future namespace ID values.</t>
</li>
</ul> </ul>
<t>Note that the namespace ID value "6ba7b813-9dad-11d1-80b4-00c04fd430c
8" and its usage is not defined by this document or by <xref target="RFC4122"/>, <t>Note that the Namespace ID value
as such it <bcp14>SHOULD NOT</bcp14> be used as a Namespace ID value.</t> "6ba7b813-9dad-11d1-80b4-00c04fd430c8" and its usage are not defined by
<t>New Namespace ID values <bcp14>MUST</bcp14> be documented as per <xre this document or by <xref target="RFC4122"/>; thus, it <bcp14>SHOULD
f target="IANA"/> if they are to be globally available and fully interoperable. NOT</bcp14> be used as a Namespace ID value.</t>
Implementations <bcp14>MAY</bcp14> continue to use vendor-specific, application- <t>New Namespace ID values <bcp14>MUST</bcp14> be documented as per
specific, and deployment-specific Namespace ID values but know that interoperabi <xref target="IANA"/> if they are to be globally available and fully
lity is not guaranteed. interoperable. Implementations <bcp14>MAY</bcp14> continue to use
These custom Namespace ID values <bcp14>MUST NOT</bcp14> use the logic above and vendor-specific, application-specific, and deployment-specific
instead are <bcp14>RECOMMENDED</bcp14> to generate a UUIDv4 or UUIDv7 Namespace Namespace ID values; but know that interoperability is not guaranteed.
ID value. These custom Namespace ID values <bcp14>MUST NOT</bcp14> use the logic
If collision probability (<xref target="collision_resistance"/>) and uniqueness above; instead, generating a
(<xref target="global_local_uniqueness"/>) of the final name-based UUID are not UUIDv4 or UUIDv7 Namespace ID value is <bcp14>RECOMMENDED</bcp14>. If c
a problem; an implementation <bcp14>MAY</bcp14> also leverage UUIDv8 instead to ollision probability (<xref
create a custom, application-specific Namespace ID value.</t> target="collision_resistance"/>) and uniqueness (<xref
<t>Implementations <bcp14>SHOULD</bcp14> provide the ability to input a target="global_local_uniqueness"/>) of the final name-based UUID are
custom namespace to account for newly registered IANA Namespace ID values outsid not a problem, an implementation <bcp14>MAY</bcp14> also leverage
e of those listed in this section or custom, application specific Namespace ID v UUIDv8 instead to create a custom, application-specific Namespace ID
alues.</t> value.</t>
<t>Implementations <bcp14>SHOULD</bcp14> provide the ability to input
a custom namespace to account for newly registered IANA Namespace ID
values outside of those listed in this section or custom,
application-specific Namespace ID values.</t>
</section> </section>
<section anchor="collision_resistance"> <section anchor="collision_resistance">
<name>Collision Resistance</name> <name>Collision Resistance</name>
<t>Implementations should weigh the consequences of UUID collisions with <t>Implementations should weigh the consequences of UUID collisions
in their within their application and when deciding between UUID versions that
application and when deciding between UUID versions that use entropy (randomness use entropy (randomness) versus the other components such as those in
) Sections <xref target="timestamp_considerations" format="counter"/>
versus the other components such as those in <xref target="timestamp_considerati and <xref target="monotonicity_counters" format="counter"/>. This is
ons"/> and <xref target="monotonicity_counters"/>. especially true for distributed node collision resistance as defined
This is especially true for distributed node collision resistance as defined by <xref target="distributed_shared_knowledge"/>.</t>
by <xref target="distributed_shared_knowledge"/>.</t> <t>There are two example scenarios below that help illustrate the
<t>There are two example scenarios below which help illustrate the varyi varying seriousness of a collision within an application.</t>
ng seriousness
of a collision within an application.</t> <dl spacing="normal" newline="true">
<dl newline="true">
<dt>Low Impact:</dt> <dt>Low Impact:</dt>
<dd> <dd>A UUID collision generated a duplicate log entry, which results
<t>A UUID collision generated a duplicate log entry which results in in incorrect statistics derived from the data. Implementations that
incorrect are not negatively affected by collisions may continue with the
statistics derived from the data. Implementations that are not negatively entropy and uniqueness provided by UUIDs defined in this document.
affected by collisions may continue with the entropy and uniqueness provided
by the traditional UUID format.</t>
</dd> </dd>
<dt>High Impact:</dt> <dt>High Impact:</dt>
<dd> <dd>A duplicate key causes an airplane to receive the wrong course,
<t>A duplicate key causes an airplane to receive the wrong course wh which puts people's lives at risk. In this scenario, there is no
ich puts margin for error. Collisions must be avoided: failure is
people's lives at risk. In this scenario there is no margin for error. Collision unacceptable. Applications dealing with this type of scenario must
s employ as much collision resistance as possible within the given
must be avoided and failure is unacceptable. Applications dealing with this application context.</dd>
type of scenario must employ as much collision resistance as possible within
the given application context.</t>
</dd>
</dl> </dl>
</section> </section>
<section anchor="global_local_uniqueness"> <section anchor="global_local_uniqueness">
<name>Global and Local Uniqueness</name> <name>Global and Local Uniqueness</name>
<t>UUIDs created by this specification <bcp14>MAY</bcp14> be used to pro <t>UUIDs created by this specification <bcp14>MAY</bcp14> be used to
vide local uniqueness provide local uniqueness guarantees. For example, ensuring UUIDs
guarantees. created within a local application context are unique within a
For example, ensuring UUIDs created within a local application context are database <bcp14>MAY</bcp14> be sufficient for some implementations
unique within a database <bcp14>MAY</bcp14> be sufficient for some implementatio where global uniqueness outside of the application context, in other
ns where applications, or around the world is not required.</t>
global uniqueness outside of the application context, in other applications, <t>Although true global uniqueness is impossible to guarantee without
or around the world is not required.</t> a shared knowledge scheme, a shared knowledge scheme is not required
<t>Although true global uniqueness is impossible to guarantee without a by a UUID to provide uniqueness for practical implementation purposes.
shared Implementations <bcp14>MAY</bcp14> use a shared knowledge
knowledge scheme, a shared knowledge scheme is not required by UUID to provide scheme, introduced in <xref target="distributed_shared_knowledge"/>,
uniqueness for practical implementation purposes. as they see fit to extend the uniqueness guaranteed by this
Implementations <bcp14>MAY</bcp14> implement a shared knowledge scheme introduce specification.</t>
d in <xref target="distributed_shared_knowledge"/> as they see fit to extend the
uniqueness guaranteed by this specification.</t>
</section> </section>
<section anchor="unguessability"> <section anchor="unguessability">
<name>Unguessability</name> <name>Unguessability</name>
<t>Implementations <bcp14>SHOULD</bcp14> utilize a cryptographically sec <t>Implementations <bcp14>SHOULD</bcp14> utilize a cryptographically
ure pseudo-random number secure pseudorandom number generator (CSPRNG) to provide values that
generator (CSPRNG) to provide values that are both difficult to predict ("ungues are both difficult to predict ("unguessable") and have a low
sable") likelihood of collision ("unique"). The exception is when a suitable
and have a low likelihood of collision ("unique"). The exception is when a CSPRNG is unavailable in the execution environment. Take care to
suitable CSPRNG is unavailable in the execution environment. ensure the CSPRNG state is properly reseeded upon state changes, such
Take care to ensure the CSPRNG state is properly reseeded upon as process forks, to ensure proper CSPRNG operation. CSPRNG ensures
state changes, such as process forks, to ensure proper CSPRNG operation. the best of Sections <xref target="collision_resistance"
CSPRNG ensures the best of <xref target="collision_resistance"/> and <xref targe format="counter"/> and <xref target="Security" format="counter"/> are
t="Security"/> are present in modern UUIDs.</t> present in modern UUIDs.</t>
<t>Further advice on generating cryptographic-quality random numbers can <t>Further advice on generating cryptographic-quality random numbers
be found in <xref target="RFC4086"/>, <xref target="RFC8937"/> and in <xref tar can be found in <xref target="RFC4086"/>, <xref target="RFC8937"/>,
get="RANDOM"/>.</t> and <xref target="RANDOM"/>.</t>
</section> </section>
<section anchor="unidentifiable"> <section anchor="unidentifiable">
<name>UUIDs That Do Not Identify the Host</name> <name>UUIDs That Do Not Identify the Host</name>
<t>This section describes how to generate a UUIDv1 or UUIDv6 value if an <t>This section describes how to generate a UUIDv1 or UUIDv6 value if
IEEE an IEEE 802 address is not available or its use is not desired.</t>
802 address is not available, or its use is not desired.</t> <t>Implementations <bcp14>MAY</bcp14> leverage MAC address
<t>Implementations <bcp14>MAY</bcp14> leverage MAC address randomization randomization techniques <xref target="IEEE802.11bh"
techniques (IEEE 802.11bh) as an alternative to the pseudo-random logic provide format="default"/> as an alternative to the pseudorandom logic
d in this section.</t> provided in this section.</t>
<t>Alternatively, implementations <bcp14>MAY</bcp14> elect to obtain a 4 <t>Alternatively, implementations <bcp14>MAY</bcp14> elect to obtain a
8 bit cryptographic-quality random 48-bit cryptographic-quality random number as per <xref
number as per <xref target="unguessability"/> to use it as the node ID. target="unguessability"/> to use as the Node ID. After generating the
After generating the 48 bit fully randomized node value, implementations <bcp14> 48-bit fully randomized node value, implementations
MUST</bcp14> set the least significant bit of the first octet of the node ID set <bcp14>MUST</bcp14> set the least significant bit of the first octet
to 1. of the Node ID to 1. This bit is the unicast or multicast bit, which
This bit is the unicast/multicast bit, which will never be set in IEEE 802 will never be set in IEEE 802 addresses obtained from network cards.
addresses obtained from network cards. Hence, there can never be a Hence, there can never be a conflict between UUIDs generated by
conflict between UUIDs generated by machines with and without network machines with and without network cards. An example of generating a
cards. randomized 48-bit node value and the subsequent bit modification is
An example of generating a randomized 48 bit node value and the subsequent bit m detailed in <xref target="test_vectors"/>. For more information about
odification is detailed in the <xref target="test_vectors"/> appendix. IEEE 802 address and the unicast or multicast or local/global bits,
For more information about IEEE 802 address and the unicast/multicast or local/g please review <xref target="RFC9542"/>.</t>
lobal bits please review <xref target="RFC7042"/>.</t>
<t>For compatibility with earlier specifications, note that this <t>For compatibility with earlier specifications, note that this
document uses the unicast/multicast bit, instead of the arguably more document uses the unicast or multicast bit instead of the arguably more
correct local/global bit because MAC addresses with the local/global bit set or correct local/global bit because MAC addresses with the local/global
not are both possible in a network. bit set or not set are both possible in a network. This is not the case
This is not the case with the unicast/multicast bit. with the unicast or multicast bit. One node cannot have a MAC address
One node cannot have a MAC address that multicasts to multiple nodes.</t> that multicasts to multiple nodes.</t>
<t>In addition, items such as the computer's name and the name of the <t>In addition, items such as the computer's name and the name of the
operating system, while not strictly speaking random, will help operating system, while not strictly speaking random, will help
differentiate the results from those obtained by other systems.</t> differentiate the results from those obtained by other systems.</t>
<t>The exact algorithm to generate a node ID using these data is system <t>The exact algorithm to generate a Node ID using these data is
specific, because both the data available and the functions to obtain system specific because both the data available and the functions to
them are often very system specific. A generic approach, however, is obtain them are often very system specific. However, a generic approach
to accumulate as many sources as possible into a buffer, use a is to accumulate as many sources as possible into a buffer, use a
message digest (such as SHA-256 or SHA-512 defined by <xref target="FIPS180-4"/> message digest (such as SHA-256 or SHA-512 defined by <xref
), take an arbitrary 6 target="FIPS180-4"/>), take an arbitrary 6 bytes from the hash value,
bytes from the hash value, and set the multicast bit as described and set the multicast bit as described above.</t>
above.</t>
</section> </section>
<section anchor="sorting"> <section anchor="sorting">
<name>Sorting</name> <name>Sorting</name>
<t>UUIDv6 and UUIDv7 are designed so that implementations that require s <t>UUIDv6 and UUIDv7 are designed so that implementations that require
orting sorting (e.g., database indexes) sort as opaque raw bytes without the
(e.g., database indexes) sort as opaque raw bytes, without need for need for parsing or introspection.</t>
parsing or introspection.</t> <t>Time-ordered monotonic UUIDs benefit from greater database-index
<t>Time ordered monotonic UUIDs benefit from greater database index loca locality because the new values are near each other in the index. As
lity a result, objects are more easily clustered together for better
because the new values are near each other in the index. performance. The real-world differences in this approach of index
As a result objects are more easily clustered together for better performance. locality versus random data inserts can be one order of magnitude or
The real-world differences in this approach of index locality vs random data more.</t>
inserts can be one order of magnitude or more.</t> <t>UUID formats created by this specification are intended to be
<t>UUID formats created by this specification are intended to be lexicog lexicographically sortable while in the textual representation.</t>
raphically sortable <t>UUIDs created by this specification are crafted with big-endian
while in the textual representation.</t> byte order (network byte order) in mind. If little-endian style is
<t>UUIDs created by this specification are crafted with big-endian byte required, UUIDv8 is available for custom UUID formats.</t>
order
(network byte order) in mind. If little-endian style is required, UUIDv8
is available for custom UUID formats.</t>
</section> </section>
<section anchor="opacity"> <section anchor="opacity">
<name>Opacity</name> <name>Opacity</name>
<t>As general guidance, it is recommend to avoid parsing UUID values unn <t>As general guidance, avoiding parsing UUID values
ecessarily, unnecessarily is recommended; instead, treat UUIDs as opaquely as possib
and instead treating UUIDs as opaquely as possible. Although application-specif le.
ic Although application-specific concerns could, of course, require some
concerns could of course require some degree of introspection degree of introspection (e.g., to examine Sections <xref
(e.g., to examine the <xref target="variant_field"/>, <xref target="version_fiel target="variant_field" format="counter"/> or <xref
d"/> or perhaps the timestamp of a UUID), target="version_field" format="counter"/> or perhaps the timestamp of
the advice here is to avoid this or other parsing unless absolutely necessary. a UUID), the advice here is to avoid this or other parsing unless
Applications typically tend to be simpler, more interoperable, and perform bette absolutely necessary. Applications typically tend to be simpler, be mor
r, e
when this advice is followed.</t> interoperable, and perform better when this advice is followed.</t>
</section> </section>
<section anchor="database_considerations"> <section anchor="database_considerations">
<name>DBMS and Database Considerations</name> <name>DBMS and Database Considerations</name>
<t>For many applications, such as databases, storing UUIDs as text is un <t>For many applications, such as databases, storing UUIDs as text is
necessarily unnecessarily verbose, requiring 288 bits to represent 128-bit UUID
verbose, requiring 288 bits to represent 128 bit UUID values. values. Thus, where feasible, UUIDs <bcp14>SHOULD</bcp14> be stored
Thus, where feasible, UUIDs <bcp14>SHOULD</bcp14> be stored within database appl within database applications as the underlying 128-bit binary
ications value.</t>
as the underlying 128 bit binary value.</t> <t>For other systems, UUIDs <bcp14>MAY</bcp14> be stored in binary
<t>For other systems, UUIDs <bcp14>MAY</bcp14> be stored in binary form form or as text, as appropriate. The trade-offs to both approaches
or as text, as appropriate. are as follows:</t>
The trade-offs to both approaches are:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>Storing in binary form requires less space and may result in faste
<t>Storing as binary requires less space and may result in faster da r
ta access.</t> data access.</li>
</li> <li>Storing as text requires more space but may require less
<li> translation if the resulting text form is to be used after
<t>Storing as text requires more space but may require less translat retrieval, which may make it simpler to implement. </li>
ion if the
resulting text form is to be used after retrieval, which thus may make it simple
r
to implement.</t>
</li>
</ul> </ul>
<t>DBMS vendors are encouraged to provide functionality to generate and
store <t>DBMS vendors are encouraged to provide functionality to generate
UUID formats defined by this specification for use as identifiers or left and store UUID formats defined by this specification for use as
parts of identifiers such as, but not limited to, primary keys, surrogate identifiers or left parts of identifiers such as, but not limited to,
keys for temporal databases, foreign keys included in polymorphic relationships, primary keys, surrogate keys for temporal databases, foreign keys
and keys for key-value pairs in JSON columns and key-value databases. included in polymorphic relationships, and keys for key-value pairs in
Applications using a monolithic database may find using database-generated JSON columns and key-value databases. Applications using a monolithic
UUIDs (as opposed to client-generate UUIDs) provides the best UUID monotonicity. database may find using database-generated UUIDs (as opposed to
In addition to UUIDs, additional identifiers <bcp14>MAY</bcp14> be used to ensur client-generated UUIDs) provides the best UUID monotonicity. In
e integrity addition to UUIDs, additional identifiers <bcp14>MAY</bcp14> be used
and feedback.</t> to ensure integrity and feedback.</t>
<t>Designers of database schema are cautioned against using name-based U <t>Designers of database schema are cautioned against using name-based
UIDs (<xref target="uuidv3"/>/<xref target="uuidv5"/>) as primary keys in tables UUIDs (see Sections <xref target="uuidv3" format="counter"/> and <xref
. target="uuidv5" format="counter"/>) as primary keys in tables. A
A common issue observed in database schema design is the assumption that a parti common issue observed in database schema design is the assumption that
cular value will never change, which then later turns out to be an incorrect ass a particular value will never change, which later turns out to be
umption. an incorrect assumption. Postal codes, license or other
Postal codes, license or other identification numbers, and numerous other such i identification numbers, and numerous other such identifiers seem
dentifiers seem unique and unchanging at a given point time; only to later turn unique and unchanging at a given point time -- only later to have edge
out to have edge cases where they need to change. cases where they need to change. The subsequent change of the
The subsequent change of the identifier, used as a "name" input for name-based U identifier, used as a "name" input for name-based UUIDs, can
UIDs, can invalidate a given database structure. invalidate a given database structure. In such scenarios, it is
In such scenarios it is observed that using any non-name-based UUID version woul observed that using any non-name-based UUID version would have
d have resulted in the field in question being placed somewhere that would have resulted in the field in question being placed somewhere that would
been easier to adapt to such changes (primary key excluded from this statement). have been easier to adapt to such changes (primary key excluded from
The general advice is to avoid name-based UUID natural keys and instead utilize this statement). The general advice is to avoid name-based UUID
time-based UUID surrogate keys based on the aforementioned problems detailed in natural keys and, instead, to utilize time-based UUID surrogate keys
this section.</t> based on the aforementioned problems detailed in this section.</t>
</section> </section>
</section> </section>
<section anchor="IANA"> <section anchor="IANA">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>All references to <xref target="RFC4122"/> in the IANA registries shoul <t>All references to <xref target="RFC4122"/> in IANA registries
d be replaced with references to this document. (outside of those created by this document) have been replaced with
References to <xref target="RFC4122"/> document's Section 4.1.2 should be update references to this document, including the IANA URN namespace
d to refer to this document's <xref target="format"/>.</t> registration <xref target="URNNamespaces"/> for UUID. References to
<t>The IANA URN namespace registration <xref target="URNNamespaces"/> for <xref target="RFC4122" sectionFormat="of" section="4.1.2"/> have been
UUID filed in <xref target="RFC4122"/> should be updated to reference this docum updated to refer to <xref target="format"/> of this document.</t>
ent.</t> <t>Finally, IANA should track UUID Subtypes and Special Case "Namespace
<t>Finally IANA should track UUID Subtypes and Special Case "Namespace IDs IDs Values" as specified in Sections <xref target="iana2"
Values" as specified in <xref target="iana2"/> and <xref target="iana3"/>.</t> format="counter"/> and <xref target="iana3" format="counter"/> at the
<t>When evaluating requests, the designated expert(s) should consider comm following location: <eref brackets="angle"
unity feedback, how well-defined is the reference specification, and this specif target="https://www.iana.org/assignments/uuid"/>.</t>
ication's requirements. <t>When evaluating requests, the designated expert should consider
Vendor-specific, application-specific, and deployment-specific values are unable community feedback, how well-defined the reference specification is, and
to be registered. this specification's requirements. Vendor-specific,
Specification documents should be published in a stable, freely available manner application-specific, and deployment-specific values are unable to be
(ideally located with a URL) but need not be standards. registered. Specification documents should be published in a stable,
The designated experts will either approve or deny the registration request, and freely available manner (ideally, located with a URL) but need not be
communicate their decision to IANA. Denials should include an explanation and, standards. The designated expert will either approve or deny the
if applicable, suggestions as to how to make the request successful.</t> registration request and communicate this decision to IANA. Denials
should include an explanation and, if applicable, suggestions as to how
to make the request successful.</t>
<section anchor="iana2"> <section anchor="iana2">
<name>IANA UUID Subtype Registry and Registration</name> <name>IANA UUID Subtype Registry and Registration</name>
<t>This specification defines the "UUID Subtype" registry for common, wi <t>This specification defines the "UUID Subtypes" registry for common
dely used UUID standards.</t> widely used UUID standards.</t>
<t><xref target="ianaSubtypes"/> should be used as-is for this registry
with "This document" replaced as required.</t>
<table anchor="ianaSubtypes"> <table anchor="ianaSubtypes">
<name>IANA UUID Subtypes</name> <name>IANA UUID Subtypes</name>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="left">ID</th> <th align="left">ID</th>
<th align="left">Subtype</th> <th align="left">Subtype</th>
<th align="left">Variant</th> <th align="left">Variant</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">Gregorian Time-based</td> <td align="left">Gregorian Time-based</td>
<td align="left">1</td> <td align="left">1</td>
<td align="left">version</td> <td align="left">version</td>
<td align="left">OSF DCE / IETF</td> <td align="left">OSF DCE / IETF</td>
<td align="left"> <td align="left">
<xref target="RFC4122"/>, This document</td> <xref target="RFC4122"/>, RFC 9562</td>
</tr> </tr>
<tr> <tr>
<td align="left">DCE Security</td> <td align="left">DCE Security</td>
<td align="left">2</td> <td align="left">2</td>
<td align="left">version</td> <td align="left">version</td>
<td align="left">OSF DCE / IETF</td> <td align="left">OSF DCE / IETF</td>
<td align="left"> <td align="left">
<xref target="C309"/>, <xref target="C311"/></td> <xref target="C309"/>, <xref target="C311"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">MD5 Name-based</td> <td align="left">MD5 Name-based</td>
<td align="left">3</td> <td align="left">3</td>
<td align="left">version</td> <td align="left">version</td>
<td align="left">OSF DCE / IETF</td> <td align="left">OSF DCE / IETF</td>
<td align="left"> <td align="left">
<xref target="RFC4122"/>, This document</td> <xref target="RFC4122"/>, RFC 9562</td>
</tr> </tr>
<tr> <tr>
<td align="left">Random</td> <td align="left">Random</td>
<td align="left">4</td> <td align="left">4</td>
<td align="left">version</td> <td align="left">version</td>
<td align="left">OSF DCE / IETF</td> <td align="left">OSF DCE / IETF</td>
<td align="left"> <td align="left">
<xref target="RFC4122"/>, This document</td> <xref target="RFC4122"/>, RFC 9562</td>
</tr> </tr>
<tr> <tr>
<td align="left">SHA-1 Name-based</td> <td align="left">SHA-1 Name-based</td>
<td align="left">5</td> <td align="left">5</td>
<td align="left">version</td> <td align="left">version</td>
<td align="left">OSF DCE / IETF</td> <td align="left">OSF DCE / IETF</td>
<td align="left"> <td align="left">
<xref target="RFC4122"/>, This document</td> <xref target="RFC4122"/>, RFC 9562</td>
</tr> </tr>
<tr> <tr>
<td align="left">Reordered Gregorian Time-based</td> <td align="left">Reordered Gregorian Time-based</td>
<td align="left">6</td> <td align="left">6</td>
<td align="left">version</td> <td align="left">version</td>
<td align="left">OSF DCE / IETF</td> <td align="left">OSF DCE / IETF</td>
<td align="left">This document</td> <td align="left">RFC 9562</td>
</tr> </tr>
<tr> <tr>
<td align="left">Unix Time-based</td> <td align="left">Unix Time-based</td>
<td align="left">7</td> <td align="left">7</td>
<td align="left">version</td> <td align="left">version</td>
<td align="left">OSF DCE / IETF</td> <td align="left">OSF DCE / IETF</td>
<td align="left">This document</td> <td align="left">RFC 9562</td>
</tr> </tr>
<tr> <tr>
<td align="left">Custom</td> <td align="left">Custom</td>
<td align="left">8</td> <td align="left">8</td>
<td align="left">version</td> <td align="left">version</td>
<td align="left">OSF DCE / IETF</td> <td align="left">OSF DCE / IETF</td>
<td align="left">This document</td> <td align="left">RFC 9562</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>This table may be extended by the "Standards Action" policy, per <xre
f target="RFC8126"/>.</t> <t>This table may be extended by Standards Action as per
<xref target="RFC8126"/>.</t>
<t>For designated experts:</t> <t>For designated experts:</t>
<ul spacing="compact">
<li> <ul spacing="normal">
<t>The minimum and maximum "ID" value for the subtype "version" with <li>The minimum and maximum "ID" value for the subtype "version"
in the "OSF DCE / IETF" variant is 0 through 15. The versions, within <xref targ within the "OSF DCE / IETF" variant is 0 through 15. The versions
et="table1"/>, described as "Reserved for future definition" or "unused" are omi within <xref target="table1"/> described as "Reserved for future
tted from this IANA registry until properly defined.</t> definition" or "unused" are omitted from this IANA registry until
</li> properly defined. </li>
<li> <li>The "Subtype" column is free-form text. However, at the time of
<t>The "Subtype" column is free-form text however at the time of thi publication, "version" and "family" are the only known UUID
s publication only "version" and "family" are known UUID subtypes. The "family" subtypes. The "family" subtype is part of the "Apollo NCS" variant
subtype is part of the "Apollo NCS" variant space (Both are outside the scope of space (both are outside the scope of this specification). The
this specification). The Microsoft variant may have subtyping mechanisms define Microsoft variant may have subtyping mechanisms defined; however,
d however they are unknown and outside of the scope of this specification. Simil they are unknown and outside of the scope of this
arly, the final "Reserved for future definition" variant may introduce new subty specification. Similarly, the final "Reserved for future definition"
ping logic at a future date. Subtype IDs are permitted to overlap, that is, an I variant may introduce new subtyping logic at a future date. Subtype
D of "1" may exist in multiple variant spaces.</t> IDs are permitted to overlap. That is, an ID of "1" may exist in
</li> multiple variant spaces.</li>
<li> <li>The "Variant" column is free-form text. However, it is likely that
<t>The "Variant" column is free-form text however it is likely one o one
f four values will be included. The first three are "OSF DCE / IETF", "Apollo NC of four values will be included: the first three are "OSF DCE /
S", "Microsoft". The final variant value belongs to the "Reserved for future def IETF", "Apollo NCS", and "Microsoft", and the final variant value belo
inition" variant and may introduce a new name at a future date.</t> ngs to
</li> the "Reserved for future definition" variant and may introduce a new
name at a future date.</li>
</ul> </ul>
</section> </section>
<section anchor="iana3"> <section anchor="iana3">
<name>IANA UUID Namespace ID Registry and Registration</name> <name>IANA UUID Namespace ID Registry and Registration</name>
<t>This specification defines the "UUID Namespace ID" registry for commo n, widely used Namespace ID values.</t> <t>This specification defines the "UUID Namespace IDs" registry for comm on, widely used Namespace ID values.</t>
<t>The full details of this registration, including information for desi gnated experts, can be found in <xref target="namespaces"/>.</t> <t>The full details of this registration, including information for desi gnated experts, can be found in <xref target="namespaces"/>.</t>
</section> </section>
</section> </section>
<section anchor="Security"> <section anchor="Security">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>Implementations <bcp14>SHOULD NOT</bcp14> assume that UUIDs are hard to <t>Implementations <bcp14>SHOULD NOT</bcp14> assume that UUIDs are hard
guess. to guess. For example, they <bcp14>MUST NOT</bcp14> be used as security
For example, they <bcp14>MUST NOT</bcp14> be used capabilities (identifiers whose mere possession grants access).
as security capabilities (identifiers whose mere possession grants Discovery of predictability in a random number source will result in a
access). Discovery of predictability in a random number source will vulnerability.</t>
result in a vulnerability.</t> <t>Implementations <bcp14>MUST NOT</bcp14> assume that it is easy to
<t>Implementations <bcp14>MUST NOT</bcp14> assume that it is easy to deter determine if a UUID has been slightly modified in order to redirect a
mine if a UUID has been reference to another object. Humans do not have the ability to easily
slightly modified in order to redirect a reference to another check the integrity of a UUID by simply glancing at it.</t>
object. Humans do not have the ability to easily check the integrity <t>MAC addresses pose inherent security risks around privacy and
of a UUID by simply glancing at it.</t> <bcp14>SHOULD NOT</bcp14> be used within a UUID. Instead CSPRNG data
<t>MAC addresses pose inherent security risks around privacy and <bcp14>SH <bcp14>SHOULD</bcp14> be selected from a source with sufficient entropy
OULD NOT</bcp14> be used within to ensure guaranteed uniqueness among UUID generation. See Sections
a UUID. <xref target="unguessability" format="counter"/> and <xref
Instead CSPRNG data <bcp14>SHOULD</bcp14> be selected from a source with suffici target="unidentifiable" format="counter"/> for more information.</t>
ent entropy <t>Timestamps embedded in the UUID do pose a very small attack
to ensure guaranteed surface. The timestamp in conjunction with an embedded counter does
uniqueness among UUID generation. See <xref target="unguessability"/> and <xref signal the order of creation for a given UUID and its corresponding data
target="unidentifiable"/> for more information.</t> but does not define anything about the data itself or the application as
<t>Timestamps embedded in the UUID do pose a very small attack surface. Th a whole. If UUIDs are required for use with any security operation
e within an application context in any shape or form, then UUIDv4 (<xref
timestamp in conjunction with target="uuidv4"/>) <bcp14>SHOULD</bcp14> be utilized.</t>
an embedded counter does signal the order of creation for a given UUID and <t>See <xref target="RFC6151"/> for MD5 security considerations and
its corresponding data but <xref target="RFC6194"/> for SHA-1 security considerations.</t>
does not define anything about the data itself or the application as a whole.
If UUIDs are required for
use with any security operation within an application context in any shape
or form then UUIDv4, <xref target="uuidv4"/> <bcp14>SHOULD</bcp14> be utilized.<
/t>
<t>See <xref target="RFC6151"/> for MD5 Security Considerations and <xref
target="RFC6194"/> for SHA-1 security considerations.</t>
</section>
<section anchor="Acknowledgements">
<name>Acknowledgements</name>
<t>The authors gratefully acknowledge the contributions of Rich Salz,
Michael Mealling,
Ben Campbell,
Ben Ramsey,
Fabio Lima,
Gonzalo Salgueiro,
Martin Thomson,
Murray S. Kucherawy,
Rick van Rein,
Rob Wilton,
Sean Leonard,
Theodore Y. Ts'o,
Robert Kieffer,
Sergey Prokhorenko,
LiosK.</t>
<t>As well as all of those in the IETF community and on GitHub to who cont
ributed
to the discussions which resulted in this document.</t>
<t>This document draws heavily on the OSF DCE specification for UUIDs.
Ted Ts'o provided helpful comments, especially on the byte ordering
section which we mostly plagiarized from a proposed wording he
supplied (all errors in that section are our responsibility,
however).</t>
<t>We are also grateful to the careful reading and bit-twiddling of Ralf
S. Engelschall, John Larmouth, and Paul Thorpe. Professor Larmouth
was also invaluable in achieving coordination with ISO/IEC.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references> <references>
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="C309" target="https://pubs.opengroup.org/onlinepubs/9 696999099/toc.pdf"> <reference anchor="C309" target="https://pubs.opengroup.org/onlinepubs/9 696999099/toc.pdf">
<front> <front>
<title>DCE: Remote Procedure Call</title> <title>X/Open DCE: Remote Procedure Call</title>
<author> <author>
<organization/> <organization>X/Open Company Limited</organization>
</author> </author>
<date year="1994" month="August"/> <date year="1994" month="August"/>
</front> </front>
<seriesInfo name="ISBN" value="1-85912-041-5"/> <seriesInfo name="ISBN" value="1-85912-041-5"/>
<refcontent>Open Group CAE Specification C309</refcontent> <seriesInfo name="Open CAE Specification" value="C309"/>
</reference> </reference>
<reference anchor="X667"> <reference anchor="X667">
<front> <front>
<title>Information Technology, "Procedures for the operation of OSI <title>Information technology - Open Systems Interconnection -
Registration Authorities: Generation and registration of Universally Unique Iden Procedures for the operation of OSI Registration Authorities:
tifiers (UUIDs) and their use as ASN.1 Object Identifier components"</title> Generation and registration of Universally Unique Identifiers
(UUIDs) and their use as ASN.1 object identifier
components</title>
<author> <author>
<organization/> <organization>ITU-T</organization>
</author> </author>
<date year="2004"/> <date month="September" year="2004"/>
</front> </front>
<seriesInfo name="ISO/IEC" value="9834-8:2004"/> <seriesInfo name="ISO/IEC" value="9834-8:2004"/>
<seriesInfo name="ITU-T Rec." value="X.667"/> <seriesInfo name="ITU-T Recommendation" value="X.667"/>
</reference>
<reference anchor="RFC8141">
<front>
<title>Uniform Resource Names (URNs)</title>
<author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre
"/>
<author fullname="J. Klensin" initials="J." surname="Klensin"/>
<date month="April" year="2017"/>
<abstract>
<t>A Uniform Resource Name (URN) is a Uniform Resource Identifier
(URI) that is assigned under the "urn" URI scheme and a particular URN namespace
, with the intent that the URN will be a persistent, location-independent resour
ce identifier. With regard to URN syntax, this document defines the canonical sy
ntax for URNs (in a way that is consistent with URI syntax), specifies methods f
or determining URN-equivalence, and discusses URI conformance. With regard to UR
N namespaces, this document specifies a method for defining a URN namespace and
associating it with a namespace identifier, and it describes procedures for regi
stering namespace identifiers with the Internet Assigned Numbers Authority (IANA
). This document obsoletes both RFCs 2141 and 3406.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8141"/>
<seriesInfo name="DOI" value="10.17487/RFC8141"/>
</reference> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8141.xml"
/>
<reference anchor="FIPS180-4" target="https://nvlpubs.nist.gov/nistpubs/ FIPS/NIST.FIPS.180-4.pdf"> <reference anchor="FIPS180-4" target="https://nvlpubs.nist.gov/nistpubs/ FIPS/NIST.FIPS.180-4.pdf">
<front> <front>
<title>Secure Hash Standard</title> <title>Secure Hash Standard (SHS)</title>
<author> <author>
<organization>National Institute of Standards and Technology</orga <organization>National Institute of Standards and Technology
nization> (NIST)</organization>
</author> </author>
<date year="2015" month="August"/> <date year="2015" month="August"/>
</front> </front>
<seriesInfo name="FIPS" value="PUB 180-4"/> <seriesInfo name="FIPS PUB" value="180-4"/>
<seriesInfo name="DOI" value="10.6028/NIST.FIPS.180-4"/>
</reference> </reference>
<reference anchor="FIPS202" target="https://nvlpubs.nist.gov/nistpubs/FI PS/NIST.FIPS.202.pdf"> <reference anchor="FIPS202" target="https://nvlpubs.nist.gov/nistpubs/FI PS/NIST.FIPS.202.pdf">
<front> <front>
<title>SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions</title> <title>SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions</title>
<author> <author>
<organization>National Institute of Standards and Technology</orga <organization>National Institute of Standards and Technology
nization> (NIST)</organization>
</author> </author>
<date year="2015" month="August"/> <date year="2015" month="August"/>
</front> </front>
<seriesInfo name="FIPS" value="PUB 202"/> <seriesInfo name="FIPS PUB" value="202"/>
<seriesInfo name="DOI" value="10.6028/NIST.FIPS.202"/>
</reference> </reference>
<reference anchor="C311" target="https://pubs.opengroup.org/onlinepubs/9 696989899/toc.pdf"> <reference anchor="C311" target="https://pubs.opengroup.org/onlinepubs/9 696989899/toc.pdf">
<front> <front>
<title>DCE 1.1: Authentication and Security Services</title> <title>DCE 1.1: Authentication and Security Services</title>
<author> <author>
<organization/> <organization>The Open Group</organization>
</author> </author>
<date year="1997"/> <date year="1997" month="August"/>
</front>
<refcontent>Open Group CAE Specification C311</refcontent>
</reference>
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front> </front>
<seriesInfo name="BCP" value="14"/> <seriesInfo name="Open Group CAE Specification" value="C311"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"
/>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC1321">
<front> <reference anchor="IEEE802.11bh" target="https://standards.ieee.org/ieee/802.11b
<title>The MD5 Message-Digest Algorithm</title> h/10525/">
<author fullname="R. Rivest" initials="R." surname="Rivest"/> <front>
<date month="April" year="1992"/> <title>IEEE Draft Standard for Information technology--Telecommunications an
<abstract> d information exchange between systems Local and metropolitan area networks--Spe
<t>This document describes the MD5 message-digest algorithm. The a cific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physi
lgorithm takes as input a message of arbitrary length and produces as output a 1 cal Layer (PHY) Specifications Amendment: Enhancements for Extremely High Throug
28-bit "fingerprint" or "message digest" of the input. This memo provides inform hput (EHT)</title>
ation for the Internet community. It does not specify an Internet standard.</t> <author>
</abstract> <organization>IEEE</organization>
</front> </author>
<seriesInfo name="RFC" value="1321"/> <date year="2023" month="March"/>
<seriesInfo name="DOI" value="10.17487/RFC1321"/> </front>
</reference> <seriesInfo name="Electronic ISBN" value="978-1-5044-9520-2"/>
<reference anchor="RFC1738"> </reference>
<front>
<title>Uniform Resource Locators (URL)</title> <reference anchor="Err1957" quote-title="false" target="https://www.rfc-editor.o
<author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee rg/errata/eid1957">
"/> <front>
<author fullname="L. Masinter" initials="L." surname="Masinter"/> <title>Erratum ID 1957</title>
<author fullname="M. McCahill" initials="M." surname="McCahill"/> <author>
<date month="December" year="1994"/> <organization>RFC Errata</organization>
<abstract> </author>
<t>This document specifies a Uniform Resource Locator (URL), the s </front>
yntax and semantics of formalized information for location and access of resourc <refcontent>RFC 4122</refcontent>
es via the Internet. [STANDARDS-TRACK]</t> </reference>
</abstract>
</front> <reference anchor="Err3546" quote-title="false" target="https://www.rfc-editor.o
<seriesInfo name="RFC" value="1738"/> rg/errata/eid3546">
<seriesInfo name="DOI" value="10.17487/RFC1738"/> <front>
</reference> <title>Erratum ID 3546</title>
<reference anchor="RFC4086"> <author>
<front> <organization>RFC Errata</organization>
<title>Randomness Requirements for Security</title> </author>
<author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3 </front>
rd"/> <refcontent>RFC 4122</refcontent>
<author fullname="J. Schiller" initials="J." surname="Schiller"/> </reference>
<author fullname="S. Crocker" initials="S." surname="Crocker"/>
<date month="June" year="2005"/> <reference anchor="Err4976" quote-title="false" target="https://www.rfc-editor.o
<abstract> rg/errata/eid4976">
<t>Security systems are built on strong cryptographic algorithms t <front>
hat foil pattern analysis attempts. However, the security of these systems is de <title>Erratum ID 4976</title>
pendent on generating secret quantities for passwords, cryptographic keys, and s <author>
imilar quantities. The use of pseudo-random processes to generate secret quantit <organization>RFC Errata</organization>
ies can result in pseudo-security. A sophisticated attacker may find it easier t </author>
o reproduce the environment that produced the secret quantities and to search th </front>
e resulting small set of possibilities than to locate the quantities in the whol <refcontent>RFC 4122</refcontent>
e of the potential number space.</t> </reference>
<t>Choosing random quantities to foil a resourceful and motivated
adversary is surprisingly difficult. This document points out many pitfalls in u <reference anchor="Err4975" quote-title="false"
sing poor entropy sources or traditional pseudo-random number generation techniq target="https://www.rfc-editor.org/errata/eid4975">
ues for generating such quantities. It recommends the use of truly random hardwa <front>
re techniques and shows that the existing hardware on many systems can be used f <title>Erratum ID 4975</title>
or this purpose. It provides suggestions to ameliorate the problem when a hardwa <author>
re solution is not available, and it gives examples of how large such quantities <organization>RFC Errata</organization>
need to be for some applications. This document specifies an Internet Best Curr </author>
ent Practices for the Internet Community, and requests discussion and suggestion </front>
s for improvements.</t> <refcontent>RFC 4122</refcontent>
</abstract> </reference>
</front>
<seriesInfo name="BCP" value="106"/> <reference anchor="Err5560" quote-title="false"
<seriesInfo name="RFC" value="4086"/> target="https://www.rfc-editor.org/errata/eid5560">
<seriesInfo name="DOI" value="10.17487/RFC4086"/> <front>
</reference> <title>Erratum ID 5560</title>
<reference anchor="RFC4122"> <author>
<front> <organization>RFC Errata</organization>
<title>A Universally Unique IDentifier (UUID) URN Namespace</title> </author>
<author fullname="P. Leach" initials="P." surname="Leach"/> </front>
<author fullname="M. Mealling" initials="M." surname="Mealling"/> <refcontent>RFC 4122</refcontent>
<author fullname="R. Salz" initials="R." surname="Salz"/> </reference>
<date month="July" year="2005"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1321.xml"
<t>This specification defines a Uniform Resource Name namespace fo />
r UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally Unique ID <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1738.xml"
entifier). A UUID is 128 bits long, and can guarantee uniqueness across space an />
d time. UUIDs were originally used in the Apollo Network Computing System and la <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4086.xml"
ter in the Open Software Foundation\'s (OSF) Distributed Computing Environment ( />
DCE), and then in Microsoft Windows platforms.</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4122.xml"
<t>This specification is derived from the DCE specification with t />
he kind permission of the OSF (now known as The Open Group). Information from ea <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"
rlier versions of the DCE specification have been incorporated into this documen />
t. [STANDARDS-TRACK]</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6151.xml"
</abstract> />
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6194.xml"
<seriesInfo name="RFC" value="4122"/> />
<seriesInfo name="DOI" value="10.17487/RFC4122"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9542.xml"
</reference> />
<reference anchor="RFC5234"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"
<front> />
<title>Augmented BNF for Syntax Specifications: ABNF</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9499.xml"
<author fullname="D. Crocker" initials="D." role="editor" surname="C />
rocker"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8937.xml"
<author fullname="P. Overell" initials="P." surname="Overell"/> />
<date month="January" year="2008"/>
<abstract>
<t>Internet technical specifications often need to define a formal
syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Au
gmented BNF (ABNF), has been popular among many Internet specifications. The cur
rent specification documents ABNF. It balances compactness and simplicity with r
easonable representational power. The differences between standard BNF and ABNF
involve naming rules, repetition, alternatives, order-independence, and value ra
nges. This specification also supplies additional rule definitions and encoding
for a core lexical analyzer of the type common to several Internet specification
s. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="68"/>
<seriesInfo name="RFC" value="5234"/>
<seriesInfo name="DOI" value="10.17487/RFC5234"/>
</reference>
<reference anchor="RFC6151">
<front>
<title>Updated Security Considerations for the MD5 Message-Digest an
d the HMAC-MD5 Algorithms</title>
<author fullname="S. Turner" initials="S." surname="Turner"/>
<author fullname="L. Chen" initials="L." surname="Chen"/>
<date month="March" year="2011"/>
<abstract>
<t>This document updates the security considerations for the MD5 m
essage digest algorithm. It also updates the security considerations for HMAC-MD
5. This document is not an Internet Standards Track specification; it is publish
ed for informational purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6151"/>
<seriesInfo name="DOI" value="10.17487/RFC6151"/>
</reference>
<reference anchor="RFC6194">
<front>
<title>Security Considerations for the SHA-0 and SHA-1 Message-Diges
t Algorithms</title>
<author fullname="T. Polk" initials="T." surname="Polk"/>
<author fullname="L. Chen" initials="L." surname="Chen"/>
<author fullname="S. Turner" initials="S." surname="Turner"/>
<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
<date month="March" year="2011"/>
<abstract>
<t>This document includes security considerations for the SHA-0 an
d SHA-1 message digest algorithm. This document is not an Internet Standards Tra
ck specification; it is published for informational purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6194"/>
<seriesInfo name="DOI" value="10.17487/RFC6194"/>
</reference>
<reference anchor="RFC7042">
<front>
<title>IANA Considerations and IETF Protocol and Documentation Usage
for IEEE 802 Parameters</title>
<author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3
rd"/>
<author fullname="J. Abley" initials="J." surname="Abley"/>
<date month="October" year="2013"/>
<abstract>
<t>Some IETF protocols make use of Ethernet frame formats and IEEE
802 parameters. This document discusses several uses of such parameters in IETF
protocols, specifies IANA considerations for assignment of points under the IAN
A OUI (Organizationally Unique Identifier), and provides some values for use in
documentation. This document obsoletes RFC 5342.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="141"/>
<seriesInfo name="RFC" value="7042"/>
<seriesInfo name="DOI" value="10.17487/RFC7042"/>
</reference>
<reference anchor="RFC8126">
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs
</title>
<author fullname="M. Cotton" initials="M." surname="Cotton"/>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<author fullname="T. Narten" initials="T." surname="Narten"/>
<date month="June" year="2017"/>
<abstract>
<t>Many protocols make use of points of extensibility that use con
stants to identify various protocol parameters. To ensure that the values in the
se fields do not have conflicting uses and to promote interoperability, their al
locations are often coordinated by a central record keeper. For IETF protocols,
that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
<t>To make assignments in a given registry prudently, guidance des
cribing the conditions under which new values should be assigned, as well as whe
n and how modifications to existing values can be made, is needed. This document
defines a framework for the documentation of these guidelines by specification
authors, in order to assure that the provided guidance for the IANA Consideratio
ns is clear and addresses the various issues that are likely in the operation of
a registry.</t>
<t>This is the third edition of this document; it obsoletes RFC 52
26.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="26"/>
<seriesInfo name="RFC" value="8126"/>
<seriesInfo name="DOI" value="10.17487/RFC8126"/>
</reference>
<reference anchor="RFC8499">
<front>
<title>DNS Terminology</title>
<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
<author fullname="A. Sullivan" initials="A." surname="Sullivan"/>
<author fullname="K. Fujiwara" initials="K." surname="Fujiwara"/>
<date month="January" year="2019"/>
<abstract>
<t>The Domain Name System (DNS) is defined in literally dozens of
different RFCs. The terminology used by implementers and developers of DNS proto
cols, and by operators of DNS systems, has sometimes changed in the decades sinc
e the DNS was first defined. This document gives current definitions for many of
the terms used in the DNS in a single document.</t>
<t>This document obsoletes RFC 7719 and updates RFC 2308.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="219"/>
<seriesInfo name="RFC" value="8499"/>
<seriesInfo name="DOI" value="10.17487/RFC8499"/>
</reference>
<reference anchor="RFC8937">
<front>
<title>Randomness Improvements for Security Protocols</title>
<author fullname="C. Cremers" initials="C." surname="Cremers"/>
<author fullname="L. Garratt" initials="L." surname="Garratt"/>
<author fullname="S. Smyshlyaev" initials="S." surname="Smyshlyaev"/
>
<author fullname="N. Sullivan" initials="N." surname="Sullivan"/>
<author fullname="C. Wood" initials="C." surname="Wood"/>
<date month="October" year="2020"/>
<abstract>
<t>Randomness is a crucial ingredient for Transport Layer Security
(TLS) and related security protocols. Weak or predictable "cryptographically se
cure" pseudorandom number generators (CSPRNGs) can be abused or exploited for ma
licious purposes. An initial entropy source that seeds a CSPRNG might be weak or
broken as well, which can also lead to critical and systemic security problems.
This document describes a way for security protocol implementations to augment
their CSPRNGs using long-term private keys. This improves randomness from broken
or otherwise subverted CSPRNGs.</t>
<t>This document is a product of the Crypto Forum Research Group (
CFRG) in the IRTF.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8937"/>
<seriesInfo name="DOI" value="10.17487/RFC8937"/>
</reference>
<reference anchor="X500"> <reference anchor="X500">
<front> <front>
<title>Information technology – Open Systems Interconnection – The D <title>Information technology - Open Systems Interconnection - The
irectory: Overview of concepts, models and services</title> Directory: Overview of concepts, models and services</title>
<author> <author>
<organization/> <organization>ITU-T</organization>
</author> </author>
<date year="2019"/> <date year="2019" month="October"/>
</front> </front>
<seriesInfo name="ISO/IEC" value="9594-1"/> <seriesInfo name="ISO/IEC" value="9594-1"/>
<seriesInfo name="ITU-T Rec." value="X.500"/> <seriesInfo name="ITU-T Recommendation" value="X.500"/>
</reference> </reference>
<reference anchor="X660"> <reference anchor="X660">
<front> <front>
<title>Information technology – Procedures for the operation of obje <title>Information technology - Procedures for the operation of
ct identifier registration authorities: General procedures and top arcs of the i object identifier registration authorities: General procedures and
nternational object identifier tree</title> top arcs of the international object identifier tree</title>
<author> <author>
<organization/> <organization>ITU-T</organization>
</author> </author>
<date year="2011"/> <date month="July" year="2011"/>
</front> </front>
<seriesInfo name="ISO/IEC" value="9834-1"/> <seriesInfo name="ISO/IEC" value="9834-1"/>
<seriesInfo name="ITU-T Rec." value="X.660"/> <seriesInfo name="ITU-T Recommendation" value="X.660"/>
</reference> </reference>
<reference anchor="X680"> <reference anchor="X680">
<front> <front>
<title>Information Technology - Abstract Syntax Notation One (ASN.1) <title>Information Technology - Abstract Syntax Notation One
&amp; ASN.1 encoding rules</title> (ASN.1) &amp; ASN.1 encoding rules</title>
<author> <author>
<organization/> <organization>ITU-T</organization>
</author> </author>
<date year="2021"/> <date month="February" year="2021"/>
</front> </front>
<seriesInfo name="ISO/IEC" value="8824-1:2021"/> <seriesInfo name="ISO/IEC" value="8824-1:2021"/>
<seriesInfo name="ITU-T Rec." value="X.680"/> <seriesInfo name="ITU-T Recommendation" value="X.680"/>
</reference> </reference>
<reference anchor="LexicalUUID" target="https://github.com/twitter-archi ve/cassie"> <reference anchor="LexicalUUID" target="https://github.com/twitter-archi ve/cassie">
<front> <front>
<title>A Scala client for Cassandra</title> <title>Cassie</title>
<author> <author>
<organization>Twitter</organization> <organization>Twitter</organization>
</author> </author>
<date year="2012" month="November"/> <date year="2012" month="November"/>
</front> </front>
<seriesInfo name="commit" value="f6da4e0"/> <refcontent>commit f6da4e0</refcontent>
</reference> </reference>
<reference anchor="Snowflake" target="https://github.com/twitter-archive
/snowflake/releases/tag/snowflake-2010"> <reference anchor="Snowflake" target="https://github.com/twitter-archive
/snowflake">
<front> <front>
<title>Snowflake is a network service for generating unique ID numbe <title>Snowflake is a network service for generating unique ID
rs at high scale with some simple guarantees.</title> numbers at high scale with some simple guarantees.</title>
<author> <author>
<organization>Twitter</organization> <organization>Twitter</organization>
</author> </author>
<date year="2014" month="May"/> <date year="2014" month="May"/>
</front> </front>
<seriesInfo name="Commit" value="b3f6a3c"/> <refcontent>commit ec40836</refcontent>
</reference> </reference>
<reference anchor="Flake" target="https://github.com/boundary/flake"> <reference anchor="Flake" target="https://github.com/boundary/flake">
<front> <front>
<title>Flake: A decentralized, k-ordered id generation service in Er lang</title> <title>Flake: A decentralized, k-ordered id generation service in Er lang</title>
<author> <author>
<organization>Boundary</organization> <organization>Boundary</organization>
</author> </author>
<date year="2017" month="February"/> <date year="2017" month="February"/>
</front> </front>
<seriesInfo name="Commit" value="15c933a"/> <refcontent>commit 15c933a</refcontent>
</reference> </reference>
<reference anchor="ShardingID" target="https://instagram-engineering.com /sharding-ids-at-instagram-1cf5a71e5a5c"> <reference anchor="ShardingID" target="https://instagram-engineering.com /sharding-ids-at-instagram-1cf5a71e5a5c">
<front> <front>
<title>Sharding &amp; IDs at Instagram</title> <title>Sharding &amp; IDs at Instagram</title>
<author> <author>
<organization>Instagram Engineering</organization> <organization>Instagram Engineering</organization>
</author> </author>
<date year="2012" month="December"/> <date year="2012" month="December"/>
</front> </front>
</reference> </reference>
<reference anchor="KSUID" target="https://github.com/segmentio/ksuid"> <reference anchor="KSUID" target="https://github.com/segmentio/ksuid">
<front> <front>
<title>K-Sortable Globally Unique IDs</title> <title>K-Sortable Globally Unique IDs</title>
<author> <author>
<organization>Segment</organization> <organization>Segment</organization>
</author> </author>
<date year="2020" month="July"/> <date year="2020" month="July"/>
</front> </front>
<seriesInfo name="Commit" value="bf376a7"/> <refcontent>commit bf376a7</refcontent>
</reference> </reference>
<reference anchor="Elasticflake" target="https://github.com/ppearcy/elas ticflake"> <reference anchor="Elasticflake" target="https://github.com/ppearcy/elas ticflake">
<front> <front>
<title>Sequential UUID / Flake ID generator pulled out of elasticsea rch common</title> <title>Sequential UUID / Flake ID generator pulled out of elasticsea rch common</title>
<author initials="P." surname="Pearcy" fullname="Paul Pearcy"> <author initials="P." surname="Pearcy" fullname="Paul Pearcy">
<organization/> <organization/>
</author> </author>
<date year="2015" month="January"/> <date year="2015" month="January"/>
</front> </front>
<seriesInfo name="Commit" value="dd71c21"/> <refcontent>commit dd71c21</refcontent>
</reference> </reference>
<reference anchor="FlakeID" target="https://github.com/T-PWK/flake-idgen "> <reference anchor="FlakeID" target="https://github.com/T-PWK/flake-idgen ">
<front> <front>
<title>Flake ID Generator</title> <title>Flake ID Generator</title>
<author initials="T." surname="Pawlak" fullname="Tom Pawlak"> <author>
<organization/> <organization/>
</author> </author>
<date year="2020" month="April"/> <date year="2020" month="April"/>
</front> </front>
<seriesInfo name="Commit" value="fcd6a2f"/> <refcontent>commit fcd6a2f</refcontent>
</reference> </reference>
<reference anchor="Sonyflake" target="https://github.com/sony/sonyflake" > <reference anchor="Sonyflake" target="https://github.com/sony/sonyflake" >
<front> <front>
<title>A distributed unique ID generator inspired by Twitter's Snowf lake</title> <title>A distributed unique ID generator inspired by Twitter's Snowf lake</title>
<author> <author>
<organization>Sony</organization> <organization>Sony</organization>
</author> </author>
<date year="2020" month="August"/> <date year="2020" month="August"/>
</front> </front>
<seriesInfo name="Commit" value="848d664"/> <refcontent>commit 848d664</refcontent>
</reference> </reference>
<reference anchor="orderedUuid" target="https://itnext.io/laravel-the-my sterious-ordered-uuid-29e7500b4f8"> <reference anchor="orderedUuid" target="https://itnext.io/laravel-the-my sterious-ordered-uuid-29e7500b4f8">
<front> <front>
<title>Laravel: The mysterious "Ordered UUID"</title> <title>Laravel: The mysterious "Ordered UUID"</title>
<author initials="I. B." surname="Cabrera" fullname="Italo Baeza Cab rera"> <author initials="I. B." surname="Cabrera" fullname="Italo Baeza Cab rera">
<organization/> <organization/>
</author> </author>
<date year="2020" month="January"/> <date year="2020" month="January"/>
</front> </front>
</reference> </reference>
<reference anchor="COMBGUID" target="https://github.com/richardtallent/R T.Comb"> <reference anchor="COMBGUID" target="https://github.com/richardtallent/R T.Comb">
<front> <front>
<title>Creating sequential GUIDs in C# for MSSQL or PostgreSql</titl e> <title>Creating sequential GUIDs in C# for MSSQL or PostgreSql</titl e>
<author initials="R." surname="Tallent" fullname="Richard Tallent"> <author>
<organization/> <organization/>
</author> </author>
<date year="2020" month="December"/> <date year="2020" month="December"/>
</front> </front>
<seriesInfo name="Commit" value="2759820"/> <refcontent>commit 2759820</refcontent>
</reference> </reference>
<reference anchor="ULID" target="https://github.com/ulid/spec"> <reference anchor="ULID" target="https://github.com/ulid/spec">
<front> <front>
<title>Universally Unique Lexicographically Sortable Identifier</tit le> <title>Universally Unique Lexicographically Sortable Identifier</tit le>
<author initials="A." surname="Feerasta" fullname="Alizain Feerasta" > <author>
<organization/> <organization/>
</author> </author>
<date year="2019" month="May"/> <date year="2019" month="May"/>
</front> </front>
<seriesInfo name="Commit" value="d0c7170"/> <seriesInfo name="Commit" value="d0c7170"/>
</reference> </reference>
<reference anchor="SID" target="https://github.com/chilts/sid"> <reference anchor="SID" target="https://github.com/chilts/sid">
<front> <front>
<title>sid : generate sortable identifiers</title> <title>sid : generate sortable identifiers</title>
<author initials="A." surname="Chilton" fullname="Andrew Chilton"> <author>
<organization/> <organization/>
</author> </author>
<date year="2019" month="June"/> <date year="2019" month="June"/>
</front> </front>
<seriesInfo name="Commit" value="660e947"/> <seriesInfo name="Commit" value="660e947"/>
</reference> </reference>
<reference anchor="pushID" target="https://firebase.googleblog.com/2015/ 02/the-2120-ways-to-ensure-unique_68.html"> <reference anchor="pushID" target="https://firebase.googleblog.com/2015/ 02/the-2120-ways-to-ensure-unique_68.html">
<front> <front>
<title>The 2^120 Ways to Ensure Unique Identifiers</title> <title>The 2^120 Ways to Ensure Unique Identifiers</title>
<author> <author fullname="Michael Lehenbauer" surname="Lehenbauer" initials= "M.">
<organization>Google</organization> <organization>Google</organization>
</author> </author>
<date year="2015" month="February"/> <date year="2015" month="February"/>
</front> </front>
</reference> </reference>
<reference anchor="XID" target="https://github.com/rs/xid"> <reference anchor="XID" target="https://github.com/rs/xid">
<front> <front>
<title>Globally Unique ID Generator</title> <title>Globally Unique ID Generator</title>
<author initials="O." surname="Poitrey" fullname="Olivier Poitrey"> <author>
<organization/> <organization/>
</author> </author>
<date year="2020" month="October"/> <date year="2020" month="October"/>
</front> </front>
<seriesInfo name="Commit" value="efa678f"/> <refcontent>commit efa678f</refcontent>
</reference> </reference>
<reference anchor="ObjectID" target="https://docs.mongodb.com/manual/ref erence/method/ObjectId/"> <reference anchor="ObjectID" target="https://docs.mongodb.com/manual/ref erence/method/ObjectId/">
<front> <front>
<title>ObjectId - MongoDB Manual</title> <title>ObjectId</title>
<author> <author>
<organization>MongoDB</organization> <organization>MongoDB</organization>
</author> </author>
<date/> <date/>
</front> </front>
</reference> </reference>
<reference anchor="CUID" target="https://github.com/ericelliott/cuid"> <reference anchor="CUID" target="https://github.com/ericelliott/cuid">
<front> <front>
<title>Collision-resistant ids optimized for horizontal scaling and performance.</title> <title>Collision-resistant ids optimized for horizontal scaling and performance.</title>
<author initials="E." surname="Elliott" fullname="Eric Elliott"> <author>
<organization/> <organization/>
</author> </author>
<date year="2020" month="October"/> <date year="2020" month="October"/>
</front> </front>
<seriesInfo name="Commit" value="215b27b"/> <refcontent>commit 215b27b</refcontent>
</reference> </reference>
<reference anchor="IEEE754" target="https://standards.ieee.org/ieee/754/ 6210/"> <reference anchor="IEEE754" target="https://standards.ieee.org/ieee/754/ 6210/">
<front> <front>
<title>IEEE Standard for Floating-Point Arithmetic.</title> <title>IEEE Standard for Floating-Point Arithmetic.</title>
<author> <author>
<organization>IEEE</organization> <organization>IEEE</organization>
</author> </author>
<date year="2019" month="July"/> <date year="2019" month="July"/>
</front> </front>
<seriesInfo name="Series" value="754-2019"/> <seriesInfo name="IEEE Std" value="754-2019"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2019.8766229"/>
</reference> </reference>
<reference anchor="URNNamespaces" target="https://www.iana.org/assignmen
ts/urn-namespaces/urn-namespaces.xhtml"> <reference anchor="URNNamespaces" target="https://www.iana.org/assignmen
ts/urn-namespaces/">
<front> <front>
<title>Uniform Resource Names (URN) Namespaces</title> <title>Uniform Resource Names (URN) Namespaces</title>
<author> <author>
<organization>IANA</organization> <organization>IANA</organization>
</author> </author>
<date year="2022" month="November" day="18"/>
</front> </front>
</reference> </reference>
<reference anchor="Python" target="https://docs.python.org/3/library/uui d.html"> <reference anchor="Python" target="https://docs.python.org/3/library/uui d.html">
<front> <front>
<title>UUID objects according to RFC</title> <title>uuid - UUID objects according to RFC 4122</title>
<author> <author>
<organization>Python</organization> <organization>Python</organization>
</author> </author>
<date year="2023" month="May" day="23"/>
</front> </front>
</reference> </reference>
<reference anchor="Microsoft" target="https://learn.microsoft.com/en-us/
openspecs/windows_protocols/ms-dtyp/a66edeb1-52a0-4d64-a93b-2f5c833d7d92"> <reference anchor="Microsoft" target="https://learn.microsoft.com/en-us/
openspecs/windows_protocols/ms-dtyp/222af2d3-5c00-4899-bc87-ed4c6515e80d">
<front> <front>
<title>curly braced GUID string</title> <title>2.3.4.3 GUID - Curly Braced String Representation</title>
<author> <author>
<organization>Microsoft</organization> <organization>Microsoft</organization>
</author> </author>
<date year="2023" month="April" day="03"/> <date year="2023" month="April"/>
</front> </front>
</reference> </reference>
<reference anchor="MS_COM_GUID" target="https://devblogs.microsoft.com/o ldnewthing/20220928-00/?p=107221"> <reference anchor="MS_COM_GUID" target="https://devblogs.microsoft.com/o ldnewthing/20220928-00/?p=107221">
<front> <front>
<title>Why does COM express GUIDs in a mix of big-endian and little- endian? Why can’t it just pick a side and stick with it?</title> <title>Why does COM express GUIDs in a mix of big-endian and little- endian? Why can't it just pick a side and stick with it?</title>
<author initials="R." surname="Chen" fullname="Raymond Chen"> <author initials="R." surname="Chen" fullname="Raymond Chen">
<organization/> <organization>Microsoft</organization>
</author> </author>
<date year="2022" month="September" day="28"/> <date year="2022" month="September"/>
</front> </front>
</reference> </reference>
<reference anchor="IBM_NCS" target="https://www.ibm.com/docs/en/aix/7.1? topic=u-uuid-gen-command-ncs"> <reference anchor="IBM_NCS" target="https://www.ibm.com/docs/en/aix/7.1? topic=u-uuid-gen-command-ncs">
<front> <front>
<title>uuid_gen Command (NCS)</title> <title>uuid_gen Command (NCS)</title>
<author> <author>
<organization>IBM</organization> <organization>IBM</organization>
</author> </author>
<date year="2023" month="March" day="23"/> <date year="2023" month="March"/>
</front> </front>
</reference> </reference>
<reference anchor="RANDOM" target="https://peteroupc.github.io/random.ht ml"> <reference anchor="RANDOM" target="https://peteroupc.github.io/random.ht ml">
<front> <front>
<title>Random Number Generator Recommendations for Applications</tit le> <title>Random Number Generator Recommendations for Applications</tit le>
<author initials="P." surname="Occil" fullname="Peter Occil"> <author initials="P." surname="Occil" fullname="Peter Occil">
<organization/> <organization/>
</author> </author>
<date year="2023"/> <date month="June" year="2023"/>
</front> </front>
</reference> </reference>
</references> </references>
</references> </references>
<?line 2069?>
<section anchor="test_vectors"> <section anchor="test_vectors">
<name>Test Vectors</name> <name>Test Vectors</name>
<t>Both UUIDv1 and UUIDv6 test vectors utilize the same 60 bit timestamp: <t>Both UUIDv1 and UUIDv6 test vectors utilize the same 60-bit
0x1EC9414C232AB00 timestamp: 0x1EC9414C232AB00 (138648505420000000) Tuesday, February 22,
(138648505420000000) Tuesday, February 22, 2022 2:22:22.000000 PM GMT-05:00</t> 2022 2:22:22.000000 PM GMT-05:00.</t>
<t>Both UUIDv1 and UUIDv6 utilize the same values in clock_seq, <t>Both UUIDv1 and UUIDv6 utilize the same values in clock_seq and
and node. All of which have been generated with random data. node; all of which have been generated with random data. For the
For the randomized node, the least significant bit of the first octet is set to randomized node, the least significant bit of the first octet is set to
a value of 1 as per <xref target="unidentifiable"/>. a value of 1 as per <xref target="unidentifiable"/>. Thus, the starting
Thus the starting value 0x9E6BDECED846 was changed to 0x9F6BDECED846.</t> value 0x9E6BDECED846 was changed to 0x9F6BDECED846.</t>
<t>The pseudocode used for converting from a 64 bit Unix timestamp to a 10 <t>The pseudocode used for converting from a 64-bit Unix timestamp to a
0ns Gregorian timestamp value 100 ns Gregorian timestamp value has been left in the document for
has been left in the document for reference purposes.</t> reference purposes.</t>
<figure> <figure>
<name>Test Vector Timestamp Pseudo-code</name> <name>Test Vector Timestamp Pseudocode</name>
<sourcecode type="code"><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
# Gregorian to Unix Offset: # Gregorian-to-Unix Offset:
# The number of 100-ns intervals between the # The number of 100 ns intervals between the
# UUID epoch 1582-10-15 00:00:00 # UUID Epoch 1582-10-15 00:00:00
# and the Unix epoch 1970-01-01 00:00:00 # and the Unix Epoch 1970-01-01 00:00:00
# Greg_Unix_offset = 0x01b21dd213814000 or 122192928000000000 # Greg_Unix_offset = 0x01b21dd213814000 or 122192928000000000
# Unix 64 bit Nanosecond Timestamp: # Unix 64-bit Nanosecond Timestamp:
# Unix NS: Tuesday, February 22, 2022 2:22:22 PM GMT-05:00 # Unix NS: Tuesday, February 22, 2022 2:22:22 PM GMT-05:00
# Unix_64_bit_ns = 0x16D6320C3D4DCC00 or 1645557742000000000 # Unix_64_bit_ns = 0x16D6320C3D4DCC00 or 1645557742000000000
# Unix Nanosecond precision to Gregorian 100-nanosecond intervals # Unix Nanosecond precision to Gregorian 100-nanosecond intervals
# Greg_100_ns = (Unix_64_bit_ns/100)+Greg_Unix_offset # Greg_100_ns = (Unix_64_bit_ns/100)+Greg_Unix_offset
# Work: # Work:
# Greg_100_ns = (1645557742000000000/100)+122192928000000000 # Greg_100_ns = (1645557742000000000/100)+122192928000000000
# Unix_64_bit_ns = (138648505420000000-122192928000000000)*100 # Unix_64_bit_ns = (138648505420000000-122192928000000000)*100
skipping to change at line 3019 skipping to change at line 2500
time_high 12 0x1EC time_high 12 0x1EC
var 2 0b10 var 2 0b10
clock_seq 14 0b11, 0x3C8 clock_seq 14 0b11, 0x3C8
node 48 0x9F6BDECED846 node 48 0x9F6BDECED846
------------------------------------------- -------------------------------------------
total 128 total 128
------------------------------------------- -------------------------------------------
final: C232AB00-9414-11EC-B3C8-9F6BDECED846 final: C232AB00-9414-11EC-B3C8-9F6BDECED846
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="uuidv3_example"> <section anchor="uuidv3_example">
<name>Example of a UUIDv3 Value</name> <name>Example of a UUIDv3 Value</name>
<t>The MD5 computation from is detailed in <xref target="v3md5"/> using <t>The MD5 computation from is detailed in <xref target="v3md5"/>
the DNS Namespace ID value and the Name "www.example.com". using the DNS Namespace ID value and the Name "www.example.com".
while the field mapping and all values are illustrated in <xref target="v3fields The field mapping and all values are illustrated in <xref
"/>. target="v3fields"/>. Finally, to further illustrate the bit swapping
Finally to further illustrate the bit swapping for version and variant see <xref for version and variant, see <xref target="v3vervar"/>.</t>
target="v3vervar"/>.</t>
<figure anchor="v3md5"> <figure anchor="v3md5">
<name>UUIDv3 Example MD5</name> <name>UUIDv3 Example MD5</name>
<artwork><![CDATA[ <artwork><![CDATA[
Namespace (DNS): 6ba7b810-9dad-11d1-80b4-00c04fd430c8 Namespace (DNS): 6ba7b810-9dad-11d1-80b4-00c04fd430c8
Name: www.example.com Name: www.example.com
------------------------------------------------------ ------------------------------------------------------
MD5: 5df418813aed051548a72f4a814cf09e MD5: 5df418813aed051548a72f4a814cf09e
]]></artwork> ]]></artwork>
</figure> </figure>
<figure anchor="v3fields"> <figure anchor="v3fields">
<name>UUIDv3 Example Test Vector</name> <name>UUIDv3 Example Test Vector</name>
<artwork><![CDATA[ <artwork><![CDATA[
------------------------------------------- -------------------------------------------
field bits value field bits value
------------------------------------------- -------------------------------------------
md5_high 48 0x5df418813aed md5_high 48 0x5df418813aed
ver 4 0x3 ver 4 0x3
md5_mid 12 0x515 md5_mid 12 0x515
var 2 0b10 var 2 0b10
skipping to change at line 3051 skipping to change at line 2537
ver 4 0x3 ver 4 0x3
md5_mid 12 0x515 md5_mid 12 0x515
var 2 0b10 var 2 0b10
md5_low 62 0b00, 0x8a72f4a814cf09e md5_low 62 0b00, 0x8a72f4a814cf09e
------------------------------------------- -------------------------------------------
total 128 total 128
------------------------------------------- -------------------------------------------
final: 5df41881-3aed-3515-88a7-2f4a814cf09e final: 5df41881-3aed-3515-88a7-2f4a814cf09e
]]></artwork> ]]></artwork>
</figure> </figure>
<figure anchor="v3vervar"> <figure anchor="v3vervar">
<name>UUIDv3 Example Ver Var bit swaps</name> <name>UUIDv3 Example Ver/Var Bit Swaps</name>
<artwork><![CDATA[ <artwork><![CDATA[
MD5 hex and dash: 5df41881-3aed-0515-48a7-2f4a814cf09e MD5 hex and dash: 5df41881-3aed-0515-48a7-2f4a814cf09e
Ver and Var Overwrite: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx Ver and Var Overwrite: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
Final: 5df41881-3aed-3515-88a7-2f4a814cf09e Final: 5df41881-3aed-3515-88a7-2f4a814cf09e
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="uuidv4_example"> <section anchor="uuidv4_example">
<name>Example of a UUIDv4 Value</name> <name>Example of a UUIDv4 Value</name>
<t>This UUIDv4 example was created by generating 16 bytes <t>This UUIDv4 example was created by generating 16 bytes of random
of random data resulting in the hexadecimal value of data resulting in the hexadecimal value of
919108F752D133205BACF847DB4148A8. This is then used to 919108F752D133205BACF847DB4148A8. This is then used to fill out the
fill out the fields as shown in <xref target="v4fields"/>.</t> fields as shown in <xref target="v4fields"/>.</t>
<t>Finally to further illustrate the bit swapping for version and varian <t>Finally, to further illustrate the bit swapping for version and
t see <xref target="v4vervar"/>.</t> variant, see <xref target="v4vervar"/>.</t>
<figure anchor="v4fields"> <figure anchor="v4fields">
<name>UUIDv4 Example Test Vector</name> <name>UUIDv4 Example Test Vector</name>
<artwork><![CDATA[ <artwork><![CDATA[
------------------------------------------- -------------------------------------------
field bits value field bits value
------------------------------------------- -------------------------------------------
random_a 48 0x919108f752d1 random_a 48 0x919108f752d1
ver 4 0x4 ver 4 0x4
random_b 12 0x320 random_b 12 0x320
var 2 0b10 var 2 0b10
skipping to change at line 3084 skipping to change at line 2574
ver 4 0x4 ver 4 0x4
random_b 12 0x320 random_b 12 0x320
var 2 0b10 var 2 0b10
random_c 62 0b01, 0xbacf847db4148a8 random_c 62 0b01, 0xbacf847db4148a8
------------------------------------------- -------------------------------------------
total 128 total 128
------------------------------------------- -------------------------------------------
final: 919108f7-52d1-4320-9bac-f847db4148a8 final: 919108f7-52d1-4320-9bac-f847db4148a8
]]></artwork> ]]></artwork>
</figure> </figure>
<figure anchor="v4vervar"> <figure anchor="v4vervar">
<name>UUIDv4 Example Ver/Var bit swaps</name> <name>UUIDv4 Example Ver/Var Bit Swaps</name>
<artwork><![CDATA[ <artwork><![CDATA[
Random hex: 919108f752d133205bacf847db4148a8 Random hex: 919108f752d133205bacf847db4148a8
Random hex and dash: 919108f7-52d1-3320-5bac-f847db4148a8 Random hex and dash: 919108f7-52d1-3320-5bac-f847db4148a8
Ver and Var Overwrite: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx Ver and Var Overwrite: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
Final: 919108f7-52d1-4320-9bac-f847db4148a8 Final: 919108f7-52d1-4320-9bac-f847db4148a8
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="uuidv5_example"> <section anchor="uuidv5_example">
<name>Example of a UUIDv5 Value</name> <name>Example of a UUIDv5 Value</name>
<t>The SHA-1 computation from is detailed in <xref target="v5sha1"/> usi <t>The SHA-1 computation form is detailed in <xref target="v5sha1"/>,
ng the DNS Namespace ID value and the Name "www.example.com". using the DNS Namespace ID value and the Name "www.example.com". The
while the field mapping and all values are illustrated in <xref target="v5fields field mapping and all values are illustrated in <xref
"/>. target="v5fields"/>. Finally, to further illustrate the bit swapping
Finally to further illustrate the bit swapping for version and variant and the u for version and variant and the unused/discarded part of the SHA-1
nused/discarded part of the SHA-1 value see <xref target="v5vervar"/>.</t> value, see <xref target="v5vervar"/>.</t>
<figure anchor="v5sha1"> <figure anchor="v5sha1">
<name>UUIDv5 Example SHA-1</name> <name>UUIDv5 Example SHA-1</name>
<artwork><![CDATA[ <artwork><![CDATA[
Namespace (DNS): 6ba7b810-9dad-11d1-80b4-00c04fd430c8 Namespace (DNS): 6ba7b810-9dad-11d1-80b4-00c04fd430c8
Name: www.example.com Name: www.example.com
---------------------------------------------------------- ----------------------------------------------------------
SHA-1: 2ed6657de927468b55e12665a8aea6a22dee3e35 SHA-1: 2ed6657de927468b55e12665a8aea6a22dee3e35
]]></artwork> ]]></artwork>
</figure> </figure>
<figure anchor="v5fields"> <figure anchor="v5fields">
<name>UUIDv5 Example Test Vector</name> <name>UUIDv5 Example Test Vector</name>
<artwork><![CDATA[ <artwork><![CDATA[
------------------------------------------- -------------------------------------------
field bits value field bits value
------------------------------------------- -------------------------------------------
sha1_high 48 0x2ed6657de927 sha1_high 48 0x2ed6657de927
ver 4 0x5 ver 4 0x5
sha1_mid 12 0x68b sha1_mid 12 0x68b
var 2 0b10 var 2 0b10
skipping to change at line 3125 skipping to change at line 2622
ver 4 0x5 ver 4 0x5
sha1_mid 12 0x68b sha1_mid 12 0x68b
var 2 0b10 var 2 0b10
sha1_low 62 0b01, 0x5e12665a8aea6a2 sha1_low 62 0b01, 0x5e12665a8aea6a2
------------------------------------------- -------------------------------------------
total 128 total 128
------------------------------------------- -------------------------------------------
final: 2ed6657d-e927-568b-95e1-2665a8aea6a2 final: 2ed6657d-e927-568b-95e1-2665a8aea6a2
]]></artwork> ]]></artwork>
</figure> </figure>
<figure anchor="v5vervar"> <figure anchor="v5vervar">
<name>UUIDv5 Example Ver/Var bit swaps and discarded SHA-1 segment</na me> <name>UUIDv5 Example Ver/Var Bit Swaps and Discarded SHA-1 Segment</na me>
<artwork><![CDATA[ <artwork><![CDATA[
SHA-1 hex and dash: 2ed6657d-e927-468b-55e1-2665a8aea6a2-2dee3e35 SHA-1 hex and dash: 2ed6657d-e927-468b-55e1-2665a8aea6a2-2dee3e35
Ver and Var Overwrite: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx Ver and Var Overwrite: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
Final: 2ed6657d-e927-568b-95e1-2665a8aea6a2 Final: 2ed6657d-e927-568b-95e1-2665a8aea6a2
Discarded: -2dee3e35 Discarded: -2dee3e35
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="uuidv6_example"> <section anchor="uuidv6_example">
<name>Example of a UUIDv6 Value</name> <name>Example of a UUIDv6 Value</name>
<figure> <figure>
<name>UUIDv6 Example Test Vector</name> <name>UUIDv6 Example Test Vector</name>
<artwork><![CDATA[ <artwork><![CDATA[
------------------------------------------- -------------------------------------------
field bits value field bits value
------------------------------------------- -------------------------------------------
time_high 32 0x1EC9414C time_high 32 0x1EC9414C
skipping to change at line 3159 skipping to change at line 2658
node 48 0x9F6BDECED846 node 48 0x9F6BDECED846
------------------------------------------- -------------------------------------------
total 128 total 128
------------------------------------------- -------------------------------------------
final: 1EC9414C-232A-6B00-B3C8-9F6BDECED846 final: 1EC9414C-232A-6B00-B3C8-9F6BDECED846
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="uuidv7_example"> <section anchor="uuidv7_example">
<name>Example of a UUIDv7 Value</name> <name>Example of a UUIDv7 Value</name>
<t>This example UUIDv7 test vector utilizes a well-known Unix epoch time <t>This example UUIDv7 test vector utilizes a well-known Unix Epoch
stamp with timestamp with millisecond precision to fill the first 48 bits.</t>
millisecond precision to fill the first 48 bits.</t>
<t>rand_a and rand_b are filled with random data.</t> <t>rand_a and rand_b are filled with random data.</t>
<t>The timestamp is Tuesday, February 22, 2022 2:22:22.00 PM GMT-05:00 r <t>The timestamp is Tuesday, February 22, 2022 2:22:22.00 PM
epresented GMT-05:00, represented as 0x017F22E279B0 or 1645557742000.</t>
as 0x017F22E279B0 or 1645557742000</t>
<figure> <figure>
<name>UUIDv7 Example Test Vector</name> <name>UUIDv7 Example Test Vector</name>
<artwork><![CDATA[ <artwork><![CDATA[
------------------------------------------- -------------------------------------------
field bits value field bits value
------------------------------------------- -------------------------------------------
unix_ts_ms 48 0x017F22E279B0 unix_ts_ms 48 0x017F22E279B0
ver 4 0x7 ver 4 0x7
rand_a 12 0xCC3 rand_a 12 0xCC3
var 2 0b10 var 2 0b10
skipping to change at line 3185 skipping to change at line 2684
------------------------------------------- -------------------------------------------
total 128 total 128
------------------------------------------- -------------------------------------------
final: 017F22E2-79B0-7CC3-98C4-DC0C0C07398F final: 017F22E2-79B0-7CC3-98C4-DC0C0C07398F
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
</section> </section>
<section anchor="ill_examples"> <section anchor="ill_examples">
<name>Illustrative Examples</name> <name>Illustrative Examples</name>
<t>The following sections contain illustrative examples which serve to sho <t>The following sections contain illustrative examples that serve to
w how one may use UUIDv8 <xref target="uuidv8"/> for custom and/or experimental show how one may use UUIDv8 (<xref target="uuidv8"/>) for custom and/or
application based logic. experimental application-based logic. The examples below have not been
The examples below have not been through the same rigorous testing, prototyping, through the same rigorous testing, prototyping, and feedback loop that
and feedback loop that other algorithms in this document have undergone. other algorithms in this document have undergone. The authors
The authors encouraged implementors to create your own UUIDv8 algorithm rather t encourage implementers to create their own UUIDv8 algorithm rather than
han use the items defined in this section.</t> use the items defined in this section.</t>
<section anchor="uuidv8_example"> <section anchor="uuidv8_example">
<name>Example of a UUIDv8 Value (time-based)</name> <name>Example of a UUIDv8 Value (Time-Based)</name>
<t>This example UUIDv8 test vector utilizes a well-known 64 bit Unix epo <t>This example UUIDv8 test vector utilizes a well-known 64-bit Unix
ch timestamp with Epoch timestamp with 10 ns precision, truncated to the
10ns precision, truncated to the least-significant, right-most, bits least significant, rightmost bits to fill the first 60 bits of
to fill the first 60 bits of custom_a and custom_b while setting the version bit custom_a and custom_b, while setting the version bits between these two
s between these two segments to the version value of 8.</t> segments to the version value of 8.</t>
<t>The variant bits are set and the final segment, custom_c, is filled w <t>The variant bits are set; and the final segment, custom_c, is filled
ith random data.</t> with random data.</t>
<t>Timestamp is Tuesday, February 22, 2022 2:22:22.000000 PM GMT-05:00 r <t>Timestamp is Tuesday, February 22, 2022 2:22:22.000000 PM
epresented GMT-05:00, represented as 0x2489E9AD2EE2E00 or 164555774200000000
as 0x2489E9AD2EE2E00 or 164555774200000000 (10ns-steps).</t> (10 ns-steps).</t>
<figure> <figure>
<name>UUIDv8 Example Time-based Illustrative Example</name> <name>UUIDv8 Example Time-Based Illustrative Example</name>
<artwork><![CDATA[ <artwork><![CDATA[
------------------------------------------- -------------------------------------------
field bits value field bits value
------------------------------------------- -------------------------------------------
custom_a 48 0x2489E9AD2EE2 custom_a 48 0x2489E9AD2EE2
ver 4 0x8 ver 4 0x8
custom_b 12 0xE00 custom_b 12 0xE00
var 2 0b10 var 2 0b10
custom_c 62 0b00, 0xEC932D5F69181C0 custom_c 62 0b00, 0xEC932D5F69181C0
------------------------------------------- -------------------------------------------
total 128 total 128
------------------------------------------- -------------------------------------------
final: 2489E9AD-2EE2-8E00-8EC9-32D5F69181C0 final: 2489E9AD-2EE2-8E00-8EC9-32D5F69181C0
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="uuidv8_example_name"> <section anchor="uuidv8_example_name">
<name>Example of a UUIDv8 Value (name-based)</name> <name>Example of a UUIDv8 Value (Name-Based)</name>
<t>As per <xref target="uuidv5"/> name-based UUIDs that desire to use mo <t>As per <xref target="uuidv5"/>, name-based UUIDs that want to use
dern hashing algorithms <bcp14>MUST</bcp14> be created within the UUIDv8 space. modern hashing algorithms <bcp14>MUST</bcp14> be created within the
These <bcp14>MAY</bcp14> leverage newer hashing algorithms such as SHA-256 or SH UUIDv8 space. These <bcp14>MAY</bcp14> leverage newer hashing
A-512 defined by <xref target="FIPS180-4"/>, SHA-3 or SHAKE defined by <xref tar algorithms such as SHA-256 or SHA-512 (as defined by <xref
get="FIPS202"/>, or even algorithms that have not been defined yet.</t> target="FIPS180-4"/>), SHA-3 or SHAKE (as defined by <xref
<t>A SHA-256 version of <xref target="uuidv5_example"/> is detailed in < target="FIPS202"/>), or even algorithms that have not been defined
xref target="v8sha256"/> as an illustrative example detailing how this can be ac yet.</t>
hieved.
The creation of the name-based UUIDv8 value in this section follows the same log <t>A SHA-256 version of the SHA-1 computation in <xref
ic defined in <xref target="uuidv5"/> with the difference being SHA-256 in place target="uuidv5_example"/> is detailed in <xref target="v8sha256"/> as
of SHA-1.</t> an illustrative example detailing how this can be achieved. The
<t>The field mapping and all values are illustrated in <xref target="v8f creation of the name-based UUIDv8 value in this section follows the
ieldssha256"/>. same logic defined in <xref target="uuidv5"/> with the difference
Finally to further illustrate the bit swapping for version and variant and the u being SHA-256 in place of SHA-1.</t>
nused/discarded part of the SHA-256 value see <xref target="v8vervar"/>. <t>The field mapping and all values are illustrated in <xref
An important note for secure hashing algorithms that produce outputs of an arbit target="v8fieldssha256"/>. Finally, to further illustrate the bit
rary size, such as those found in SHAKE, the output hash <bcp14>MUST</bcp14> be swapping for version and variant and the unused/discarded part of the
128 bits or larger.</t> SHA-256 value, see <xref target="v8vervar"/>. An important note for
secure hashing algorithms that produce outputs of an arbitrary size,
such as those found in SHAKE, is that the output hash
<bcp14>MUST</bcp14> be 128 bits or larger.</t>
<figure anchor="v8sha256"> <figure anchor="v8sha256">
<name>UUIDv8 Example SHA256</name> <name>UUIDv8 Example SHA256</name>
<artwork><![CDATA[ <artwork><![CDATA[
Namespace (DNS): 6ba7b810-9dad-11d1-80b4-00c04fd430c8 Namespace (DNS): 6ba7b810-9dad-11d1-80b4-00c04fd430c8
Name: www.example.com Name: www.example.com
---------------------------------------------------------------- ----------------------------------------------------------------
SHA-256: SHA-256:
5c146b143c524afd938a375d0df1fbf6fe12a66b645f72f6158759387e51f3c8 5c146b143c524afd938a375d0df1fbf6fe12a66b645f72f6158759387e51f3c8
]]></artwork> ]]></artwork>
</figure> </figure>
skipping to change at line 3250 skipping to change at line 2771
ver 4 0x8 ver 4 0x8
custom_b 12 0xafd custom_b 12 0xafd
var 2 0b10 var 2 0b10
custom_c 62 0b00, 0x38a375d0df1fbf6 custom_c 62 0b00, 0x38a375d0df1fbf6
------------------------------------------- -------------------------------------------
total 128 total 128
------------------------------------------- -------------------------------------------
final: 5c146b14-3c52-8afd-938a-375d0df1fbf6 final: 5c146b14-3c52-8afd-938a-375d0df1fbf6
]]></artwork> ]]></artwork>
</figure> </figure>
<figure anchor="v8vervar"> <figure anchor="v8vervar">
<name>UUIDv8 Example Ver/Var bit swaps and discarded SHA-256 segment</ name> <name>UUIDv8 Example Ver/Var Bit Swaps and Discarded SHA-256 Segment</ name>
<artwork><![CDATA[ <artwork><![CDATA[
A: 5c146b14-3c52-4afd-938a-375d0df1fbf6-fe12a66b645f72f6158759387e51f3c8 A: 5c146b14-3c52-4afd-938a-375d0df1fbf6-fe12a66b645f72f6158759387e51f3c8
B: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx B: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
C: 5c146b14-3c52-8afd-938a-375d0df1fbf6 C: 5c146b14-3c52-8afd-938a-375d0df1fbf6
D: -fe12a66b645f72f6158759387e51f3c8 D: -fe12a66b645f72f6158759387e51f3c8
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Examining <xref target="v8vervar"/>:</t> <t>Examining <xref target="v8vervar"/>:</t>
<ul spacing="compact">
<li> <ul spacing="normal">
<t>Line A details the full SHA-256 as a hexadecimal value with the d <li>Line A details the full SHA-256 as a hexadecimal value with the
ashes inserted.</t> dashes inserted.</li>
</li> <li>Line B details the version and variant hexadecimal positions,
<li> which must be overwritten.</li>
<t>Line B details the version and variant hexadecimal positions whic <li>Line C details the final value after the ver and var have been
h must be overwritten.</t> overwritten.</li>
</li> <li>Line D details the discarded leftover values from the original
<li> SHA-256 computation.</li>
<t>Line C details the final value after the ver/var have been overwr
itten.</t>
</li>
<li>
<t>Line D details the discarded, leftover values from the original S
HA-256 computation.</t>
</li>
</ul> </ul>
</section> </section>
</section> </section>
</back> <section anchor="Acknowledgements" toc="default" numbered="false">
<!-- ##markdown-source: <name>Acknowledgements</name>
H4sIAAAAAAAAA+y96XIbWZYm+J9mfAdv0qZFVgMgAIJrdlYWRUkRrAwtLVKZ <t>The authors gratefully acknowledge the contributions of <contact
WTY9I3MADtJTgDvK3cElFBrrd5hf82+eZR6ln2TOd5Z7rzsAioqMyKzqLEWY fullname="Rich Salz"/>, <contact fullname="Michael Mealling"/>, <contact
RALudzn33LMv7XZ7c+P2NNrf3BjnoyyeJafRuIgnVTtNqkl7sUjHRXLbLiaj fullname="Ben Campbell"/>, <contact fullname="Ben Ramsey"/>, <contact
Qa/fH6ZluzfY3BjF1WlUVuPNjXxY5tOkSsrT6BmeeEZf5lmZZOUCH1XFIqGP fullname="Fabio Lima"/>, <contact fullname="Gonzalo Salgueiro"/>,
ysVwlpZlmmfVw5xmuHh59WpzY56ebm5ENE6Rjmi8Zw9J+QwfVPmo/ts4mVc3 <contact fullname="Martin Thomson"/>, <contact fullname="Murray
9NE+f1A+zIpkUgaPlHlRBR9F21E8GqXjJKvi6fQhGuVFkYyqNLt2n0en7d3N S. Kucherawy"/>, <contact fullname="Rick van Rein"/>, <contact
jSqtprSaD1l6mxQlP0s//+siiS5e0EPpJKWPo50PHy5e0NPxcEigoMfpV/qt fullname="Rob Wilton"/>, <contact fullname="Sean Leonard"/>, <contact
SOLT6Oz91ebG3fVppIDa3Ph0J78QPOOKBu93+wRben5R3eQFbbgdCZR///Bj fullname="Theodore Y. Ts'o"/>, <contact fullname="Robert Kieffer"/>,
UkTvO9GL+DYtsY1kFqfT0+jTwxif/NMoLUd5Z5TP8F1e0CTn+CS6fCirZFb6 <contact fullname="Sergey Prokhorenko"/>, and <contact
kZ4X8Tj6rhO9S+JhPn4IhhrSN/80l487ae4G+pCNpvlijCHSjMD2rhP9kMSj fullname="LiosK"/>.</t>
GzwgY4af6GDzP0+P/mlx10nGi2AgBl1aPUT5JPpjXN4QlKs8w46zvJjFFX3P <t>As well as all of those in the IETF community and on GitHub to who
p3y+3z3hH+hE4+I6oQO/qap5ebq3N18My04+T7LrIl/MOzTwXp5N0yzBF3sn contributed to the discussions that resulted in this document.</t>
h/TfyUn35GSPUKEzH090FDm8rRfnL0+j98ksr5LoXZGPaHlFEp3TaW7JgwVh <t>This document draws heavily on the OSF DCE specification (Appendix A
01saPfoOw0fnZy+jy3kyotMlNCaU5KXJo2VSpEmZZpNclxpFF5fP35xGvfbx of <xref target="C309" format="default"/>) for UUIDs. <contact
wUmv3+4Oeu0D+UqO92xxvSirqHdyMsDHfzo8PDp9ZKy3excvzwlNT473B+3j fullname="Ted Ts'o"/> provided helpful comments.</t>
0363O3jmvr360L6inYw6p9GfOjRQbZ//6B6jERmwtPKrZHST5dP8+qEVbbnN <t>We are also grateful to the careful reading and bit-twiddling of
lxE9EVU3ib1CsC3kBTqkt5cXNMl1StdOPjtjzEyrFJf4uySzZ+NsbAMU4fM0 <contact fullname="Ralf S. Engelschall"/>, <contact fullname="John
xqobM27cmHIXI2AZaWHjLMokisvo7PJNpxe9Hf6ZbmXwIl3U2TzP6NdyK4Qx Larmouth"/>, and <contact fullname="Paul Thorpe"/>. <contact
oITf3786P+4Neqf2Az57dfHusnfcbQ/W4FZ2O2X0ymj9nev8dg8/MF7hzb03 fullname="Professor Larmouth"/> was also invaluable in achieving
F5dXHfzU4UGWsOsyGQGbvifEji4r2k9cKFDcfcYvbbkNbxhA8ZTOqKQBFoSR coordination with ISO/IEC.</t>
BCx7r2R4+CNbgUb9bu9gLfZgmXQxPzyPeK22eyIwf+neaYjle3X5/Vl73y2e </section>
Jk6K2aLiHbafx2UyFqhgTy/vq4SeGk6T9tsFzVBFrxbZCE/aQf4toUW7EwLU
6/18AnRM/60nQFGv0zvliwRcHrn7I/gD6niZFLfpKCmfTpN6vXDLRGCOQFRT
u/1KVukq9Pb7cifwg312tH98aj/oZ4Pu8eGp/WCfEcs+tR/0s4P+/uDUftDP
DnsHMgd+cJ+dDE7tB/3sqDuQ8fCDu7P9w1P7wT4bnJyc2g/22cn+0an9wMT0
oNt9EjE9OBm0e2voKI3xdTpaOTSL/uf/+L/lZJTN0nNVUpBMkyWM0fzA1U0S
vUghVOTFA53kLU43uQP+0pMjElfKVjTLx8lU0LjU069Ttd6Jsoyn7RIsY90u
aYxv3uUyv6gzilzoc+rpc40NxMtsYxrN/ZhM/PN5FBejEsNh/BSwzOzeL09A
UlzSgFFPYHT8JBgdH/cJRsRW+2sBdfwEQHmqQ7TqbIgt0zovH0ievI/e5EIE
o7dZEu0wK9uN/rPytCQb5WMImsVi2jxuuZw/JPd0x6fgkGuo0XVa3SyGEPz2
qru0Ioi1CYY3dOP3RjEJ0UltA2fRJQ0XR6NpCrkWJ3lOTxH0i3g97b2SgRuw
7reN6KyAMq1nltIyJ4fjeJAwFC+z/G4yjT8l376T0l7dK5JpQuyk3Kvia/9x
m5az5qTcrFFKWBZlSXWXF5/sjjEErlWKoYNYmEAfZYvZENJJXEU36fWNDVcS
+JKIlndDesQsicp0NqcPrhdxERO6JmXnW8E4aHfX86VzBeNwf3IY74+Yiz8N
hMN8Ac74sMebr8HmmQxByDBORoQGdBXTH5NxK/rUzotxUhCzTscOKoS7Bqw0
i14W0zi7frZ+k8913sYuj9rCVx/dZe9gdLK/z4h4eUNcnU5kLd6TJkIoUMSz
NjFiYr40anbNOy/11XY6Ltsxqabuyd5ochAf9ZKD+GBUF9z0FbqZJIrizC/s
pfU7dY9EL/0Klu8Ib/v3l0+6wWVyPQN5y/c+lawVBmv8ffuSFFeITdF303xY
1z/L9cu8lDEb1KXb7h59Hesm+0eHMT/3chqT2DV64v2dkxZZjB72kuCthqRM
66aNEl0HbYv2BK1x8RTv6F7OF9Mp4WJOEiJxBB2rxMg3TF+gOK7Ytaqk8WIK
HZeW0TiTg3Z3Pd2yrY/HR72R0GBe2VNO76r97o+/l/tGuEf7qG3ZbfA72+Aj
q7/KZ7SDO3pl+dwGX138ZDQ+jPsseF7m2cMTD62kR/mv5eMiSgFWng5J7B4H
RNKfFV2yeQrKMXwwOves9MT3EfSkCZf3ePzVPR4PjseHhwwLJVof6MasIxZV
ltxXHbpXU6LTt8m0TfJFewaZrUjzRWl0jy1Y7f5JckSC4HAwOa7TzR/k5VOW
6Pzb0dZbJZvA5a3VxFHO9aKKp3n0PE5+jInxDovE2G64eca687evn3/3JKJR
pCOQL1iv6Ertvb/qEIyGtZWfF4nwt9LfOwxegqSfbzMXfH15+d9+IFhG7/Ky
ui6Sy3+dPrKR9zJpdCWzLm2i93Vq/6x/dHBy3O8yvD788JStLqbpeK8k1ae2
uxX2BZabciLO8xvIT/SFI57egvDI9s6II8YEm1dE1YnsNA6pd/IUnj3ujo56
RyL6PGVzJOpMq3KvbND9Z/RBdGpXLWHzJW/ES8LlYyh3RrIdKRvnGN0oZriR
w69uhNSF5GTAbGC+KG/W7mVCBGBIwlnnOs+vp8mQRGLeGGjuXre/hzvX7xFy
3MUPZbvK27D7Fklb6MnHw+POTTWb1jaPi9b/P+md6I/0DmkIxGvxzgo70noS
8x0vZ5kLMIr+6UlXrNy7bxzLMg9+EmF/O01vobu8y1NSX5Ypn4mxjxxHMokP
j46ZuotRbO0Oxvmo7BCbvM7Hso9ZnC3iKQnREyJXpHnuzRJa43hPxxnv1bZo
n9LiX2OQF8+j1zzAelDrc+G2JvG0TKLt6E9/+lM0uklGzNHOn0TZCAajZDpN
86raGzXlofOcvoGToE36I3EnEr/pSpDyOK/SGeRZpmpQOn/MYdpn0Z2t+qRq
kubKChzBYLXALqf1khZAog+v4OccVb93MOwfMS2+ePny5dHBOsNjaXasTpok
CduU8MMevbF32O916weDsZzpi7f5apozgW8TXhEczkjTvqGzTUePqCMYZZkc
rJcKL/mj04jW1DZzxIf3b94QpMp5PKKvVu/t7u6uk8ZZzLuCSnqdQSAt9xZF
1s7c241fO/dLxIBuGg6NtPMyXxSkj/DU0Q4tYjfyy3hkx2dvzhrHCCW23WM+
/+6B3sgeu0pzfoL3sb83TYcF9CuIDMuEi6VaMVmU8CPlol8QAXv/6nz9CmUN
jTXuE7dpwy8URa/TUZGX+aRas0xSjousM7On5BZl7UW5B4MlOGe5d5dm4/yu
/Dgv8iof5dNyb1a2x9XDfC8+PEzGybDXPujH3fZgfDhoxyf7w3Z/cjA63t8f
H41P+rVdjhYFUUCCw4iuGwQKds+ZFrSSQNjSlvdIirDs8fIjCT8fHxF+xskt
mEvZ2Gg+HWfJXQWn0h6OtnvSP253u3u/m/+21z3q93u1tf/x5iEa54Q/NFmU
3M+JipReKIqjWXoPtWOYXhOfGhMCM+GYkmg7TfST3/Egozj7n//j/yHiU0V/
hqF5no4+0fvEthMx51X4gE0GafW7x2Sq+IGI9ZhYddJEgX67e9LuM5pePH/9
8c355WOXbThjeABn6fT34vR+76jT+12V09J+uxAhl+SJNpQoWmE7G5U10OCB
j/QA0zFsYYcm3H3kXj1/vXyc+4qy78/evHj7ep0tPSEZOl/MRx0l+ySiFzRj
Plu+Ulvv+YvoDVtmPLeFtY7WCZ8COxGYIJ7N51O1jq/xKqiaiAVEb0ejdNrc
Agzo7XY7itWkh9+vbtIyKmu293EyIeW/ZIsle7KIID3qInaeLiESK6maEjVH
Djs6dEyiD/HTPPpEmlUG75hg7M6yOOLnIx5wJnPR4nv9Y8JpIkrTXHlhWrKl
NRsnMMF6U9bmhghmGS5GjIuGrdNiZP3pjFaly7ojcYJQIb1OM17EAg4fukXs
VTybE6fOozdqeSOcmi9YGRGbuVyrGMcgb6hBnW71HW13c+MVW5QAa9Iod95e
vtqNXgTaqB/vZXabFjkzl2jnxfnL3ZZBOoMrxNOe6I9CAqM5zQvgw2q38nDp
A9Ls6DSJzRaEe1gePDj1p/hu814/pSJcaPyCWbJp0dEOnZg/tivbJ7t0cESh
SZnnIlI+hajILnPgtQ62PP8NaaXRMJFtEquZ59AUcAJ0nhV2RaRgAbh0oqvw
18gFZJhXp2NYP0vHYwjNmxvbcGoU+XghHo3P28/j0Sf4vrLxl/9V70RBenIK
v0SWR2oi3dyoOTTYd1Ea4iTsrIavWxhISRyF5PtZQrMTOtzGJe0e+D0ybKW7
Q6898AdFWhKksXs6vFCxozcm0D8Lgj20HlA2IsgP5nqBRm/xHeVidIPNL2M5
NhQH9DCyRzHj6/zHdDqNoz8mQ2Lk9DjNylSBkImnGsHc3iL0GsHeTYwy18vN
32Ykf5vwGkGvW3eT4oqWOa9Yh7MXSEqnNcTEMkFfYWGOIb8nGUEtpi3RVGUK
VVcWREyVZpA3wuGGRKImxH2xHUCOAMVuuCypOnI4aXC3bkCraHmzBBoDv04D
wxFHp0DUD2xbPFy0UbraHKRCp5NHbOrna2MeOjp1nIEcekJUQIgYQWqYZgFt
IMQto8+fNRLhyxeYWXI8TcMnhkKyLJIznA8q4GpyiJl5r7z0//kzokhoSAEL
CGaNYvGsuNlfvhDKPc/huEgqEBNCmfCESk9G6DqRkJ6MZVLg3QLXiD2CYk5B
3NZsTu/R6dD63+QsdQkBD+lLeZMvpmOAGHFeiO9iHpMTKSgAaEfPnB+ftyH0
Q+xpglHbhKhVehsrCZq5X5gEwbmm1HEGs02RxKVJAuERpTq+v9VQFC3cCp53
ekLvPi80Hs9SxEEk7PGcRTvxlJ5cXBO5v8sjQSpCJcLKaUJ7iq8T1j/hsCSK
DjXtuNun6cY1c01LDh9wou+qXTqYMziniOAsplUrcL1sbjA1ZSGM5EwBJNCw
AmWhZeczpvT4npkudhxHtzGpahxlRZdoUeDKlkJwhOYFvp14ep2ztkjTlCNi
qjQI42K5mBMfod3Rvui84QSjh6e53mdwGGZJvS7xCqjIGSgdIdcoFx5IYBkR
VkAwiGZM12g1WQKqSXpTKypzOYxKyCDwhGDIe+StgECRJFLGwncMEzzRp8nj
aJLe07MlSMmO0XFi/Hc3KdE4Pk2gQjwkcJUzWr9irp4vnwNtSx3Ntwomem9K
N48QpiqT6YTkm+mUCRcBhLCpRccCiy9+ZNDfSCgbr4iexGN0yCUJp3or6BLH
QyGk4jEknHOwlDHg1sQAxFjgVJrpm3JUU976JXH3JOB6aohXgwaMIIRiLQHo
DN6G5B72E1xE5aibG3XlWZHCBhqmU1wCSIFmboTL9E6wBqQMzph4NStk7LiT
SydrFOKa+8vJdNBLS/R4QgoTbZVZ2SgvK7ns29GHOQTx4NLj89fgOExplFiN
buLs2omaLJMSfD2QmnLpCHbwZEyTvKYrWWR1tshDYr+CG/KwXK0qBaUw0Avn
JLY9Y0dnwK+b1y8apxO2tUE9RHyIigDT5F5FAQtvUD7eYhFuumBrAQm4oA+k
dM7SShZliBR9Sh4ImSYpcUeWiFrhdZPB6LbJN8w+g4g7rBJXrWqPwSmy8J7J
JQNBRcwq1itXSbbOILqOmTjP8/liGhvVrC2sYyIA79lJzrQzXEfaGp1F6FGi
u7eQCz1bPheWjUVmUVlkC4RPRgOX2YrKERFnJkd0A4R6DB/8pVM6G0H/2NzA
ZW7ZISYTAkZVo/mjnI01bGv37pKMGBqsgSEcRSmiq+zCCkCjsUNYRURgiukU
iVZkKolMEBvCZE8AqkSdl+xxTu5jq0a8brDO23i6gIULJCWAnyKPu6GyHblT
uhlcVNCEUhhZHF3nOTifJ30txje+6U7l6LUPjJY275LxaAJ0IGO0SJUbERyS
ogIjFvpKnCUt2GcBpxFBgCDJvtxT4NrmRq8TvSE5EtfXRSDU12ESKz69HUQ7
nlfRJJ8/w2BxO/jyZVcQdE6b9ghJUnByD+Ue9Bb0jW2ijJ+QAU0kICon0DUq
gaFpXpA2ZpS0fSDRaAq5kM4KAc+6wZTtNYLiNJkqMwsnS8A9mhQmrZr1GTyO
zoqtGrY+w3ihyyIQ4Byz5JoPKbRcA3nZvphn6g+PnKpQOnFAVkab3XneRsSU
UAPwdbq7JAKT7qVIOCa2E4vNmM8EK+h1u+0sznJl698R4c/xWpTMc9q+Kfp8
Lr3V59LDueBsScibzVkIW2Tef4/lgEqmI9oqAFQksMWBZMaj0QJMiC0KbLp3
gqLG56gIxvjBg0HMVlM7Cby6EdZfIewCunvE/HmwhqjHiAdsFi7CN3+UtEQl
EaWn4pj4YcJLATrTa3oebPDjUKDhQ5W0hw9t/BuJrJHSJba1vCOKG48eeNs+
GEnjPtOyBALijUTIpu379dk5CaNjNlKaYSUSwZJoEYlOqnvalYl6jEQvVV0L
Xk/qRCdmlYPUKVzbclFMYOChfTEyJm6JHIs3MfO6qMi3CdFFYBF84HwR8F2o
a8VDUCO+vMqdCA0hUc+YhMAdBYJI+Fq06NZWQmvpGzfaOCE6MiV9PTobj1Ph
lVMSHk2IoF3dsiFjEt2mRbWgFbmZWGiG74d+K8BZoxoYA+tWyoo+tH9CAWcA
G9uZsdxhQYmmBJqlg9dnyq4hvqOH9OttPoU2Rjx2zIeWTyal09YIwKI2Ol0X
YiYP9iDSBMmTNSklkyvtBGlGQjbPaMQk2wbYQVxbamm7CVc3TsdM1MBMCNEW
pO0SZlR3UAIrJkB8Qdhf04yVizW3JYqU3oEu4hm+CA9O/CX5rxV5vQnCqUjv
4NVOPuLVvVjw/vlcaaREgqHAZeRmtMTocEdMuCFBOGofworYG9sWi+va53RH
iOQWKs2UWFYl0j0dlIp2OQFwxhG6GjoBLk+Q4fg9ZlSYbdzy7niVoRvCoOYw
xDX5SK1wN7BxTIX6sHiBe9Q4NNI0bkX5jOYxUke6/yV6SIiC8WrZpURflTCP
2aLBtkh/v6kYRCZ+OtvMH28gMxKJBWHi95u2GtYgaPUQ5/FE7zAUY5vrY7kg
pmv5YD5X4jKsOxEK5XC8ElUiHeS6umlBO6PzeCCqQIKCxLYqCQeM9ywgtiUw
ZoYRIQms5RmIPh9+InxiRGRBCCI/sOfzQ1pQ+tRbTFDPxlOnuc3AX9vBZPDV
1EIfmQ/Q8yqrfD5lIzh98Nstpu6jauuL3isEsdClIh5y1glCR/i7IJJXHnHR
oPy1i5Ra9eUr/4UPr5TXXJikfB2ELfL3HHcoX7k4QP4ijOeT7991XLicn9Qt
tuPC0WReCxPTsTmIi78JgrF0SfSuC3XiRyy0Sb5/3/FBRDJ2AEQXtcLfSPSJ
fGlBHfzFn+zTtx0fWcHfWISEfO3CE2Qdbg0vO97Lv7lxlnE4m0bwC90vl8ip
s1gr0/aiD3E9oiPh7a4bxdQ2wT6XUqxM8bxyerZ+JExKp+Yp+Pq+WhTgF606
k1EzRcy3jhVYYuqgHDcIgwzGi01wwrbgD/Sy9Qpts0YHTo0bpiWsCnGWgF4l
Bd2UuKSPSXuHTYodA8FFJ4GZCI23Msrup0nMM8BfkanlYh3DekGy5wKilQjb
dc2ApSQVP4NJzbjEwlFJe/qURFu45h9v0o90ch91gC3TDU3rH4LpaXjMmMUM
Njxnpp8w2Vd7CFNSdj0Q7b1NWWff0rVgxi1RklKlJCPvnuSH9luqzwgp4p8P
vJyIEZfkjSEMJmYuLw3azBWJUU3bJKyRMEgHlEEuMxmoyJAvx6pwPoTxWvQ2
Ikll5UJiEA4AWrvuGNQkA5xwqBxglhNim0sUKQzu8CJw0LKtVpX9a+aRdHhz
URvLurzacvY1Z6yEHU2S7UR9ghQnUBQcEdR+HJZloE7osYrtltfXgLsxSMyx
B/PJPa015e81hBlK7nW2NCdbPiuA5JYTgFT0S6fTBRvQEj43swao5knQmCvX
r3FmNYVfwcGoKSeftyv/2xe1nr0PxbYfYhLsAOPP26E493Gqn38xFxZJJjCR
0HXZev3h8mqrJf9Gb97yz+9f/rcPF+9fvsDPl9+f/fCD+2FDn7j8/u2HH174
n/ybRPJfv3zzQl6mT6PaRxtbr8/+ZUvOb+vtu6uLt2/Oftha9iZAbJQryoIu
yTACrI2a2vn8/N3/9//2BkQg/xNRyH6vd0IUUn457h2RWkgXN1Gjaw5Xk/wK
wXQj5sh19jWR3D2K5ymdb8lKYHkD7yJM452NjX/43wGZ/+M0+q/D0bw3+Ef9
ABuufWgwq33IMFv+ZOllAeKKj1ZM46BZ+7wB6fp6z/6l9rvBPfjwv/4OaY1R
u3f8u3/cUNQ647z2VG/Q523YwLKHWemwyMuNce1RNli7uIDgWE9VrILpJKt+
u9UbQKAS3WJ1un0QwSsP3va++mj0B1OM3Uv9p7/Udy/tP/2lfffS4OkvDdxL
B09/6cC9dPj0lw7dS0dPf+nIvXT89JeORXT+8P6NvrMijI8Fr+dvXuGJswWL
qoQrCDVYlO038aKIXrH/YnPj/PLd+zff4bnz4mFe1aO8hSm8K5PFOG+vCRhi
V8LZOUZ4nYzTODpjI190nsNONOWvL5/z1yTTRJdE1pkCEwV6nrKE+OL560t8
/8KUutekAF2Lb/hSbe/i/8NTtYzll1NiAwUrPpwMzb/mGQQxSyMienORiRXu
4uqDjBBmQl4lU/YNLzJTaAmk6iF5cSDbKktQ/BfpNTgPowfRGHwV5qifGTvV
79u9tU9EPTG5zHTksYwM/99hl51uNka/P1g/Sn/lKOy9o6Ho1fpQB4c/e6iD
w9pQB73+zx2KXq0Ntb9+oH195vcvH3kmUlkji37/8vz87PdequFLcsWIee6c
EGN/yaIrkjjYPSO0cakmgtLoc3aLkUBA9HlkP38BkSXeT1pBmhWTERNsKd7S
Gzyi2bajsxd0VzljebsvQbTR5WLIouJrUte9aL/N6Q7NFy7VmvUHsa5DuPqD
mJ73bJjzfLqYZXi/t/z+d/CGElOWnUSxBXqwzfOg08NrfbxGgOc7hdtyLeRn
mOJAGxoIPT/A8y9IkZnGBFJm+Fk63ZvF984nXSamGkwgC3AsFSrROLs5xjnA
OK/S++i2t3d7SNpGZuIguJyX+vDsYQDw/UcBDvEN7zKotfrGAw0xkGWrsBN6
4+l8STYleLgwaFhdtnuHDM/X0EdHaeWStfmpeC5PLeYQqiZpQTNyrmQmqZ63
+3u3BxjjiDcpemfEdVrYGeqnujVA08OHBpErZ1OhCfGL1oEQ5hG9vI/ZXE6v
8K4EZy2hn89Riw9gdRe+kAEBRNUznMDhvp3kooRu+aDLhrQxjMUe5aj0h1IW
eXAQHEX/0aO4epjnmGdwjPd4c5cvz19cvHcYyqVFmp/28Tkj5dt3l/WnGWUu
3jQf5otz8fLyO4fv9OGhYMMt3AG9wzb0W2hGb2Dlss0MTvjKjMcRMa19AEtv
V3TFdkla9r4+ofbzZec6dnjAx/zyfg7Q0wFdeW3XzgpuARhTi8D2Ri+e2JEL
v+XcC14i+9OeldFsBNMlVk9odUYidjamp7e5OASdPN/OB9ILYkOSLYnUUcMm
Cd9bIKL2Hb04cGhdR6fSskWvcH/+oBoXvcDgvYRSh6n0JR60vkWC51GAHL1H
keONuwtb8LRLdOwWwLTlohS34GkvHu44pma7t89Q1ouN0z/1ZIreW8jJqGXH
WyKwh325/W8Yn4qkXej7z9kqTWQB/thoK4Z7J+c4LefF4gINoyqpSkBvn9Hq
HL5rQu7qlJFcj6bI71OEFAkR88dMo40WU4cs+4rFVzXc3j8JQNd9nKe8v6L/
7VWg3KskGQ/hhKJxuiFeSDkdpWkw5ZSs9ak7lgtRQIsT3Z0X17cbkXjEDezH
ix9/hHpCD+779XZPHl3vDxwKolcI4GRW4M5HKimwYMohhExDt3v9/eDI7LyZ
pPwnfNtf8S39CkE0NJfodaUX+L68LApOuDUs5msjWBxgPR7ni3kxg3FKAvDY
zjZiX5baycR56M1UgF//OADL8aNgwa2vlET29u0TsQlGh/3+QbQTI1xkF98f
4a/jGoM/hbYekbIO7s2qLT0yaDyCk5yzWyu8EHSmtz3GHGK89NZh4633LOrY
sKkzwEUDbLEbso2tCUngVXuax4iBL6DA3nKBqQXk7i0+3P0+k19xe7O4+A7o
QHgkOXRYQsBWukePwI1PEXE3bBy6Vnpf3SXxJ0aM7onQfd7AIvOuvq19FkW3
3OkfORSnt44DProlcXEcmSe++62o/Y/RVvABh8gkk3gxpQGLZCpePYCVD6qr
vCcpiOmQXMQEgXBNrk6X6ZgUA9M5y2D3h1/Z/Wts3Bgd6WCV7JsvxBXggEWI
VUdMcgh9StrJbH4Ti1yuUZZBFTAMwCioBNHox7kEgUTQLvEMo5eXDQVe9P1h
B4y4Gx7iwVe2ca7xZw4+tMzwZ3EYasQXa4c/AMrRm3TqzNi8jE60fcIk9QyR
t6S/MUoRN0/uK+/rVkVELPQizG2fMN6/RrSfqtt7FgIw4lCrKDCwaxbHgYTO
02JAAwhwJ3ya5ymEgktOiOJkrris5zvJIh10HtMaAgRGJHyshsXt436L/joW
69v2CZ/XO5T/WvgwZ1gzi6isHqYJh3fitVBGZJs33zwIGUTLFFwDaFw8Ch/l
STfaYe/A9vHhrnEEAJywJkQthA4chT4/OriDzpHCyBk+aMBesKv3xIBN3CEN
raITfZ0TQwLnjXbsAHfFP+G+gX0cWzwX0gLQ941qxrNher2AT4VPXU37YtVB
1BHiM4yfbx+fOAlIzobjGIjBVYJnPK3S+Cp3YTIKn+3jg1Cmn7EWx54rrV4E
bzgcxCwJvH8j9nTvawn9GtvHcohi74ZLDEFGTNn4UZ06MQFNn6fDwMPY6USX
IWraA07WobBEjaPuk3cbqAIWGhKXVlEf0+wkGIGjwPauOTeEZdLbUrzATkjl
sRyWP6aqefF8LDJdg3Nviz6L092Cyfq6kEhCriwUyGRegRJl6wrxmIjccVRX
c1txMARNjcdk0Ui/2D5Sgm0SCZTWuumhJCpzeFIXXFlnDuy0LqZ9WzQ53Blx
qchYNZPu9uFBcCOAJxLqiXw9WtC+Q9FzsVYR8jcAxKpdkFy0fXjsXuL6Sm+W
1b6mPrgt2jzckkEsgRL2mjP14sWbi6vLaKKSJosA+V12jcicyOz3eMGb2SXo
ZQH+q8HRLslnW7R/zNtRRHazt1gqMup1dNx4sGmQODrxD8jce7yceIyMUnHj
bB/zATvWADIywNbEbzlzxMdf8l6Axo+puQFtnY0PPnKoP10utgi64UASbuLe
x1lKhFt0PmeJIH625/geTAd6QyvVQA9DamN8WTMxsrYRY4nesOB2icPBoSNA
T4WsRtwrzxcUId1WZdhUzOetkPtlKrwchFg7XkhcUCLyASMwX+WGz3JblH9P
40UMP0dFA+ZFyPjjQM07dppsiz7Ngo6r69jA/vfOdxlt9w/VhAWr5/LGRIFV
7ZzJFWLIQejEwa2Oai8Rg5DVxPrBvihVCfFxmHyAhypGqk/yRY5ydWZOfOAT
+B4W8O3DXmCICNdGELisOBPEYd0gtCMs5kiBunlAdNS9Cs9OvuaoO2J0LnJp
2wxcyG+JLkWwPQdSeKPBYT9A6sfUc7lRABELgJdzVJKgA0r43LZVESHytvUU
EMQlJ4FsBSof80g92Cay9BgP34ot4t0UumuYs8qIziewLZqIcfiPxOElNBRP
LNjEI3IBZtnuKzu5hl25zw/uq7GNSa5olEw9vXWuVr73ikToKbvx89UcS1RW
knqwfbkSnqayLkfQ0HKf9DQf2PMFqdX8bA069FSkjwmlhJjxANtSQF8hMRvl
3e4fBTdzy8dbbKkgEKcm2piAcCzouC267qu6JAG5zhRcL++R9ncQbYuNAbr4
qRMbBx2STk3ge4UXW4IdMqfKG1v0stwlCdZXIZ/3Xwtf/j65hwcGEsU+L+95
Ac3meZpBl2MfmEXtSqbuXR6BdoBPiz2QT5KFBGUwWIbXYwUD+RfakdghgdE0
9B1ipGunoXEpLtJkwCReXydxWcyVoGoS2FN7mV5Exmcoxm6LJRPz/RAPE47j
i7bW0cetCNIku+pYHi1gL+OcHZYst83UySfPiXP+ed71FmLJLT1Q7PJpeEtv
6JbSyQz4WptmaZapg5BoPG6Yep0U194Ax6qXvKeF0dvEf+aQwNpE6aWUglwQ
0oc6s7FnpaeBxKLldvVSHJrhc9Vz/d7AnjtW0/Lq53Cx5DmpvLvqOZQ15vrP
PKT7bcBnpQ4//x6RAmj7ZqPv1YVNIlGGbHwgLwCVqFub+apIZ0hrGCNUAqei
REFvhCZy+edRBoLo6rBMK5HUuC5EhCiV21hCAhkl4yo+jZ7H47oQyAWLD7rR
f/8p2j8kqG0PwsdVoHn94sBm4KQNUUNQH4PfGxwdEk+Jds4QxfWKxTUbAHSV
K2FIVM5HiEbY+UfYdnd28Xpv/4BuTn83nNeMqSNQcEnhrfDs4eEhvCm98FlM
8fzsRfQWyrYEUvCjMJxtn4RPXmTalyB6FyMO9wY1j5RBePK1z4s6Jop7EL68
uhoaCPo7d8mwFLw86B8TuWouctDp0eA1kqDp6rwmtkrg7ZMD2I6WXq/TEq++
CWk7xquDkyPa81HtzQY13y/Ge1NT0ohymp+DY87nyQjDHBwcdknybS7AMVcL
/wNCchjcjOhGuwxc/KwSmj4mC4N9sVtDxbqFyZIkOOVD8kgQU+S2LbYKdinX
5mGY7R8MML7YguVOHdAMnX7HOSU40VXtfexFZVaxRYCUICmVstWo6cZgvuq2
Qg++T6ZpoMYcsu9UZAr/lkF9jPYRC05pDnKlraqzJCc8Iot3WM+EIbYm98vM
dAsJa+T0Y40WhRkmLvZurQ6IRqW7YZ6zBWSccnhzPZK8Fl7nwisHP//V/Z//
6oF7lV1yRH3WSf/uUrRCpuBeFe3rqS+fDCQ0kE/hlZhcPm8LZ3KhWaE9BmUv
DtUAEWROs6GcDvo3NUsL4yrTtOzPWqvfWyVVFNvc4KdqoXj4GpU3ffDrOJFw
RVj2EJTqEtY6kSQmjMUmbzn7zh4hmRwC+aZuU1ZxgZIQUVcyqTNOrOv1jzRE
VxDtCW9I9O2FLDweluY7S+6hJNKsYRYJKtQGfC2yelqNugqeVuISIfGdEwdF
LkWhEOQ8aKixVuQoK+R6B1FHoCvioN9xRU6Wic6uJInHt77gAWzQXtyUYx8j
IXv4EKQ2sK1IFUk6taDklbxF436f3yWaiKJ1KrTcyii+TWJNaXWlR56VXJaH
7fIWpYKM62m0c/729a4WaHElE+pGZiadpeziOy0AAew1zLCY/BS5fkGxMMTB
s/+3tMoSRMDmiXt4OZJWYPT67F8k6ltPU+JvFWxI24nY3cYxJVjLH7G+lNOM
g+oeSNUqnVYdZiHB1v0QXXOiNaO0FMWg+1KfdCiC7NZNct9GVa5xXN5saUE1
Oz61ZmitAbMDbG5wKwo2KS7m8JOxnfMuKUacEjWdkyyk+cs0ejwmQMzgO7Fs
3NJZe3kZnKFNAKcFJOXezcOcdux2zjGcIhe7/Oo5F2UXogSc+/zZvvtY14w1
J1PiRGGDDC3JViTA15FriI4437lZeBVcPtx0B8LmruRFQCTWuf4v+kN3OZvI
eXMpw99GA4LDWyYLW+0tq3DIf/q/6DeH9s3mhnvmt9H3L//04uI7/Wdzg/66
uJJ1/W/3+902tEV9BJ/J13vR1tkW/n7Of5/z3y/475f896st2Sw2/SavEhfJ
JAgwRDnI8MhRtUSiiARpgCst/tWhTotrd7ARRb+VwHQH45bXIDv7DPCzzLkk
GdySwMoXEJcDCZqNQ3XlASRvhlWG1OKtOZuy5PEuGSUkgcqd7ObG5Lg3Hkzi
pH1EaN3u9cbddnx0eEB6XtwdnfSSw+Hk0J4lrW+7OZiYq3/7zIQt+SZkPs8c
A+VwFG8QWLUySSv2txoB6UJKduxx+V0e321FH7JSqu1Y3Jp7UD/QJ6UaDygv
LO3uIfrFHmim5EuxoQBWPfzp8h/8gP+68lmPP7Bf5C95zj3b7f73zQ33Dn8v
H+tz+jx/bK/xszK4vrN8FB4czaNQwOErOQN5db9/ctztHu0fHJ4cHxwfHvZP
+icHpACeHB0f9HoH3cPeUf8E9r3mTAE8m1MtHQI/tCNIKAmcSjTFfbMbLmhR
ZKfQFE9/Hi7qCS4tiU7Zb10KRMEwLgXAWKS+06LIcvCqJCjW/kYcKM7vhlcl
WxkYktAdJ8R4J4Q7C8hFWjrDLK7yTbwo2c2CuBurF8gBN44Sc7qMz/pGYxer
OfQV++xlbvepkZrTCmqUSVrxItPUaimRShcNayEBwGQO1J64S4l65dJUypWs
EVEgZKOtyNdYESbXghg2tcpmQVnTkvUYV2RL91zWROlQsLScXzPs8QIIkKTh
80igItPkGhUAPn/WUp4gGvVsI83nBtppWnE4ny+9JcObHty954qlnz+zQmg3
f3vbPcAmTVILVKz/yCKfI24m7JvFVAV1CcRTV3LAorl0EEuULSlH4HJyXJgp
eIkgqikQjr+PkzlnP+byWZlUkmStE4TP19YlpbKAHC0kjEnZKHY2+2IRLFnB
zgFJjtOH5d3fRHeQUbgwCYeNaTGTCDuVUhkGWtaRtThSHS4qgZWilPN3OAiX
VSl1/FZr++bxjY5rgORL4g6NL1rpVAb2/enTtZWgLktSaN3AqRgktu5hEBiz
PwvIs0Wy/rOqPaK7vyXRmDzZT9HrctiN+J+e/NOXf/bpH8OWn14ERvNf4M9P
mJj+YGL6c0//3PPn9k+vfSQPvlfjTCui2xHBVcvm7NrhaE1AXGPaqguocQJK
lk4XnIPccRP3Ijd/feLj9knrrP08+ik87lpFh0YRzW/csU6Mf7q1ic/bL5o7
9uUbz7WQJ6d9roTB2oWsmLhXm/hl+1V9YiZckwWXYQpE8hqQnYfXAXkW3xuQ
3cTga4LLxtAkjkaj5oWbXfhCFbyTFitNmaipWt3DxdlrSifpMBrtyTUORdQx
dRT8yhfu4Fxm/RSJuNMHK/SYSS41V+yxHFVRm007hHnUlzBrnn1LbvLhgEFz
eFBTWnb4OzEp9ILbviumuCHTOaxE3DBdTisM0azIEQ3epOFnVj4chU9AU2H/
wABCkaYaxRXf5qlkpCsDkiQGrMkxgtC3BUYgvztGcOXNOUbRUkeHl2jaoEHV
SLQRCAyOEQXE5T4OeiGEdkNa13e0jvnEJDQmWbBPqpzWLmUPPO6Rm/kE6qbb
+yn6Zclbg7qt/Ed/+pCxDv0L/Xl04p6bGD/heH0Fp2Y6+7cSvNUT95o7Buxr
VAb1Pp1ZU89br3xCKMcBLe/eXl78Sct/ftvEfsf7uuPMx0cbbq/fqkjBCxg1
YLvVxPPOyol7a854oBNLfCBC04toLhmJ7iOrr/iUNXUen9jv+OAv3LGYnMM9
r5546YwP+YytdNsvgWKPTux3fMTXKb2PXnJoyV+K0tES61x3j4+bWD0iNcmi
I81m/U3TPzqx3/FJc+Ilpv1k8eTRiZtn3Ov+dSd2O+71fu2J19zj3hLl+nUn
9jve/ytNvHTGg7/uxH7HB7/GxE4S7dck0Zos4eSNwHa27C0QoTUwbd5aqL2O
Zdk0zveodmnR43gRmxuSA/bamwfLUORBM4KRBm9roHNoq28YTUlc6t4Pop3u
EKa2Xal0hnfeLA2vS6wPHxTlneSLoPzc43OGsDvd3OjeH2MJMPbttmhBJ/pb
j387k9968t1z/a236w1nZjxs818D/HVsv9qflU+dPOmpsyc99Xz5qXv90+a/
XuOvN/ar/QnseAF20cmb/mwpiarxhMXQYW8be/u8KDhFgtrlzvbs1J/A9uVt
BOY684XZysWwXT3MUUZNMUqSkxAHnZYz86IVifUi4sKbS96X1auQRjZuhrDC
vdbiVrebjlL3vNXE8+167snnbbk7YobKI64Oicj0UZ5NFlJ5latIstLju0dZ
xKt6sNk2jlZnCpEgiUDsUzKr7D7cduhSYjsvu9LUwVYPro1rVa1qnji+Q7oU
zlNj6yq7uWQIwMg7BZxZckmnyjP19LpC2GESSo/ApTVV1Zvlyn2KT7YpAE0S
VFaWao1Sp8EnQqKKd837uL7mQLTz4ep8V+DDWXFS+L3bRolpVxyWDYC3Maph
cg3ubveU/+90uy2Q+LejKodK2Ts47kc7XEcq5qIYmxteZCwSDoxUp/n5DVcK
juFnRkX2WJ3cFsyIqC3ZI9u7Glkyoh+7UvBWZPkmmc5FW97ccOHfGlooBkUp
wMqOaLbD8bBgCqTlmilG9GIuyAD7t+C9RrBb8oFzdgaFWmsGxCxyTQK4Iolm
KrRorQu2RFhoo8th4ALjTo2wVg9s21OjzCIL8xWcoXyRWWlKEJGaW0isUo0/
vRWf9Vd8ts/v9+i7fdJ8DkgXOCLp+ORbPtvc+C/tv/A/FTPW/OHCb8SOvyIw
/MKr4FmRLhHOEuHKRk6c15J01ze/7CqIbPuV+MjyYBXBH0bOXxkWK/4sT/ur
nMhKLt1TExiuxvO0Um4knJoeveXI+d8+68onhj6nKLoiHpy4Qbf3+84Yhiur
tJbDjNj/bUSXqzK/HY2IxSRlpPZCM5bt96IdZSLd9r5QOkMiN7c0ZkLw1s+d
kNZqMw6O3IyD9oHMSPjpJhtYOCQzGSFgcVl3NNeNiF9aZuQk0ZQkwWint7ti
DUsmQjUh+j3jUvA6LOuV6TN7+LSo82oOao+7sIJvAc2BB83hvgPNYftIQRN7
0PQFNDXn0BJoao62EDS97orZa1ZltR3zvO4Gu9l7anxVUFgh4DoDXDXFodvg
0Ynb4HH7RDaIO8lzDI4FaHA2SEu3ZnnjFYMfe1RG8J2N3uu2e4pbr1xzinoo
P1diJhmD2HKcTsGgpBsBfc1fsY8LiZuCHK7HCbea04qKGQ0bSyH0q3MOVZF2
XqU8PEaBZ3j4LB+MuSuvlpNkIbXyykjT1Gi3Vs0dXlhDJnQMEgknqIbNIiZt
QBJvsVQpJM+uchQXNfEs+pEdGKgCnoiUdzF5RMrQEByUqPb9mWpPbG7sJJ3r
TkuDHf1GuB7sHLE8KDc1mfh+eLUuQDBexRnOvmIXxaJILDcvbKPiLZYivfqC
/lYT5gajiMo5lULeInr5zWFBtHY+vmwFwrKfRNy3kllPZ6HQmSPvFHkpMng+
WfU6AY+jEuEbRo23f5FakdonJBn/xnfdgvdY05C8X8Ykqwi+YBCg9r8uuGVE
3X4buFIvSVmh/cMzs1oEjPRwhsko5mLgQa+QYixVgvlMkfkydsXXrYj9bst8
46v2GyyZzk8cNqZAWZOafBiEfMdBvuNYzkhqhZMkrJokwg7S+uHw/I7V2NL8
2diRaA+7+hpJZ8tHaVxTe6xvj8GKEUxPruJ2jatwY+k4hUbI7Uc9f3H1OaF7
BW5xPyLfw2Qn7SR0NrlWvGIqk04SubgTlHyXm4Sw6BSEkEPgQ0RRoFeB4uoS
I6aa72K9M4XuWYMpF0oyi+/T2WLG8cMaTGd5doBP2F9IiSboHidKgZoSUEea
I6XXHocqPxXxPB0zRK64NwnvQY/LZd0N/XJ91edGy7KOBRWWqo07tcU0ELxQ
WinPdfE+b7NaqxoXwOqHC4r+wh3s2AErxooB0OM6q4bLchnIaVHxU30wHiI6
/m8Ib5JvUqZqy5GGUap3ixAVtp6oVsmQrajATWyzRDPQjpSPbDmYw6uRnd5B
Z6DCoZvO1cARDmndrGgVabFqeWKo/PYFRmdZ2EuNi3gFrcQCGVlvD0dXc/Fp
GnKCGhi14n74UbdSg57vzWVyiifITZNJ30wm/abJpO/YBWSEmldS2N7nz+f7
3RN35uf7PfXHWwASmzCaFrTS2oR9YzB6c+H7tvD95sL3ffvKRksOmVjyJbkC
2RYoqXYaGRfxnUTbihygEp0Yt1oSLRjWLfOhNPTZRzYqfbTO0BrPrVYEyZmx
9kmYywpZDx98x1OgKXyqHJqKdMgvtDE4G7lQPSxvHCKfhRUM5WLuyBqk0gUC
XbldJ02Q1dkK95kCLUKYLr9KxHeCwKgh+l56+WnkMh2Zlj9WMK3VEOolmNC6
VUJ2wliZWELpLSC4W2xLyvE3EzWsPRqgITuUcneZM1FJb7VKorNde9ow1kTM
kJ0gscfQgwsAWAEGSUNj27+ad6Wxwa3G2H1FmVPUb+gxfNETn5zGGM3qwmIo
pW6l/BB3GQrM14LOH/VNRZ6w77HWvClR4FZ7zIRn+qwMjkqDIZ1ttok9y9M/
hsetaOtMwmBzHWRLu6WAFDrviKR4BYKjVbSepsnCgj5v9zui6UjXy2B/udyA
dWUDhOVoMtjfl4XOFx75te1BwSpWztm00OGh0Ij3a1joVsDir26t/NutYqWF
bv+bLHR2ks4+ItlygzrhVNcNdzROER4ME8ZaXww6FE3q0g6ed3YlYWzJ2JPx
zlrLXmBn6/4adrZeL9rZ/2Y7m6K2WdmYXK2AV93VtVp2xcyBdNjzop4ZKrky
QCrd/HzSlh3c1yD778ZUp7cmQEREmB/2VwF2NUjUaa/r5LhVhg5jrEdXPoP2
OvE8nE2XMPg5KBzYC0OT3jEsequk1oFJrYOm1Dp4itRaFYvpQzswwtTtLlo6
raPRGI2sCajFTtkIhaZQ2zBv4OaGyVoTTRrxspVPhbXWovIJJJ+muCWRF7+U
vCWjLQtcvGGvWXEg8NL+oYqNbnJtT7qk5opmxZn3ru+lbwYlNnOAXF78GLd0
iI9D0Rf0txGyxc0kj/5u3qyYhXJ5LbYlhFFaay3Iul/qtKBXXG4N/f049YQb
jfvDqzVmW6We/z2JTHZOvz6DDlaxctKmyGR48wuv4hGRyeHmXxMWf8NVOJEp
Hf/2WUiinjWCkb5FiLKzfZIQJdESqmMFrKlm2Vnqi7p0X/9WElOv2412Bt8s
MRlmf01kWgGdBmBWx2o04fFvVMgxRP91pZyfBbHHBJaVdrYDk1gOmhLLwb9J
O9vBU+xsEsn/+TNKfnHFr59va/tfwNT2uG7XNK8J7P4yu5xztPpwyv3+Vyzq
NpTMr1nMjFBpCV8hewD+zVr7pI07L5SrbN5zSy2JUVhtCDz4d2UIvGJDoNbM
cP01faCeJDRLv2tCves4S3+0dHhn75vnKCME55a4WOSop+mwoNESKcmhbvjA
81XQ4AnK6i2yMp4klmMeeiLSypbGYLLm9E70DzKChHaZ245pmFWdpXGz5C7h
0oBacbdkjadcMYLzH5o7SakTEME8aXomdjluj6VFSh0JGRmOrXiIa4yZ3iYh
1un7VrgQy11aUhjLq9PGVjjW5jGk4yp+innrbLWuAPLXrLUng78v1YMLQf+V
rbWr52yoHq5C9S+8ikdUD57yb26t/eutYqW19uCbFA13lH8Tc23A3x+NxvzV
NZBetHPwzRqIYfjf0mjrzu/nAPjfqEpjF+hXU2lQV+1TOp/bk/1HMTic1MuQ
PkEXAzurm9XY0mKLh18fmiFzlj3wx6wSyNAiJYYyp6owEt/xF6pah6ZqHX4x
dcbdn0NJYGHYtYMKN/a9iQA94+Q9HHbhko61ZzdaXY3RoFViMFEkg3OvUGjx
HrKw5V1pSWOOJ54X6YzQaPoQenS5+Mp9ZdEwOrmmkdCglyvCWNPsNp/eugo/
+o56ixcaGXJ7ZFtARSENylEJ2IWwlnMURbRj9c3LpFA4R8PetRALLjom80Xf
Yb5APKDM3nIdZKwfBoefmPJVhp3RoDbJ8ZdVXph0OON6lOj91yQgrI9oCSCR
upezjFSRqpmCXJpkL1AHcJ6bG+6rw5b6LpQxrK6o49dKr+LRlt5Hr0HWyfQO
l3Azk/Pu8uPusm1u9Op335ULam5xXcChL+TPw8jIdJcs+tEoZ1q4BdXhsW7g
+rg+GAHJXBrHuiJelcHOtUdJyDescDFwv4luLOi5UYur6VcICighnWl5aWGs
1jC5iW9TJPRKwTy3tWhtgETwttS3Vi1CZHxI3Zj782eL1mrWlPT5s2iZSSjd
Mk3dNl2vLnh7qBmIMs7fjRDfTD369UTGn5UUFQiz/5EU9UuvouY/sAtQ9x0c
fnuKVE2kXyLY/5EitVIN6HWjncOflyJl4urjGVLLyWr/kSL1bzhF6o9cUjoQ
gUgmnJfa5OAxodCRc9YL9E5sbkBEevvu6uLtm7MfLG+J5aJA2V75qmCSSi2K
Syw9mWGdzcLo7YgVLgutK3X6FZKsyJcBfqLCq4p3KPq+jL56r1nYZ3l8spha
xwXRhbh0qai/Llm8LtYor2+qKEemohwtqyhHYao5Z9qb8qHylRbODCyr2N8d
ohkeNjfc/KpUoZ+Uxp83ShgJgMp8UYwk1S2I0wgauJZ2nHRYGWeI9aJ/pp33
To66kgNHsJtH+jBM8qjjB1VD1RAR/oC6pFI67SlCt4d8/uBrRQOQo1JcR0tK
WOQkdvvwMHRXHa1xV1nzerbt8/5D1Khtc30BumOPJtCyDfO8wnwkNKClm/cP
aOzJKi+KvBB6IC02piE9HwUZJPANielZyQB3dXvEa9mI5lklc3NgEpbrdvHn
PEXeoq4uDstw+GouzkqzGEpMQMuVn5LeJA4zV+tUpmDi3rXYi2B1FV0DbFKC
ar2gnO8lODbOBeqhXmvm6A+XEAlbEAddubkYIzQ0406c6MSpUbtBxclg2o/a
oLkkJPQdVwn1+o1ZUf+USMQUPQ8S2DT0xacP2wOW9zH2Po39PnBMP44W+BZ5
TB4jWWwSbb9x5GYmCN0pR7W01kYHL1JkJpsbFpv+96W8oJ/gx6r8OCt/bVH5
p69Muir4KYyP+ivEi/OUw3Xf/jqw+BuuYqUH4uib1BV/kqEoFzQ+WVg9eM95
P/gWlutZVcxOByEq7qlVTTD+dn4HxIof/azIJw0NMwJdtzExNfxGNqhW7D0U
JPMN3bXlc/k03hNCfA0Z//ejxcgdWu+D+EVBTmgeQF044hNB/s3w/mZfwbEJ
4sfLgvixT56mPbx/dR46DAIbICz+RcosdgoGfkuXOy/alnvJIeDc2MSKo3Gx
BhUOuVReqkq1unZcKTRbiaTABsWdgY2GGWJdrGOGhdjU76eJ5MfPyvAQWQFD
yntNUnDr96EWmsYdl+ViloydOZS3Y72rOEZFUdZM59JcoV56uSYLmwBJwiD3
Y+qhw6y4VtXhEgagu4Vp4d4rrrk9opdxmzSCw3X91UAlV5JQI1Yt5J5gJZ4X
CbXqq65pa4e9f2WooJRlCFpfkIRbLVTGSjNNANDFiIFZin7laCBwKlLUP0TL
6QV3/BRqDHAjSZQq1jUFFmxzUYe9DoL65XdaqyBAkeUKeesWACVNxgraS+1N
Y7rh2AXppVWRqguId4nFpNlNyt6KG1cXPKj9SDvm4oEftM+W4I0FzbToMAjI
FjJTgrC5m4cWhKuCdZhOBdVwCcqx60AfdmPHAO6ILKDq7ymKRoD0Vw7gXzlp
U4bVh/6KAfw64984gP+vt4qVMuzxN8mwdpI/N1w/LlfkEJGCLGEzafW3is1H
Ndlo5/ibJVRD2p8Rm78WFAyHfzfSo6HvrxbD8q1weorU51q3fN62ni1aM9O+
sHIZGuvreitZ4R8fWFBpuTASGeC+15ug0PwxKfKAvdQrAdf/8pWAm/fUrfZV
0BruzG9CLMGKXWqZRr2SfDZbZFJ3icNSfW9R380rGIC7sDqphTfqK1epgBpp
q6m45t6G6csvZ8SG8LkrOoNg/mReRVtZLh22ZDrIWVuI9F2UCCXmFnZBMW5+
kqcquZSZD7dZKZb6lbuyQV6KbkBqQkdVhhJTwV27FVXP5kBM7gLkpG/RPbyD
AT1Tah1TaIiq1jDGXm2W+K6XJd72/W0+b1tjG5OI3FccpPTt2OhyBTY3rAVM
R8pAuWMasji+gBkfWCHnlSJ5QqQ2BzjdBhpu1focedR+pX/aK/6yP8uo7fZY
R233cRO1tV4y6gfTeqYrMVcl+BqGCnqpAR4FvGKHltb0bUsLAElGRVpWW1pC
T7r4KEYnGvz0a6JrY/ePo+vWg5zt0EW4b1kh+3oxbY/D3M/8l0JhmeU5+lK/
095GparRH4f06UfreFQ6xOaqZYtZqPSWq7OdWOdqdHcO24g4Q7hydlrSS/rx
AaC6jpJpKW2Dl9iH9CSUg6wkMXtuPgjvMiukzeEIZg5TokhNKfJ5AR4mhnYJ
Qgs8beLp44rsKB1YJNPkltlwLF272ScFt1bC7XgRcmL1oTkJubZcPg9hZpwB
5SqvkwI0Ttoo6CglyK2Wniui3nDuGL25clbERnPvz9trTYfOFrLsJ6Q7MUql
mY74TbNr0ozvlJJU+ZxwnbDsGj44AuWQwIaeBKgZyX45W+7tkW++VC9TFZ0j
Csw50djlGHhwkDz+gELoYZdsJpjAA0AhLyrOU8JalP5p0KLYOhQXkCLnWgGy
kwr8Ey0S4P/SpoFcXAzjrJaOg173LA41vS3xSJhoqAWH3ijSXmGimEp7P4Ex
Tci2RjW3qWPTJf7VXMI4AkQepJnkB3HZwhjAYznpnDt5LkrO9aniTwn3CU8y
X33TL8YiN53fLslu0yLnOvgYi62ndlm18h+Gp9fGU7mqMVqFOhbla6CK9aSO
nxwVHpADXu8rNqexss6VLkVKcHWRLOJOZ5cYCxRFRJVC17xuvGBhEhtNmb7N
YkAnisd/JkgwFeEsPzqNIJLV6qaWD9mI7p/lVbl+6xzG3vSfgu4LybB+8zd6
uRkowiPE9BftXCaJ+GMJgK3o1eJHVNVrKWgvZ0nMV1l6pu6KeQnowHjVqMLP
grnkQJojLw4aIjXdB3L95NZhPn2nNJ94Iyagg4qbak5q3H+tDK+Gl6DIf6ST
AiOM7bbMMhOWPBTD2WLYVt/sO6MnvKkzbq85ksv0OubQ8Vui6myVdk9y0IVg
g6sPe1rzkCBoGfUw9Tesz7cQKIV0DZMH+kVi1J0JGmqK+oiXWpPwKkq/dL+g
MCtOEki4VOc9c1TwhFW74AtTu82EqJnG87xaFDgAaJetGr4znZ2VyRRBKSL4
wY9EA0wfgD/XJCsspnGhzSsZa/kWTQoORoKFdiqCunJ9v6KceY0LUm5ed16Y
CxxqomOLWzUEUK7vNmhNIfiIwYwRWMBL6LRnkNXHGLJxOV5Mq5r103nMGPAS
KJ+I/RcJoonkyIaAGcVzJrjwq4Hwz3KCn6t56UiR3IFVZ+etzC6Dkt/SQr3S
nX6N30LjKtTP7iPR2WciMfYEi3wqGa8BgRaZuCRJamrxLZ+SZC7BLdYwQ2AQ
xvKIYMVw8QnTzTrLFnXli+xGIamVcticpMGcOa1E31QnmuUKaOhHYAfgcTxh
YXuB6+2Bt9bvVwLDWPK1esVQrl3Sc9AMN2rgXtAkBCJwsAn3DdOhH1h6CQru
szDDFYwl08CvZpyCXUxZwIjhNgSl5ybZ/hkSej+5RGQNCDTOyFdmiLYjIg1o
0AnW7uPm67FrYh1hvYMk3kRI1RVxcQ41WeLkfJVxZ20fLPdMJRulJrmGR2LX
cIm7eMayKtkiRboOPREdHPb3o7MXPl6kFr82OMb469/Goh+I89H5HR+f0Di+
BlGNS4YscqWghUgmLgorho9RtdDS6Ip4l7Uu5dps1iXdYpGNvFvNDRcpTK4Y
HcNUhQ45MheQhI235EawVCEuEesVrYS7FQgGYcgcby4IwBmnbsYwIM+zM1x8
Nl/SePmQI3BrMVGyut/4gfj5/iDagdoKQAhh48d2GTUIa9i5BGsRBEjoDyo5
h7I5Ye0npqwN6S3iekrOocu1m3E/uNl5EA8rYAuVbFXB5MAMMxkpL4xyadaT
yVqwp3pW5uiYb78UEtU6+cSwJWS4B7GD1MiblYlOPQP04K+TFzneJ1GYd/Bu
K87+8aZGUebyVWioWBGhB9GJnlwZSad3q4x2XN7drnzARJ39lGFZBadw2dTs
2pf6yS4McCmpD7MspwwuhVPylCDQSam2SJqysijgZTKguTa3R0sFnVnjho7P
mPktS22u0/E2f5IS9NtcfJFPp22o6HTxub5Iv7t/3O722r0T8VcWi0ziSFec
ZBniZiVPGkIi66toLYcXu6OrycbhYd1ZG7fKze3LfNeXrwLnyjD8leW0nSP8
iHf3sijog+9Bmhx9xQkrVgMutAbR8H07h6EEMSSS/lvlubBDvrSBgzpGn67r
abLyjgRN02BaS6WQhlAX4iEZh1hjdUwkabN68o3OEp6ZhKIyU/W4ItZZRot5
qx7IoOMjMpp7XgctC1Tj1s4FsTAHCVwBngAcTKG8DS+17hE56pHA5qMwW1os
u6oc+RKZz8e/NOrhO1lCw5h94XzZZss74CXDFEpoxSIVaNIcWGkR0CI+E/3m
ephWEd8d1jyHoi4ZBr4oiLO2iWrsMy3rwm4yuuFwEp/UuyhLC02hX6siHSJn
+2N5Qw+MPwLo02R8bZUxYBWvRf7QQZ2rvAwz+Uo5Gi/W3trhlaJcjIBXuc0w
EbUIMeGBrRMm0V2tvMO2g6EFLPjmdiUsSVaQmRjiG7DIKSKj/UNiKHNmk9BW
aYE1bv0OpTLfg9pdYp8a2TQtChp8PWDqNo1D90vpjY5mRlUzmJC0FYKkbMXr
BvTeUC8QG2a5E56bExKC5uWmEu8B10JpkqBgQz1K2fQMSS3ifTMJQIKt61tZ
LiYTFLBBx9P8msDGrUSl2I3Lr2FbIhfBGasSoGFGS8ug3T7HJtQJYi+uioX3
Mq8/MxezRnsFJEeh/ZpRzo+bwPqkjRAbCoQrASPUsM1XfZXdNgpTvY2xaCcC
Owxsl/cm9HMZmcJs1iD5HTA5YmxS6+LmRgDsGjI5dGNxU6UmRhM5grjOyw0q
MHCzjuOMvbGLWe9ELzwtkFYeSwRjc+NJFGNNVHtCH+cPjQwFLTEkTpuvAF8L
rJnvc7iMN8yIuBep85TyfSug6YnkG8Jxc4NlENZyle5ryn7AEdYYl1+l98m4
LTpq9CIZp8IClDIidqP0qQO7zLZZzWkilHEP8ynCHdUoySqmFKcLWgyDMpuc
SOB8UcwtjA800OWHoTjrkrVBbwMGbFyIhlsBKrOY4Eisu5eowbbqr3rzmLqo
6ajl5CXLZQfWBDEGIr3pXpbvRcd1xZlxmxmh8NK4iJu7Sjvl1dVgOUTBLr2R
BYf63jrGpFawrmXuOwTrmxNih3VxZlSVVZirC667LhGD7bXWVTQuBUgGoLHD
CVuNT9CMi1oTI/GbEEjYSbKMf2KZqQri/DitMCWpTsFrWSjAGw3IB1FhlxbB
drwYMfxdVLBnoRfCfZNbIThFUl963Xy8TudZUne0+jItI2gUw45jzyrDeTo1
4cEybewu9eUurT9LQw0u91FxrzZm69wnloR1KS7n2tiquMiY5/lKzdFd98nH
0Zarq1zPJdryEp9dhPCQ1+biusoPK5kW+yCyFUYvdzsFF5+VBmZD5aBFhbBO
Z090YAusHkxOHZEJJGJHI1RVWLGCq5tgq2GpiVUILf5APSroGtcJY78GwliR
P71GQWc5Cd+JLiqViEonwJdhSQpDUVGN1U5dj4H3NeLUmBDY6DX1ce2+FIl7
vjdwk77WRLSYlOSCAAXrtmYppPnYZFnAwjtFQeRqy7RAacCsRGV215XQrcrJ
XHaDHhC2Gtnha1g4X7nhw2pxZhLfspoWTt2y8BMCM/QRuLSjMI8TjkyYeIyG
dMTjKoUnfwAJeA3ioLf3uVP4L8QJClbJVifvYvL5e3zDXzk1WDUpDn5enTkY
+L3rXklVvjkSJKA2PHPg/ghajNUsT7kvcJkYg5HQhF6/RobXR9LV7etpWRfw
osc9yAyxZsJksFm292MU1U5EyXfEOoyO0MvRiLwI3MiPsMgAdIy0gdPHWUlk
10teBUMjrkrl4UzvtSIfPwMGLAb1hvEjQgLBKJ6OpOQqr4wh1pJKBd6IhDsU
5MDWvZ8WLCT02+WZIkodqECkE6TMyt+G39dst4YCssBdOtFzKXjmbyB7oswl
Hp6t8pKw33qamSOnBphIi9kOuieHTi9T630IK6H97PGZTHOR5zk6gq0xaJY+
NvKKbubVDR1pOmqZfUHDhx7drCrpD7IW7gDAhvcxMtZ3qpxd+qDKu6o523xC
NfjDomCzYeUs5mxdU59R1zmMrAVirLWYbONpZmKUlfMTYgDhMODYbBsRw4D6
qTrRS7BSH3QR+I793rTAAa82zWQL7gUchqCl4pzI3BIAskw8DBfLxMsxjbCJ
aVI9KzVJx9vw/G2BNZsT+Pvd/j4RmdP9wenBYafX3x8cHB6Zj8loi19EzYLS
m5UsLEAwReSNdUvtdjAIU/ZYyvatOXpp63mHHZU3YoEY5WO9fvS2Zv+18Iha
BBG/8oRbMEm1+UOuQIp2gFqst/VNpen1CY7ctHbXatw5nEWK5kOECKOQJLqd
NPYq2KVG34CdaRSPR1hjMQK2AJHdgL3joy6hVEhJbuhYEY82I7qocWtR1L0/
Grzk/bDtKs3iQimyJF6i7Dz+IRi/zUTErLS8tIJFocsLLFeK2TUZu0H4lCuZ
DBjUpWbhXDrRLpFdZ+/f9dIwymiXLn3dxDLcCRXN7ERLKeRhnjZW1Xz4VymW
3sxC96qbOmPSwdzd9fepwaal1auqSiYZCLufprNUDbDLpQOkYhkHh4bWKylD
rMMFvNz4DtMk2NhImpuIS52vAcvCdYbYEEJUKxTjcxUE9Kxlo/GU7u84NO6m
NUHEWcyDTM+m4MD6mrS/VW+HpBFaa5aF1JZmY1E6Ea9qUrDU3AxOlPN3lmM+
Pdaf6rUR/2zaFBM+bmkduUp5Etwl1h2rdS30Yy0UxKkSiFLCb02uiAKrpKt7
mYrS4NMZ81DDrBf6UW77oBPpyJBMgupxQemMNgcXqqU20l+sSS7sLlMpe+HN
aRYsiMzEx0wBrkvutxmVLkndXOdj961gJS4+mN5UA1X5nPbqGxqbHGJP8q6c
MWGFwuf0EKcE+YcgpkslTJX0W7WxofGoPz3UjlURMzLjtS62MotwynQyaKu7
Rg8nXM2za+66aga4mnnA6XEiidCpNQJuVtuQ+DtJm0GQCSOJt1A5fRGyEc9t
JMDVDxHbVsZICpSasDkLGOwmAyceE7rGom/4WBEA1MWLKHNZYQhjvTkGD0MZ
JqIjRU5PKJELleNAafX2YXHtr0Wsx5BKQjyIRLgqkZ6s1lANCnGdYzn3XSPg
HcqtN0FxtUgR5lWWiqO++FttAMnh5TAqvE8ClJlPH22U1hIXm9pgVix5LC2/
fAGXR1zboT9yKMwp7BtOV4PDpJy7pWG9hWFfOIy0/17l3hQO9RVSEQRPXTLa
BEgWWHGdaiLBSVwGCtYgQxdnP1nB5gBY6UHQEHJXKqtBpSnFQcimat0J3DiZ
yKaN0IUgesyNyBN/J6NyrD4HyITp+jasN4TFldrfTEyASJHlEQhGopeEljDo
+xLJTwjTDqZSuLqrKreR74LexFAGsTJbgSZMDzXuB5vPnOl82Wppg8DA60p4
qVWrZk1aKua1wiEQhG6yQfApnNEQU3AHjwgVlQDv6kF6Xuu6NzeEYqzhgIa/
723M73AjShcF6IUS9uk+jWGq104TV0SyDmuPlcm1BEpN1jNPthy4nfI9ZUMm
0Tw2wBDwNdGPRNH0miPLGhdXjHilPzkO6qyLWSa8MAS9PVoxo050eSPDJcef
8/uEEZNOG/PsbJ092teEF0LnCxOXjeDk5jRLPFbc+wGbF29S2Dz9EVraqvWO
CYUFOgwDKgY0qtlZiUG10JnzJjF1pnpLlVBBJExggXJzm6cScyBRYcFBmht9
BREK1SCjtYXF4MVDjqtNGi5JUXhD35c63ydFkvyY1KgN1xCMU1/uOBDVUGXh
NlaxV7RbM5vXfMkqXAyLnEibnM/X69J5LKrPGt9onORy3KCYj5JAEqhTs2W/
MTv9NUTRkx+JOmiGRUhYK9vv1a+4uWHCtqpHdpfQJIpjYLXQR6/DZrx4bSaQ
8mIzudwiaQBCpxRIrwcR6IAXkzVjgV7/K4e/5rXxQuWmBtxQAohHo1zEA33b
pGWhB09dwFK4zapFFEl7WT+w+RrCn66mriuwM8M1H6KvTMdGhXm2RWhglpSc
v4OCSDT9xwRhI0o5TI9jUSlxkdJL8R+7a5z03osoUXTnN8no0zoNSqWEEZ6x
oDGFXxjL6hJYFYwclZA1kaP+uJ5HWtpt47Fjwe2MNVizjUp3LVJfQnGW69Kw
19XSY0WzBRVDeBSSaIKoZceIW5qD1hQgo7OQMLn4DCR1eumEhrSrxoF6atp0
dVp0bI6p1u3nxGFmq8QjKNmatRh4xx5BRYnkMGmtSCATwS4XWo449hBlm5wP
U+KodIEtuT5PIc5MalA4NllzHyRbp0713FP121ArZfWdi4K8JDTjVFwXGPmx
5I9cHu6OVeLabUZQ8oNSyikMz4bNSMSgUiLhQJFQBijnMvxE0/O8kmCuIGGv
EM2bDXZiXmqjPG0kwTzRbT4lkOhgtCje+GI+Fu2YsJX9THwh/aQMVH1oV0VG
nER9WaH7n21yoGYuC0ul3norvTC+Q3iYSLdaVgHkIAgDCnzMqlMJknp6wSgj
V9zJqRqM7nMkpBJY6VpgqKXN8hKG2pAI9zgwPHIat9TyDcho3QLVcgagsJ+y
r1mFwN7l7GjLl9KEsoc65J3NkPEdqc8VQ5rjXU2SbIInLoXCwcyr9FVKKdTC
5VyQsKkCV0rCvNzoe801Vj1MRjHuU6qhlmYNkrks2IrpnQ8XnBis62RuFfjy
IoSe2e9tllLuPiiSSVFI3rAoYqKAmsPXcgG/IXh8w3BtNy62jfmCXU7ccITr
aeRCu00D0xRhnCz0Yf10nufTFfxsGJdp6YsVPKm9ubOy+ADskIoJdqdhFI8I
nTkUcrZuJMj6NTKoN21RaYI1R8ppHbwymZE0rmoiI4qMDsz32fnh7Jy+3yyw
fckd8twCPvoFfPnCm1/V/+MugfYBgPmVV/mUTocXXtt06WI3l2rjtoyLc0Sh
1tgQ+iX51KE7xPqGcvD7RJpGFmgpA/oqyBUOlfr+iWLQTEiAVNOv5WgLdd2V
FCKxU+u8eoaBhKW1WcTO71qpMJEONaqWWr19QpIlGYpjTSgDjVBxbmooAtrK
NR1WMEhTfteAT6l8lXgaFE/v4odaTsVdkVaVGEVqdIljf4T7WIZdGsTGaLph
LeVkiauI6kf3mINm1MvrGtyIjhkGCAHEKMBhTorY1cMpIc1A2a8lSiQWDC1G
Q58zEuq5cWWwZ17ozmlFMx7aY7PFT0v4Nm+NOezmhmOxI5AHvYQC55C9Kz/t
NPKNU03dbLZXcqfvObKCVOuPDBu5xTTEw5zbp0okUsXWrTL0OzGXhhQBa+uo
QPNgJubABCHv8eZGiMe1OuRLbRaYwYkUgowU1ObMSkQH4DhH3C1WpRCBhs9u
cAhk8pzl8IRuMpFjvNhkhoOg6D7M0kHE7ZBXaLFYevZ+VlkqsA7NkWLEbrWZ
qfBS6xO5UfX6Q/zi0SX9JdX+YzcEtSpxQmIYcx0KjIDi5+1HY61djctV+rko
ahz6pFHz7EHn2GoIJVgE6xN1R60xUWlhhuqMSqGl5wUwSprc1nQiXyDGdx8Z
OumJr6EW77BsF9r+H13Zg9K5PzU3dZWFdJXJ9QbsoBQRwvEJ8CdujOaKniyH
QIcLt32J3PAbdENjYsciDryp6U2ej3mS2E8TyLgripfwvHd5PcB1BQu2XDpz
4/oM8HyoxYyQFuROTjWo5oEThANMCWO6hDleVEH+BvoaS/+7FvL6brSYTbAT
2YQU5wzD8/miIcyD4S0JhKhRuyIlRqcz3GNtqVa2+I1SS1F5mDt+BVZYwbh5
W5aCSn3WK+38Bzo+5AC0dCGOOFnpEbFeqEruPGO1QlGugE841VfgvWyH0O2W
a0KXm73aDDquATlHVY5D47wFdEgygDcp+/w09Qe4W8PxNm0X9eC7ZOfiq7Ro
gVrAp+u5Fua9kKA4IaKhwXeN4nVhf49MPhfUjaxjha+apBl1K92OIri6lnNw
RLESGaZn6fuNtgkuPOTYGWgbD1qt5Cy6ePnyZXTc7ddazrna1rX2cjKSy9fj
IiU+FobJTjJhyWQpxQMBMUhKIfVBI2A42ZnYv++mXi+zxD61kOszwTM9ieWN
5DonnmsorY2HdKNahUqIm4ajsMwJuzPqpPDUa0o8sREddFd9lu+Ta2D7w0rk
5cp2QkOruPxk+matmpRUG0LYFVFQGRg+dx7U7N3AqbSYNYQzdwFkex24Dmo2
dQ5ztPgCq6+Y+hrM8k1jTrWskYaas2gxzOEqz2D2Ux0mHlXL9odIWBkBXjKh
SRDuRJcirzi2TCu6obPXYGedee96SnroVDJneQ2pRlEHKPEYPliNOyDu+5fn
b1+/fvnmxUupxxCKEDXYLJdvq1hopslFHb4hrU/8H0gMYw6mtuUCoS15zSmp
HNRU3IoPnkdwVTzRi/2568VeF2XQav0jx3h95Fp0HrBfuKSE8CGufzAvkokU
ezN73B3sRFvoeStpnVtS1knceUsOADzHfj1fcnrn9YuDSNvG93ZbUT0VVHIH
hOVLNXBzYIz/DJ5IZ73lG81vAQ0ksRHOPnqTY6hcQa2RBgXRFCQAsXxtMwkp
sK5UK2vCXfkYDZ/IuNTlnp1IpTpFJJjoH5aSD0CwfYE6aAu+fBh7HjFstOM7
B/OHJMtKPK1W0d8N0s/cW8JFzHPGDo3O6kXIjCRJBFQfA2gXVmbqVihv3dSN
eXklTp7x4+4w2DnjhDP6AuPP7qOrq8Pjqeta3hMWV/4Fq4OPgEYNRemknqSL
5Sr4vnpsnKSBk/F6ElPbVWPWQbAS6sEG2N+9cg/Lks8ZC5ygJTyS8+NbuU+6
aQJ25mk22W4AwiGJyOPpg9Uz0rp6DeMr2jTDq8YjEJsI4OG0dKuUzBZMyUSO
RZghiLmeV3W6KywylgNm0D4rg7HrJcgwb6aHIbI8p2MsyoUeS6nGAE1mF23L
KhLZoJ1a2X9RWuA+8yjmchBKby9gmplYY79Vm2jiiIFezQSxyzsA7nONUbXC
1t8TK5jDCnErBCW9iLYtRwTF3k+8msGhzcD7V+fHg5OTL19oOLahMCzVErHz
4s3lLocWVjdFwvhzmzyYZkAIX56akrlzd3fX0ak79NluKwpPaen7zq740aEw
a+eQnX165kif2adnuhIX/UOes9+AHvn8+U8H3S4WK9R8kZY3ydhu54s35W6r
7iUKupivYvCa9mBBM0iX0ZDowqLI6zO5YORiMeUpX77f1VdkEbDxZzBZu/Ng
GPeO9o9p2SQqMRaguhezdJZsUR1j58P7H7B6YKlIShZyHEfcQq0NqiL1jeWk
2nKFX/23F292NRi4cNGS6hnkOo2herJ0THhp56aq5uXp3l7zSx8AygF/M6lj
Q4dweIhDyIfg1LXqHDtv6YLsBrtQZWKcV6RMW0OPYJHTJJZiNoTHO/3OyckJ
AcFrIOb+WXq0I89y1o2E2gXdNZgCKIZaA+w/HR5jzebjoHVGF5mGXEABVqlb
z+UiABk92r54f7Eb7ez9MzJ92heXb9sXVx/aV3svBVgGKBhX2KpPMlQhkd9W
nU8Jnd6WoFcOXbFWhEMMP4wjQoeWIGTw8Z86hP18b1bCM66BCC/Q0n/TFGSW
NCUfI6iaGl8LYmWkaRW4AozQSji1y60kYC2JSJa3YKIc6h6wQs9Z6VbHR28K
HDa4d0LErMIyYtYZnJxI5DhAXHnHmCeEvBraOtbnub4mVi9HPSWwXqXlrJRy
p9mtLE1zyXnxPkLNrzII9ULP+FqjILMNpEXIKyAGSDHNrykZoRwve6IT+lCK
0j2OznytGhHnZYIvDTsYR+aLO/LzZ/cYQQG1FZ1pqcZD7LhE+g9q3bAvRksY
BVviiyO5MhzZ/BTW0fpG4vd1ytLSPk5fYwPiYDFvY83Sxiq5wcTXAmpFF2dv
zkxV9AqgWFPs+XmCWDSW7fPamYHe8wC49KZCiWegeSJEftocEgADE6C8xWf5
QvWVLWvQJBF3aiDjDf0UTPlTHWX+wEr7iq4p/BgRNpNUforqL/pvXJuVn0CU
3PuHw/hoeNzrtk/G8bjd64177ePucNDudkfdwWQ82O+OjumxEB/4Pf5g0Ov3
gYNXNd3PpqFjb07Te8o0ilBPnQa0vjFN/6vTKCbae0+YBjjZmGbw9WkEkZ88
DQn72yE6uf4YIS6KFnCByq3meYzHY6uVBUcQI6ZoM1uXNZnovSLcFhGFaToK
ms7hfHt9azL8iiVWxJCyRsMt35Cd6LkJ0TnOmmzVL4ro0a58V0Ojpv3hSXrt
t1vcXG5UbdFu2kGjnZCGmZPQcVIEVrjU5XFYxzpgVOpx3XoKam+FLResTztn
/HawrEtfXGt5XWUjZPPRjAg2bFpTcDBgt7wtLVfNsai+lXJZ1aJ26Gy3HtsH
L/dNqNME62SrgpAtC5GWOLRahTjpehIE3DFo3iyN15EDQ0CZbeJgy0JYGknp
brsi90DpWh7QmxUhC0dcN5Zx10Z/9AQ7hj+LOTB5yNnUViub53bVwLTByAL+
ixVwamETWxP9swUxwv32OBJp/vSqil7eO6A+4xUTr+iQsfyUA8f+42uRlg+l
mt3SuvzV7HARSV3DGmGKVRwghF1R8YKvykqkoC2sPF4fD26zyjBCd8BWiUSK
C/4hSDgUA2+tPB+2Jh2nWYzhet1SJ2NVnLP2CUjM7NnoU1lz1IafQgBPUFcL
4/mGJqs2hrg12Knl3IJF1WqNuNJiYxcGpwXl1wLL7iPTFbmqw/xWIGCRKgBV
YLnmJqMWHCzO/duBqwx7tPrMLkI/bxjatbMuwkg0+0BKpiflqD6C6E8/+q/w
sMv/yNSUFOoqFvIXW5zrb1bE6rkALeevsmLkCgdfLs4K9a8+2nVYuyZo2TR0
VnUUKqyzzqW5jpygv6cScMGp+mxgTu44LwsCJxceYflx1YGbw4JBBQkcrXms
uFEg2kKrWd5e9BiCmv5x7s74vXf/ft5eecKrQKKUjYPIVNPNzAjokp48JtVV
p82NZkgbZ7hy7rp0gJDCFWHtPjXW4gpYuMKOeE2AWLvcGK9cCMsRGR7iRJ6x
fd+sAAJNLsq5vmm0qhzre+5agGai7AORR8Vi2XvOfsLVMQmuMd3mBhPbJxT8
u5IWT0WyuqGntM2wIj4oQ+aahgrG3pJqz5llCYcCA2rNgAuncteC/9YYnX+g
2S5YYGN781njxEMfSVBZlkgXn9+DrlQc4WweJdnJ1w5HbJJm0FkIoDOiS1Xn
lb5sox/mP5T09ngykUTB4UOIkhCVHUtwEodhV4OoWTErTQdjda+IXTgFb14M
Fwyv73EvauDxMPiUPEhgFxfBiNOC1D9JWKbdJ6nmFd4VOcdmLtCXTMOyF5U2
4c5p78+Qf8yVNCoSK8tPWlouCM7HOIVyfNptcZ1q+TOO6fc0gAe17EtOwlIH
wIT47EIDz1HMPZmzJtFIbRgnsU9IxAI4k0UzEt1aeHwtT4kaU9wYZs3lcIl0
gpCWGSOxFCHtwPFZaQGma98x4+HF/wDmgzrRdoSft9exJev2VIaRFSsMyI3g
emMIPF6ALJsbvnZoR1QnZ6V3xqX6fM7YJWOt2KPUn9UQBPc47gL4py0tkDOd
tadpAOQ6EbRGAVWA4zW+k6xaBNeTWuqNjOgkjlpmSVudydOloB/rbKDhUCCZ
y2vQWm16/rU26d7uaUGezYiAlvtuKVhgKQJp+OD0KFcpLFgHV16XNm6oPFOX
QCzxYY2c6Z5+bDkgMygT+aQi0Rpox0UYIiuUwoUXxaHu1+1Fy9U47K/Kh3ri
8uftRgv7tXKQrxE8Kh7mVX5dxPMbFzc8AsGoh1pZ2pUP5tw5v3z3/s13u4/V
WuHmTrDyoq5fJU8i+biKdraCuppbxPvjTHO4Yu7B4kMKo1rYIt4DoLZ2NTAa
zXHmFtnGMkiMesCp2EtkjUr8mkVjknva6Yrybqu7k7jBJOZWilRILQB4zbiw
xmKOABh5QFuR+VQ0i4edoF5QKxhbG57o8NqwiI9ZPwrLOA7ViLA2WUBEHx+S
VWtaxL2CuE2QVZV2NlekwaJ0vef77NMP0UMcWoRojaQP6xDMtIOvAjTP7vEh
NE+xQp3sH+na5PuzNy/evvaV04WSciXuFzlq0ps7R9j09zC2ALvNvIxjbFrU
Xd669S9rKk5hSw2NmJpYcNvmBqLbLLLN6kn6lCHEOrL+HWjfpaOIqyiI02zC
kDkBnIVYBjXndyzCrtPrDW92tX1w2FDCEmFr11LUSFelc1WJ9CdkKYs3LmzE
Ij0WHj39zQ0NdXJaf4P4fDEdPa1cdUMJ2KR1nXGdhgDR8LXOKtYAA5VJ4Wo2
XNlbhFMdblbVjDULnTNFShPovJ7w4hrNKkppRRKlyyMadI+ji/GT1GQMXGuS
KQPGnfAFs5MkmianDm1qqG2UJDRFc2iQOVMSHftekrZE1PPJN0NOG3BRpKFK
FQbncEeEEckSFk0nXnphtDoVDcNzcbKUKR6oo+IPIA4hrifhAe/qDwatCfAE
URMvW3GyD7wuhorwpFTopnqbcBdRkIA54uLTexWqltKaJOffxZu6WFPPJhvH
QYOwwKXBg1ILYT7lHDqYPZM7IUFH3UE/MISzpbpKlXNqOaNimkrPCc9siVJn
gREPkrGzsy00gW4dkgTpRyyMFcTZh4TakilgKcHN1buUwIBwJEEbmKXnuQJ3
IRTLmG5Qx4JNtIwFgeJbS652Q6/cB72FCnyiCseZz7CsUTaGj3uPow5cgw6O
exVCmbkAdtSkg7fDK/aJeakL0ovYM+m6pMUWEINmp42Ofi21tXPpJxLAuMGZ
eTIUqVtyVaFUW8tZ9p7Wqh26uD8uMmQ3dmhh276xnoQf0jVCuSCLnmxwHCMt
Lv6sTFy9bRmJBAVnn7Qj57MzBblhJBVbeqbtPh215kwr6WKaT5BgxrFz6tO1
GbjVOa8OVkdNp2i5Zh2cMCS2roU05mP9jnNotWVmqNJpVvRwATi2Is1vmoH2
XyOW7xoyyo4dLIJJ+weHFld60OuHluvPn19dvLvsHXfbgy9fEAsE4Qusz8Uy
HMLAUoVRmYhcDXLNHPmvoa1YaLQHM9FimFpN3LjU+iSft7VSiVMfawnO0tiB
PWZcyU4twqusFtZsQcfb3NCUSafcISPoPil3+QmsLZ/HUAOL+E4qO7QCmp1o
qft5XDD6cLYqKRs4TsfYrzhKzLpuutRtYQ9WjZFhZtUD6osRQsK1VAz9xNlz
F9avztDYjlO95BZYfWSMAHYi6SQctS4hAKWvsqi1r10aFSHtdcKjcEJ6UmFR
Qde2jsX1xtO2qJ92VUcWfpeWvrMW12QLNxLd1roeoBBBCRenCagcb6StVgi7
SUqoEKmkbKjjGkZbHNLjlgRpTuAr5w8hf9yno7oypd13rH20gs/iMBuBkU81
YnAz7gK1rjSPYJhet8FWsc+HSndJSGiShv+Qg3JnKYrXXky0+p29WlYP06Te
yk3M8gTJstFRSU3lIby8XvoW/mBWSHP56QtjSrPERMuVWkCQFWvCVkHIMF/s
x4KOiyxLoEHFRcpdp0K/SVVPpHD3a/oQUq4OF+0R48UqbwJLW0jutqoiUo+r
KJPggs9AE64RXMkIGFxLd+srse6mWaJCkDal/8hVZEUrUqO4fRRJA8ObeF66
GFBX61gUmN2WZNWqomaGQQczRhTX8dUguMg4m9WqKHFtDIEiajHWrICa5wpj
uB6GtGolekdkXkW1wEcn1FcvsN7nFjA9sasqK00tYCBI6Hz++pLffmE0aamx
u1GrVX3dWXQEe6qZsJwsYa/iIyQXhHjBhri0gU3sexjmJed14aDxSv9YO82x
WddU6F5fZOMAM5luLVz51gnoHoNHJvVl9TTVU01/jhzXk0tjkyldqwWbUuNb
vZfL9/dV4cSmNFOiSy3VVyWguTA4SI1rXypGCTCs4kk7n0wkxRoySZCCGbuK
UP8QXSp049JmcEULGevEdcW1ReKHoH74JC6NIWlGsyvKVBuUD8sNKSUleEg4
aWVIuZaSsU3Ev5zGliqp2RguUc8HZ+q1ce5vVkaLBPlG3M/P6hhoLWA0DAWp
0qugBYadHOCWzkgtHmlt/pCBepBQVLM1mxAXm/vRi40QZirWDmqMqOnpX45b
ZxmsrIXfQTFKJhVLEdJeJvxWr0pLKzuGWQKIA09nOMxPyQPfqqLIr7nUKj6Q
OIwE3TiQs+OvGkJHSVTitywMmJFvnk8f6OzAFKUuMBD9Jp2XSsTdqPRDW9TN
eUzaOt7958u3b2D/W8w0Q9A/46Zu0jGRuaX+1RR3beTvGs6TgGk9oO3zttOn
jQPvMA+BjVi80VNY5N1jcs927UwD2xwfXOh57NTUHoylXc+CVN7wZBoeCjUS
cqF1afPLbh2SEVHRSlLbREQt+JDdTtlKHYusEC80oNdqtMnul6KBdz5/RtrZ
7f6XL3v64wGHB5Q1nGAxBhyAQW8h0lztz6dkhxRO1yKytJlWuLy/2G7FYhy0
gAnbDoSlSPzdJB4zlZpYC/BrbfUl6arODxnMQSt9l6P5ZoQa/QR+wheCbeI5
ph2CXiu1bgqTo1+I7xE9UHLLsTThdUpI21LPjrgdeb2aBGE5xNJ2Aqz9N1ru
Ig82YXtg7ZodDSMu0WNFwZMH30qPgWElaLxJRuumqMHBL7AVxPlwjt6Wxjys
SptrsbycZtzjWrRZWb4/Tm6YvmCZmXCboeHd2CLUOTxQpz+DAgXccsmDCGNG
LOfjzpdyE6rtDUmu/r40a+XKSRzXJ3G3EMsMTgg89wNxnQBwZElEjMfxvJKO
NfBeipE+2gmwGy4FIV2+HSab9EHrdxXmJsp6CceJYc3NcRFFepQvTiizurT/
eqijp7fyiu/WsRyfryE2TbtbwwS8LXEqSxIWh2nBQjz1eVGaL+JCxwz+Yag1
snJ9XJyLfWZNpD5QLS6tg8ZH66axh56RvKQG/UGn1+kHE1l1NUvjWpqA3v38
WXimj7iQlX94/yYI66mFjH/+TF+6OJtS6y0J/zWQhitdvyDNK6tvGSWoMxaq
eSH6Nk0++iSTXC6G8LQLblxqOOM5rtlWPQqXA8bLLY7lEwHAFke6Rdx3vh/8
tq8A4FQgCDWLWCvv8/3RnptL0cA7pUspNKnbEsarB8d02HAU3SXTadskk9S6
YBkYGmlrYsBqii7PnKppVSH+8JfF8wWGi0UWq/t5aAeeiL+mHj3tk479wc4X
w6kkKEjvZ03UQDRvLXaRVJAM+UYp4ifoG4uQ1goOH97/sCvyVZJIKibL5LR4
NcZfrTqDUrieZrix4H0rmbZJ9qBQDtBXT9RKWFpyf6IpLmOrK06AAAJ2ohdJ
lqLlu27X8rVQMOIeYSwupItrKCn8ef/l4vpaiK9oUrl52mbW1UYXA+IKoX6y
mJrCJ7cwwHdXL4EX/r52I7cFoc3BVz8vxjhBt61wwC1fuGAiBv4ZMA/Fjizu
WchrcABIisFcdgfr11tYZju1ui5sqtAp+Ii3avH+X00DWZHs4ZM+aGU/Odj8
RJedLQb++2bWR/gyJviOlpbjnejK85NwgqhHfxmn/Sl6e/kqenH+MtqLLl5e
vXo8kUEyTOhhcyuv3EHU/9oE5/vdE7F+/P/VXVlvG8kRfheg/zCgH2wnHHlO
cihgHySS2jg+1rCcXeRJGIlDiTCv5ZCyvcbmt6euvmaGNHVshDBeIaJ6erqr
q6ur6/iqH4ehTqKQGSD4wPu8Yez6BfHDZiBF9ravgZc87AWEm7B9DvCC9IEz
KJTBt3G54QWd3S+oJahUuOhf88nXZgZSM+g+7AV9thvuWIPsIS/AZBt7Q6tk
m5r4kYybTya3RtJudDFUCRFsnSt54Z2QXqLSbNp3SLL5caLMbDLnum5kK+GC
TK3Xg5ZVJVTcryQgWkKhlg121HKJ1fLE7IincwAtVmT4DFOu06Gictuqi+/f
iRAhZyCK5wRFWetjIbq8lfJAcnjCBMGkis18Q6gf5IiaIdahrUDb6uM3wXrT
8TOiROikj5aW6HzxJwMinL0+2W7IiqMKOTZlzNPpfaVQMqF/QyzKIRrns8n0
G4+UgWhF7WbGYOroVori2DFWUpS7VetkiSZN733/3NBZECBOF4J0tCdszUt+
5bvJ1WpRLsZr3R+yJF1ieBBcCFxnxOr8W6GFzrXYzHlalAzpBgTuymv1zicw
5XyFYSImvv+Hi28PVofEkRvJjFrSHdaUGs89oLlRn3cqyQz4QVhHav9M82Vb
3G50EycwtLHXClv0PsJRII+G8jU7S1EalpLzdA+WUqXSPhcGgmKMlfREuVS4
fcrCdWQlujHoAs6kuhfbDsfAb3q1W6oDpLYavqoLQRWaVOzP3kuhDK5mOXKN
jVFfhZqGVsk23a2mxfuqaXave+hq2zIfPqmUMpXgq5jZ1orbsjpcVsNEl4y3
pEDWI9iszG2JUjPKT+0iraPtdqSeYPaPFLQkfjYIRTdYI4XCZNkO7gQb06bW
6UOilZKToFTDucqXHHOF9/IXtlXqC4UyzNAsgi4w6J7C+jG6FB0NpKNjIOVg
UlKJGoIBkBBNne80N9i6LrgVbgSENdVFQb3bzXSuM6WaI+PUTGxSCOhnXn5j
wKo1SoE5h+cxRyKgCRpyDg/KKaZfUhDNSN+ANcwUDp3tfvaNfKEg9g4P2EeN
MVcbuLyVCqpPF8OykoKU95rqHLDPW5tgtU8OtQRyC3zzruHudCUGvwnf/N0I
niVnrtww5IFePgz8L1Xk9XI1uc2veLM1JOqpYHoB7EXrG9uSJFKUHCqWv0mV
V5KkWr1wVC65Ch5KISBibjYxyE5INcPlVSDfjjxGr67F/7E5ohK12QxnrSMa
FLiswi60cBxxsYiGucS4zBBbLV+v0ZQCo0Y0apKlNuhvQwlGtKCbF6iqBITN
Q5KBgUl1oICGE7TRIDnVjYodYKAAWpvL5WI+Uj4FvPZjpFhhp2qi/XPNmGuX
Ck2FY4LWsFJjVa/OyaxCiy1s46kk9hmpYeNwwhqpMC6K2VGspWOJm9OCdF7C
hCGhy5t8WVAeAJ+KNzLR2wSvbOQNSGD9DH+JBZPvuMwEoA13wjSUZcYr3Tax
ydxB7XuJtOcLlJFszhMihk+udFQ9222+P6t+pWtF5Jv1DTrjrtFnw3GluWmr
st44an8iRRU+on/hPJ/+0YYNDP8/L6beO7TvYGL84cEpEKUPnAVn81R+/ZjP
ygIjEs6A9xfe28ksh19+Xsz/yOG8h65gX0xWC+yPstGBRxezEk4p+GKzWsFB
fX7kvdmApFnlX7Cfj1xlGzP7Jtjq4+LS+20yXdMj5wX84W2xmMOx0aZpLka4
m/4NvF8+X3BzONa8N5OCArTwkdU1HCMfVovPQI5i/hlbvZ0syjccIlySMY+Y
bTo1OYvK9IsXL2MFJK1y7v08Wf9jc4mCEtjTUBEFhqq6A6fKppTcQStVzLJS
O3ZS92Y3Alpg7eD8dmJAFpVSVXeAqnj2T9A7ksEERauSYxxjgqe9lfUn/Zr4
GAre0mDFHOXLEEHQejnNryegY/1hRCpeYshH+EVKDqH4KTe4yeDLF0hPytWy
4MMUqgldEKgG+BL5nMUmLIwoooyI8lsh6AvlQnOxhiaCv+CvK8EQEqxVfw16
FBeYQ3bOp2PggCNvOL8upiXwM/Ct98/FDTBRvpqBHLph2+GHHLoCzlwtMU4G
eGUMwhwoq1odHnzJBR6VfEMblUuBwcfFLZchICIYkeO9Pv/l1ethX1zkvu97
aEDmjfwJLYW/cmQwbGInUBhb0DWqBrfvYTtP2jnQyYSB0AkoVEIfAMde8DUc
9ntJmPSjODo5DYLDgxdhnHWSLA3SJAr489L7BIfXKIe7z1lxudqgMyiK2lhg
PPKi4wj/HXFT78M77+d3n/wgPcbOtg60NjaNMMGQ7xdl8bt4wDFa9Aihgwze
nXFeVaquusVQzpwipzpcvn23eHhyGDnlAqjCuhXa757hCNWEIS88N4WxwU8G
X3vDzulg2B8OsqTD8B6M8Y/9w1/PzF+1Rs9pDVQ9XSM7EdwT9yybrcOFTMlI
5ZZw88IgADFjrGIV2H/YVaJCMvywiDYtbfB9RmO0ksMOD/4DH/IZI89aL1jw
OH4Zj4F0x8TQGD6pEdRhRD6hjoN2cYsGdxXAT3EpUvioWC6u0CSTRX4Y+GHq
BcEx/cMWKuqX3iMte93AD0L457TEYV1gs4sFDcf7CQgdhJdROBpFwOxhgnwL
cwyjKOxFvSgL1If3Ir1CyPveFBHVGtmxbvT+/HiPrVLZI/zsRSe5gBdcAFVw
fGFn0ImjoB8PkkG/L+PrJGmadrt6XzoDfN9Q3hQXwqwKEd200sTXRIIG/P4X
7ohewR9e/r1KR373b4vV5+OGHhoGy900UbmBBA1iyK8/+vJvoSICeRIbRlIT
cUTKWufMy2SIFLOoJYLNWnsfOMcIeZ6tpM+eeUOTNKLTqRjB6vsz0gzDC7mz
/qk2Dcn7fT9YChw9/PShqDvZt3fqQ8PDeF4cwY/gqxH69LfZBF8RduhvSDGK
/NMW5IS+D6UxgbdiCVyPKQxtc9OWvr4MoWctzaFxwt+GbXgk7mdcEEL1nvFr
LQF41/lRlQb6hFF2ZwIj93iKIj5O3w9hXv4pjNR3h1XlFFlyxQYW4+xgkdhl
kdhiETJ4wu2AUz5Ej0MpX0ki+v79Np6NUgSj00i+iHXWgDikxCW52loVZEyE
FOIQbBNNMoO7kNKbUFGzvMcGeUGPgp5ha5Dy6IPoGUv2ZAWqgfJyvkj/eLgo
jwa+S9so6cZ0G9+ijFqJnYkJb6ZHsHzH3l6gbvzcseMUqdDhTjzjsA+sltuz
l47GSZhlYZwXoyAN0yTLu9E4yeG4uRoHvcLiosnop+e0kM8dhoo100Dvzx8u
Oe4tOGBkst1lk9pzc2QEi4iYHxFxwhICKOBICCMgsClLpQ5/GQQoH2rkutOQ
jSy4tyhQk/Rxln4ME/AzGJS/cxF5H2xbx5pg4Kdxq98UXzlwIy9vjl0O4gEg
D/lJfQC/SgnfX4G2v8BSYCkt4PKv8vHpxzv88V79qj6yVyuMW3vznlPnjbpt
6jhMHKLa++UOyZi4kjFxJCOIQGmkUjVJiTYpIVbaJhxlUinWFOMjm5IJexZd
F8ifYzTILJ9qHf/woBf2wiA766bRIIxBG0tPT/pnWdIdnMLpkJ1kR55VzHCu
olKRgxjH1YhTigkpb9DxxBIzsSTmY8vMpEFm3nEHPFhmMLUvcnOwEy3HQMtR
2CAzEv3IpZYZQPEtMkOaXhmZQToFXJ/HsDyjS1ye/K77/hFkhpqkj7P0E5iA
34NB+e6o3I2TNMmM5EcyQ8I1gG+d7WtTmTi2RhLzoCNv3JHjo35aH/lfIWzu
RbMmYZPYwuaVI2w8Jt0WeZO68iataGJsd91DF0vLmzx8emUsfXxlzGSYo4x7
hcbLfIX2Q9vrz3TiGYokSv8ftDfewTR6p/+oGHU6aXdU9KJu0sku07QII/gm
z/Ii7+RRNCqKuIjTKnMSG7ismWquo9c8gjJ3f8mMo3PVOXuiTVe+VB5yFDog
yLYrHzV2VToSzxX6PcH1Ts3Ux6n6KczB78GofHdYleVsks/pj+Qzb4aaVucO
ALnKT6sD8A1j/RXydj8aDNQWr3fwo4+/dWM0Se10h9Qm0mlZo/xf1xTOvl19
7LjivPOItpcHGl941ynrizJLOdYXZX5BO4S7F2Uzdty+ZDeSEcfejc0WmN0m
mMe1wdx/lyrC+EgEv4PmmH2NMJ3t+3ILt3Rdbuk63ELqvbpnSHPLxaK8GOSH
xoh/iZgzJmljaWfn+gzrozVZaenKYDwPjDHDNnZUdkGRVrXeQUHGcx8faPZ6
SJ6q8fKX+7lvHLO0SeqViBo0mXfPomgYdXundXM0U/ipdtcGrcfr8mJWaia2
R9u4kbqassKt9G2/H2/dSEJ9+jgHW9ZPBv0A/9eNe9nZU+wZNV0f5+t3YRp+
D4blu+Nq3DPdHYZL77XSFhFmS9qhQxK4T+2UUvRkTmNnDFYBYkHPN4JmTexe
1GMKRByj9ijpDBMm8D+MK1R1JwT6WCIsMgmFEIAFWI9XFA+Gtb0pkMqFluQw
bYqvPNK4NPxuhpMlPyLnnpDvaSWVbMUnuZpcLyixcc0FRNpchIjjNtkxrNJ+
4C2LJfuwBT/SVA6sOvT5tZTDfg1zPXLDMay8aJ1Fjd8b1Odv6BlXoblAHAOz
AxS+UXXMFWYJIwnpXKSmFLgmuZiJXHxhMvBeKiGZVS0yjojM9hCRtrOyWVKG
6LLUIrKNeJrzK5VRpv2326oPtEmWULRFRbKyD5yCWZiLRLTKL5cCmFQWaw29
pm5E9JzlqCwZq1g0Eh2JqpprX3GmhbK6T1FPKMXRHanxiyjIVXprqwFdEUj/
Tml/Z0lfc9Q3SPsoyXrD3skgGg6j4Tb/o/cCl8kv18VSitQ8jbVJr6S+0lij
b7A2ZfoRY20aBtusTWolKhZq0FLiaJCedXphFvaD/721SU3Sx1n6GUwAfvR7
vjuqRpmfGZlv8lmaZP0OPVtLCJPUW5cQF/hHRriRaAnJm6/n13N5aFN0HqNz
GY+zoRqrqrBQARhW4ZAwOLIx6PoDDurkvPiCta3rvd4DlqtNLWJp+mZYbwib
D5vhQUX4zuZ1pmC7PoPU098Kjvs60WOxav8pKmox/GeDNSqDazg8x+C6efMZ
LM9QaBYVdZhoPCgOXFIVHEygp0KHdFcP6C2ooRUMfymGY85UznawjiOLJTTW
noG2kkx2RQQEzMAsQhwG3QdN2PvdDWUZ3+wVnZ7AXEbrahvMMstgxiU8ESOL
ypyvOdFJEIgbmJe4aSk5DVxFjo45BzCuhLO4XSkYoCP7iYE5Okqq0BGanNpr
ArXD6Cn56rpYHdlqf92wx5ryPa179HlEE58SnkL348OD9CpMOpdhEl+lUZKP
R704y+NuOgpG43B8Oe6MizDKO51LOPbG3WjcCdOsm0KjbpGG4/iqZpWWHfd8
i6SFF+Nfn9CRWzsmbQrseUwCne52TFaI+gSOXJmkj7P0M5iAjyvtu6OqLKUt
GrYtqFWsXG3m7Uco939SHU7SOBz/x6x3uq8ZsL8vBQb7mfr2GFuFlk1mv+xO
Zj8krWP4GxKCHMFUWkJzVyYpJru9xTyDE6eCJGVLqVdQQkHdFWyOJZCGFKOK
yImSk0l9njp9Nh0Jdq/LRTlZW5HfqjTFQiy862Juuu67w5VEOPIiETKXvPAV
bkkTFtvY1cDpSlO4TVGf+IQ6LjWYKBwt1/RGRSHLCwb9/hepcOh1yK0BAA==
</back>
</rfc> </rfc>
 End of changes. 319 change blocks. 
3351 lines changed or deleted 1643 lines changed or added

This html diff was produced by rfcdiff 1.48.