1 2 3 4Network Working Group H. Chu 5Internet-Draft Symas Corp. 6Intended status: Informational May 2006 7Expires: November 2, 2006 8 9 10 Ordered Entries and Values in LDAP 11 draft-chu-ldap-xordered-00.txt 12 13Status of this Memo 14 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 24 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 29 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 32 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 35 36 This Internet-Draft will expire on November 2, 2006. 37 38Copyright Notice 39 40 Copyright (C) The Internet Society (2006). 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55Chu Expires November 2, 2006 [Page 1] 56 57Internet-Draft LDAP Ordering Extension May 2006 58 59 60Abstract 61 62 As LDAP is used more extensively for managing various kinds of data, 63 one often encounters a need to preserve both the ordering and the 64 content of data, despite the inherently unordered structure of 65 entries and attribute values in the directory. This document 66 describes a scheme to attach ordering information to attributes in a 67 directory so that the ordering may be preserved and propagated to 68 other LDAP applications. 69 70 71Table of Contents 72 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . 3 74 2. Conventions . . . . . . . . . . . . . . . . . . . . . 4 75 3. Ordering Extension . . . . . . . . . . . . . . . . . . 5 76 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 5 77 3.2. Encoding . . . . . . . . . . . . . . . . . . . . . . . 5 78 3.3. Ordering Properties . . . . . . . . . . . . . . . . . 6 79 4. Examples . . . . . . . . . . . . . . . . . . . . . . . 8 80 4.1. Sample Schema . . . . . . . . . . . . . . . . . . . . 8 81 4.2. Ordered Values . . . . . . . . . . . . . . . . . . . . 8 82 4.3. Ordered Siblings . . . . . . . . . . . . . . . . . . . 10 83 5. Security Considerations . . . . . . . . . . . . . . . 13 84 6. Normative References . . . . . . . . . . . . . . . . . 14 85 Appendix A. IANA Considerations . . . . . . . . . . . . . . . . . 15 86 Author's Address . . . . . . . . . . . . . . . . . . . 16 87 Intellectual Property and Copyright Statements . . . . 17 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111Chu Expires November 2, 2006 [Page 2] 112 113Internet-Draft LDAP Ordering Extension May 2006 114 115 1161. Introduction 117 118 Information in LDAP directories is usually handled by applications in 119 the form of ordered lists, which tends to encourage application 120 developers to assume they are maintained as such, i.e., it is assumed 121 that information stored in a particular order will always be 122 retrieved and presented in that same order. The fact that directory 123 attributes actually store sets of values, which are inherently 124 unordered, often causes grief to users migrating their data into 125 LDAP. Similar concerns arise over the order in which entries 126 themselves are stored and retrieved from the directory. 127 128 This document describes a schema extension that may be used in LDAP 129 attribute definitions to store ordering information along with the 130 attribute values, so that the ordering can be recovered when 131 retrieved by an LDAP client. The extension also provides automated 132 management of this ordering information to ease manipulation of the 133 ordered values. 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167Chu Expires November 2, 2006 [Page 3] 168 169Internet-Draft LDAP Ordering Extension May 2006 170 171 1722. Conventions 173 174 Imperative keywords defined in [RFC2119] are used in this document, 175 and carry the meanings described there. 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223Chu Expires November 2, 2006 [Page 4] 224 225Internet-Draft LDAP Ordering Extension May 2006 226 227 2283. Ordering Extension 229 2303.1. Overview 231 232 The "X-ORDERED" schema extension is added to an 233 AttributeTypeDescription to signify the use of this ordering 234 mechanism. The extension has two variants, selected by either the 235 'VALUES' or 'SIBLINGS' qdstrings. In general this extension is only 236 compatible with AttributeTypes that have a string-oriented syntax. 237 238 The "X-ORDERED 'VALUES'" extension is used with multi-valued 239 attributes to maintain the order of multiple values of a given 240 attribute. For example, this feature is useful for storing data such 241 as access control rules, which must be evaluated in a specific order. 242 If the access control information is stored in a multi-valued 243 attribute without a means of preserving the the order of the rules, 244 the access control rules cannot be evaluated properly. As the use of 245 LDAP to store security policy and access control information becomes 246 more prevalent, the necessity of this feature continues to grow. 247 248 The "X-ORDERED 'SIBLINGS'" extension is used with single-valued 249 attributes to maintain the order of all the onelevel children of a 250 parent entry. That is, ordering will be maintained for all the child 251 entries whose RDNs are all of the same AttributeType. The motivation 252 for this feature is much the same as for the 'VALUES' feature. 253 Sometimes the information with the ordering dependency is too complex 254 or highly structured to be conveniently stored in values of a multi- 255 valued attribute. For example, one could store a prioritized list of 256 servers as a set of separate entries, each entry containing separate 257 attributes for a URL, a set of authentication credentials, and 258 various other parameters. Using the 'SIBLINGS' feature with the 259 attribute in the entries' RDNs would ensure that when obtaining the 260 list of these entries, the list is returned in the intended order. 261 2623.2. Encoding 263 264 Ordering information is encoded by prepending a value's ordinal index 265 to each value, enclosed in braces. The following BNF specifies the 266 encoding. It uses elements defined in [RFC2252]. 267 268 d = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" 269 270 numericstring = 1*d 271 272 ordering-prefix = "{" numericstring "}" 273 274 value = <any sequence of octets> 275 276 277 278 279Chu Expires November 2, 2006 [Page 5] 280 281Internet-Draft LDAP Ordering Extension May 2006 282 283 284 ordered-value = ordering-prefix value 285 286 The ordinals are zero-based and increment by one for each value. 287 288 Note that when storing ordered-values into the directory, the 289 ordering-prefix can usually be omitted as it will be generated 290 automatically. But if the original value already begins with a 291 sequence of characters in the form of an ordering-prefix, then an 292 ordering-prefix must always be provided with that value, otherwise 293 the value will be processed and stored incorrectly. 294 295 Using this extension on an attribute requires that ordering-prefix is 296 a legal value of the LDAP syntax of that attribute. 297 2983.3. Ordering Properties 299 300 Since the ordering-prefix is stored with the attribute values, it 301 will be propagated to any clients or servers that access the data. 302 303 Servers implementing this scheme SHOULD sort the values according to 304 their ordering-prefix before returning them in search results. 305 306 The presence of the ordering extension alters the matching rules that 307 apply to the attribute: 308 309 When presented with an AssertionValue that does not have an 310 ordering-prefix, the ordering-prefix in the AttributeValue is 311 ignored. 312 313 When presented with an AssertionValue that consists solely of an 314 ordering-prefix, only the ordering-prefix of the AttributeValue is 315 compared; the remainder of the value is ignored. 316 317 When presented with an AssertionValue containing both the 318 ordering-prefix and a value, both components are compared to 319 determine a match. 320 321 A side effect of these properties is that even attributes that 322 normally would have no equality matching rule can be matched by an 323 ordering-prefix. 324 325 The ordering-prefix may also be used in Modification requests to 326 specify which values to delete, and in which position values should 327 be added. When processing deletions and insertions, all of the 328 ordinals are recounted after each individual modification. 329 330 If a value being added does not have an ordering-prefix, it is simply 331 appended to the list and the appropriate ordering-prefix is 332 333 334 335Chu Expires November 2, 2006 [Page 6] 336 337Internet-Draft LDAP Ordering Extension May 2006 338 339 340 automatically generated. Likewise if an ordering-prefix is provided 341 that is greater than or equal to the number of existing values. 342 343 See the examples in the next section. 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391Chu Expires November 2, 2006 [Page 7] 392 393Internet-Draft LDAP Ordering Extension May 2006 394 395 3964. Examples 397 3984.1. Sample Schema 399 400 This schema is used for all of the examples: 401 402 ( EXAMPLE_AT.1 NAME 'olcDatabase' 403 EQUALITY caseIgnoreMatch 404 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 405 SINGLE-VALUE X-ORDERED 'SIBLINGS' ) 406 407 ( EXAMPLE_AT.2 NAME 'olcSuffix' 408 EQUALITY distinguishedNameMatch 409 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 410 X-ORDERED 'VALUES' ) 411 412 ( EXAMPLE_OC.1 NAME 'olcDatabaseConfig' 413 SUP top STRUCTURAL 414 MAY ( olcDatabase $ olcSuffix ) ) 415 4164.2. Ordered Values 417 418 Given this entry: 419 420 dn: olcDatabase={1}bdb,cn=config 421 olcDatabase: {1}bdb 422 objectClass: olcDatabaseConfig 423 olcSuffix: {0}dc=example,dc=com 424 olcSuffix: {1}o=example.com 425 olcSuffix: {2}o=The Example Company 426 olcSuffix: {3}o=example,c=us 427 428 We can perform these Modify operations: 429 430 1. dn: olcDatabase={1}bdb,cn=config 431 changetype: modify 432 delete: olcSuffix 433 olcSuffix: {0} 434 - 435 This operation deletes the first olcSuffix, regardless of its 436 value. All other values are bumped up one position. The 437 olcSuffix attribute will end up containing: 438 olcSuffix: {0}o=example.com 439 olcSuffix: {1}o=The Example Company 440 olcSuffix: {2}o=example,c=us 441 442 2. Starting from the original entry, we could issue this change 443 instead: 444 445 446 447Chu Expires November 2, 2006 [Page 8] 448 449Internet-Draft LDAP Ordering Extension May 2006 450 451 452 delete: olcSuffix 453 olcSuffix: o=example.com 454 - 455 This operation deletes the olcSuffix that matches the value, 456 regardless of its ordering-prefix. The olcSuffix attribute will 457 contain: 458 olcSuffix: {0}dc=example,dc=com 459 olcSuffix: {1}o=The Example Company 460 olcSuffix: {2}o=example,c=us 461 462 3. Again, starting from the original entry, we could issue this 463 change: 464 delete: olcSuffix 465 olcSuffix: {2}o=The Example Company 466 - 467 Here both the ordering-prefix and the value must match, otherwise 468 the Modify would fail with noSuchAttribute. In this case the 469 olcSuffix attribute results in: 470 olcSuffix: {0}dc=example,dc=com 471 olcSuffix: {1}o=example.com 472 olcSuffix: {2}o=example,c=us 473 474 4. Adding a new value without an ordering-prefix simply appends: 475 add: olcSuffix 476 olcSuffix: o=example.org 477 - 478 The resulting attribute would be: 479 olcSuffix: {0}dc=example,dc=com 480 olcSuffix: {1}o=example.com 481 olcSuffix: {2}o=The Example Company 482 olcSuffix: {3}o=example,c=us 483 olcSuffix: {4}o=example.org 484 485 5. Adding a new value with an ordering-prefix inserts into the 486 specified position: 487 add: olcSuffix 488 olcSuffix: {0}o=example.org 489 - 490 The resulting attribute would be: 491 olcSuffix: {0}o=example.org 492 olcSuffix: {1}dc=example,dc=com 493 olcSuffix: {2}o=example.com 494 olcSuffix: {3}o=The Example Company 495 olcSuffix: {4}o=example,c=us 496 497 6. Modifying multiple values in one operation: 498 add: olcSuffix 499 olcSuffix: {0}ou=Dis,o=example.com 500 501 502 503Chu Expires November 2, 2006 [Page 9] 504 505Internet-Draft LDAP Ordering Extension May 2006 506 507 508 olcSuffix: {0}ou=Dat,o=example,com 509 - 510 delete: olcSuffix: 511 olcSuffix: {2} 512 olcSuffix: {1} 513 - 514 The resulting attribute would be: 515 olcSuffix: {0}ou=Dat,o=example,com 516 olcSuffix: {1}dc=example,dc=com 517 olcSuffix: {2}o=example.com 518 olcSuffix: {3}o=The Example Company 519 olcSuffix: {4}o=example,c=us 520 521 7. If the Adds and Deletes in the previous example were done in the 522 opposite order: 523 delete: olcSuffix: 524 olcSuffix: {2} 525 olcSuffix: {1} 526 - 527 add: olcSuffix 528 olcSuffix: {0}ou=Dis,o=example.com 529 olcSuffix: {0}ou=Dat,o=example,com 530 - 531 The result would be: 532 olcSuffix: {0}ou=Dat,o=example,com 533 olcSuffix: {1}ou=Dis,o=example.com 534 olcSuffix: {2}o=example.org 535 olcSuffix: {3}o=The Example Company 536 olcSuffix: {4}o=example,c=us 537 538 Note that matching against an ordering-prefix can also be done in 539 Compare operations and Search filters. E.g., the filter 540 "(olcSuffix={4})" would match all entries with at least 5 olcSuffix 541 values. 542 5434.3. Ordered Siblings 544 545 The rules for Ordered Siblings are basically the same as for Ordered 546 Values, except instead of working primarily with the Modify request, 547 the operations of interest here are Add, Delete, and ModRDN. 548 549 Given these entries: 550 551 dn: olcDatabase={0}config,cn=config 552 olcDatabase: {0}config 553 objectClass: olcDatabaseConfig 554 olcSuffix: {0}cn=config 555 556 557 558 559Chu Expires November 2, 2006 [Page 10] 560 561Internet-Draft LDAP Ordering Extension May 2006 562 563 564 dn: olcDatabase={1}bdb,cn=config 565 olcDatabase: {1}bdb 566 objectClass: olcDatabaseConfig 567 olcSuffix: {0}dc=example,dc=com 568 569 We can perform these operations: 570 571 1. Add a new entry with no ordering-prefix: 572 dn: olcDatabase=hdb,cn=config 573 changetype: add 574 olcDatabase: hdb 575 objectClass: olcDatabaseConfig 576 olcSuffix: {0}dc=example,dc=org 577 The resulting entry will be: 578 dn: olcDatabase={2}hdb,cn=config 579 olcDatabase: {2}hdb 580 objectClass: olcDatabaseConfig 581 olcSuffix: {0}dc=example,dc=org 582 583 2. Continuing on with these three entries, we can add another entry 584 with a specific ordering-prefix: 585 dn: olcDatabase={1}ldif,cn=config 586 changetype: add 587 olcDatabase: {1}ldif 588 objectClass: olcDatabaseConfig 589 olcSuffix: {0}o=example.com 590 This would give us four entries, whose DNs are: 591 592 dn: olcDatabase={0}config,cn=config 593 594 dn: olcDatabase={1}ldif,cn=config 595 596 dn: olcDatabase={2}bdb,cn=config 597 598 dn: olcDatabase={3}hdb,cn=config 599 600 3. Issuing a ModRDN request will cause multiple entries to be 601 renamed: 602 dn: olcDatabase={1}ldif,cn=config 603 changetype: modrdn 604 newrdn: olcDatabase={99}ldif 605 deleteoldrdn: 1 606 The resulting entries would be named: 607 608 dn: olcDatabase={0}config,cn=config 609 610 dn: olcDatabase={1}bdb,cn=config 611 612 613 614 615Chu Expires November 2, 2006 [Page 11] 616 617Internet-Draft LDAP Ordering Extension May 2006 618 619 620 dn: olcDatabase={2}hdb,cn=config 621 622 dn: olcDatabase={3}ldif,cn=config 623 624 4. As may be expected, a Delete request will also rename the 625 remaining entries: 626 dn: olcDatabase={1}bdb,cn=config 627 changetype: delete 628 The remaining entries would be named: 629 630 dn: olcDatabase={0}config,cn=config 631 632 dn: olcDatabase={1}hdb,cn=config 633 634 dn: olcDatabase={2}ldif,cn=config 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671Chu Expires November 2, 2006 [Page 12] 672 673Internet-Draft LDAP Ordering Extension May 2006 674 675 6765. Security Considerations 677 678 General LDAP security considerations [RFC3377] apply. 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727Chu Expires November 2, 2006 [Page 13] 728 729Internet-Draft LDAP Ordering Extension May 2006 730 731 7326. Normative References 733 734 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 735 Requirement Levels", BCP 14, RFC 2119, March 1997. 736 737 [RFC2252] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, 738 "Lightweight Directory Access Protocol (v3): Attribute 739 Syntax Definitions", RFC 2252, December 1997. 740 741 [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access 742 Protocol (v3): Technical Specification", RFC 3377, 743 September 2002. 744 745 [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) 746 Considerations for the Lightweight Directory Access 747 Protocol (LDAP)", RFC 3383, September 2002. 748 749 [X680] International Telecommunications Union, "Abstract Syntax 750 Notation One (ASN.1): Specification of basic notation", 751 ITU-T Recommendation X.680, July 2002. 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783Chu Expires November 2, 2006 [Page 14] 784 785Internet-Draft LDAP Ordering Extension May 2006 786 787 788Appendix A. IANA Considerations 789 790 In accordance with [RFC3383] (what needs to be done here?) . We 791 probably need an OID for advertising in supportedFeatures. 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839Chu Expires November 2, 2006 [Page 15] 840 841Internet-Draft LDAP Ordering Extension May 2006 842 843 844Author's Address 845 846 Howard Chu 847 Symas Corp. 848 18740 Oxnard Street, Suite 313A 849 Tarzana, California 91356 850 USA 851 852 Phone: +1 818 757-7087 853 Email: hyc@symas.com 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895Chu Expires November 2, 2006 [Page 16] 896 897Internet-Draft LDAP Ordering Extension May 2006 898 899 900Full Copyright Statement 901 902 Copyright (C) The Internet Society (2006). 903 904 This document is subject to the rights, licenses and restrictions 905 contained in BCP 78, and except as set forth therein, the authors 906 retain all their rights. 907 908 This document and the information contained herein are provided on an 909 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 910 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 911 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 912 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 913 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 914 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 915 916 917Intellectual Property 918 919 The IETF takes no position regarding the validity or scope of any 920 Intellectual Property Rights or other rights that might be claimed to 921 pertain to the implementation or use of the technology described in 922 this document or the extent to which any license under such rights 923 might or might not be available; nor does it represent that it has 924 made any independent effort to identify any such rights. Information 925 on the procedures with respect to rights in RFC documents can be 926 found in BCP 78 and BCP 79. 927 928 Copies of IPR disclosures made to the IETF Secretariat and any 929 assurances of licenses to be made available, or the result of an 930 attempt made to obtain a general license or permission for the use of 931 such proprietary rights by implementers or users of this 932 specification can be obtained from the IETF on-line IPR repository at 933 http://www.ietf.org/ipr. 934 935 The IETF invites any interested party to bring to its attention any 936 copyrights, patents or patent applications, or other proprietary 937 rights that may cover technology that may be required to implement 938 this standard. Please address the information to the IETF at 939 ietf-ipr@ietf.org. 940 941 942Acknowledgment 943 944 Funding for the RFC Editor function is provided by the IETF 945 Administrative Support Activity (IASA). 946 947 948 949 950 951Chu Expires November 2, 2006 [Page 17] 952 953