idnits 2.17.1 draft-chu-ldap-xordered-00.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 470. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 447. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 454. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 460. ** 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 'Intended status' indicated for this document; assuming Proposed Standard 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. (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 (May 3, 2006) is 6565 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) == Unused Reference: 'X680' is defined on line 418, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2252 (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4523) ** Obsolete normative reference: RFC 3377 (Obsoleted by RFC 4510) ** Obsolete normative reference: RFC 3383 (Obsoleted by RFC 4520) -- Possible downref: Non-RFC (?) normative reference: ref. 'X680' Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Chu 3 Internet-Draft Symas Corp. 4 Expires: November 4, 2006 May 3, 2006 6 Ordered Entries and Values in LDAP 7 draft-chu-ldap-xordered-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on November 4, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 As LDAP is used more extensively for managing various kinds of data, 41 one often encounters a need to preserve both the ordering and the 42 content of data, despite the inherently unordered structure of 43 entries and attribute values in the directory. This document 44 describes a scheme to attach ordering information to attributes in a 45 directory so that the ordering may be preserved and propagated to 46 other LDAP applications. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . 3 51 2. Conventions . . . . . . . . . . . . . . . . . . . . . 4 52 3. Ordering Extension . . . . . . . . . . . . . . . . . . 5 53 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 5 54 3.2. Encoding . . . . . . . . . . . . . . . . . . . . . . . 5 55 3.3. Ordering Properties . . . . . . . . . . . . . . . . . 6 56 4. Examples . . . . . . . . . . . . . . . . . . . . . . . 8 57 4.1. Sample Schema . . . . . . . . . . . . . . . . . . . . 8 58 4.2. Ordered Values . . . . . . . . . . . . . . . . . . . . 8 59 4.3. Ordered Siblings . . . . . . . . . . . . . . . . . . . 10 60 5. Security Considerations . . . . . . . . . . . . . . . 13 61 6. Normative References . . . . . . . . . . . . . . . . . 13 62 Appendix A. IANA Considerations . . . . . . . . . . . . . . . . . 14 63 Author's Address . . . . . . . . . . . . . . . . . . . 15 64 Intellectual Property and Copyright Statements . . . . 16 66 1. Introduction 68 Information in LDAP directories is usually handled by applications in 69 the form of ordered lists, which tends to encourage application 70 developers to assume they are maintained as such, i.e., it is assumed 71 that information stored in a particular order will always be 72 retrieved and presented in that same order. The fact that directory 73 attributes actually store sets of values, which are inherently 74 unordered, often causes grief to users migrating their data into 75 LDAP. Similar concerns arise over the order in which entries 76 themselves are stored and retrieved from the directory. 78 This document describes a schema extension that may be used in LDAP 79 attribute definitions to store ordering information along with the 80 attribute values, so that the ordering can be recovered when 81 retrieved by an LDAP client. The extension also provides automated 82 management of this ordering information to ease manipulation of the 83 ordered values. 85 2. Conventions 87 Imperative keywords defined in [RFC2119] are used in this document, 88 and carry the meanings described there. 90 3. Ordering Extension 92 3.1. Overview 94 The "X-ORDERED" schema extension is added to an 95 AttributeTypeDescription to signify the use of this ordering 96 mechanism. The extension has two variants, selected by either the 97 'VALUES' or 'SIBLINGS' qdstrings. In general this extension is only 98 compatible with AttributeTypes that have a string-oriented syntax. 100 The "X-ORDERED 'VALUES'" extension is used with multi-valued 101 attributes to maintain the order of multiple values of a given 102 attribute. For example, this feature is useful for storing data such 103 as access control rules, which must be evaluated in a specific order. 104 If the access control information is stored in a multi-valued 105 attribute without a means of preserving the the order of the rules, 106 the access control rules cannot be evaluated properly. As the use of 107 LDAP to store security policy and access control information becomes 108 more prevalent, the necessity of this feature continues to grow. 110 The "X-ORDERED 'SIBLINGS'" extension is used with single-valued 111 attributes to maintain the order of all the onelevel children of a 112 parent entry. That is, ordering will be maintained for all the child 113 entries whose RDNs are all of the same AttributeType. The motivation 114 for this feature is much the same as for the 'VALUES' feature. 115 Sometimes the information with the ordering dependency is too complex 116 or highly structured to be conveniently stored in values of a multi- 117 valued attribute. For example, one could store a prioritized list of 118 servers as a set of separate entries, each entry containing separate 119 attributes for a URL, a set of authentication credentials, and 120 various other parameters. Using the 'SIBLINGS' feature with the 121 attribute in the entries' RDNs would ensure that when obtaining the 122 list of these entries, the list is returned in the intended order. 124 3.2. Encoding 126 Ordering information is encoded by prepending a value's ordinal index 127 to each value, enclosed in braces. The following BNF specifies the 128 encoding. It uses elements defined in [RFC2252]. 130 d = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" 132 numericstring = 1*d 134 ordering-prefix = "{" numericstring "}" 136 value = 137 ordered-value = ordering-prefix value 139 The ordinals are zero-based and increment by one for each value. 141 Note that when storing ordered-values into the directory, the 142 ordering-prefix can usually be omitted as it will be generated 143 automatically. But if the original value already begins with a 144 sequence of characters in the form of an ordering-prefix, then an 145 ordering-prefix must always be provided with that value, otherwise 146 the value will be processed and stored incorrectly. 148 Using this extension on an attribute requires that ordering-prefix is 149 a legal value of the LDAP syntax of that attribute. 151 3.3. Ordering Properties 153 Since the ordering-prefix is stored with the attribute values, it 154 will be propagated to any clients or servers that access the data. 156 Servers implementing this scheme SHOULD sort the values according to 157 their ordering-prefix before returning them in search results. 159 The presence of the ordering extension alters the matching rules that 160 apply to the attribute: 162 When presented with an AssertionValue that does not have an 163 ordering-prefix, the ordering-prefix in the AttributeValue is 164 ignored. 166 When presented with an AssertionValue that consists solely of an 167 ordering-prefix, only the ordering-prefix of the AttributeValue is 168 compared; the remainder of the value is ignored. 170 When presented with an AssertionValue containing both the 171 ordering-prefix and a value, both components are compared to 172 determine a match. 174 A side effect of these properties is that even attributes that 175 normally would have no equality matching rule can be matched by an 176 ordering-prefix. 178 The ordering-prefix may also be used in Modification requests to 179 specify which values to delete, and in which position values should 180 be added. When processing deletions and insertions, all of the 181 ordinals are recounted after each individual modification. 183 If a value being added does not have an ordering-prefix, it is simply 184 appended to the list and the appropriate ordering-prefix is 185 automatically generated. Likewise if an ordering-prefix is provided 186 that is greater than or equal to the number of existing values. 188 See the examples in the next section. 190 4. Examples 192 4.1. Sample Schema 194 This schema is used for all of the examples: 196 ( EXAMPLE_AT.1 NAME 'olcDatabase' 197 EQUALITY caseIgnoreMatch 198 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 199 SINGLE-VALUE X-ORDERED 'SIBLINGS' ) 201 ( EXAMPLE_AT.2 NAME 'olcSuffix' 202 EQUALITY distinguishedNameMatch 203 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 204 X-ORDERED 'VALUES' ) 206 ( EXAMPLE_OC.1 NAME 'olcDatabaseConfig' 207 SUP top STRUCTURAL 208 MAY ( olcDatabase $ olcSuffix ) ) 210 4.2. Ordered Values 212 Given this entry: 214 dn: olcDatabase={1}bdb,cn=config 215 olcDatabase: {1}bdb 216 objectClass: olcDatabaseConfig 217 olcSuffix: {0}dc=example,dc=com 218 olcSuffix: {1}o=example.com 219 olcSuffix: {2}o=The Example Company 220 olcSuffix: {3}o=example,c=us 222 We can perform these Modify operations: 224 1. dn: olcDatabase={1}bdb,cn=config 225 changetype: modify 226 delete: olcSuffix 227 olcSuffix: {0} 228 - 229 This operation deletes the first olcSuffix, regardless of its 230 value. All other values are bumped up one position. The 231 olcSuffix attribute will end up containing: 232 olcSuffix: {0}o=example.com 233 olcSuffix: {1}o=The Example Company 234 olcSuffix: {2}o=example,c=us 236 2. Starting from the original entry, we could issue this change 237 instead: 239 delete: olcSuffix 240 olcSuffix: o=example.com 241 - 242 This operation deletes the olcSuffix that matches the value, 243 regardless of its ordering-prefix. The olcSuffix attribute will 244 contain: 245 olcSuffix: {0}dc=example,dc=com 246 olcSuffix: {1}o=The Example Company 247 olcSuffix: {2}o=example,c=us 249 3. Again, starting from the original entry, we could issue this 250 change: 251 delete: olcSuffix 252 olcSuffix: {2}o=The Example Company 253 - 254 Here both the ordering-prefix and the value must match, otherwise 255 the Modify would fail with noSuchAttribute. In this case the 256 olcSuffix attribute results in: 257 olcSuffix: {0}dc=example,dc=com 258 olcSuffix: {1}o=example.com 259 olcSuffix: {2}o=example,c=us 261 4. Adding a new value without an ordering-prefix simply appends: 262 add: olcSuffix 263 olcSuffix: o=example.org 264 - 265 The resulting attribute would be: 266 olcSuffix: {0}dc=example,dc=com 267 olcSuffix: {1}o=example.com 268 olcSuffix: {2}o=The Example Company 269 olcSuffix: {3}o=example,c=us 270 olcSuffix: {4}o=example.org 272 5. Adding a new value with an ordering-prefix inserts into the 273 specified position: 274 add: olcSuffix 275 olcSuffix: {0}o=example.org 276 - 277 The resulting attribute would be: 278 olcSuffix: {0}o=example.org 279 olcSuffix: {1}dc=example,dc=com 280 olcSuffix: {2}o=example.com 281 olcSuffix: {3}o=The Example Company 282 olcSuffix: {4}o=example,c=us 284 6. Modifying multiple values in one operation: 285 add: olcSuffix 286 olcSuffix: {0}ou=Dis,o=example.com 287 olcSuffix: {0}ou=Dat,o=example,com 288 - 289 delete: olcSuffix: 290 olcSuffix: {2} 291 olcSuffix: {1} 292 - 293 The resulting attribute would be: 294 olcSuffix: {0}ou=Dat,o=example,com 295 olcSuffix: {1}dc=example,dc=com 296 olcSuffix: {2}o=example.com 297 olcSuffix: {3}o=The Example Company 298 olcSuffix: {4}o=example,c=us 300 7. If the Adds and Deletes in the previous example were done in the 301 opposite order: 302 delete: olcSuffix: 303 olcSuffix: {2} 304 olcSuffix: {1} 305 - 306 add: olcSuffix 307 olcSuffix: {0}ou=Dis,o=example.com 308 olcSuffix: {0}ou=Dat,o=example,com 309 - 310 The result would be: 311 olcSuffix: {0}ou=Dat,o=example,com 312 olcSuffix: {1}ou=Dis,o=example.com 313 olcSuffix: {2}o=example.org 314 olcSuffix: {3}o=The Example Company 315 olcSuffix: {4}o=example,c=us 317 Note that matching against an ordering-prefix can also be done in 318 Compare operations and Search filters. E.g., the filter 319 "(olcSuffix={4})" would match all entries with at least 5 olcSuffix 320 values. 322 4.3. Ordered Siblings 324 The rules for Ordered Siblings are basically the same as for Ordered 325 Values, except instead of working primarily with the Modify request, 326 the operations of interest here are Add, Delete, and ModRDN. 328 Given these entries: 330 dn: olcDatabase={0}config,cn=config 331 olcDatabase: {0}config 332 objectClass: olcDatabaseConfig 333 olcSuffix: {0}cn=config 334 dn: olcDatabase={1}bdb,cn=config 335 olcDatabase: {1}bdb 336 objectClass: olcDatabaseConfig 337 olcSuffix: {0}dc=example,dc=com 339 We can perform these operations: 341 1. Add a new entry with no ordering-prefix: 342 dn: olcDatabase=hdb,cn=config 343 changetype: add 344 olcDatabase: hdb 345 objectClass: olcDatabaseConfig 346 olcSuffix: {0}dc=example,dc=org 347 The resulting entry will be: 348 dn: olcDatabase={2}hdb,cn=config 349 olcDatabase: {2}hdb 350 objectClass: olcDatabaseConfig 351 olcSuffix: {0}dc=example,dc=org 353 2. Continuing on with these three entries, we can add another entry 354 with a specific ordering-prefix: 355 dn: olcDatabase={1}ldif,cn=config 356 changetype: add 357 olcDatabase: {1}ldif 358 objectClass: olcDatabaseConfig 359 olcSuffix: {0}o=example.com 360 This would give us four entries, whose DNs are: 362 dn: olcDatabase={0}config,cn=config 364 dn: olcDatabase={1}ldif,cn=config 366 dn: olcDatabase={2}bdb,cn=config 368 dn: olcDatabase={3}hdb,cn=config 370 3. Issuing a ModRDN request will cause multiple entries to be 371 renamed: 372 dn: olcDatabase={1}ldif,cn=config 373 changetype: modrdn 374 newrdn: olcDatabase={99}ldif,cn=config 375 deleteoldrdn: 1 376 The resulting entries would be named: 378 dn: olcDatabase={0}config,cn=config 380 dn: olcDatabase={1}bdb,cn=config 381 dn: olcDatabase={2}hdb,cn=config 383 dn: olcDatabase={3}ldif,cn=config 385 4. As may be expected, a Delete request will also rename the 386 remaining entries: 387 dn: olcDatabase={1}bdb,cn=config 388 changetype: delete 389 The remaining entries would be named: 391 dn: olcDatabase={0}config,cn=config 393 dn: olcDatabase={1}hdb,cn=config 395 dn: olcDatabase={2}ldif,cn=config 397 5. Security Considerations 399 General LDAP security considerations [RFC3377] apply. 401 6. Normative References 403 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 404 Requirement Levels", BCP 14, RFC 2119, March 1997. 406 [RFC2252] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, 407 "Lightweight Directory Access Protocol (v3): Attribute 408 Syntax Definitions", RFC 2252, December 1997. 410 [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access 411 Protocol (v3): Technical Specification", RFC 3377, 412 September 2002. 414 [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) 415 Considerations for the Lightweight Directory Access 416 Protocol (LDAP)", BCP 64, RFC 3383, September 2002. 418 [X680] International Telecommunications Union, "Abstract Syntax 419 Notation One (ASN.1): Specification of basic notation", 420 ITU-T Recommendation X.680, July 2002. 422 Appendix A. IANA Considerations 424 In accordance with [RFC3383] (what needs to be done here?) . We 425 probably need an OID for advertising in supportedFeatures. 427 Author's Address 429 Howard Chu 430 Symas Corp. 431 18740 Oxnard Street, Suite 313A 432 Tarzana, California 91356 433 USA 435 Phone: +1 818 757-7087 436 Email: hyc@symas.com 438 Intellectual Property Statement 440 The IETF takes no position regarding the validity or scope of any 441 Intellectual Property Rights or other rights that might be claimed to 442 pertain to the implementation or use of the technology described in 443 this document or the extent to which any license under such rights 444 might or might not be available; nor does it represent that it has 445 made any independent effort to identify any such rights. Information 446 on the procedures with respect to rights in RFC documents can be 447 found in BCP 78 and BCP 79. 449 Copies of IPR disclosures made to the IETF Secretariat and any 450 assurances of licenses to be made available, or the result of an 451 attempt made to obtain a general license or permission for the use of 452 such proprietary rights by implementers or users of this 453 specification can be obtained from the IETF on-line IPR repository at 454 http://www.ietf.org/ipr. 456 The IETF invites any interested party to bring to its attention any 457 copyrights, patents or patent applications, or other proprietary 458 rights that may cover technology that may be required to implement 459 this standard. Please address the information to the IETF at 460 ietf-ipr@ietf.org. 462 Disclaimer of Validity 464 This document and the information contained herein are provided on an 465 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 466 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 467 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 468 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 469 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 470 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 472 Copyright Statement 474 Copyright (C) The Internet Society (2006). This document is subject 475 to the rights, licenses and restrictions contained in BCP 78, and 476 except as set forth therein, the authors retain all their rights. 478 Acknowledgment 480 Funding for the RFC Editor function is currently provided by the 481 Internet Society.