From: Howard Chu <hyc@openldap.org>
Date: Wed, 19 Oct 2011 10:52:07 +0000 (-0700)
Subject: This ought to have been here a long time ago
X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=0e70713702f999f2e801c1a85957f1d4edfb6a78;p=openldap

This ought to have been here a long time ago
---

diff --git a/doc/drafts/draft-chu-ldap-xordered-xx.txt b/doc/drafts/draft-chu-ldap-xordered-xx.txt
new file mode 100644
index 0000000000..057a20ded3
--- /dev/null
+++ b/doc/drafts/draft-chu-ldap-xordered-xx.txt
@@ -0,0 +1,952 @@
+
+
+
+Network Working Group                                             H. Chu
+Internet-Draft                                               Symas Corp.
+Intended status: Informational                                  May 2006
+Expires: November 2, 2006
+
+
+                   Ordered Entries and Values in LDAP
+                     draft-chu-ldap-xordered-00.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on November 2, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chu                     Expires November 2, 2006                [Page 1]
+
+Internet-Draft           LDAP Ordering Extension                May 2006
+
+
+Abstract
+
+   As LDAP is used more extensively for managing various kinds of data,
+   one often encounters a need to preserve both the ordering and the
+   content of data, despite the inherently unordered structure of
+   entries and attribute values in the directory.  This document
+   describes a scheme to attach ordering information to attributes in a
+   directory so that the ordering may be preserved and propagated to
+   other LDAP applications.
+
+
+Table of Contents
+
+   1.          Introduction . . . . . . . . . . . . . . . . . . . . .  3
+   2.          Conventions  . . . . . . . . . . . . . . . . . . . . .  4
+   3.          Ordering Extension . . . . . . . . . . . . . . . . . .  5
+   3.1.        Overview . . . . . . . . . . . . . . . . . . . . . . .  5
+   3.2.        Encoding . . . . . . . . . . . . . . . . . . . . . . .  5
+   3.3.        Ordering Properties  . . . . . . . . . . . . . . . . .  6
+   4.          Examples . . . . . . . . . . . . . . . . . . . . . . .  8
+   4.1.        Sample Schema  . . . . . . . . . . . . . . . . . . . .  8
+   4.2.        Ordered Values . . . . . . . . . . . . . . . . . . . .  8
+   4.3.        Ordered Siblings . . . . . . . . . . . . . . . . . . . 10
+   5.          Security Considerations  . . . . . . . . . . . . . . . 13
+   6.          Normative References . . . . . . . . . . . . . . . . . 14
+   Appendix A. IANA Considerations  . . . . . . . . . . . . . . . . . 15
+               Author's Address . . . . . . . . . . . . . . . . . . . 16
+               Intellectual Property and Copyright Statements . . . . 17
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chu                     Expires November 2, 2006                [Page 2]
+
+Internet-Draft           LDAP Ordering Extension                May 2006
+
+
+1.  Introduction
+
+   Information in LDAP directories is usually handled by applications in
+   the form of ordered lists, which tends to encourage application
+   developers to assume they are maintained as such, i.e., it is assumed
+   that information stored in a particular order will always be
+   retrieved and presented in that same order.  The fact that directory
+   attributes actually store sets of values, which are inherently
+   unordered, often causes grief to users migrating their data into
+   LDAP.  Similar concerns arise over the order in which entries
+   themselves are stored and retrieved from the directory.
+
+   This document describes a schema extension that may be used in LDAP
+   attribute definitions to store ordering information along with the
+   attribute values, so that the ordering can be recovered when
+   retrieved by an LDAP client.  The extension also provides automated
+   management of this ordering information to ease manipulation of the
+   ordered values.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chu                     Expires November 2, 2006                [Page 3]
+
+Internet-Draft           LDAP Ordering Extension                May 2006
+
+
+2.  Conventions
+
+   Imperative keywords defined in [RFC2119] are used in this document,
+   and carry the meanings described there.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chu                     Expires November 2, 2006                [Page 4]
+
+Internet-Draft           LDAP Ordering Extension                May 2006
+
+
+3.  Ordering Extension
+
+3.1.  Overview
+
+   The "X-ORDERED" schema extension is added to an
+   AttributeTypeDescription to signify the use of this ordering
+   mechanism.  The extension has two variants, selected by either the
+   'VALUES' or 'SIBLINGS' qdstrings.  In general this extension is only
+   compatible with AttributeTypes that have a string-oriented syntax.
+
+   The "X-ORDERED 'VALUES'" extension is used with multi-valued
+   attributes to maintain the order of multiple values of a given
+   attribute.  For example, this feature is useful for storing data such
+   as access control rules, which must be evaluated in a specific order.
+   If the access control information is stored in a multi-valued
+   attribute without a means of preserving the the order of the rules,
+   the access control rules cannot be evaluated properly.  As the use of
+   LDAP to store security policy and access control information becomes
+   more prevalent, the necessity of this feature continues to grow.
+
+   The "X-ORDERED 'SIBLINGS'" extension is used with single-valued
+   attributes to maintain the order of all the onelevel children of a
+   parent entry.  That is, ordering will be maintained for all the child
+   entries whose RDNs are all of the same AttributeType.  The motivation
+   for this feature is much the same as for the 'VALUES' feature.
+   Sometimes the information with the ordering dependency is too complex
+   or highly structured to be conveniently stored in values of a multi-
+   valued attribute.  For example, one could store a prioritized list of
+   servers as a set of separate entries, each entry containing separate
+   attributes for a URL, a set of authentication credentials, and
+   various other parameters.  Using the 'SIBLINGS' feature with the
+   attribute in the entries' RDNs would ensure that when obtaining the
+   list of these entries, the list is returned in the intended order.
+
+3.2.  Encoding
+
+   Ordering information is encoded by prepending a value's ordinal index
+   to each value, enclosed in braces.  The following BNF specifies the
+   encoding.  It uses elements defined in [RFC2252].
+
+      d = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"
+
+      numericstring = 1*d
+
+      ordering-prefix = "{" numericstring "}"
+
+      value = <any sequence of octets>
+
+
+
+
+Chu                     Expires November 2, 2006                [Page 5]
+
+Internet-Draft           LDAP Ordering Extension                May 2006
+
+
+      ordered-value = ordering-prefix value
+
+   The ordinals are zero-based and increment by one for each value.
+
+   Note that when storing ordered-values into the directory, the
+   ordering-prefix can usually be omitted as it will be generated
+   automatically.  But if the original value already begins with a
+   sequence of characters in the form of an ordering-prefix, then an
+   ordering-prefix must always be provided with that value, otherwise
+   the value will be processed and stored incorrectly.
+
+   Using this extension on an attribute requires that ordering-prefix is
+   a legal value of the LDAP syntax of that attribute.
+
+3.3.  Ordering Properties
+
+   Since the ordering-prefix is stored with the attribute values, it
+   will be propagated to any clients or servers that access the data.
+
+   Servers implementing this scheme SHOULD sort the values according to
+   their ordering-prefix before returning them in search results.
+
+   The presence of the ordering extension alters the matching rules that
+   apply to the attribute:
+
+      When presented with an AssertionValue that does not have an
+      ordering-prefix, the ordering-prefix in the AttributeValue is
+      ignored.
+
+      When presented with an AssertionValue that consists solely of an
+      ordering-prefix, only the ordering-prefix of the AttributeValue is
+      compared; the remainder of the value is ignored.
+
+      When presented with an AssertionValue containing both the
+      ordering-prefix and a value, both components are compared to
+      determine a match.
+
+   A side effect of these properties is that even attributes that
+   normally would have no equality matching rule can be matched by an
+   ordering-prefix.
+
+   The ordering-prefix may also be used in Modification requests to
+   specify which values to delete, and in which position values should
+   be added.  When processing deletions and insertions, all of the
+   ordinals are recounted after each individual modification.
+
+   If a value being added does not have an ordering-prefix, it is simply
+   appended to the list and the appropriate ordering-prefix is
+
+
+
+Chu                     Expires November 2, 2006                [Page 6]
+
+Internet-Draft           LDAP Ordering Extension                May 2006
+
+
+   automatically generated.  Likewise if an ordering-prefix is provided
+   that is greater than or equal to the number of existing values.
+
+   See the examples in the next section.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chu                     Expires November 2, 2006                [Page 7]
+
+Internet-Draft           LDAP Ordering Extension                May 2006
+
+
+4.  Examples
+
+4.1.  Sample Schema
+
+   This schema is used for all of the examples:
+
+   ( EXAMPLE_AT.1 NAME 'olcDatabase'
+   EQUALITY caseIgnoreMatch
+   SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+   SINGLE-VALUE X-ORDERED 'SIBLINGS' )
+
+   ( EXAMPLE_AT.2 NAME 'olcSuffix'
+   EQUALITY distinguishedNameMatch
+   SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+   X-ORDERED 'VALUES' )
+
+   ( EXAMPLE_OC.1 NAME 'olcDatabaseConfig'
+   SUP top STRUCTURAL
+   MAY ( olcDatabase $ olcSuffix ) )
+
+4.2.  Ordered Values
+
+   Given this entry:
+
+   dn: olcDatabase={1}bdb,cn=config
+   olcDatabase: {1}bdb
+   objectClass: olcDatabaseConfig
+   olcSuffix: {0}dc=example,dc=com
+   olcSuffix: {1}o=example.com
+   olcSuffix: {2}o=The Example Company
+   olcSuffix: {3}o=example,c=us
+
+   We can perform these Modify operations:
+
+   1.  dn: olcDatabase={1}bdb,cn=config
+       changetype: modify
+       delete: olcSuffix
+       olcSuffix: {0}
+       -
+       This operation deletes the first olcSuffix, regardless of its
+       value.  All other values are bumped up one position.  The
+       olcSuffix attribute will end up containing:
+       olcSuffix: {0}o=example.com
+       olcSuffix: {1}o=The Example Company
+       olcSuffix: {2}o=example,c=us
+
+   2.  Starting from the original entry, we could issue this change
+       instead:
+
+
+
+Chu                     Expires November 2, 2006                [Page 8]
+
+Internet-Draft           LDAP Ordering Extension                May 2006
+
+
+       delete: olcSuffix
+       olcSuffix: o=example.com
+       -
+       This operation deletes the olcSuffix that matches the value,
+       regardless of its ordering-prefix.  The olcSuffix attribute will
+       contain:
+       olcSuffix: {0}dc=example,dc=com
+       olcSuffix: {1}o=The Example Company
+       olcSuffix: {2}o=example,c=us
+
+   3.  Again, starting from the original entry, we could issue this
+       change:
+       delete: olcSuffix
+       olcSuffix: {2}o=The Example Company
+       -
+       Here both the ordering-prefix and the value must match, otherwise
+       the Modify would fail with noSuchAttribute.  In this case the
+       olcSuffix attribute results in:
+       olcSuffix: {0}dc=example,dc=com
+       olcSuffix: {1}o=example.com
+       olcSuffix: {2}o=example,c=us
+
+   4.  Adding a new value without an ordering-prefix simply appends:
+       add: olcSuffix
+       olcSuffix: o=example.org
+       -
+       The resulting attribute would be:
+       olcSuffix: {0}dc=example,dc=com
+       olcSuffix: {1}o=example.com
+       olcSuffix: {2}o=The Example Company
+       olcSuffix: {3}o=example,c=us
+       olcSuffix: {4}o=example.org
+
+   5.  Adding a new value with an ordering-prefix inserts into the
+       specified position:
+       add: olcSuffix
+       olcSuffix: {0}o=example.org
+       -
+       The resulting attribute would be:
+       olcSuffix: {0}o=example.org
+       olcSuffix: {1}dc=example,dc=com
+       olcSuffix: {2}o=example.com
+       olcSuffix: {3}o=The Example Company
+       olcSuffix: {4}o=example,c=us
+
+   6.  Modifying multiple values in one operation:
+       add: olcSuffix
+       olcSuffix: {0}ou=Dis,o=example.com
+
+
+
+Chu                     Expires November 2, 2006                [Page 9]
+
+Internet-Draft           LDAP Ordering Extension                May 2006
+
+
+       olcSuffix: {0}ou=Dat,o=example,com
+       -
+       delete: olcSuffix:
+       olcSuffix: {2}
+       olcSuffix: {1}
+       -
+       The resulting attribute would be:
+       olcSuffix: {0}ou=Dat,o=example,com
+       olcSuffix: {1}dc=example,dc=com
+       olcSuffix: {2}o=example.com
+       olcSuffix: {3}o=The Example Company
+       olcSuffix: {4}o=example,c=us
+
+   7.  If the Adds and Deletes in the previous example were done in the
+       opposite order:
+       delete: olcSuffix:
+       olcSuffix: {2}
+       olcSuffix: {1}
+       -
+       add: olcSuffix
+       olcSuffix: {0}ou=Dis,o=example.com
+       olcSuffix: {0}ou=Dat,o=example,com
+       -
+       The result would be:
+       olcSuffix: {0}ou=Dat,o=example,com
+       olcSuffix: {1}ou=Dis,o=example.com
+       olcSuffix: {2}o=example.org
+       olcSuffix: {3}o=The Example Company
+       olcSuffix: {4}o=example,c=us
+
+   Note that matching against an ordering-prefix can also be done in
+   Compare operations and Search filters.  E.g., the filter
+   "(olcSuffix={4})" would match all entries with at least 5 olcSuffix
+   values.
+
+4.3.  Ordered Siblings
+
+   The rules for Ordered Siblings are basically the same as for Ordered
+   Values, except instead of working primarily with the Modify request,
+   the operations of interest here are Add, Delete, and ModRDN.
+
+   Given these entries:
+
+   dn: olcDatabase={0}config,cn=config
+   olcDatabase: {0}config
+   objectClass: olcDatabaseConfig
+   olcSuffix: {0}cn=config
+
+
+
+
+Chu                     Expires November 2, 2006               [Page 10]
+
+Internet-Draft           LDAP Ordering Extension                May 2006
+
+
+   dn: olcDatabase={1}bdb,cn=config
+   olcDatabase: {1}bdb
+   objectClass: olcDatabaseConfig
+   olcSuffix: {0}dc=example,dc=com
+
+   We can perform these operations:
+
+   1.  Add a new entry with no ordering-prefix:
+       dn: olcDatabase=hdb,cn=config
+       changetype: add
+       olcDatabase: hdb
+       objectClass: olcDatabaseConfig
+       olcSuffix: {0}dc=example,dc=org
+       The resulting entry will be:
+       dn: olcDatabase={2}hdb,cn=config
+       olcDatabase: {2}hdb
+       objectClass: olcDatabaseConfig
+       olcSuffix: {0}dc=example,dc=org
+
+   2.  Continuing on with these three entries, we can add another entry
+       with a specific ordering-prefix:
+       dn: olcDatabase={1}ldif,cn=config
+       changetype: add
+       olcDatabase: {1}ldif
+       objectClass: olcDatabaseConfig
+       olcSuffix: {0}o=example.com
+       This would give us four entries, whose DNs are:
+
+          dn: olcDatabase={0}config,cn=config
+
+          dn: olcDatabase={1}ldif,cn=config
+
+          dn: olcDatabase={2}bdb,cn=config
+
+          dn: olcDatabase={3}hdb,cn=config
+
+   3.  Issuing a ModRDN request will cause multiple entries to be
+       renamed:
+       dn: olcDatabase={1}ldif,cn=config
+       changetype: modrdn
+       newrdn: olcDatabase={99}ldif
+       deleteoldrdn: 1
+       The resulting entries would be named:
+
+          dn: olcDatabase={0}config,cn=config
+
+          dn: olcDatabase={1}bdb,cn=config
+
+
+
+
+Chu                     Expires November 2, 2006               [Page 11]
+
+Internet-Draft           LDAP Ordering Extension                May 2006
+
+
+          dn: olcDatabase={2}hdb,cn=config
+
+          dn: olcDatabase={3}ldif,cn=config
+
+   4.  As may be expected, a Delete request will also rename the
+       remaining entries:
+       dn: olcDatabase={1}bdb,cn=config
+       changetype: delete
+       The remaining entries would be named:
+
+          dn: olcDatabase={0}config,cn=config
+
+          dn: olcDatabase={1}hdb,cn=config
+
+          dn: olcDatabase={2}ldif,cn=config
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chu                     Expires November 2, 2006               [Page 12]
+
+Internet-Draft           LDAP Ordering Extension                May 2006
+
+
+5.  Security Considerations
+
+   General LDAP security considerations [RFC3377] apply.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chu                     Expires November 2, 2006               [Page 13]
+
+Internet-Draft           LDAP Ordering Extension                May 2006
+
+
+6.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2252]  Wahl, M., Coulbeck, A., Howes, T., and S. Kille,
+              "Lightweight Directory Access Protocol (v3): Attribute
+              Syntax Definitions", RFC 2252, December 1997.
+
+   [RFC3377]  Hodges, J. and R. Morgan, "Lightweight Directory Access
+              Protocol (v3): Technical Specification", RFC 3377,
+              September 2002.
+
+   [RFC3383]  Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+              Considerations for the Lightweight Directory Access
+              Protocol (LDAP)", RFC 3383, September 2002.
+
+   [X680]     International Telecommunications Union, "Abstract Syntax
+              Notation One (ASN.1): Specification of basic notation",
+              ITU-T Recommendation X.680, July 2002.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chu                     Expires November 2, 2006               [Page 14]
+
+Internet-Draft           LDAP Ordering Extension                May 2006
+
+
+Appendix A.  IANA Considerations
+
+   In accordance with [RFC3383] (what needs to be done here?) .  We
+   probably need an OID for advertising in supportedFeatures.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chu                     Expires November 2, 2006               [Page 15]
+
+Internet-Draft           LDAP Ordering Extension                May 2006
+
+
+Author's Address
+
+   Howard Chu
+   Symas Corp.
+   18740 Oxnard Street, Suite 313A
+   Tarzana, California  91356
+   USA
+
+   Phone: +1 818 757-7087
+   Email: hyc@symas.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chu                     Expires November 2, 2006               [Page 16]
+
+Internet-Draft           LDAP Ordering Extension                May 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.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+Chu                     Expires November 2, 2006               [Page 17]
+
diff --git a/doc/drafts/draft-chu-ldap-xordered-xx.xml b/doc/drafts/draft-chu-ldap-xordered-xx.xml
new file mode 100644
index 0000000000..821f2d07bf
--- /dev/null
+++ b/doc/drafts/draft-chu-ldap-xordered-xx.xml
@@ -0,0 +1,390 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
+	<!ENTITY rfc2119	PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
+	 <!ENTITY rfc822 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.0822.xml'>
+	 <!ENTITY rfc2222 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2222.xml'>
+	 <!ENTITY rfc2251 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2251.xml'>
+	 <!ENTITY rfc2252 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2252.xml'>
+	 <!ENTITY rfc2254 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2254.xml'>
+	 <!ENTITY rfc2255 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2255.xml'>
+	<!ENTITY rfc3377 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3377.xml'>
+	<!ENTITY rfc3383 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3383.xml'>
+
+]>
+<?xml-stylesheet type='text/xsl' href='http://www.greenbytes.de/tech/webdav/rfc2629.xslt' ?>
+<?rfc toc="yes" ?>
+<?rfc tocdepth="2" ?>
+<?rfc tocindent="no" ?>
+<?rfc symrefs="yes" ?>
+<?rfc sortrefs="yes"?>
+<?rfc iprnotified="no" ?>
+<?rfc strict="yes" ?>
+<rfc ipr="full3978" docName="draft-chu-ldap-xordered-00.txt">
+	<front>
+		<title abbrev="LDAP Ordering Extension">Ordered Entries and Values in LDAP</title>
+		<author initials="H" fullname="Howard Chu" surname="Chu">
+			<organization>Symas Corp.</organization>
+			<address>
+				<postal>
+					<street>18740 Oxnard Street, Suite 313A</street>
+					<city>Tarzana</city>
+					<region>California</region>
+					<code>91356</code>
+					<country>USA</country>
+				</postal>
+				<phone>+1 818 757-7087</phone>
+				<email>hyc@symas.com</email>
+			</address>
+		</author>
+		<date year="2006" month="May"/>
+		<abstract>
+			<t>As LDAP is used more extensively for managing various
+kinds of data, one often encounters a need to preserve both the
+ordering and the content of data, despite the inherently unordered
+structure of entries and attribute values in the directory. This
+document describes a scheme to attach ordering information to
+attributes in a directory so that the ordering may be
+preserved and propagated to other LDAP applications.</t>
+		</abstract>
+	</front>
+
+	<middle>
+
+		<section title="Introduction">
+			<t>Information in LDAP directories is usually handled by
+applications in the form of ordered lists, which tends to encourage
+application developers to
+assume they are maintained as such, i.e., it is assumed that information
+stored in a particular order will always be retrieved and presented in
+that same order. The fact that directory attributes actually store sets of
+values, which are inherently unordered, often causes grief to users
+migrating their data into LDAP. Similar concerns arise over the order
+in which entries themselves are stored and retrieved from the directory.</t>
+			<t>This document describes a schema extension that may be
+used in LDAP attribute definitions to store ordering information along
+with the attribute values, so that the ordering can be recovered when
+retrieved by an LDAP client. The extension also provides automated
+management of this ordering information to ease manipulation of the
+ordered values.</t>
+		</section>
+
+		<section title="Conventions">
+			<t>Imperative keywords defined in <xref target="RFC2119"/> are used
+in this document, and carry the meanings described there.</t>
+		</section>
+
+		<section title="Ordering Extension">
+			<section title="Overview">
+		<t>The "X-ORDERED" schema extension is added to an
+AttributeTypeDescription to signify the use of this ordering mechanism. The
+extension has two variants, selected by either the 'VALUES' or 'SIBLINGS'
+qdstrings. In general this extension is only compatible with AttributeTypes
+that have a string-oriented syntax.</t>
+		<t>The "X-ORDERED 'VALUES'" extension is used with multi-valued
+attributes to maintain the order of multiple values of a given attribute.
+For example, this feature is useful for storing data such as access control
+rules, which must be evaluated in a specific order. If the access control
+information is stored in a multi-valued attribute without a means of
+preserving the the order of the rules, the access control rules cannot be
+evaluated properly. As the use of LDAP to store security policy and access
+control information becomes more prevalent, the necessity of this feature
+continues to grow.</t>
+		<t>
+The "X-ORDERED 'SIBLINGS'" extension is used with single-valued attributes
+to maintain the order of all the onelevel children of a parent entry. That is,
+ordering will be maintained for all the child entries whose RDNs are all of
+the same AttributeType. The motivation for this feature is much the same
+as for the 'VALUES' feature. Sometimes the information with the ordering
+dependency is too complex or highly structured to be conveniently stored
+in values of a multi-valued attribute. For example, one could store a
+prioritized list of servers as a set of separate entries, each entry
+containing separate attributes for a URL, a set of authentication
+credentials, and various other parameters. Using the 'SIBLINGS' feature
+with the attribute in the entries' RDNs would ensure that when obtaining
+the list of these entries, the list is returned in the intended order.
+		</t>
+			</section>
+			<section title="Encoding">
+		<t>Ordering information is encoded by prepending a value's ordinal
+index to each value, enclosed in braces. The following BNF specifies the
+encoding. It uses elements defined in <xref target="RFC2252"/>.
+	<list style="empty">
+	<t>d = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"</t>
+	<t>numericstring = 1*d</t>
+	<t>ordering-prefix = "{" numericstring "}"</t>
+	<t>value = &lt;any sequence of octets&gt;</t>
+	<t>ordered-value = ordering-prefix value</t>
+	</list></t>
+		<t>The ordinals are zero-based and increment by one for each value.</t>
+		<t>Note that when storing ordered-values into the directory, the
+ordering-prefix can usually be omitted as it will be generated automatically.
+But if the original value already begins with a sequence of characters in
+the form of an ordering-prefix, then an ordering-prefix must always be
+provided with that value, otherwise the value will be processed and
+stored incorrectly.</t>
+		<t>Using this extension on an attribute requires that ordering-prefix
+is a legal value of the LDAP syntax of that attribute.</t>
+		</section>
+		<section title="Ordering Properties">
+		<t>Since the ordering-prefix is stored with the attribute values,
+it will be propagated to any clients or servers that access the data.</t>
+		<t>Servers implementing this scheme SHOULD sort the values according
+to their ordering-prefix before returning them in search results.</t>
+		<t>The presence of the ordering extension alters the matching rules
+that apply to the attribute:
+	<list>
+	<t>When presented with an AssertionValue that does not have an
+ordering-prefix, the ordering-prefix in the AttributeValue is ignored.</t>
+	<t>When presented with an AssertionValue that consists solely of an
+ordering-prefix, only the ordering-prefix of the AttributeValue is compared;
+the remainder of the value is ignored.</t>
+	<t>When presented with an AssertionValue containing both the
+ordering-prefix and a value, both components are compared to determine a match.</t>
+	</list></t>
+	<t>A side effect of these properties is that even attributes that
+normally would have no equality matching rule can be matched by an
+ordering-prefix.</t>
+		<t>The ordering-prefix may also be used in Modification requests to
+specify which values to delete, and in which position values should be added.
+When processing deletions and insertions, all of the ordinals are recounted
+after each individual modification.</t>
+		<t>If a value being added does not have
+an ordering-prefix, it is simply appended to the list and the appropriate
+ordering-prefix is automatically generated. Likewise if an ordering-prefix
+is provided that is greater than or equal to the number of existing values.</t>
+		<t>See the examples in the next section.</t>
+			</section>
+		</section>
+		<section title="Examples">
+			<section title="Sample Schema">
+			<t>This schema is used for all of the examples:</t>
+			<t>( EXAMPLE_AT.1 NAME 'olcDatabase'<vspace/>
+			EQUALITY caseIgnoreMatch<vspace/>
+			SYNTAX 1.3.6.1.4.1.1466.115.121.1.15<vspace/>
+			SINGLE-VALUE X-ORDERED 'SIBLINGS' )</t>
+			<t>( EXAMPLE_AT.2 NAME 'olcSuffix'<vspace/>
+			EQUALITY distinguishedNameMatch<vspace/>
+			SYNTAX 1.3.6.1.4.1.1466.115.121.1.12<vspace/>
+			X-ORDERED 'VALUES' )</t>
+			<t>(  EXAMPLE_OC.1 NAME 'olcDatabaseConfig' <vspace/>
+			SUP top STRUCTURAL<vspace/>
+			MAY ( olcDatabase $ olcSuffix ) )</t>
+			</section>
+			<section title="Ordered Values">
+			<t>Given this entry:</t>
+			<t>dn: olcDatabase={1}bdb,cn=config<vspace/>
+			olcDatabase: {1}bdb<vspace/>
+			objectClass: olcDatabaseConfig<vspace/>
+			olcSuffix: {0}dc=example,dc=com<vspace/>
+			olcSuffix: {1}o=example.com<vspace/>
+			olcSuffix: {2}o=The Example Company<vspace/>
+			olcSuffix: {3}o=example,c=us</t>
+
+			<t>We can perform these Modify operations:
+			<list style="numbers">
+
+			<t>dn: olcDatabase={1}bdb,cn=config<vspace/>
+			changetype: modify<vspace/>
+			delete: olcSuffix<vspace/>
+			olcSuffix: {0}<vspace/>
+			-<vspace/>
+			This operation deletes the first olcSuffix, regardless of its
+			value. All other values are bumped up one position. The olcSuffix
+			attribute will end up containing:<vspace/>
+			olcSuffix: {0}o=example.com<vspace/>
+			olcSuffix: {1}o=The Example Company<vspace/>
+			olcSuffix: {2}o=example,c=us</t>
+
+			<t>Starting from the original entry, we could issue this change
+			instead:<vspace/>
+			delete: olcSuffix<vspace/>
+			olcSuffix: o=example.com<vspace/>
+			-<vspace/>
+			This operation deletes the olcSuffix that matches the value,
+			regardless of its ordering-prefix. The olcSuffix attribute will contain:<vspace/>
+			olcSuffix: {0}dc=example,dc=com<vspace/>
+			olcSuffix: {1}o=The Example Company<vspace/>
+			olcSuffix: {2}o=example,c=us</t>
+
+			<t>Again, starting from the original entry, we could issue this
+			change:<vspace/>
+			delete: olcSuffix<vspace/>
+			olcSuffix: {2}o=The Example Company<vspace/>
+			-<vspace/>
+			Here both the ordering-prefix and the value must match, otherwise
+			the Modify would fail with noSuchAttribute. In this case the
+			olcSuffix attribute results in:<vspace/>
+			olcSuffix: {0}dc=example,dc=com<vspace/>
+			olcSuffix: {1}o=example.com<vspace/>
+			olcSuffix: {2}o=example,c=us</t>
+
+			<t>Adding a new value without an ordering-prefix simply appends:<vspace/>
+			add: olcSuffix<vspace/>
+			olcSuffix: o=example.org<vspace/>
+			-<vspace/>
+			The resulting attribute would be:<vspace/>
+			olcSuffix: {0}dc=example,dc=com<vspace/>
+			olcSuffix: {1}o=example.com<vspace/>
+			olcSuffix: {2}o=The Example Company<vspace/>
+			olcSuffix: {3}o=example,c=us<vspace/>
+			olcSuffix: {4}o=example.org</t>
+
+			<t>Adding a new value with an ordering-prefix inserts into the
+			specified position:<vspace/>
+			add: olcSuffix<vspace/>
+			olcSuffix: {0}o=example.org<vspace/>
+			-<vspace/>
+			The resulting attribute would be:<vspace/>
+			olcSuffix: {0}o=example.org<vspace/>
+			olcSuffix: {1}dc=example,dc=com<vspace/>
+			olcSuffix: {2}o=example.com<vspace/>
+			olcSuffix: {3}o=The Example Company<vspace/>
+			olcSuffix: {4}o=example,c=us</t>
+
+			<t>Modifying multiple values in one operation:<vspace/>
+			add: olcSuffix<vspace/>
+			olcSuffix: {0}ou=Dis,o=example.com<vspace/>
+			olcSuffix: {0}ou=Dat,o=example,com<vspace/>
+			-<vspace/>
+			delete: olcSuffix:<vspace/>
+			olcSuffix: {2}<vspace/>
+			olcSuffix: {1}<vspace/>
+			-<vspace/>
+			The resulting attribute would be:<vspace/>
+			olcSuffix: {0}ou=Dat,o=example,com<vspace/>
+			olcSuffix: {1}dc=example,dc=com<vspace/>
+			olcSuffix: {2}o=example.com<vspace/>
+			olcSuffix: {3}o=The Example Company<vspace/>
+			olcSuffix: {4}o=example,c=us</t>
+
+			<t>If the Adds and Deletes in the previous example were done
+			in the opposite order:<vspace/>
+			delete: olcSuffix:<vspace/>
+			olcSuffix: {2}<vspace/>
+			olcSuffix: {1}<vspace/>
+			-<vspace/>
+			add: olcSuffix<vspace/>
+			olcSuffix: {0}ou=Dis,o=example.com<vspace/>
+			olcSuffix: {0}ou=Dat,o=example,com<vspace/>
+			-<vspace/>
+			The result would be:<vspace/>
+			olcSuffix: {0}ou=Dat,o=example,com<vspace/>
+			olcSuffix: {1}ou=Dis,o=example.com<vspace/>
+			olcSuffix: {2}o=example.org<vspace/>
+			olcSuffix: {3}o=The Example Company<vspace/>
+			olcSuffix: {4}o=example,c=us</t>
+			</list>
+
+			</t>
+			<t>Note that matching against an ordering-prefix can also
+			be done in Compare operations and Search filters. E.g., 
+			the filter "(olcSuffix={4})" would match all entries with
+			at least 5 olcSuffix values.</t>
+			</section>
+			<section title="Ordered Siblings">
+			<t>The rules for Ordered Siblings are basically the same
+as for Ordered Values, except instead of working primarily with the Modify
+request, the operations of interest here are Add, Delete, and ModRDN.</t>
+			<t>Given these entries:</t>
+			<t>dn: olcDatabase={0}config,cn=config<vspace/>
+			olcDatabase: {0}config<vspace/>
+			objectClass: olcDatabaseConfig<vspace/>
+			olcSuffix: {0}cn=config</t>
+
+			<t>dn: olcDatabase={1}bdb,cn=config<vspace/>
+			olcDatabase: {1}bdb<vspace/>
+			objectClass: olcDatabaseConfig<vspace/>
+			olcSuffix: {0}dc=example,dc=com</t>
+
+			<t>We can perform these operations:
+			<list style="numbers">
+			<t>Add a new entry with no ordering-prefix:<vspace/>
+			dn: olcDatabase=hdb,cn=config<vspace/>
+			changetype: add<vspace/>
+			olcDatabase: hdb<vspace/>
+			objectClass: olcDatabaseConfig<vspace/>
+			olcSuffix: {0}dc=example,dc=org<vspace/>
+			The resulting entry will be:<vspace/>
+			dn: olcDatabase={2}hdb,cn=config<vspace/>
+			olcDatabase: {2}hdb<vspace/>
+			objectClass: olcDatabaseConfig<vspace/>
+			olcSuffix: {0}dc=example,dc=org</t>
+
+			<t>Continuing on with these three entries, we can add another
+			entry with a specific ordering-prefix:<vspace/>
+			dn: olcDatabase={1}ldif,cn=config<vspace/>
+			changetype: add<vspace/>
+			olcDatabase: {1}ldif<vspace/>
+			objectClass: olcDatabaseConfig<vspace/>
+			olcSuffix: {0}o=example.com<vspace/>
+			<vspace/>This would give us four entries, whose DNs are:
+			<list style="empty">
+			<t>dn: olcDatabase={0}config,cn=config</t>
+			<t>dn: olcDatabase={1}ldif,cn=config</t>
+			<t>dn: olcDatabase={2}bdb,cn=config</t>
+			<t>dn: olcDatabase={3}hdb,cn=config</t>
+			</list>
+			</t>
+
+			<t>Issuing a ModRDN request will cause multiple entries to
+			be renamed:<vspace/>
+			dn: olcDatabase={1}ldif,cn=config<vspace/>
+			changetype: modrdn<vspace/>
+			newrdn: olcDatabase={99}ldif<vspace/>
+			deleteoldrdn: 1<vspace/>
+			<vspace/>The resulting entries would be named:
+			<list style="empty">
+			<t>dn: olcDatabase={0}config,cn=config</t>
+			<t>dn: olcDatabase={1}bdb,cn=config</t>
+			<t>dn: olcDatabase={2}hdb,cn=config</t>
+			<t>dn: olcDatabase={3}ldif,cn=config</t>
+			</list>
+			</t>
+
+			<t>As may be expected, a Delete request will also rename the
+			remaining entries:<vspace/>
+			dn: olcDatabase={1}bdb,cn=config<vspace/>
+			changetype: delete<vspace/>
+			<vspace/>The remaining entries would be named:
+			<list style="empty">
+			<t>dn: olcDatabase={0}config,cn=config</t>
+			<t>dn: olcDatabase={1}hdb,cn=config</t>
+			<t>dn: olcDatabase={2}ldif,cn=config</t>
+			</list>
+			</t>
+			</list>
+			</t>
+			</section>
+
+		</section>
+		<section title="Security Considerations">
+		<t>General LDAP security considerations <xref target="RFC3377"/>
+		apply.</t>
+		</section>
+	</middle>
+
+	<back>
+		<references title="Normative References">
+			&rfc2119;
+			&rfc2252;
+			&rfc3377;
+			&rfc3383;
+			<reference anchor="X680">
+				<front>
+					<title>Abstract Syntax Notation One (ASN.1): Specification of basic notation</title>
+					<author>
+						<organization>International Telecommunications Union</organization>
+					</author>
+					<date month="July" year="2002"/>
+				</front>
+				<seriesInfo name="ITU-T" value="Recommendation X.680"/>
+			</reference>
+		</references>
+
+		<section title="IANA Considerations">
+			<t>In accordance with <xref target="RFC3383"/> (what needs to be done here?) . We probably need an OID for advertising in supportedFeatures.
+			</t>
+
+		</section>
+	</back>
+</rfc>