1 files changed, 1795 insertions, 0 deletions

diff --git a/misc/rfc4122-uuid.txt b/misc/rfc4122-uuid.txt
new file mode 100644
index 0000000..31ceaab
--- /dev/null
+++ b/misc/rfc4122-uuid.txt
@@ -0,0 +1,1795 @@
+
+
+
+
+
+
+Network Working Group                                           P. Leach
+Request for Comments: 4122                                     Microsoft
+Category: Standards Track                                    M. Mealling
+                                                Refactored Networks, LLC
+                                                                 R. Salz
+                                              DataPower Technology, Inc.
+                                                               July 2005
+
+
+          A Universally Unique IDentifier (UUID) URN Namespace
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This specification defines a Uniform Resource Name namespace for
+   UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally
+   Unique IDentifier).  A UUID is 128 bits long, and can guarantee
+   uniqueness across space and time.  UUIDs were originally used in the
+   Apollo Network Computing System and later in the Open Software
+   Foundation's (OSF) Distributed Computing Environment (DCE), and then
+   in Microsoft Windows platforms.
+
+   This specification is derived from the DCE specification with the
+   kind permission of the OSF (now known as The Open Group).
+   Information from earlier versions of the DCE specification have been
+   incorporated into this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Leach, et al.               Standards Track                     [Page 1]
+
+RFC 4122                  A UUID URN Namespace                 July 2005
+
+
+Table of Contents
+
+   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
+   2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   3. Namespace Registration Template  . . . . . . . . . . . . . . .  3
+   4. Specification  . . . . . . . . . . . . . . . . . . . . . . . .  5
+      4.1. Format. . . . . . . . . . . . . . . . . . . . . . . . . .  5
+           4.1.1. Variant. . . . . . . . . . . . . . . . . . . . . .  6
+           4.1.2. Layout and Byte Order. . . . . . . . . . . . . . .  6
+           4.1.3. Version. . . . . . . . . . . . . . . . . . . . . .  7
+           4.1.4. Timestamp. . . . . . . . . . . . . . . . . . . . .  8
+           4.1.5. Clock Sequence . . . . . . . . . . . . . . . . . .  8
+           4.1.6. Node . . . . . . . . . . . . . . . . . . . . . . .  9
+           4.1.7. Nil UUID . . . . . . . . . . . . . . . . . . . . .  9
+      4.2. Algorithms for Creating a Time-Based UUID . . . . . . . .  9
+           4.2.1. Basic Algorithm. . . . . . . . . . . . . . . . . . 10
+           4.2.2. Generation Details . . . . . . . . . . . . . . . . 12
+      4.3. Algorithm for Creating a Name-Based UUID. . . . . . . . . 13
+      4.4. Algorithms for Creating a UUID from Truly Random or
+           Pseudo-Random Numbers . . . . . . . . . . . . . . . . . . 14
+      4.5. Node IDs that Do Not Identify the Host. . . . . . . . . . 15
+   5. Community Considerations . . . . . . . . . . . . . . . . . . . 15
+   6. Security Considerations  . . . . . . . . . . . . . . . . . . . 16
+   7. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 16
+   8. Normative References . . . . . . . . . . . . . . . . . . . . . 16
+   A. Appendix A - Sample Implementation . . . . . . . . . . . . . . 18
+   B. Appendix B - Sample Output of utest  . . . . . . . . . . . . . 29
+   C. Appendix C - Some Name Space IDs . . . . . . . . . . . . . . . 30
+
+1.  Introduction
+
+   This specification defines a Uniform Resource Name namespace for
+   UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally
+   Unique IDentifier).  A UUID is 128 bits long, and requires no central
+   registration process.
+
+   The information here is meant to be a concise guide for those wishing
+   to implement services using UUIDs as URNs.  Nothing in this document
+   should be construed to override the DCE standards that defined UUIDs.
+
+   There is an ITU-T Recommendation and ISO/IEC Standard [3] that are
+   derived from earlier versions of this document.  Both sets of
+   specifications have been aligned, and are fully technically
+   compatible.  In addition, a global registration function is being
+   provided by the Telecommunications Standardisation Bureau of ITU-T;
+   for details see <http://www.itu.int/ITU-T/asn1/uuid.html>.
+
+
+
+
+
+Leach, et al.               Standards Track                     [Page 2]
+
+RFC 4122                  A UUID URN Namespace                 July 2005
+
+
+2.  Motivation
+
+   One of the main reasons for using UUIDs is that no centralized
+   authority is required to administer them (although one format uses
+   IEEE 802 node identifiers, others do not).  As a result, generation
+   on demand can be completely automated, and used for a variety of
+   purposes.  The UUID generation algorithm described here supports very
+   high allocation rates of up to 10 million per second per machine if
+   necessary, so that they could even be used as transaction IDs.
+
+   UUIDs are of a fixed size (128 bits) which is reasonably small
+   compared to other alternatives.  This lends itself well to sorting,
+   ordering, and hashing of all sorts, storing in databases, simple
+   allocation, and ease of programming in general.
+
+   Since UUIDs are unique and persistent, they make excellent Uniform
+   Resource Names.  The unique ability to generate a new UUID without a
+   registration process allows for UUIDs to be one of the URNs with the
+   lowest minting cost.
+
+3.  Namespace Registration Template
+
+   Namespace ID:  UUID
+   Registration Information:
+      Registration date: 2003-10-01
+
+   Declared registrant of the namespace:
+      JTC 1/SC6 (ASN.1 Rapporteur Group)
+
+   Declaration of syntactic structure:
+      A UUID is an identifier that is unique across both space and time,
+      with respect to the space of all UUIDs.  Since a UUID is a fixed
+      size and contains a time field, it is possible for values to
+      rollover (around A.D. 3400, depending on the specific algorithm
+      used).  A UUID can be used for multiple purposes, from tagging
+      objects with an extremely short lifetime, to reliably identifying
+      very persistent objects across a network.
+
+      The internal representation of a UUID is a specific sequence of
+      bits in memory, as described in Section 4.  To accurately
+      represent a UUID as a URN, it is necessary to convert the bit
+      sequence to a string representation.
+
+      Each field is treated as an integer and has its value printed as a
+      zero-filled hexadecimal digit string with the most significant
+      digit first.  The hexadecimal values "a" through "f" are output as
+      lower case characters and are case insensitive on input.
+
+
+
+
+Leach, et al.               Standards Track                     [Page 3]
+
+RFC 4122                  A UUID URN Namespace                 July 2005
+
+
+      The formal definition of the UUID string representation is
+      provided by the following ABNF [7]:
+
+      UUID                   = time-low "-" time-mid "-"
+                               time-high-and-version "-"
+                               clock-seq-and-reserved
+                               clock-seq-low "-" node
+      time-low               = 4hexOctet
+      time-mid               = 2hexOctet
+      time-high-and-version  = 2hexOctet
+      clock-seq-and-reserved = hexOctet
+      clock-seq-low          = hexOctet
+      node                   = 6hexOctet
+      hexOctet               = hexDigit hexDigit
+      hexDigit =
+            "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" /
+            "a" / "b" / "c" / "d" / "e" / "f" /
+            "A" / "B" / "C" / "D" / "E" / "F"
+
+   The following is an example of the string representation of a UUID as
+   a URN:
+
+   urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
+
+   Relevant ancillary documentation:
+      [1][2]
+   Identifier uniqueness considerations:
+      This document specifies three algorithms to generate UUIDs: the
+      first leverages the unique values of 802 MAC addresses to
+      guarantee uniqueness, the second uses pseudo-random number
+      generators, and the third uses cryptographic hashing and
+      application-provided text strings.  As a result, the UUIDs
+      generated according to the mechanisms here will be unique from all
+      other UUIDs that have been or will be assigned.
+
+   Identifier persistence considerations:
+      UUIDs are inherently very difficult to resolve in a global sense.
+      This, coupled with the fact that UUIDs are temporally unique
+      within their spatial context, ensures that UUIDs will remain as
+      persistent as possible.
+
+   Process of identifier assignment:
+      Generating a UUID does not require that a registration authority
+      be contacted.  One algorithm requires a unique value over space
+      for each generator.  This value is typically an IEEE 802 MAC
+      address, usually already available on network-connected hosts.
+      The address can be assigned from an address block obtained from
+      the IEEE registration authority.  If no such address is available,
+
+
+
+Leach, et al.               Standards Track                     [Page 4]
+
+RFC 4122                  A UUID URN Namespace                 July 2005
+
+
+      or privacy concerns make its use undesirable, Section 4.5
+      specifies two alternatives.  Another approach is to use version 3
+      or version 4 UUIDs as defined below.
+
+   Process for identifier resolution:
+      Since UUIDs are not globally resolvable, this is not applicable.
+
+   Rules for Lexical Equivalence:
+      Consider each field of the UUID to be an unsigned integer as shown
+      in the table in section Section 4.1.2.  Then, to compare a pair of
+      UUIDs, arithmetically compare the corresponding fields from each
+      UUID in order of significance and according to their data type.
+      Two UUIDs are equal if and only if all the corresponding fields
+      are equal.
+
+      As an implementation note, equality comparison can be performed on
+      many systems by doing the appropriate byte-order canonicalization,
+      and then treating the two UUIDs as 128-bit unsigned integers.
+
+      UUIDs, as defined in this document, can also be ordered
+      lexicographically.  For a pair of UUIDs, the first one follows the
+      second if the most significant field in which the UUIDs differ is
+      greater for the first UUID.  The second precedes the first if the
+      most significant field in which the UUIDs differ is greater for
+      the second UUID.
+
+   Conformance with URN Syntax:
+      The string representation of a UUID is fully compatible with the
+      URN syntax.  When converting from a bit-oriented, in-memory
+      representation of a UUID into a URN, care must be taken to
+      strictly adhere to the byte order issues mentioned in the string
+      representation section.
+
+   Validation mechanism:
+      Apart from determining whether the timestamp portion of the UUID
+      is in the future and therefore not yet assignable, there is no
+      mechanism for determining whether a UUID is 'valid'.
+
+   Scope:
+      UUIDs are global in scope.
+
+4.  Specification
+
+4.1.  Format
+
+   The UUID format is 16 octets; some bits of the eight octet variant
+   field specified below determine finer structure.
+
+
+
+
+Leach, et al.               Standards Track                     [Page 5]
+
+RFC 4122                  A UUID URN Namespace                 July 2005
+
+
+4.1.1.  Variant
+
+   The variant field determines the layout of the UUID.  That is, the
+   interpretation of all other bits in the UUID depends on the setting
+   of the bits in the variant field.  As such, it could more accurately
+   be called a type field; we retain the original term for
+   compatibility.  The variant field consists of a variable number of
+   the most significant bits of octet 8 of the UUID.
+
+   The following table lists the contents of the variant field, where
+   the letter "x" indicates a "don't-care" value.
+
+   Msb0  Msb1  Msb2  Description
+
+    0     x     x    Reserved, NCS backward compatibility.
+
+    1     0     x    The variant specified in this document.
+
+    1     1     0    Reserved, Microsoft Corporation backward
+                     compatibility
+
+    1     1     1    Reserved for future definition.
+
+   Interoperability, in any form, with variants other than the one
+   defined here is not guaranteed, and is not likely to be an issue in
+   practice.
+
+4.1.2.  Layout and Byte Order
+
+   To minimize confusion about bit assignments within octets, the UUID
+   record definition is defined only in terms of fields that are
+   integral numbers of octets.  The fields are presented with the most
+   significant one first.
+
+   Field                  Data Type     Octet  Note
+                                        #
+
+   time_low               unsigned 32   0-3    The low field of the
+                          bit integer          timestamp
+
+   time_mid               unsigned 16   4-5    The middle field of the
+                          bit integer          timestamp
+
+   time_hi_and_version    unsigned 16   6-7    The high field of the
+                          bit integer          timestamp multiplexed
+                                               with the version number
+
+
+
+
+
+Leach, et al.               Standards Track                     [Page 6]
+
+RFC 4122                  A UUID URN Namespace                 July 2005
+
+
+   clock_seq_hi_and_rese  unsigned 8    8      The high field of the
+   rved                   bit integer          clock sequence
+                                               multiplexed with the
+                                               variant
+
+   clock_seq_low          unsigned 8    9      The low field of the
+                          bit integer          clock sequence
+
+   node                   unsigned 48   10-15  The spatially unique
+                          bit integer          node identifier
+
+   In the absence of explicit application or presentation protocol
+   specification to the contrary, a UUID is encoded as a 128-bit object,
+   as follows:
+
+   The fields are encoded as 16 octets, with the sizes and order of the
+   fields defined above, and with each field encoded with the Most
+   Significant Byte first (known as network byte order).  Note that the
+   field names, particularly for multiplexed fields, follow historical
+   practice.
+
+   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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                          time_low                             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |       time_mid                |         time_hi_and_version   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |clk_seq_hi_res |  clk_seq_low  |         node (0-1)            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         node (2-5)                            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+4.1.3.  Version
+
+   The version number is in the most significant 4 bits of the time
+   stamp (bits 4 through 7 of the time_hi_and_version field).
+
+   The following table lists the currently-defined versions for this
+   UUID variant.
+
+   Msb0  Msb1  Msb2  Msb3   Version  Description
+
+    0     0     0     1        1     The time-based version
+                                     specified in this document.
+
+    0     0     1     0        2     DCE Security version, with
+                                     embedded POSIX UIDs.
+
+
+
+Leach, et al.               Standards Track                     [Page 7]
+
+RFC 4122                  A UUID URN Namespace                 July 2005
+
+
+    0     0     1     1        3     The name-based version
+                                     specified in this document
+                                     that uses MD5 hashing.
+
+    0     1     0     0        4     The randomly or pseudo-
+                                     randomly generated version
+                                     specified in this document.
+
+    0     1     0     1        5     The name-based version
+                                     specified in this document
+                                     that uses SHA-1 hashing.
+
+   The version is more accurately a sub-type; again, we retain the term
+   for compatibility.
+
+4.1.4.  Timestamp
+
+   The timestamp is a 60-bit value.  For UUID version 1, this is
+   represented by Coordinated Universal Time (UTC) as a count of 100-
+   nanosecond intervals since 00:00:00.00, 15 October 1582 (the date of
+   Gregorian reform to the Christian calendar).
+
+   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
+   consistently throughout the system.  However, this is not recommended
+   since generating the UTC from local time only needs a time zone
+   offset.
+
+   For UUID version 3 or 5, the timestamp is a 60-bit value constructed
+   from a name as described in Section 4.3.
+
+   For UUID version 4, the timestamp is a randomly or pseudo-randomly
+   generated 60-bit value, as described in Section 4.4.
+
+4.1.5.  Clock Sequence
+
+   For UUID version 1, the clock sequence is used to help avoid
+   duplicates that could arise when the clock is set backwards in time
+   or if the node ID changes.
+
+   If the clock is set backwards, or might have been set backwards
+   (e.g., while the system was powered off), and the UUID generator can
+   not be sure that no UUIDs were generated with timestamps larger than
+   the value to which the clock was set, then the clock sequence has to
+   be changed.  If the previous value of the clock sequence is known, it
+   can just be incremented; otherwise it should be set to a random or
+   high-quality pseudo-random value.
+
+
+
+
+Leach, et al.               Standards Track                     [Page 8]
+
+RFC 4122                  A UUID URN Namespace                 July 2005
+
+
+   Similarly, if the node ID changes (e.g., because a network card has
+   been moved between machines), setting the clock sequence to a random
+   number minimizes the probability of a duplicate due to slight
+   differences in the clock settings of the machines.  If the value of
+   clock sequence associated with the changed node ID were known, then
+   the clock sequence could just be incremented, but that is unlikely.
+
+   The clock sequence MUST be originally (i.e., once in the lifetime of
+   a system) initialized to a random number to minimize the correlation
+   across systems.  This provides maximum protection against node
+   identifiers that may move or switch from system to system rapidly.
+   The initial value MUST NOT be correlated to the node identifier.
+
+   For UUID version 3 or 5, the clock sequence is a 14-bit value
+   constructed from a name as described in Section 4.3.
+
+   For UUID version 4, clock sequence is a randomly or pseudo-randomly
+   generated 14-bit value as described in Section 4.4.
+
+4.1.6.  Node
+
+   For UUID version 1, the node field consists of an IEEE 802 MAC
+   address, usually the host address.  For systems with multiple IEEE
+   802 addresses, any available one can be used.  The lowest addressed
+   octet (octet number 10) contains the global/local bit and the
+   unicast/multicast bit, and is the first octet of the address
+   transmitted on an 802.3 LAN.
+
+   For systems with no IEEE address, a randomly or pseudo-randomly
+   generated value may be used; see Section 4.5.  The multicast bit must
+   be set in such addresses, in order that they will never conflict with
+   addresses obtained from network cards.
+
+   For UUID version 3 or 5, the node field is a 48-bit value constructed
+   from a name as described in Section 4.3.
+
+   For UUID version 4, the node field is a randomly or pseudo-randomly
+   generated 48-bit value as described in Section 4.4.
+
+4.1.7.  Nil UUID
+
+   The nil UUID is special form of UUID that is specified to have all
+   128 bits set to zero.
+
+4.2.  Algorithms for Creating a Time-Based UUID
+
+   Various aspects of the algorithm for creating a version 1 UUID are
+   discussed in the following sections.
+
+
+
+Leach, et al.               Standards Track                     [Page 9]
+
+RFC 4122                  A UUID URN Namespace                 July 2005
+
+
+4.2.1.  Basic Algorithm
+
+   The following algorithm is simple, correct, and inefficient:
+
+   o  Obtain a system-wide global lock
+
+   o  From a system-wide shared stable store (e.g., a file), read the
+      UUID generator state: the values of the timestamp, clock sequence,
+      and node ID used to generate the last UUID.
+
+   o  Get the current time as a 60-bit count of 100-nanosecond intervals
+      since 00:00:00.00, 15 October 1582.
+
+   o  Get the current node ID.
+
+   o  If the state was unavailable (e.g., non-existent or corrupted), or
+      the saved node ID is different than the current node ID, generate
+      a random clock sequence value.
+
+   o  If the state was available, but the saved timestamp is later than
+      the current timestamp, increment the clock sequence value.
+
+   o  Save the state (current timestamp, clock sequence, and node ID)
+      back to the stable store.
+
+   o  Release the global lock.
+
+   o  Format a UUID from the current timestamp, clock sequence, and node
+      ID values according to the steps in Section 4.2.2.
+
+   If UUIDs do not need to be frequently generated, the above algorithm
+   may be perfectly adequate.  For higher performance requirements,
+   however, issues with the basic algorithm include:
+
+   o  Reading the state from stable storage each time is inefficient.
+
+   o  The resolution of the system clock may not be 100-nanoseconds.
+
+   o  Writing the state to stable storage each time is inefficient.
+
+   o  Sharing the state across process boundaries may be inefficient.
+
+   Each of these issues can be addressed in a modular fashion by local
+   improvements in the functions that read and write the state and read
+   the clock.  We address each of them in turn in the following
+   sections.
+
+
+
+
+
+Leach, et al.               Standards Track                    [Page 10]
+
+RFC 4122                  A UUID URN Namespace                 July 2005
+
+
+4.2.1.1.  Reading Stable Storage
+
+   The state only needs to be read from stable storage once at boot
+   time, if it is read into a system-wide shared volatile store (and
+   updated whenever the stable store is updated).
+
+   If an implementation does not have any stable store available, then
+   it can always say that the values were unavailable.  This is the
+   least desirable implementation because it will increase the frequency
+   of creation of new clock sequence numbers, which increases the
+   probability of duplicates.
+
+   If the node ID can never change (e.g., the net card is inseparable
+   from the system), or if any change also reinitializes the clock
+   sequence to a random value, then instead of keeping it in stable
+   store, the current node ID may be returned.
+
+4.2.1.2.  System Clock Resolution
+
+   The timestamp is generated from the system time, whose resolution may
+   be less than the resolution of the UUID timestamp.
+
+   If UUIDs do not need to be frequently generated, the timestamp can
+   simply be the system time multiplied by the number of 100-nanosecond
+   intervals per system time interval.
+
+   If a system overruns the generator by requesting too many UUIDs
+   within a single system time interval, the UUID service MUST either
+   return an error, or stall the UUID generator until the system clock
+   catches up.
+
+   A high resolution timestamp can be simulated by keeping a count of
+   the number of UUIDs that have been generated with the same value of
+   the system time, and using it to construct the low order bits of the
+   timestamp.  The count will range between zero and the number of
+   100-nanosecond intervals per system time interval.
+
+   Note: If the processors overrun the UUID generation frequently,
+   additional node identifiers can be allocated to the system, which
+   will permit higher speed allocation by making multiple UUIDs
+   potentially available for each time stamp value.
+
+4.2.1.3.  Writing Stable Storage
+
+   The state does not always need to be written to stable store every
+   time a UUID is generated.  The timestamp in the stable store can be
+   periodically set to a value larger than any yet used in a UUID.  As
+   long as the generated UUIDs have timestamps less than that value, and
+
+
+
+Leach, et al.               Standards Track                    [Page 11]
+
+RFC 4122                  A UUID URN Namespace                 July 2005
+
+
+   the clock sequence and node ID remain unchanged, only the shared
+   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
+   reinitialization of the clock sequence.
+
+4.2.1.4.  Sharing State Across Processes
+
+   If it is too expensive to access shared state each time a UUID is
+   generated, then the system-wide generator can be implemented to
+   allocate a block of time stamps each time it is called; a per-
+   process generator can allocate from that block until it is exhausted.
+
+4.2.2.  Generation Details
+
+   Version 1 UUIDs are generated according to the following algorithm:
+
+   o  Determine the values for the UTC-based timestamp and clock
+      sequence to be used in the UUID, as described in Section 4.2.1.
+
+   o  For the purposes of this algorithm, consider the timestamp to be a
+      60-bit unsigned integer and the clock sequence to be a 14-bit
+      unsigned integer.  Sequentially number the bits in a field,
+      starting with zero for the least significant bit.
+
+   o  Set the time_low field equal to the least significant 32 bits
+      (bits zero through 31) of the timestamp in the same order of
+      significance.
+
+   o  Set the time_mid field equal to bits 32 through 47 from the
+      timestamp in the same order of significance.
+
+   o  Set the 12 least significant bits (bits zero through 11) of the
+      time_hi_and_version field equal to bits 48 through 59 from the
+      timestamp in the same order of significance.
+
+   o  Set the four most significant bits (bits 12 through 15) of the
+      time_hi_and_version field to the 4-bit version number
+      corresponding to the UUID version being created, as shown in the
+      table above.
+
+   o  Set the clock_seq_low field to the eight least significant bits
+      (bits zero through 7) of the clock sequence in the same order of
+      significance.
+
+
+
+
+
+
+
+Leach, et al.               Standards Track                    [Page 12]
+
+RFC 4122                  A UUID URN Namespace                 July 2005
+
+
+   o  Set the 6 least significant bits (bits zero through 5) of the
+      clock_seq_hi_and_reserved field to the 6 most significant bits
+      (bits 8 through 13) of the clock sequence in the same order of
+      significance.
+
+   o  Set the two most significant bits (bits 6 and 7) of the
+      clock_seq_hi_and_reserved to zero and one, respectively.
+
+   o  Set the node field to the 48-bit IEEE address in the same order of
+      significance as the address.
+
+4.3.  Algorithm for Creating a Name-Based UUID
+
+   The version 3 or 5 UUID is meant for generating UUIDs from "names"
+   that are drawn from, and unique within, some "name space".  The
+   concept of name and name space should be broadly construed, and not
+   limited to textual names.  For example, some name spaces are the
+   domain name system, URLs, ISO Object IDs (OIDs), X.500 Distinguished
+   Names (DNs), and reserved words in a programming language.  The
+   mechanisms or conventions used for allocating names and ensuring
+   their uniqueness within their name spaces are beyond the scope of
+   this specification.
+
+   The requirements for these types of UUIDs are as follows:
+
+   o  The UUIDs generated at different times from the same name in the
+      same namespace MUST be equal.
+
+   o  The UUIDs generated from two different names in the same namespace
+      should be different (with very high probability).
+
+   o  The UUIDs generated from the same name in two different namespaces
+      should be different with (very high probability).
+
+   o  If two UUIDs that were generated from names are equal, then they
+      were generated from the same name in the same namespace (with very
+      high probability).
+
+   The algorithm for generating a UUID from a name and a name space are
+   as follows:
+
+   o  Allocate a UUID to use as a "name space ID" for all UUIDs
+      generated from names in that name space; see Appendix C for some
+      pre-defined values.
+
+   o  Choose either MD5 [4] or SHA-1 [8] as the hash algorithm; If
+      backward compatibility is not an issue, SHA-1 is preferred.
+
+
+
+
+Leach, et al.               Standards Track                    [Page 13]
+
+RFC 4122                  A UUID URN Namespace                 July 2005
+
+
+   o  Convert the name to a canonical sequence of octets (as defined by
+      the standards or conventions of its name space); put the name
+      space ID in network byte order.
+
+   o  Compute the hash of the name space ID concatenated with the name.
+
+   o  Set octets zero through 3 of the time_low field to octets zero
+      through 3 of the hash.
+
+   o  Set octets zero and one of the time_mid field to octets 4 and 5 of
+      the hash.
+
+   o  Set octets zero and one of the time_hi_and_version field to octets
+      6 and 7 of the hash.
+
+   o  Set the four most significant bits (bits 12 through 15) of the
+      time_hi_and_version field to the appropriate 4-bit version number
+      from Section 4.1.3.
+
+   o  Set the clock_seq_hi_and_reserved field to octet 8 of the hash.
+
+   o  Set the two most significant bits (bits 6 and 7) of the
+      clock_seq_hi_and_reserved to zero and one, respectively.
+
+   o  Set the clock_seq_low field to octet 9 of the hash.
+
+   o  Set octets zero through five of the node field to octets 10
+      through 15 of the hash.
+
+   o  Convert the resulting UUID to local byte order.
+
+4.4.  Algorithms for Creating a UUID from Truly Random or
+      Pseudo-Random Numbers
+
+   The version 4 UUID is meant for generating UUIDs from truly-random or
+   pseudo-random numbers.
+
+   The algorithm is as follows:
+
+   o  Set the two most significant bits (bits 6 and 7) of the
+      clock_seq_hi_and_reserved to zero and one, respectively.
+
+   o  Set the four most significant bits (bits 12 through 15) of the
+      time_hi_and_version field to the 4-bit version number from
+      Section 4.1.3.
+
+   o  Set all the other bits to randomly (or pseudo-randomly) chosen
+      values.
+
+
+
+Leach, et al.               Standards Track                    [Page 14]
+
+RFC 4122                  A UUID URN Namespace                 July 2005
+
+
+   See Section 4.5 for a discussion on random numbers.
+
+4.5.  Node IDs that Do Not Identify the Host
+
+   This section describes how to generate a version 1 UUID if an IEEE
+   802 address is not available, or its use is not desired.
+
+   One approach is to contact the IEEE and get a separate block of
+   addresses.  At the time of writing, the application could be found at
+   <http://standards.ieee.org/regauth/oui/pilot-ind.html>, and the cost
+   was US$550.
+
+   A better solution is to obtain a 47-bit cryptographic quality random
+   number and use it as the low 47 bits of the node ID, with the least
+   significant bit of the first octet of the node ID set to one.  This
+   bit is the unicast/multicast bit, which will never be set in IEEE 802
+   addresses obtained from network cards.  Hence, there can never be a
+   conflict between UUIDs generated by machines with and without network
+   cards.  (Recall that the IEEE 802 spec talks about transmission
+   order, which is the opposite of the in-memory representation that is
+   discussed in this document.)
+
+   For compatibility with earlier specifications, note that this
+   document uses the unicast/multicast bit, instead of the arguably more
+   correct local/global bit.
+
+   Advice on generating cryptographic-quality random numbers can be
+   found in RFC1750 [5].
+
+   In addition, items such as the computer's name and the name of the
+   operating system, while not strictly speaking random, will help
+   differentiate the results from those obtained by other systems.
+
+   The exact algorithm to generate a node ID using these data is system
+   specific, because both the data available and the functions to obtain
+   them are often very system specific.  A generic approach, however, is
+   to accumulate as many sources as possible into a buffer, use a
+   message digest such as MD5 [4] or SHA-1 [8], take an arbitrary 6
+   bytes from the hash value, and set the multicast bit as described
+   above.
+
+5.  Community Considerations
+
+   The use of UUIDs is extremely pervasive in computing.  They comprise
+   the core identifier infrastructure for many operating systems
+   (Microsoft Windows) and applications (the Mozilla browser) and in
+   many cases, become exposed to the Web in many non-standard ways.
+
+
+
+
+Leach, et al.               Standards Track                    [Page 15]
+
+RFC 4122                  A UUID URN Namespace                 July 2005
+
+
+   This specification attempts to standardize that practice as openly as
+   possible and in a way that attempts to benefit the entire Internet.
+
+6.  Security Considerations
+
+   Do not assume that UUIDs are hard to guess; they should not be used
+   as security capabilities (identifiers whose mere possession grants
+   access), for example.  A predictable random number source will
+   exacerbate the situation.
+
+   Do not assume that it is easy to determine if a UUID has been
+   slightly transposed in order to redirect a reference to another
+   object.  Humans do not have the ability to easily check the integrity
+   of a UUID by simply glancing at it.
+
+   Distributed applications generating UUIDs at a variety of hosts must
+   be willing to rely on the random number source at all hosts.  If this
+   is not feasible, the namespace variant should be used.
+
+7.  Acknowledgments
+
+   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).
+
+   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.
+
+8.  Normative References
+
+   [1]  Zahn, L., Dineen, T., and P. Leach, "Network Computing
+        Architecture", ISBN 0-13-611674-4, January 1990.
+
+   [2]  "DCE: Remote Procedure Call", Open Group CAE Specification C309,
+        ISBN 1-85912-041-5, August 1994.
+
+   [3]  ISO/IEC 9834-8:2004 Information Technology, "Procedures for the
+        operation of OSI Registration Authorities: Generation and
+        registration of Universally Unique Identifiers (UUIDs) and their
+        use as ASN.1 Object Identifier components" ITU-T Rec. X.667,
+        2004.
+
+   [4]  Rivest, R., "The MD5 Message-Digest Algorithm ", RFC 1321, April
+        1992.
+
+
+
+
+Leach, et al.               Standards Track                    [Page 16]
+
+RFC 4122                  A UUID URN Namespace                 July 2005
+
+
+   [5]  Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness
+        Requirements for Security", BCP 106, RFC 4086, June 2005.
+
+   [6]  Moats, R., "URN Syntax", RFC 2141, May 1997.
+
+   [7]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
+        Specifications: ABNF", RFC 2234, November 1997.
+
+   [8]  National Institute of Standards and Technology, "Secure Hash
+        Standard", FIPS PUB 180-1, April 1995,
+        <http://www.itl.nist.gov/fipspubs/fip180-1.htm>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Leach, et al.               Standards Track                    [Page 17]
+
+RFC 4122                  A UUID URN Namespace                 July 2005
+
+
+Appendix A.  Appendix A - Sample Implementation
+
+   This implementation consists of 5 files: uuid.h, uuid.c, sysdep.h,
+   sysdep.c and utest.c.  The uuid.* files are the system independent
+   implementation of the UUID generation algorithms described above,
+   with all the optimizations described above except efficient state
+   sharing across processes included.  The code has been tested on Linux
+   (Red Hat 4.0) with GCC (2.7.2), and Windows NT 4.0 with VC++ 5.0.
+   The code assumes 64-bit integer support, which makes it much clearer.
+
+   All the following source files should have the following copyright
+   notice included:
+
+copyrt.h
+
+/*
+** Copyright (c) 1990- 1993, 1996 Open Software Foundation, Inc.
+** Copyright (c) 1989 by Hewlett-Packard Company, Palo Alto, Ca. &
+** Digital Equipment Corporation, Maynard, Mass.
+** Copyright (c) 1998 Microsoft.
+** To anyone who acknowledges that this file is provided "AS IS"
+** without any express or implied warranty: permission to use, copy,
+** modify, and distribute this file for any purpose is hereby
+** granted without fee, provided that the above copyright notices and
+** this notice appears in all source code copies, and that none of
+** the names of Open Software Foundation, Inc., Hewlett-Packard
+** Company, Microsoft, or Digital Equipment Corporation be used in
+** advertising or publicity pertaining to distribution of the software
+** without specific, written prior permission. Neither Open Software
+** Foundation, Inc., Hewlett-Packard Company, Microsoft, nor Digital
+** Equipment Corporation makes any representations about the
+** suitability of this software for any purpose.
+*/
+
+
+uuid.h
+
+#include "copyrt.h"
+#undef uuid_t
+typedef struct {
+    unsigned32  time_low;
+    unsigned16  time_mid;
+    unsigned16  time_hi_and_version;
+    unsigned8   clock_seq_hi_and_reserved;
+    unsigned8   clock_seq_low;
+    byte        node[6];
+} uuid_t;
+
+
+
+
+Leach, et al.               Standards Track                    [Page 18]
+
+RFC 4122                  A UUID URN Namespace                 July 2005
+
+
+/* uuid_create -- generate a UUID */
+int uuid_create(uuid_t * uuid);
+
+/* uuid_create_md5_from_name -- create a version 3 (MD5) UUID using a
+   "name" from a "name space" */
+void uuid_create_md5_from_name(
+    uuid_t *uuid,         /* resulting UUID */
+    uuid_t nsid,          /* UUID of the namespace */
+    void *name,           /* the name from which to generate a UUID */
+    int namelen           /* the length of the name */
+);
+
+/* uuid_create_sha1_from_name -- create a version 5 (SHA-1) UUID
+   using a "name" from a "name space" */
+void uuid_create_sha1_from_name(
+
+    uuid_t *uuid,         /* resulting UUID */
+    uuid_t nsid,          /* UUID of the namespace */
+    void *name,           /* the name from which to generate a UUID */
+    int namelen           /* the length of the name */
+);
+
+/* uuid_compare --  Compare two UUID's "lexically" and return
+        -1   u1 is lexically before u2
+         0   u1 is equal to u2
+         1   u1 is lexically after u2
+   Note that lexical ordering is not temporal ordering!
+*/
+int uuid_compare(uuid_t *u1, uuid_t *u2);
+
+
+uuid.c
+
+#include "copyrt.h"
+#include <string.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <time.h>
+#include "sysdep.h"
+#include "uuid.h"
+
+/* various forward declarations */
+static int read_state(unsigned16 *clockseq, uuid_time_t *timestamp,
+    uuid_node_t *node);
+static void write_state(unsigned16 clockseq, uuid_time_t timestamp,
+    uuid_node_t node);
+static void format_uuid_v1(uuid_t *uuid, unsigned16 clockseq,
+    uuid_time_t timestamp, uuid_node_t node);
+
+
+
+Leach, et al.               Standards Track                    [Page 19]
+
+RFC 4122                  A UUID URN Namespace                 July 2005
+
+
+static void format_uuid_v3or5(uuid_t *uuid, unsigned char hash[16],
+    int v);
+static void get_current_time(uuid_time_t *timestamp);
+static unsigned16 true_random(void);
+
+/* uuid_create -- generator a UUID */
+int uuid_create(uuid_t *uuid)
+{
+     uuid_time_t timestamp, last_time;
+     unsigned16 clockseq;
+     uuid_node_t node;
+     uuid_node_t last_node;
+     int f;
+
+     /* acquire system-wide lock so we're alone */
+     LOCK;
+     /* get time, node ID, saved state from non-volatile storage */
+     get_current_time(&timestamp);
+     get_ieee_node_identifier(&node);
+     f = read_state(&clockseq, &last_time, &last_node);
+
+     /* if no NV state, or if clock went backwards, or node ID
+        changed (e.g., new network card) change clockseq */
+     if (!f || memcmp(&node, &last_node, sizeof node))
+         clockseq = true_random();
+     else if (timestamp < last_time)
+         clockseq++;
+
+     /* save the state for next time */
+     write_state(clockseq, timestamp, node);
+
+     UNLOCK;
+
+     /* stuff fields into the UUID */
+     format_uuid_v1(uuid, clockseq, timestamp, node);
+     return 1;
+}
+
+/* format_uuid_v1 -- make a UUID from the timestamp, clockseq,
+                     and node ID */
+void format_uuid_v1(uuid_t* uuid, unsigned16 clock_seq,
+                    uuid_time_t timestamp, uuid_node_t node)
+{
+    /* Construct a version 1 uuid with the information we've gathered
+       plus a few constants. */
+    uuid->time_low = (unsigned long)(timestamp & 0xFFFFFFFF);
+    uuid->time_mid = (unsigned short)((timestamp >> 32) & 0xFFFF);
+    uuid->time_hi_and_version =
+
+
+
+Leach, et al.               Standards Track                    [Page 20]
+
+RFC 4122                  A UUID URN Namespace                 July 2005
+
+
+        (unsigned short)((timestamp >> 48) & 0x0FFF);
+    uuid->time_hi_and_version |= (1 << 12);
+    uuid->clock_seq_low = clock_seq & 0xFF;
+    uuid->clock_seq_hi_and_reserved = (clock_seq & 0x3F00) >> 8;
+    uuid->clock_seq_hi_and_reserved |= 0x80;
+    memcpy(&uuid->node, &node, sizeof uuid->node);
+}
+
+/* data type for UUID generator persistent state */
+typedef struct {
+    uuid_time_t  ts;       /* saved timestamp */
+    uuid_node_t  node;     /* saved node ID */
+    unsigned16   cs;       /* saved clock sequence */
+} uuid_state;
+
+static uuid_state st;
+
+/* read_state -- read UUID generator state from non-volatile store */
+int read_state(unsigned16 *clockseq, uuid_time_t *timestamp,
+               uuid_node_t *node)
+{
+    static int inited = 0;
+    FILE *fp;
+
+    /* only need to read state once per boot */
+    if (!inited) {
+        fp = fopen("state", "rb");
+        if (fp == NULL)
+            return 0;
+        fread(&st, sizeof st, 1, fp);
+        fclose(fp);
+        inited = 1;
+    }
+    *clockseq = st.cs;
+    *timestamp = st.ts;
+    *node = st.node;
+    return 1;
+}
+
+/* write_state -- save UUID generator state back to non-volatile
+   storage */
+void write_state(unsigned16 clockseq, uuid_time_t timestamp,
+                 uuid_node_t node)
+{
+    static int inited = 0;
+    static uuid_time_t next_save;
+    FILE* fp;
+
+
+
+
+Leach, et al.               Standards Track                    [Page 21]
+
+RFC 4122                  A UUID URN Namespace                 July 2005
+
+
+    if (!inited) {
+        next_save = timestamp;
+        inited = 1;
+    }
+
+    /* always save state to volatile shared state */
+    st.cs = clockseq;
+    st.ts = timestamp;
+    st.node = node;
+    if (timestamp >= next_save) {
+        fp = fopen("state", "wb");
+        fwrite(&st, sizeof st, 1, fp);
+        fclose(fp);
+        /* schedule next save for 10 seconds from now */
+        next_save = timestamp + (10 * 10 * 1000 * 1000);
+    }
+}
+
+/* get-current_time -- get time as 60-bit 100ns ticks since UUID epoch.
+   Compensate for the fact that real clock resolution is
+   less than 100ns. */
+void get_current_time(uuid_time_t *timestamp)
+{
+    static int inited = 0;
+    static uuid_time_t time_last;
+    static unsigned16 uuids_this_tick;
+    uuid_time_t time_now;
+
+    if (!inited) {
+        get_system_time(&time_now);
+        uuids_this_tick = UUIDS_PER_TICK;
+        inited = 1;
+    }
+
+    for ( ; ; ) {
+        get_system_time(&time_now);
+
+        /* if clock reading changed since last UUID generated, */
+        if (time_last != time_now) {
+            /* reset count of uuids gen'd with this clock reading */
+            uuids_this_tick = 0;
+            time_last = time_now;
+            break;
+        }
+        if (uuids_this_tick < UUIDS_PER_TICK) {
+            uuids_this_tick++;
+            break;
+        }
+
+
+
+Leach, et al.               Standards Track                    [Page 22]
+
+RFC 4122                  A UUID URN Namespace                 July 2005
+
+
+        /* going too fast for our clock; spin */
+    }
+    /* add the count of uuids to low order bits of the clock reading */
+    *timestamp = time_now + uuids_this_tick;
+}
+
+/* true_random -- generate a crypto-quality random number.
+   **This sample doesn't do that.** */
+static unsigned16 true_random(void)
+{
+    static int inited = 0;
+    uuid_time_t time_now;
+
+    if (!inited) {
+        get_system_time(&time_now);
+        time_now = time_now / UUIDS_PER_TICK;
+        srand((unsigned int)
+               (((time_now >> 32) ^ time_now) & 0xffffffff));
+        inited = 1;
+    }
+
+    return rand();
+}
+
+/* uuid_create_md5_from_name -- create a version 3 (MD5) UUID using a
+   "name" from a "name space" */
+void uuid_create_md5_from_name(uuid_t *uuid, uuid_t nsid, void *name,
+                               int namelen)
+{
+    MD5_CTX c;
+    unsigned char hash[16];
+    uuid_t net_nsid;
+
+    /* put name space ID in network byte order so it hashes the same
+       no matter what endian machine we're on */
+    net_nsid = nsid;
+    net_nsid.time_low = htonl(net_nsid.time_low);
+    net_nsid.time_mid = htons(net_nsid.time_mid);
+    net_nsid.time_hi_and_version = htons(net_nsid.time_hi_and_version);
+
+    MD5Init(&c);
+    MD5Update(&c, &net_nsid, sizeof net_nsid);
+    MD5Update(&c, name, namelen);
+    MD5Final(hash, &c);
+
+    /* the hash is in network byte order at this point */
+    format_uuid_v3or5(uuid, hash, 3);
+}
+
+
+
+Leach, et al.               Standards Track                    [Page 23]
+
+RFC 4122                  A UUID URN Namespace                 July 2005
+
+
+void uuid_create_sha1_from_name(uuid_t *uuid, uuid_t nsid, void *name,
+                                int namelen)
+{
+    SHA_CTX c;
+    unsigned char hash[20];
+    uuid_t net_nsid;
+
+    /* put name space ID in network byte order so it hashes the same
+       no matter what endian machine we're on */
+    net_nsid = nsid;
+    net_nsid.time_low = htonl(net_nsid.time_low);
+    net_nsid.time_mid = htons(net_nsid.time_mid);
+    net_nsid.time_hi_and_version = htons(net_nsid.time_hi_and_version);
+
+    SHA1_Init(&c);
+    SHA1_Update(&c, &net_nsid, sizeof net_nsid);
+    SHA1_Update(&c, name, namelen);
+    SHA1_Final(hash, &c);
+
+    /* the hash is in network byte order at this point */
+    format_uuid_v3or5(uuid, hash, 5);
+}
+
+/* format_uuid_v3or5 -- make a UUID from a (pseudo)random 128-bit
+   number */
+void format_uuid_v3or5(uuid_t *uuid, unsigned char hash[16], int v)
+{
+    /* convert UUID to local byte order */
+    memcpy(uuid, hash, sizeof *uuid);
+    uuid->time_low = ntohl(uuid->time_low);
+    uuid->time_mid = ntohs(uuid->time_mid);
+    uuid->time_hi_and_version = ntohs(uuid->time_hi_and_version);
+
+    /* put in the variant and version bits */
+    uuid->time_hi_and_version &= 0x0FFF;
+    uuid->time_hi_and_version |= (v << 12);
+    uuid->clock_seq_hi_and_reserved &= 0x3F;
+    uuid->clock_seq_hi_and_reserved |= 0x80;
+}
+
+/* uuid_compare --  Compare two UUID's "lexically" and return */
+#define CHECK(f1, f2) if (f1 != f2) return f1 < f2 ? -1 : 1;
+int uuid_compare(uuid_t *u1, uuid_t *u2)
+{
+    int i;
+
+    CHECK(u1->time_low, u2->time_low);
+    CHECK(u1->time_mid, u2->time_mid);
+
+
+
+Leach, et al.               Standards Track                    [Page 24]
+
+RFC 4122                  A UUID URN Namespace                 July 2005
+
+
+    CHECK(u1->time_hi_and_version, u2->time_hi_and_version);
+    CHECK(u1->clock_seq_hi_and_reserved, u2->clock_seq_hi_and_reserved);
+    CHECK(u1->clock_seq_low, u2->clock_seq_low)
+    for (i = 0; i < 6; i++) {
+        if (u1->node[i] < u2->node[i])
+            return -1;
+        if (u1->node[i] > u2->node[i])
+            return 1;
+    }
+    return 0;
+}
+#undef CHECK
+
+
+sysdep.h
+
+#include "copyrt.h"
+/* remove the following define if you aren't running WIN32 */
+#define WININC 0
+
+#ifdef WININC
+#include <windows.h>
+#else
+#include <sys/types.h>
+#include <sys/time.h>
+#include <sys/sysinfo.h>
+#endif
+
+#include "global.h"
+/* change to point to where MD5 .h's live; RFC 1321 has sample
+   implementation */
+#include "md5.h"
+
+/* set the following to the number of 100ns ticks of the actual
+   resolution of your system's clock */
+#define UUIDS_PER_TICK 1024
+
+/* Set the following to a calls to get and release a global lock */
+#define LOCK
+#define UNLOCK
+
+typedef unsigned long   unsigned32;
+typedef unsigned short  unsigned16;
+typedef unsigned char   unsigned8;
+typedef unsigned char   byte;
+
+/* Set this to what your compiler uses for 64-bit data type */
+#ifdef WININC
+
+
+
+Leach, et al.               Standards Track                    [Page 25]
+
+RFC 4122                  A UUID URN Namespace                 July 2005
+
+
+#define unsigned64_t unsigned __int64
+#define I64(C) C
+#else
+#define unsigned64_t unsigned long long
+#define I64(C) C##LL
+#endif
+
+typedef unsigned64_t uuid_time_t;
+typedef struct {
+    char nodeID[6];
+} uuid_node_t;
+
+void get_ieee_node_identifier(uuid_node_t *node);
+void get_system_time(uuid_time_t *uuid_time);
+void get_random_info(char seed[16]);
+
+
+sysdep.c
+
+#include "copyrt.h"
+#include <stdio.h>
+#include "sysdep.h"
+
+/* system dependent call to get IEEE node ID.
+   This sample implementation generates a random node ID. */
+void get_ieee_node_identifier(uuid_node_t *node)
+{
+    static inited = 0;
+    static uuid_node_t saved_node;
+    char seed[16];
+    FILE *fp;
+
+    if (!inited) {
+        fp = fopen("nodeid", "rb");
+        if (fp) {
+            fread(&saved_node, sizeof saved_node, 1, fp);
+            fclose(fp);
+        }
+        else {
+            get_random_info(seed);
+            seed[0] |= 0x01;
+            memcpy(&saved_node, seed, sizeof saved_node);
+            fp = fopen("nodeid", "wb");
+            if (fp) {
+                fwrite(&saved_node, sizeof saved_node, 1, fp);
+                fclose(fp);
+            }
+        }
+
+
+
+Leach, et al.               Standards Track                    [Page 26]
+
+RFC 4122                  A UUID URN Namespace                 July 2005
+
+
+        inited = 1;
+    }
+
+    *node = saved_node;
+}
+
+/* system dependent call to get the current system time. Returned as
+   100ns ticks since UUID epoch, but resolution may be less than
+   100ns. */
+#ifdef _WINDOWS_
+
+void get_system_time(uuid_time_t *uuid_time)
+{
+    ULARGE_INTEGER time;
+
+    /* NT keeps time in FILETIME format which is 100ns ticks since
+       Jan 1, 1601. UUIDs use time in 100ns ticks since Oct 15, 1582.
+       The difference is 17 Days in Oct + 30 (Nov) + 31 (Dec)
+       + 18 years and 5 leap days. */
+    GetSystemTimeAsFileTime((FILETIME *)&time);
+    time.QuadPart +=
+
+          (unsigned __int64) (1000*1000*10)       // seconds
+        * (unsigned __int64) (60 * 60 * 24)       // days
+        * (unsigned __int64) (17+30+31+365*18+5); // # of days
+    *uuid_time = time.QuadPart;
+}
+
+/* Sample code, not for use in production; see RFC 1750 */
+void get_random_info(char seed[16])
+{
+    MD5_CTX c;
+    struct {
+        MEMORYSTATUS m;
+        SYSTEM_INFO s;
+        FILETIME t;
+        LARGE_INTEGER pc;
+        DWORD tc;
+        DWORD l;
+        char hostname[MAX_COMPUTERNAME_LENGTH + 1];
+    } r;
+
+    MD5Init(&c);
+    GlobalMemoryStatus(&r.m);
+    GetSystemInfo(&r.s);
+    GetSystemTimeAsFileTime(&r.t);
+    QueryPerformanceCounter(&r.pc);
+    r.tc = GetTickCount();
+
+
+
+Leach, et al.               Standards Track                    [Page 27]
+
+RFC 4122                  A UUID URN Namespace                 July 2005
+
+
+    r.l = MAX_COMPUTERNAME_LENGTH + 1;
+    GetComputerName(r.hostname, &r.l);
+    MD5Update(&c, &r, sizeof r);
+    MD5Final(seed, &c);
+}
+
+#else
+
+void get_system_time(uuid_time_t *uuid_time)
+{
+    struct timeval tp;
+
+    gettimeofday(&tp, (struct timezone *)0);
+
+    /* Offset between UUID formatted times and Unix formatted times.
+       UUID UTC base time is October 15, 1582.
+       Unix base time is January 1, 1970.*/
+    *uuid_time = ((unsigned64)tp.tv_sec * 10000000)
+        + ((unsigned64)tp.tv_usec * 10)
+        + I64(0x01B21DD213814000);
+}
+
+/* Sample code, not for use in production; see RFC 1750 */
+void get_random_info(char seed[16])
+{
+    MD5_CTX c;
+    struct {
+        struct sysinfo s;
+        struct timeval t;
+        char hostname[257];
+    } r;
+
+    MD5Init(&c);
+    sysinfo(&r.s);
+    gettimeofday(&r.t, (struct timezone *)0);
+    gethostname(r.hostname, 256);
+    MD5Update(&c, &r, sizeof r);
+    MD5Final(seed, &c);
+}
+
+#endif
+
+utest.c
+
+#include "copyrt.h"
+#include "sysdep.h"
+#include <stdio.h>
+#include "uuid.h"
+
+
+
+Leach, et al.               Standards Track                    [Page 28]
+
+RFC 4122                  A UUID URN Namespace                 July 2005
+
+
+uuid_t NameSpace_DNS = { /* 6ba7b810-9dad-11d1-80b4-00c04fd430c8 */
+    0x6ba7b810,
+    0x9dad,
+    0x11d1,
+    0x80, 0xb4, 0x00, 0xc0, 0x4f, 0xd4, 0x30, 0xc8
+};
+
+/* puid -- print a UUID */
+void puid(uuid_t u)
+{
+    int i;
+
+    printf("%8.8x-%4.4x-%4.4x-%2.2x%2.2x-", u.time_low, u.time_mid,
+    u.time_hi_and_version, u.clock_seq_hi_and_reserved,
+    u.clock_seq_low);
+    for (i = 0; i < 6; i++)
+        printf("%2.2x", u.node[i]);
+    printf("\n");
+}
+
+/* Simple driver for UUID generator */
+void main(int argc, char **argv)
+{
+    uuid_t u;
+    int f;
+
+    uuid_create(&u);
+    printf("uuid_create(): "); puid(u);
+
+    f = uuid_compare(&u, &u);
+    printf("uuid_compare(u,u): %d\n", f);     /* should be 0 */
+    f = uuid_compare(&u, &NameSpace_DNS);
+    printf("uuid_compare(u, NameSpace_DNS): %d\n", f); /* s.b. 1 */
+    f = uuid_compare(&NameSpace_DNS, &u);
+    printf("uuid_compare(NameSpace_DNS, u): %d\n", f); /* s.b. -1 */
+    uuid_create_md5_from_name(&u, NameSpace_DNS, "www.widgets.com", 15);
+    printf("uuid_create_md5_from_name(): "); puid(u);
+}
+
+Appendix B.  Appendix B - Sample Output of utest
+
+     uuid_create(): 7d444840-9dc0-11d1-b245-5ffdce74fad2
+     uuid_compare(u,u): 0
+     uuid_compare(u, NameSpace_DNS): 1
+     uuid_compare(NameSpace_DNS, u): -1
+     uuid_create_md5_from_name(): e902893a-9d22-3c7e-a7b8-d6e313b71d9f
+
+
+
+
+
+Leach, et al.               Standards Track                    [Page 29]
+
+RFC 4122                  A UUID URN Namespace                 July 2005
+
+
+Appendix C.  Appendix C - Some Name Space IDs
+
+   This appendix lists the name space IDs for some potentially
+   interesting name spaces, as initialized C structures and in the
+   string representation defined above.
+
+   /* Name string is a fully-qualified domain name */
+   uuid_t NameSpace_DNS = { /* 6ba7b810-9dad-11d1-80b4-00c04fd430c8 */
+       0x6ba7b810,
+       0x9dad,
+       0x11d1,
+       0x80, 0xb4, 0x00, 0xc0, 0x4f, 0xd4, 0x30, 0xc8
+   };
+
+   /* Name string is a URL */
+   uuid_t NameSpace_URL = { /* 6ba7b811-9dad-11d1-80b4-00c04fd430c8 */
+       0x6ba7b811,
+       0x9dad,
+       0x11d1,
+       0x80, 0xb4, 0x00, 0xc0, 0x4f, 0xd4, 0x30, 0xc8
+   };
+
+   /* Name string is an ISO OID */
+   uuid_t NameSpace_OID = { /* 6ba7b812-9dad-11d1-80b4-00c04fd430c8 */
+       0x6ba7b812,
+       0x9dad,
+       0x11d1,
+       0x80, 0xb4, 0x00, 0xc0, 0x4f, 0xd4, 0x30, 0xc8
+   };
+
+   /* Name string is an X.500 DN (in DER or a text output format) */
+   uuid_t NameSpace_X500 = { /* 6ba7b814-9dad-11d1-80b4-00c04fd430c8 */
+       0x6ba7b814,
+       0x9dad,
+       0x11d1,
+       0x80, 0xb4, 0x00, 0xc0, 0x4f, 0xd4, 0x30, 0xc8
+   };
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Leach, et al.               Standards Track                    [Page 30]
+
+RFC 4122                  A UUID URN Namespace                 July 2005
+
+
+Authors' Addresses
+
+   Paul J. Leach
+   Microsoft
+   1 Microsoft Way
+   Redmond, WA  98052
+   US
+
+   Phone: +1 425-882-8080
+   EMail: paulle@microsoft.com
+
+
+   Michael Mealling
+   Refactored Networks, LLC
+   1635 Old Hwy 41
+   Suite 112, Box 138
+   Kennesaw, GA 30152
+   US
+
+   Phone: +1-678-581-9656
+   EMail: michael@refactored-networks.com
+   URI: http://www.refactored-networks.com
+
+
+   Rich Salz
+   DataPower Technology, Inc.
+   1 Alewife Center
+   Cambridge, MA  02142
+   US
+
+   Phone: +1 617-864-0455
+   EMail: rsalz@datapower.com
+   URI:   http://www.datapower.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Leach, et al.               Standards Track                    [Page 31]
+
+RFC 4122                  A UUID URN Namespace                 July 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Leach, et al.               Standards Track                    [Page 32]
+