idnits 2.17.1 draft-zeilenga-ldap-uuid-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 336. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 307. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 314. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 320. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 324), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (18 July 2005) is 6854 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC3377' is mentioned on line 171, but not defined ** Obsolete undefined reference: RFC 3377 (Obsoleted by RFC 4510) == Unused Reference: 'BCP64bis' is defined on line 295, but no explicit reference was found in the text -- No information found for draft-ietf-ldapbis-roadmap-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Roadmap' -- Possible downref: Non-RFC (?) normative reference: ref. 'UUIDURN' -- No information found for draft-ietf-ldapbis-models-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Models' -- No information found for draft-ietf-ldapbis-syntaxes-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Syntaxes' -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII' -- No information found for draft-ietf-ldapbis-dn-xx - is the name correct? -- No information found for draft-ietf-ldapbis-bcp64-xx - is the name correct? Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Kurt D. Zeilenga 3 Intended Category: Standard Track OpenLDAP Foundation 4 Expires in six months 18 July 2005 6 The LDAP entryUUID operational attribute 7 9 Status of this Memo 11 This document is intended to be, after appropriate review and 12 revision, submitted to the RFC Editor as an Standard Track document. 13 Distribution of this memo is unlimited. Technical discussion of this 14 document will take place on the IETF LDAP Extensions mailing list 15 . Please send editorial comments directly to the 16 author . 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware have 20 been or will be disclosed, and any of which he or she becomes aware 21 will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering Task 24 Force (IETF), its areas, and its working groups. Note that other 25 groups may also distribute working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference material 30 or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 Copyright (C) The Internet Society (2005). All Rights Reserved. 40 Please see the Full Copyright section near the end of this document 41 for more information. 43 Abstract 44 This document describes the LDAP/X.500 'entryUUID' operational 45 attribute and associated matching rules and syntax. The attribute 46 holds a server-assigned Universally Unique Identifier (UUID) for the 47 object. Directory clients may use this attribute to distinguish 48 objects identified by a distinguished name or to locate an object 49 after renaming. 51 1. Background and Intended Use 53 In X.500 Directory Services [X.501], such as those accessible using 54 the Lightweight Directory Access Protocol (LDAP) [Roadmap], an object 55 is identified by its distinguished name (DN). However, DNs are not 56 stable identifiers. That is, a new object may be identified by a DN 57 which previously identified another (now renamed or deleted) object. 59 A Universally Unique Identifier (UUID) is "an identifier unique across 60 both space and time, with respect to the space of all UUIDs" 61 [UUIDURN]. UUIDs are used in a wide range of systems. 63 This document describes the 'entryUUID' operational attribute which 64 holds the UUID assigned to the object by the server. Clients may use 65 this attribute to distinguish objects identified by a particular 66 distinguished name or to locate a particular object after renaming. 68 This document defines the UUID syntax, the 'uuidMatch' and 69 'uuidOrderingMatch' matching rules, and the 'entryUUID' attribute 70 type. 72 Schema definitions are provided using LDAP description formats 73 [Models]. Definitions provided here are formatted (line wrapped) for 74 readability. 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in BCP 14 [RFC2119]. 80 2. UUID Schema Elements 82 2.1 UUID Syntax 84 A Universally Unique Identifier (UUID) [UUIDURN] is a 16-octet 85 (128-bit) value which identifies an object. The ASN.1 [X.680] type 86 UUID is defined to represent UUIDs as follows: 88 UUID ::= OCTET STRING (SIZE(16)) 89 -- constrained to an UUID [UUIDURN] 91 In LDAP, UUID values are encoded using the [ASCII] character string 92 representation described in [UUIDURN]. For example, 93 "597ae2f6-16a6-1027-98f4-d28b5365dc14". 95 The following is a LDAP syntax description suitable for publication in 96 subschema subentries. 98 ( IANA-ASSIGNED-OID.1 DESC 'UUID' ) 100 2.2 'uuidMatch' Matching Rule 102 The 'uuidMatch' matching rule compares an asserted UUID with a stored 103 UUID for equality. Its semantics are same as the 'octetStringMatch' 104 [X.520][Syntaxes] matching rule. The rule differs from 105 'octetStringMatch' in that the assertion value is encoded using the 106 UUID string representation instead of the normal OCTET STRING string 107 representation. 109 The following is a LDAP matching rule description suitable for 110 publication in subschema subentries. 112 ( IANA-ASSIGNED-OID.2 NAME 'uuidMatch' 113 SYNTAX IANA-ASSIGNED-OID.1 ) 115 2.3 'uuidOrderingMatch' Matching Rule 117 The 'uuidOrderingMatch' matching rule compares an asserted UUID 118 with a stored UUID for ordering. Its semantics are the same as the 119 'octetStringOrderingMatch' [X.520][Syntaxes] matching rule. The 120 rule differs from 'octetStringOrderingMatch' in that the assertion 121 value is encoded using the UUID string representation instead of 122 the normal OCTET STRING string representation. 124 The following is a LDAP matching rule description suitable for 125 publication in subschema subentries. 127 ( IANA-ASSIGNED-OID.3 NAME 'uuidOrderingMatch' 128 SYNTAX IANA-ASSIGNED-OID.1 ) 130 It is noted that not all UUID variants have a defined ordering and, 131 even where so, servers are not obligated to assign UUIDs in any 132 particular order. This matching rule is provided for completeness. 134 2.4. 'entryUUID' attribute 135 The 'entryUUID' operational attribute provides the Universally Unique 136 Identifier (UUID) assigned to the entry. 138 The following is a LDAP attribute type description suitable for 139 publication in subschema subentries. 141 ( IANA-ASSIGNED-OID.4 NAME 'entryUUID' 142 DESC 'UUID of the entry' 143 EQUALITY uuidMatch 144 ORDERING uuidOrderingMatch 145 SYNTAX IANA-ASSIGNED-OID.1 146 SINGLE-VALUE 147 NO-USER-MODIFICATION 148 USAGE directoryOperation ) 150 Servers SHALL generate and assign a new UUID to each entry upon its 151 addition to the directory and provide that UUID as the value of the 152 'entryUUID' operational attribute. An entry's UUID is immutable. 154 UUID are to be generated in accordance with Section 4 of [UUIDURN]. 155 In particular, servers MUST ensure that each generated UUID is unique 156 in space and time. 158 3. Security Considerations 160 An entry's relative distinguish name (RDN) is composed from attribute 161 values of the entry, values which are commonly descriptive of the 162 object the entry represents. While deployers are encouraged to use 163 naming attributes whose values are widely disclosable [LDAPDN], 164 entries are often named using information which cannot be disclosed to 165 all parties. As UUIDs do not contain any descriptive information of 166 the object they identify, UUIDs may be used to identify a particular 167 entry without disclosure of its contents. 169 General UUID security considerations [UUIDURN] apply. 171 General LDAP security considerations [RFC3377] apply. 173 4. IANA Considerations 175 It is requested that IANA register upon Standards Action the LDAP 176 values specified in this document. 178 4.1. Object Identifier Registration 179 Subject: Request for LDAP OID Registration 180 Person & email address to contact for further information: 181 Kurt Zeilenga 182 Specification: RFC XXXX 183 Author/Change Controller: IESG 184 Comments: 185 Identifies the UUID schema elements 187 4.2. UUID Syntax Registration 189 Subject: Request for LDAP Syntax Registration 190 Object Identifier: IANA-ASSIGNED-OID.1 191 Description: UUID 192 Person & email address to contact for further information: 193 Kurt Zeilenga 194 Specification: RFC XXXX 195 Author/Change Controller: IESG 196 Comments: 197 Identifies the UUID syntax 199 4.3. 'uuidMatch' Descriptor Registration 201 Subject: Request for LDAP Descriptor Registration 202 Descriptor (short name): uuidMatch 203 Object Identifier: IANA-ASSIGNED-OID.2 204 Person & email address to contact for further information: 205 Kurt Zeilenga 206 Usage: Matching Rule 207 Specification: RFC XXXX 208 Author/Change Controller: IESG 210 4.3. 'uuidOrderingMatch' Descriptor Registration 212 Subject: Request for LDAP Descriptor Registration 213 Descriptor (short name): uuidOrderingMatch 214 Object Identifier: IANA-ASSIGNED-OID.3 215 Person & email address to contact for further information: 216 Kurt Zeilenga 217 Usage: Matching Rule 218 Specification: RFC XXXX 219 Author/Change Controller: IESG 221 5.4. 'entryUUID' Descriptor Registration 222 It is requested that IANA register upon Standards Action the LDAP 223 'entryUUID' descriptor. 225 Subject: Request for LDAP Descriptor Registration 226 Descriptor (short name): entryUUID 227 Object Identifier: IANA-ASSIGNED-OID.4 228 Person & email address to contact for further information: 229 Kurt Zeilenga 230 Usage: Attribute Type 231 Specification: RFC XXXX 232 Author/Change Controller: IESG 234 6. Acknowledgments 236 This document is based upon discussions in the LDAP Update and 237 Duplication Protocols (LDUP) WG. Members of the LDAP Directorate 238 provided review. 240 7. Author's Address 242 Kurt D. Zeilenga 243 OpenLDAP Foundation 245 Email: Kurt@OpenLDAP.org 247 8. References 249 [[Note to the RFC Editor: please replace the citation tags used in 250 referencing Internet-Drafts with tags of the form RFCnnnn where 251 possible.]] 253 8.1. Normative References 255 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 256 Requirement Levels", BCP 14 (also RFC 2119), March 1997. 258 [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification 259 Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in 260 progress. 262 [UUIDURN] Leach, P, M. Mealling, R. Salz, "A UUID URN Namespace", 263 a work in progress. 265 [Models] Zeilenga, K. (editor), "LDAP: Directory Information 266 Models", draft-ietf-ldapbis-models-xx.txt, a work in 267 progress. 269 [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules", 270 draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress. 272 [ASCII] Coded Character Set--7-bit American Standard Code for 273 Information Interchange, ANSI X3.4-1986. 275 [X.501] International Telecommunication Union - 276 Telecommunication Standardization Sector, "The Directory 277 -- Models," X.501(1993) (also ISO/IEC 9594-2:1994). 279 [X.520] International Telecommunication Union - 280 Telecommunication Standardization Sector, "The 281 Directory: Selected Attribute Types", X.520(1993) (also 282 ISO/IEC 9594-6:1994). 284 [X.680] International Telecommunication Union - 285 Telecommunication Standardization Sector, "Abstract 286 Syntax Notation One (ASN.1) - Specification of Basic 287 Notation", X.680(2002) (also ISO/IEC 8824-1:2002). 289 8.2. Informative References 291 [LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of 292 Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a 293 work in progress. 295 [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP", 296 draft-ietf-ldapbis-bcp64-xx.txt, a work in progress. 298 Intellectual Property Rights 300 The IETF takes no position regarding the validity or scope of any 301 Intellectual Property Rights or other rights that might be claimed to 302 pertain to the implementation or use of the technology described in 303 this document or the extent to which any license under such rights 304 might or might not be available; nor does it represent that it has 305 made any independent effort to identify any such rights. Information 306 on the procedures with respect to rights in RFC documents can be found 307 in BCP 78 and BCP 79. 309 Copies of IPR disclosures made to the IETF Secretariat and any 310 assurances of licenses to be made available, or the result of an 311 attempt made to obtain a general license or permission for the use of 312 such proprietary rights by implementers or users of this specification 313 can be obtained from the IETF on-line IPR repository at 314 http://www.ietf.org/ipr. 316 The IETF invites any interested party to bring to its attention any 317 copyrights, patents or patent applications, or other proprietary 318 rights that may cover technology that may be required to implement 319 this standard. Please address the information to the IETF at 320 ietf-ipr@ietf.org. 322 Full Copyright 324 Copyright (C) The Internet Society (2005). 326 This document is subject to the rights, licenses and restrictions 327 contained in BCP 78, and except as set forth therein, the authors 328 retain all their rights. 330 This document and the information contained herein are provided on an 331 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 332 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 333 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 334 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 335 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 336 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.