From: Quanah Gibson-Mount Date: Wed, 2 Nov 2011 23:47:28 +0000 (-0700) Subject: Delete non-release file X-Git-Tag: OPENLDAP_REL_ENG_2_4_27~225 X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=ba4a6cf34c8b926c575774befd2ef093ed91084a;p=openldap Delete non-release file --- diff --git a/doc/drafts/draft-chu-ldap-xordered-xx.xml b/doc/drafts/draft-chu-ldap-xordered-xx.xml deleted file mode 100644 index 821f2d07bf..0000000000 --- a/doc/drafts/draft-chu-ldap-xordered-xx.xml +++ /dev/null @@ -1,390 +0,0 @@ - - - - - - - - - - - -]> - - - - - - - - - - - Ordered Entries and Values in LDAP - - Symas Corp. -
- - 18740 Oxnard Street, Suite 313A - Tarzana - California - 91356 - USA - - +1 818 757-7087 - hyc@symas.com -
- - - - 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. - - - - - -
- 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. -
- -
- Imperative keywords defined in are used -in this document, and carry the meanings described there. -
- -
-
- 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. - -
-
- 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 . - - d = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" - numericstring = 1*d - ordering-prefix = "{" numericstring "}" - value = <any sequence of octets> - 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. -
-
- 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 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. -
-
-
-
- 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 ) ) -
-
- 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: - - - 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 - - Starting from the original entry, we could issue this change - instead: - 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 - - 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 - - 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 - - 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 - - Modifying multiple values in one operation: - add: olcSuffix - olcSuffix: {0}ou=Dis,o=example.com - 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 - - 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. -
-
- 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 - - dn: olcDatabase={1}bdb,cn=config - olcDatabase: {1}bdb - objectClass: olcDatabaseConfig - olcSuffix: {0}dc=example,dc=com - - We can perform these operations: - - 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 - - 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 - - - - 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 - dn: olcDatabase={2}hdb,cn=config - dn: olcDatabase={3}ldif,cn=config - - - - 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 - - - - -
- -
-
- General LDAP security considerations - apply. -
- - - - - &rfc2119; - &rfc2252; - &rfc3377; - &rfc3383; - - - Abstract Syntax Notation One (ASN.1): Specification of basic notation - - International Telecommunications Union - - - - - - - -
- In accordance with (what needs to be done here?) . We probably need an OID for advertising in supportedFeatures. - - -
- -