In order to guarantee uniqueness across all resources for all time
   the opaquelocktoken requires the use of the Universal Unique
   Identifier (UUID) mechanism, as described in [ISO-11578].

   Opaquelocktoken generators, however, have a choice of how they create
   these tokens.  They can either generate a new UUID for every lock
   token they create or they can create a single UUID  and then add
   extension characters.  If the second method is selected then the
   program generating the extensions MUST guarantee that the same
   extension will never be used twice with the associated UUID.

   OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension]  ; The UUID
   production is the string representation of a UUID, as defined in
   [ISO-11578]. Note that white space (LWS) is not allowed between
   elements of this production.

   Extension = path  ; path is defined in section 3.2.1 of RFC 2068
   [RFC2068]

6.4.1 Node Field Generation Without the IEEE 802 Address

   UUIDs, as defined in [ISO-11578], contain a "node" field that
   contains one of the IEEE 802 addresses for the server machine.  As
   noted in section 17.8, there are several security risks associated
   with exposing a machine's IEEE 802 address. This section provides an
   alternate mechanism for generating the "node" field of a UUID which
   does not employ an IEEE 802 address.  WebDAV servers MAY use this
   algorithm for creating the node field when generating UUIDs.  The
   text in this section isoriginally from an Internet-Draft by Paul
   Leach and Rich Salz, who are noted here to properly attribute their
   work.

   The ideal 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 most
   significant bit of the first octet of the node ID set to 1.  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.

   If a system does not have a primitive to generate cryptographic
   quality random numbers, then in most systems there are usually a
   fairly large number of sources of randomness available from which one
   can be generated. Such sources are system specific, but often
   include:







 
RFC 2518                         WEBDAV                    February 1999


     - the percent of memory in use
     - the size of main memory in bytes
     - the amount of free main memory in bytes
     - the size of the paging or swap file in bytes
     - free bytes of paging or swap file
     - the total size of user virtual address space in bytes
     - the total available user address space bytes
     - the size of boot disk drive in bytes
     - the free disk space on boot drive in bytes
     - the current time
     - the amount of time since the system booted
     - the individual sizes of files in various system directories
     - the creation, last read, and modification times of files in
       various system directories
     - the utilization factors of various system resources (heap, etc.)
     - current mouse cursor position
     - current caret position
     - current number of running processes, threads
     - handles or IDs of the desktop window and the active window
     - the value of stack pointer of the caller
     - the process and thread ID of caller
     - various processor architecture specific performance counters
       (instructions executed, cache misses, TLB misses)

   (Note that it is precisely the above kinds of sources of randomness
   that are used to seed cryptographic quality random number generators
   on systems without special hardware for their construction.)

   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. However, assuming that one can
   concatenate all the values from the randomness sources into a buffer,
   and that a cryptographic hash function such as MD5 is available, then
   any 6 bytes of the MD5 hash of the buffer, with the multicast bit
   (the high bit of the first byte) set will be an appropriately random
   node ID.

   Other hash functions, such as SHA-1, can also be used. The only
   requirement is that the result be suitably random _ in the sense that