oidspecs: adding OID specifications from RFC4530

2 files changed, 768 insertions, 0 deletions

diff --git a/doc/oidspecs/rfc/rfc4530.oidspec b/doc/oidspecs/rfc/rfc4530.oidspec
new file mode 100644
index 0000000..6e88524
--- /dev/null
+++ b/doc/oidspecs/rfc/rfc4530.oidspec
@@ -0,0 +1,317 @@
+
+
+{
+   //
+   // RFC 4122                  A UUID URN Namespace                 July 2005
+   //
+   // 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.
+   // 
+   //       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,
+   //       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.
+   //
+   //
+   // RFC 4530                     LDAP entryUUID                    June 2006
+   // 
+   // 2.1.  UUID Syntax
+   // 
+   //    A Universally Unique Identifier (UUID) [RFC4122] is a 16-octet (128-
+   //    bit) value that identifies an object.  The ASN.1 [X.680] type UUID is
+   //    defined to represent UUIDs as follows:
+   // 
+   //        UUID ::= OCTET STRING (SIZE(16))
+   //              -- constrained to an UUID [RFC4122]
+   //        
+   //    In LDAP, UUID values are encoded using the [ASCII] character string
+   //    representation described in [RFC4122].  For example,
+   //    "597ae2f6-16a6-1027-98f4-d28b5365dc14".
+   // 
+   //    The following is an LDAP syntax description suitable for publication
+   //    in subschema subentries.
+   // 
+   //        ( 1.3.6.1.1.16.1 DESC 'UUID' )
+   // 
+   .oid           =  "1.3.6.1.1.16.1",
+   .name          =  "UUID",
+   .desc          =  "UUID",
+   .flags         =  LDAPSCHEMA_O_READABLE,
+   .type          =  LDAPSCHEMA_SYNTAX,
+   .class         =  LDAPSCHEMA_CLASS_ASCII,
+   .def           =  "( 1.3.6.1.1.16.1 DESC 'UUID' )",
+   .abnf          =  "UUID                   = time-low \"-\" time-mid \"-\"\n"
+                     "                         time-high-and-version \"-\"\n"
+                     "                         clock-seq-and-reserved\n"
+                     "                         clock-seq-low \"-\" node\n"
+                     "time-low               = 4hexOctet\n"
+                     "time-mid               = 2hexOctet\n"
+                     "time-high-and-version  = 2hexOctet\n"
+                     "clock-seq-and-reserved = hexOctet\n"
+                     "clock-seq-low          = hexOctet\n"
+                     "node                   = 6hexOctet\n"
+                     "hexOctet               = hexDigit hexDigit\n"
+                     "hexDigit =\n"
+                     "      \"0\" / \"1\" / \"2\" / \"3\" / \"4\" / \"5\" / \"6\" / \"7\" / \"8\" / \"9\" /\n"
+                     "      \"a\" / \"b\" / \"c\" / \"d\" / \"e\" / \"f\" /\n"
+                     "      \"A\" / \"B\" / \"C\" / \"D\" / \"E\" / \"F\"\n",
+   .re_posix      =  NULL,
+   .re_pcre       =  NULL,
+   .spec          =  "RFC 4530: LDAP entryUUID",
+   .spec_type     =  LDAPSCHEMA_SPEC_RFC,
+   .spec_name     =  "4530",
+   .spec_section  =  "2.1",
+   .spec_source   =  NULL,
+   .spec_vendor   =  "IETF",
+   .spec_text     =  NULL,
+   .notes         =  NULL,
+   .examples      =  (const char *[])
+                     {
+                        "597ae2f6-16a6-1027-98f4-d28b5365dc14",
+                        NULL,
+                     },
+};
+
+
+
+
+{
+   //
+   // RFC 4530                     LDAP entryUUID                    June 2006
+   // 
+   // 2.2.  'uuidMatch' Matching Rule
+   // 
+   //    The 'uuidMatch' matching rule compares an asserted UUID with a stored
+   //    UUID for equality.  Its semantics are the same as the
+   //    'octetStringMatch' [X.520][RFC4517] matching rule.  The rule differs
+   //    from 'octetStringMatch' in that the assertion value is encoded using
+   //    the UUID string representation instead of the normal OCTET STRING
+   //    string representation.
+   // 
+   //    The following is an LDAP matching rule description suitable for
+   //    publication in subschema subentries.
+   // 
+   //        ( 1.3.6.1.1.16.2 NAME 'uuidMatch'
+   //            SYNTAX 1.3.6.1.1.16.1 )
+   //
+   .oid           =  "1.3.6.1.1.16.2",
+   .name          =  "uuidMatch",
+   .desc          =  "'uuidMatch' Matching Rule",
+   .flags         =  0,
+   .type          =  LDAPSCHEMA_MATCHINGRULE,
+   .def           =  "( 1.3.6.1.1.16.2 NAME 'uuidMatch' SYNTAX 1.3.6.1.1.16.1 )",
+   .spec          =  "RFC 4530: LDAP entryUUID",
+   .spec_type     =  LDAPSCHEMA_SPEC_RFC,
+   .spec_name     =  "4530",
+   .spec_section  =  "2.2",
+   .spec_source   =  NULL,
+   .spec_vendor   =  "IETF",
+   .spec_text     =  NULL,
+   .notes         =  NULL,
+   .examples      =  NULL,
+};
+
+
+
+{
+   //
+   // RFC 4530                     LDAP entryUUID                    June 2006
+   // 
+   // 2.3.  'uuidOrderingMatch' Matching Rule
+   // 
+   //    The 'uuidOrderingMatch' matching rule compares an asserted UUID with
+   //    a stored UUID for ordering.  Its semantics are the same as the
+   //    'octetStringOrderingMatch' [X.520][RFC4517] matching rule.  The rule
+   //    differs from 'octetStringOrderingMatch' in that the assertion value
+   //    is encoded using the UUID string representation instead of the normal
+   //    OCTET STRING string representation.
+   // 
+   //   The following is an LDAP matching rule description suitable for
+   //    publication in subschema subentries.
+   // 
+   //        ( 1.3.6.1.1.16.3 NAME 'uuidOrderingMatch'
+   //            SYNTAX 1.3.6.1.1.16.1 )
+   //      
+   //    Note that not all UUID variants have a defined ordering; and even
+   //    where it does, servers are not obligated to assign UUIDs in any
+   //    particular order.  This matching rule is provided for completeness.
+   //
+   .oid           =  "1.3.6.1.1.16.3",
+   .name          =  "uuidOrderingMatch",                                           
+   .desc          =  "'uuidOrderingMatch' Matching Rule",
+   .flags         =  0,                                 
+   .type          =  LDAPSCHEMA_MATCHINGRULE,
+   .def           =  "( 1.3.6.1.1.16.3 NAME 'uuidOrderingMatch' SYNTAX 1.3.6.1.1.16.1 )",
+   .spec          =  "RFC 4530: LDAP entryUUID",
+   .spec_type     =  LDAPSCHEMA_SPEC_RFC,                                   
+   .spec_name     =  "4530",
+   .spec_section  =  "2.3",
+   .spec_source   =  NULL,                                                  
+   .spec_vendor   =  "IETF",                                                
+   .spec_text     =  NULL,                                                  
+   .notes         =  NULL,                                                  
+   .examples      =  NULL,
+};  
+
+
+
+{
+   //
+   // RFC 4530                     LDAP entryUUID                    June 2006
+   // 
+   // 2.4.  'entryUUID' Attribute
+   // 
+   //    The 'entryUUID' operational attribute provides the Universally Unique
+   //    Identifier (UUID) assigned to the entry. 
+   // 
+   //    The following is an LDAP attribute type description suitable for
+   //    publication in subschema subentries.
+   // 
+   //        ( 1.3.6.1.1.16.4 NAME 'entryUUID'
+   //            DESC 'UUID of the entry'
+   //            EQUALITY uuidMatch
+   //            ORDERING uuidOrderingMatch
+   //            SYNTAX 1.3.6.1.1.16.1
+   //            SINGLE-VALUE
+   //            NO-USER-MODIFICATION
+   //            USAGE directoryOperation )
+   //      
+   //    Servers SHALL generate and assign a new UUID to each entry upon its
+   //    addition to the directory and provide that UUID as the value of the
+   //    'entryUUID' operational attribute.  An entry's UUID is immutable.
+   // 
+   //    UUID are to be generated in accordance with Section 4 of [RFC4122].
+   //    In particular, servers MUST ensure that each generated UUID is unique
+   //    in space and time.
+   //
+   .oid           =  "1.3.6.1.1.16.4",
+   .name          =  "entryUUID",
+   .desc          =  "UUID of the entry",
+   .flags         =  LDAPSCHEMA_O_READABLE | LDAPSCHEMA_O_SINGLEVALUE | LDAPSCHEMA_O_NO_USER_MOD,
+   .type          =  LDAPSCHEMA_ATTRIBUTETYPE,
+   .def           =  "( 1.3.6.1.1.16.4 NAME 'entryUUID' DESC 'UUID of the entry' EQUALITY uuidMatch ORDERING uuidOrderingMatch SYNTAX 1.3.6.1.1.16.1 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )",
+   .spec          =  "RFC 4530: LDAP entryUUID",
+   .spec_type     =  LDAPSCHEMA_SPEC_RFC,
+   .spec_name     =  "4530",
+   .spec_section  =  "2.4",
+   .spec_source   =  NULL,
+   .spec_vendor   =  "IETF",
+   .spec_text     =  NULL,
+   .notes         =  NULL,
+   .examples      =  NULL,
+};
+
+
+
+
+
+// end of OID spec file
diff --git a/doc/rfc/rfc4530.txt b/doc/rfc/rfc4530.txt
new file mode 100644
index 0000000..219a7c2
--- /dev/null
+++ b/doc/rfc/rfc4530.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                        K. Zeilenga
+Request for Comments: 4530                           OpenLDAP Foundation
+Category: Standards Track                                      June 2006
+
+
+              Lightweight Directory Access Protocol (LDAP)
+                    entryUUID Operational Attribute
+
+
+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 (2006).
+
+Abstract
+
+   This document describes the LDAP/X.500 'entryUUID' operational
+   attribute and associated matching rules and syntax.  The attribute
+   holds a server-assigned Universally Unique Identifier (UUID) for the
+   object.  Directory clients may use this attribute to distinguish
+   objects identified by a distinguished name or to locate an object
+   after renaming.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 1]
+
+RFC 4530                     LDAP entryUUID                    June 2006
+
+
+Table of Contents
+
+   1. Background and Intended Use .....................................2
+   2. UUID Schema Elements ............................................3
+      2.1. UUID Syntax ................................................3
+      2.2. 'uuidMatch' Matching Rule ..................................3
+      2.3. 'uuidOrderingMatch' Matching Rule ..........................3
+      2.4. 'entryUUID' Attribute ......................................4
+   3. Security Considerations .........................................4
+   4. IANA Considerations .............................................5
+      4.1. Object Identifier Registration .............................5
+      4.2. UUID Syntax Registration ...................................5
+      4.3. 'uuidMatch' Descriptor Registration ........................5
+      4.4. 'uuidOrderingMatch' Descriptor Registration ................5
+      4.5. 'entryUUID' Descriptor Registration ........................6
+   5. Acknowledgements ................................................6
+   6. References ......................................................6
+      6.1. Normative References .......................................6
+      6.2. Informative References .....................................7
+
+1.  Background and Intended Use
+
+   In X.500 Directory Services [X.501], such as those accessible using
+   the Lightweight Directory Access Protocol (LDAP) [RFC4510], an object
+   is identified by its distinguished name (DN).  However, DNs are not
+   stable identifiers.  That is, a new object may be identified by a DN
+   that previously identified another (now renamed or deleted) object.
+
+   A Universally Unique Identifier (UUID) is "an identifier unique
+   across both space and time, with respect to the space of all UUIDs"
+   [RFC4122].  UUIDs are used in a wide range of systems.
+
+   This document describes the 'entryUUID' operational attribute, which
+   holds the UUID assigned to the object by the server.  Clients may use
+   this attribute to distinguish objects identified by a particular
+   distinguished name or to locate a particular object after renaming.
+
+   This document defines the UUID syntax, the 'uuidMatch' and
+   'uuidOrderingMatch' matching rules, and the 'entryUUID' attribute
+   type.
+
+   Schema definitions are provided using LDAP description formats
+   [RFC4512].  Definitions provided here are formatted (line wrapped)
+   for readability.
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 2]
+
+RFC 4530                     LDAP entryUUID                    June 2006
+
+
+   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
+   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
+   and "OPTIONAL" are to be interpreted as described in BCP 14
+   [RFC2119].
+
+2.  UUID Schema Elements
+
+2.1.  UUID Syntax
+
+   A Universally Unique Identifier (UUID) [RFC4122] is a 16-octet (128-
+   bit) value that identifies an object.  The ASN.1 [X.680] type UUID is
+   defined to represent UUIDs as follows:
+
+       UUID ::= OCTET STRING (SIZE(16))
+             -- constrained to an UUID [RFC4122]
+
+   In LDAP, UUID values are encoded using the [ASCII] character string
+   representation described in [RFC4122].  For example,
+   "597ae2f6-16a6-1027-98f4-d28b5365dc14".
+
+   The following is an LDAP syntax description suitable for publication
+   in subschema subentries.
+
+       ( 1.3.6.1.1.16.1 DESC 'UUID' )
+
+2.2.  'uuidMatch' Matching Rule
+
+   The 'uuidMatch' matching rule compares an asserted UUID with a stored
+   UUID for equality.  Its semantics are the same as the
+   'octetStringMatch' [X.520][RFC4517] matching rule.  The rule differs
+   from 'octetStringMatch' in that the assertion value is encoded using
+   the UUID string representation instead of the normal OCTET STRING
+   string representation.
+
+   The following is an LDAP matching rule description suitable for
+   publication in subschema subentries.
+
+       ( 1.3.6.1.1.16.2 NAME 'uuidMatch'
+           SYNTAX 1.3.6.1.1.16.1 )
+
+2.3.  'uuidOrderingMatch' Matching Rule
+
+   The 'uuidOrderingMatch' matching rule compares an asserted UUID with
+   a stored UUID for ordering.  Its semantics are the same as the
+   'octetStringOrderingMatch' [X.520][RFC4517] matching rule.  The rule
+   differs from 'octetStringOrderingMatch' in that the assertion value
+   is encoded using the UUID string representation instead of the normal
+   OCTET STRING string representation.
+
+
+
+Zeilenga                    Standards Track                     [Page 3]
+
+RFC 4530                     LDAP entryUUID                    June 2006
+
+
+   The following is an LDAP matching rule description suitable for
+   publication in subschema subentries.
+
+       ( 1.3.6.1.1.16.3 NAME 'uuidOrderingMatch'
+           SYNTAX 1.3.6.1.1.16.1 )
+
+   Note that not all UUID variants have a defined ordering; and even
+   where it does, servers are not obligated to assign UUIDs in any
+   particular order.  This matching rule is provided for completeness.
+
+2.4.  'entryUUID' Attribute
+
+   The 'entryUUID' operational attribute provides the Universally Unique
+   Identifier (UUID) assigned to the entry.
+
+   The following is an LDAP attribute type description suitable for
+   publication in subschema subentries.
+
+       ( 1.3.6.1.1.16.4 NAME 'entryUUID'
+           DESC 'UUID of the entry'
+           EQUALITY uuidMatch
+           ORDERING uuidOrderingMatch
+           SYNTAX 1.3.6.1.1.16.1
+           SINGLE-VALUE
+           NO-USER-MODIFICATION
+           USAGE directoryOperation )
+
+   Servers SHALL generate and assign a new UUID to each entry upon its
+   addition to the directory and provide that UUID as the value of the
+   'entryUUID' operational attribute.  An entry's UUID is immutable.
+
+   UUID are to be generated in accordance with Section 4 of [RFC4122].
+   In particular, servers MUST ensure that each generated UUID is unique
+   in space and time.
+
+3.  Security Considerations
+
+   An entry's relative distinguish name (RDN) is composed from attribute
+   values of the entry, which are commonly descriptive of the object the
+   entry represents.  Although deployers are encouraged to use naming
+   attributes whose values are widely disclosable [RFC4514], entries are
+   often named using information that cannot be disclosed to all
+   parties.  As UUIDs do not contain any descriptive information of the
+   object they identify, UUIDs may be used to identify a particular
+   entry without disclosure of its contents.
+
+   General UUID security considerations [RFC4122] apply.
+
+
+
+
+Zeilenga                    Standards Track                     [Page 4]
+
+RFC 4530                     LDAP entryUUID                    June 2006
+
+
+   General LDAP security considerations [RFC4510] apply.
+
+4.  IANA Considerations
+
+   The IANA has registered the LDAP values [RFC4520] specified in this
+   document.
+
+4.1.  Object Identifier Registration
+
+       Subject: Request for LDAP OID Registration
+       Person & email address to contact for further information:
+           Kurt Zeilenga <kurt@OpenLDAP.org>
+       Specification: RFC 4530
+       Author/Change Controller: IESG
+       Comments:
+           Identifies the UUID schema elements
+
+4.2.  UUID Syntax Registration
+
+       Subject: Request for LDAP Syntax Registration
+       Object Identifier: 1.3.6.1.1.16.1
+       Description: UUID
+       Person & email address to contact for further information:
+           Kurt Zeilenga <kurt@OpenLDAP.org>
+       Specification: RFC 4530
+       Author/Change Controller: IESG
+       Comments:
+            Identifies the UUID syntax
+
+4.3.  'uuidMatch' Descriptor Registration
+
+       Subject: Request for LDAP Descriptor Registration
+       Descriptor (short name): uuidMatch
+       Object Identifier: 1.3.6.1.1.16.2
+       Person & email address to contact for further information:
+           Kurt Zeilenga <kurt@OpenLDAP.org>
+       Usage: Matching Rule
+       Specification: RFC 4530
+       Author/Change Controller: IESG
+
+4.4.  'uuidOrderingMatch' Descriptor Registration
+
+       Subject: Request for LDAP Descriptor Registration
+       Descriptor (short name): uuidOrderingMatch
+       Object Identifier: 1.3.6.1.1.16.3
+       Person & email address to contact for further information:
+           Kurt Zeilenga <kurt@OpenLDAP.org>
+       Usage: Matching Rule
+
+
+
+Zeilenga                    Standards Track                     [Page 5]
+
+RFC 4530                     LDAP entryUUID                    June 2006
+
+
+       Specification: RFC 4530
+       Author/Change Controller: IESG
+
+4.5.  'entryUUID' Descriptor Registration
+
+   The IANA has registered the LDAP 'entryUUID' descriptor.
+
+       Subject: Request for LDAP Descriptor Registration
+       Descriptor (short name): entryUUID
+       Object Identifier: 1.3.6.1.1.16.4
+       Person & email address to contact for further information:
+           Kurt Zeilenga <kurt@OpenLDAP.org>
+       Usage: Attribute Type
+       Specification: RFC 4530
+       Author/Change Controller: IESG
+
+5.  Acknowledgements
+
+   This document is based upon discussions in the LDAP Update and
+   Duplication Protocols (LDUP) WG.  Members of the LDAP Directorate
+   provided review.
+
+6.  References
+
+6.1.  Normative References
+
+   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4122]     Leach, P., Mealling, M., and R. Salz, "A Universally
+                 Unique IDentifier (UUID) URN Namespace", RFC 4122, July
+                 2005.
+
+   [RFC4510]     Zeilenga, K., Ed., "Lightweight Directory Access
+                 Protocol (LDAP): Technical Specification Road Map", RFC
+                 4510, June 2006.
+
+   [RFC4512]     Zeilenga, K., "Lightweight Directory Access Protocol
+                 (LDAP): Directory Information Models", RFC 4512, June
+                 2006.
+
+   [RFC4517]     Legg, S., Ed., "Lightweight Directory Access Protocol
+                 (LDAP): Syntaxes and Matching Rules", RFC 4517, June
+                 2006.
+
+   [ASCII]       Coded Character Set--7-bit American Standard Code for
+                 Information Interchange, ANSI X3.4-1986.
+
+
+
+
+Zeilenga                    Standards Track                     [Page 6]
+
+RFC 4530                     LDAP entryUUID                    June 2006
+
+
+   [X.501]       International Telecommunication Union -
+                 Telecommunication Standardization Sector, "The
+                 Directory -- Models," X.501(1993) (also ISO/IEC 9594-
+                 2:1994).
+
+   [X.520]       International Telecommunication Union -
+                 Telecommunication Standardization Sector, "The
+                 Directory: Selected Attribute Types", X.520(1993) (also
+                 ISO/IEC 9594-6:1994).
+
+   [X.680]       International Telecommunication Union -
+                 Telecommunication Standardization Sector, "Abstract
+                 Syntax Notation One (ASN.1) - Specification of Basic
+                 Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
+
+6.2.  Informative References
+
+   [RFC4514]     Zeilenga, K., Ed., "Lightweight Directory Access
+                 Protocol (LDAP): String Representation of Distinguished
+                 Names", RFC 4514, June 2006.
+
+   [RFC4520]     Zeilenga, K., "Internet Assigned Numbers Authority
+                 (IANA) Considerations for the Lightweight Directory
+                 Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+Author's Address
+
+   Kurt D. Zeilenga
+   OpenLDAP Foundation
+
+   EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 7]
+
+RFC 4530                     LDAP entryUUID                    June 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   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 provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 8]
+