From: Kurt Zeilenga Date: Thu, 27 Dec 2001 01:00:24 +0000 (+0000) Subject: Zap some old I-Ds which are not terrible relevant anymore. X-Git-Tag: LDBM_PRE_GIANT_RWLOCK~465 X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=9465ef0616054c20862baa659d0426ba09798945;p=openldap Zap some old I-Ds which are not terrible relevant anymore. Note that old I-Ds can always be found on www.watersprings.com --- diff --git a/doc/drafts/draft-good-ldap-changelog-xx.txt b/doc/drafts/draft-good-ldap-changelog-xx.txt deleted file mode 100644 index 975e063b25..0000000000 --- a/doc/drafts/draft-good-ldap-changelog-xx.txt +++ /dev/null @@ -1,450 +0,0 @@ - -Change Record Object Class Definition Gordon Good -INTERNET-DRAFT Netscape Communications - 10 March 2000 - - Definition of an Object Class to Hold LDAP Change Records - Filename: draft-good-ldap-changelog-01.txt - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - 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 expires September 10, 2000. - - - -Abstract - - In order to support more flexible replication methods, it is - desirable to specify some manner in which an LDAP client may retrieve - a set of changes which have been applied to an LDAP server's - database. The client, which may be another LDAP server, may then - choose to update its own replicated copy of the data. This document - specifies an object class which may be used to represent changes - applied to an LDAP server. It also specifies a method for - discovering the location of the container object which holds these - change records, so that clients and servers have a common rendezvous - point for this information. - - - -Background and Intended Usage - - This document describes an objectclass which can be used to represent - changes which have been applied to a directory server. It also - suggests a common location for a container which holds these objects. - - - -Good March 9, 2000 [Page 1] - -INTERNET-DRAFT Change Record Object Class 11 March 1998 - - - A client may update its local copy of directory information by - reading the entries within this container, and applying the changes - to its local database. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are - to be interpreted as described in RFC 2119 [3]. - -New Attribute Types Used in the changeLogEntry Object Class - - ( 2.16.840.1.113730.3.1.5 - NAME 'changeNumber' - DESC 'a number which uniquely identifies a change made to a - directory entry' - SYNTAX 'INTEGER' - EQUALITY 'integerMatch' - ORDERING 'integerOrderingMatch' ) - - ( 2.16.840.1.113730.3.1.6 - NAME 'targetDN' - DESC 'the DN of the entry which was modified' - EQUALITY distinguishedNameMatch - SYNTAX 'DN' ) - - ( 2.16.840.1.113730.3.1.7 - NAME 'changeType' - DESC 'the type of change made to an entry' - EQUALITY caseIgnoreMatch - SYNTAX 'DirectoryString' ) - - ( 2.16.840.1.113730.3.1.8 - NAME 'changes' - DESC 'a set of changes to apply to an entry' - SYNTAX 'OctetString' ) - - ( 2.16.840.1.113730.3.1.9 - NAME 'newRDN' - DESC 'the new RDN of an entry which is the target of a - modrdn operation' - EQUALITY distinguishedNameMatch - SYNTAX 'DN' ) - - ( 2.16.840.1.113730.3.1.10 - NAME 'deleteOldRDN' - DESC 'a flag which indicates if the old RDN should be retained - as an attribute of the entry' - EQUALITY booleanMatch - SYNTAX 'BOOLEAN' ) - - - -Good March 9, 2000 [Page 2] - -INTERNET-DRAFT Change Record Object Class 11 March 1998 - - - ( 2.16.840.1.113730.3.1.11 - NAME 'newSuperior' - DESC 'the new parent of an entry which is the target of a - moddn operation' - EQUALITY distinguishedNameMatch - SYNTAX 'DN' ) - - -Schema Definition of the changeLogEntry Object Class - - ( 2.16.840.1.113730.3.2.1 - NAME 'changeLogEntry' - SUP top - STRUCTURAL - MUST ( - changeNumber $ targetDN $ changeType - ) - MAY ( - changes $ newRDN $ deleteOldRDN $ newSuperior - ) - ) - - - -Discussion of changeLogEntry Attributes: - - changeNumber: the change number, as assigned by the supplier. This - integer MUST strictly increase as new entries are added, and must - always be unique within a given server. Syntax: INTEGER - - targetdn: the distinguished name of the entry which was added, - modified or deleted. In the case of a modrdn operation, the targetdn - gives the DN of the entry before it was modified. Syntax: DN - - changeType: the type of change. One of: "add", "delete", "modify", - "modrdn". Later RFCs may define additional values for changeType. - Syntax: DirectoryString - - changes: the changes which were made to the directory server. These - changes are in LDIF format, which is described in [1]. - Syntax: OctetString - - newRDN: the new RDN (Relative Distinguished Name) of the entry, if the - changeType is "modrdn". If the changeType attribute does not have the - value "modrdn", then there should be no values contained in the newRDN - attribute. - Syntax: DN - - - - -Good March 9, 2000 [Page 3] - -INTERNET-DRAFT Change Record Object Class 11 March 1998 - - - deleteOldRDN: a flag which tells whether the old RDN of the entry - should be retained as a distinguished attribute of the entry, or - should be deleted. A value of "FALSE" indicates that the RDN should be - retained as a distinguished attribute, and a value of "TRUE" indicates - that it should not be retained as a distinguished attribute of the - entry. If any value other than "TRUE" or "FALSE" is contained in the - deleteOldRDN attribute, or if the deleteOldRDN contains multiple - values, the RDN should be retained as a distinguished attribute (that - is, "FALSE" is the default if no values are present, or if illegal - values are present). - Syntax: BOOLEAN - - newSuperior: if present, gives the name of the entry which - becomes the immediate superior of the existing entry. This optional - attribute reflects LDAPv3 functionality, and MUST NOT be generated - by LDAPv2 servers [2]. - Syntax: DN - - - -Discussion of the changeLogEntry object class - - The changeLogEntry object class is used to represent changes made to a - directory server. The set of changes made to a directory server, then, - is given by the ordered set of all entries within the changelog - container, ordered by changeNumber. - - A client may synchronize its local copy of a remote directory server's - contents by searching the remote server's changelog container for any - entries where the changenumber is greater than or equal to the last - change previously retrieved from that server. If the entry with the - changenumber matching the last change retrieved is not returned in the - search results, then the server's changelog has been trimmed. The - client must then fall back to reading the entire directory to bring its - copy in sync with the server's. - - Assuming that the client has successfully retrieved one or more changelog - entries from the server, it can then use the information contained in each - entry to update the corresponding entry (named by the targetDN attribute) - in its local copy of the database. - - Note that, due to access control restrictions, the client is not guaranteed - read access to the "changes" attribute. If the client discovers that the - "changes" attribute has no values, then it must read the entry given by - the targetDN attribute, possibly only retrieving attributes it deems - "interesting". However, in the case of delete and modrdn operations, there - is never a "changes" attribute, so it is never necessary to read the target - entry in these cases. - - - -Good March 9, 2000 [Page 4] - -INTERNET-DRAFT Change Record Object Class 11 March 1998 - - -Examples of the changeLogEntry object class - - In each example below, the "changes" attribute is shown in plain text, - with embedded newlines. This is done for clarity. It is intended that - newlines be stored in the entry literally, not encoded in any way. - If a "changes" attribute value is stored in an LDIF file, it must - base-64 encoded. - - Example 1: A changeLogEntry representing the addition of a - new entry to the directory - - dn: changenumber=1923, cn=changelog - changenumber: 1923 - targetdn: cn=Barbara Jensen, ou=Accounting, o=Ace Industry, c=US - changetype: add - changes: cn: Barbara Jensen\ncn: Babs Jensen\nsn: Jensen\n - givenname: Barbara\ntelephonenumber: +1 212 555-1212\nmail: babs@ace.com\n - objectclass: top\nobjectclass: person\nobjectclass: organizationalPerson\n - objectclass: inetOrgPerson - - Example 2: A changeLogEntry representing the deletion of an entry - from the directory - - dn: changenumber=2933, cn=changelog - changenumber: 2933 - targetdn: cn=Gern Jensen, ou=Product Testing, o=Ace Industry, c=US - changetype: delete - - Example 3: A changeLogEntry representing the modification of an entry - in the directory - - dn: changenumber=5883, cn=changelog - changenumber: 5883 - targetdn: cn=Bjorn Jensen, ou=Product Development, o=Ace Industry, c=US - changetype: modify - changes: delete: telephonenumber\ntelephonenumber: 1212\n-\n - add: telephonenumber\ntelephonenumber: +1 212 555 1212\n- - - Example 4: A changeLogEntry representing a modrdn operation performed - on an entry in the directory - - dn: changenumber=10042, cn=changelog - changenumber: 10042 - targetdn: cn=Bjorn Jensen, ou=Product Development, o=Ace Industry, c=US - changetype: modrdn - newrdn: cn=Bjorn J Jensen - deleteoldrdn: FALSE - - - - -Good March 9, 2000 [Page 5] - -INTERNET-DRAFT Change Record Object Class 11 March 1998 - - -Location of the container containing changeLogEntry objects - - For LDAPv3 servers, the location of the container which holds - changeLogEntry objects is obtained by reading the "changeLog" attribute - of a server's root DSE. For example, if the container's root is - "cn=changelog", then the root DSE must have an attribute named - "changeLog" with the value "cn=changelog". - - The "changelog" attribute is defined as follows: - - ( 2.16.840.1.113730.3.1.35 - NAME 'changelog' - DESC 'the distinguished name of the entry which contains - the set of entries comprising this server's changelog' - EQUALITY distinguishedNameMatch - SYNTAX 'DN' - ) - - For LDAPv2 servers, the name of the changelog container must be - "cn=changelog". - -Interoperability between LDAPv2 and LDAPv3 implementations - - Implementors are discouraged from developing implementations in which - an LDAPv2 server is synchronized from an LDAPv3 server using the - changelog method described in this document. Problems can arise when an - LDAPv2 server reads a "moddn" changelog entry which gives a new - superior. Since LDAPv2 does not support such an operation, there is not - way for the v2 server to perform the moddn operation atomically. It - could, of course, delete all the entries under the old superior and add - them under the new superior entry, but such an operation would either - not be atomic, or require extensive server-side support on the LDAPv2 - server to make the operation appear as if it were atomic. - - It is recommended that servers which only implement LDAPv2 should - refuse to synchronize from LDAPv3 servers. Before beginning - synchronization, the LDAPv2 server should attempt to read the root DSE - of the supplier server. If the root DSE is present, and the - supportedldapversion attribute contained in the root DSE contains the - value "3", then the LDAPv2 server should immediately disconnect and - proceed no further with synchronization. - -Security Considerations - - Servers implementing this scheme MUST NOT allow the "changes" - attribute to be generally readable. The "changes" attribute contains - all modifications made to an entry, and some changes may contain - sensitive data, e.g. passwords. - - - -Good March 9, 2000 [Page 6] - -INTERNET-DRAFT Change Record Object Class 11 March 1998 - - - If a server does allow read access on the "changes: attribute to a - particular bound DN, then that DN should be trusted. For example, two - cooperating servers may exchange the password for some DN which is - granted read access to the "changes" attribute of the changeLog. This - would allow one server to retrieve changes and apply them directly to - its database. - - In situations where the "changes" attribute is not readable by a client, - that client may still use the entries in the changeLog to construct a - list of entry DNs which are known to have changed since the last time - the client synchronized. The client may then read each of those entries, - subject to whatever access control is in effect on the server, - and update its local copy of each entry. - - Servers implementing this scheme should disallow write access to the - changelog container object and all entries contained within. - - - -Acknowledgements - - This material is based in part upon work supported by the National - Science Foundation under Grant No. NCR-9416667. - - - -References - - [1] Good, G., "The LDAP Data Interchange Format", INTERNET-DRAFT - draft-good-ldap-ldif-06.txt, Netscape Communications Corp., March 2000 - - - [2] Wahl, M., Howes, T., Kille, S., "Lightweight Directory Access - Protocol (v3)", RFC 2251 Critical Angle, Inc., Netscape Communications Corp., - ISODE Consortium, July, 1997, - - - [3] S. Bradner, "Key Words for use in RFCs to Indicate Requirement - Levels", Harvard University, RFC 2119, March 1997, - - - -Author's Address - - Gordon Good - Netscape Communications Corp. - 501 E. Middlefield Rd. - Mailstop MV068 - - - -Good March 9, 2000 [Page 7] - -INTERNET-DRAFT Change Record Object Class 11 March 1998 - - - Mountain View, CA 94043, USA - Phone: +1 650 937-3825 - EMail: ggood@netscape.com - - This Internet Draft expires September 10, 2000 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Good March 9, 2000 [Page 8] - diff --git a/doc/drafts/draft-ietf-asid-ldapv3-attributes-03.txt b/doc/drafts/draft-ietf-asid-ldapv3-attributes-03.txt deleted file mode 100644 index d622f7e563..0000000000 --- a/doc/drafts/draft-ietf-asid-ldapv3-attributes-03.txt +++ /dev/null @@ -1,2261 +0,0 @@ - -Network Working Group M. Wahl -INTERNET-DRAFT Critical Angle Inc. -Obsoletes: RFC 1778 A. Coulbeck - ISODE Consortium - T. Howes - Netscape Communications Corp. - S. Kille - ISODE Consortium -Intended Category: Standards Track October 22, 1996 - - - Lightweight Directory Access Protocol: - Standard and Pilot Attribute Definitions - - -1. Status of this Memo - - This document is an Internet-Draft. 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." - - To learn the current status of any Internet-Draft, please check the - "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow - Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), - ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). - -2. Abstract - - The Lightweight Directory Access Protocol (LDAP) [1] requires that the - contents of AttributeValue fields in protocol elements be octet - strings. This document defines the requirements that must be - satisfied by encoding rules used to render directory attribute - syntaxes into a form suitable for use in the LDAP, then goes on to - define the encoding rules for the standard set of attribute syntaxes - of [2],[3] and [4]. It also identifies all the attribute types, object - classes and matching rules for LDAP version 3. - -3. Overview - - Section 4 states the general requirements and notations for attribute - types, object classes, syntax and matching rule definitions. - - The core definitions are given in section 5, those which are based on - X.500(1993) in section 6, and other optional definitions in section 7. - - - - - -Wahl, Coulbeck, Howes & Kille [Page 1] - -INTERNET-DRAFT LDAP Standard and Pilot Attributes October 1996 - -4. General Issues - -4.1. Attribute Types - - The attribute types are described by sample values for the subschema - "attributeTypes" attribute, which is written in the - AttributeTypeDescription syntax. While lines have been folded for - readability, the values transferred in protocol would not contain - newlines. - - The AttributeTypeDescription is encoded according to the following BNF, - and the productions for , and - are given in sections 4.2.1. - - ::= "(" - -- AttributeType identifier - [ "NAME" ] -- name used in AttributeType - [ "DESC" ] - [ "OBSOLETE" ] - [ "SUP" ] -- derived from this other AttributeType - [ "EQUALITY" ] -- Matching Rule name - [ "ORDERING" ] -- Matching Rule name - [ "SUBSTR" ] -- Matching Rule name - [ "SYNTAX" ] -- see section 4.2 - [ "SINGLE-VALUE" ] -- default multi-valued - [ "COLLECTIVE" ] -- default not collective - [ "NO-USER-MODIFICATION" ] -- default user modifiable - [ "USAGE" ] -- default user applications - ")" - - ::= - "userApplications" - | "directoryOperation" - | "distributedOperation" -- DSA-shared - | "dSAOperation" -- DSA-specific, value depends on server - - Servers are not required to provide the same or any text - in the description part of the subschema values they maintain. - - Servers must implement all the attribute types in section 5.1, and - may also implement the types listed in sections 6.1 and 7.1. Servers must - be able to perform equality matching of values, but need not perform - any additional validity checks on attribute values. - - Servers may recognize additional names and attributes not listed in this - document. Later documents may define additional types. - - Servers may implement additional attribute types not listed in this - document, and if they do so, must publish the definitions of the types - in the attributeTypes attribute of their subschema subentries. - - AttributeDescriptions may be used as the value in a NAME part of an - AttributeTypeDescription. Note that these are case insensitive. - -Wahl, Coulbeck, Howes & Kille [Page 2] - -INTERNET-DRAFT LDAP Standard and Pilot Attributes October 1996 - -4.2. Syntaxes - - This section defines general requirements for LDAP attribute value - syntax encodings. All documents defining attribute syntax encodings for - use with LDAP are expected to conform to these requirements. - - The encoding rules defined for a given attribute syntax must produce - octet strings. To the greatest extent possible, encoded octet - strings should be usable in their native encoded form for display - purposes. In particular, encoding rules for attribute syntaxes - defining non-binary values should produce strings that can be - displayed with little or no translation by clients implementing - LDAP. There are a few cases (e.g. Audio) however, when it is not sensible - to produce a printable representation, and clients must not assume that - an unrecognized syntax is a string representation. - -4.2.1. Common Encoding Aspects - - In these encodings where an arbitrary string is used as part of a larger - production (other than a Distinguished Name), a backslash quoting mechanism - is used to encode the following separator symbol character (such as ''', - '$' or '#') if it should occur in that string. The backslash is followed - by a pair of hexadecimal digits representing the next character. A - backslash itself in the string which forms part of a larger syntax is - always transmitted as '\5C' or '\5c'. - - For the purposes of defining the encoding rules for attribute syntaxes, - the following auxiliary BNF definitions will be used: - - ::= 'a' | 'b' | 'c' | 'd' | 'e' | 'f' | 'g' | 'h' | 'i' | - 'j' | 'k' | 'l' | 'm' | 'n' | 'o' | 'p' | 'q' | 'r' | - 's' | 't' | 'u' | 'v' | 'w' | 'x' | 'y' | 'z' | 'A' | - 'B' | 'C' | 'D' | 'E' | 'F' | 'G' | 'H' | 'I' | 'J' | - 'K' | 'L' | 'M' | 'N' | 'O' | 'P' | 'Q' | 'R' | 'S' | - 'T' | 'U' | 'V' | 'W' | 'X' | 'Y' | 'Z' - - ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' - - ::= | 'a' | 'b' | 'c' | 'd' | 'e' | 'f' | - 'A' | 'B' | 'C' | 'D' | 'E' | 'F' - - ::= | | '-' - -

::= | | ''' | '(' | ')' | '+' | ',' | '-' | '.' | - '/' | ':' | '?' | ' ' - - ::= | - - ::= | - - ::= | - - ::= | - -Wahl, Coulbeck, Howes & Kille [Page 3] - -INTERNET-DRAFT LDAP Standard and Pilot Attributes October 1996 - - ::=

|

- - ::= ' ' | ' ' - - ::= | empty - - ::= any sequence of octets formed from the UTF-8 [11] - transformation of a character from ISO 10646 [12] - - ::= | - - ::= | '(' ')' - - ::= | "" - - ::= ''' ''' - - ::= | '(' ')' - - ::= '$' | - - -- is defined in 5.2.1.15 - -4.2.2 Binary Transfer of Values - - This encoding format is used if the binary encoding is requested by the - client for an attribute, or if the attribute syntax name is 'Binary'. The - value, an instance of the ASN.1 AttributeValue type, is BER-encoded, - subject to the restrictions of section 5.1 of [1], and this sequence of - octets is used as the value. - - All servers must implement this form for both generating Search responses - and parsing Add, Compare and Modify requests. Clients must be prepared - receiving values in binary (e.g. userCertificate or audio), and must not - simply display binary or unrecognized values to users. - -4.2.3. Syntax Namees - - Names of syntaxes for use with LDAP are ASCII strings which either - begin with a letter and contain only letters or digits. The names are - case insensitive. Historically since syntaxes correspond to ASN.1 types, - they have been named starting with a capital letter. A suggested upper - bound on the number of characters in value with a DirectoryString or - IA5String syntax or the number of bytes in a value for all other syntaxes - may be indicated by appending this bound count inside of curly braces, e.g. - "DirectoryString{64}". Note that a single character of the DirectoryString - may be encoded in more than one byte since UTF-8 is a variable-length - encoding. - - Syntax names do not have global scope: two clients or servers may - know of different syntaxes with the same name. - - - -Wahl, Coulbeck, Howes & Kille [Page 4] - -INTERNET-DRAFT LDAP Standard and Pilot Attributes October 1996 - - The definition of additional arbitrary syntaxes is strongly depreciated - since it will hinder interoperability: today's client and server - implementations generally do not have the ability to dynamically recognize - new syntaxes. In most cases attributes will be defined with the - DirectoryString syntax. - - The following syntax names are used for attributes in this document. - Servers are only required to implement the syntaxes in section 5.2. - - AccessPoint ACIItem - AttributeTypeDescription Audio - Binary BitString - Certificate CertificateList - CertificatePair DataQualitySyntax - DeliveryMethod DirectoryString - DITContentRuleDescription DN - DSAQualitySyntax DSEType - EnhancedGuide FacsimileTelephoneNumber - Fax GeneralizedTime - Guide IA5String - INTEGER JPEG - MailPreference MasterAndShadowAccessPoints - MatchingRuleDescription MatchingRuleUseDescription - ModifyRight NameAndOptionalUID - NameFormDescription NumericString - ObjectClassDescription OID - OtherMailbox Password - PostalAddress PresentationAddress - PrintableString ProtocolInformation - SubtreeSpecification SupplierAndConsumers - SupplierInformation SupplierOrConsumer - TelephoneNumber TeletexTerminalIdentifier - TelexNumber UTCTime - -4.3. Object Classes - - These are described as sample values for the subschema "objectClasses" - attribute for a server which implements the LDAP schema. - While lines have been folded for readability, the values transferred in - protocol would not contain newlines. - - Object class descriptions are written according to the following BNF: - - ::= "(" - -- ObjectClass identifier - [ "NAME" ] - [ "DESC" ] - [ "OBSOLETE" ] - [ "SUP" ] -- Superior ObjectClasses - [ ( "ABSTRACT" | "STRUCTURAL" | "AUXILIARY" ) ] -- default structural - [ "MUST" ] -- AttributeTypes - [ "MAY" ] -- AttributeTypes - ")" - -Wahl, Coulbeck, Howes & Kille [Page 5] - -INTERNET-DRAFT LDAP Standard and Pilot Attributes October 1996 - - Servers must implement all the object classes in section 5.3: - account alias - applicationEntity applicationProcess - certificationAuthority country - dNSDomain dSA - device document - documentSeries domain - domainRelatedObject friendlyCountry - groupOfNames groupOfUniqueNames - locality newPilotPerson - organization organizationalPerson - organizationalRole organizationalUnit - person pilotDSA - pilotObject pilotOrganization - qualityLabelledData rFC822localPart - residentialPerson room - simpleSecurityObject strongAuthenticationUser - top - - and may also implement the object classes of 6.3 and 7.3. - - Servers may implement additional object classes not listed in this - document, and if they do so, must publish the definitions of the classes - in the objectClasses attribute of their subschema subentries. Later - documents may define additional object classes. - -4.4. Matching Rules - - Matching rules are used by servers to compare attribute values against - assertion values when performing Search and Compare operations. - - Most of the attributes given in this document will have an equality - matching rule defined. - - Matching rule descriptions are written according to the following BNF: - - ::= "(" - -- MatchingRule identifier - [ "NAME" ] - [ "DESC" ] - [ "OBSOLETE" ] - "SYNTAX" - ")" - - Servers must implement all the matching rules in section 5.4: - bitStringMatch caseExactIA5Match - caseIgnoreIA5Match caseIgnoreListMatch - caseIgnoreMatch distinguishedNameMatch - generalizedTimeMatch integerMatch - numericStringMatch objectIdentifierMatch - octetStringMatch telephoneNumberMatch - - and may also implement the matching rules of 6.4 and 7.4. - -Wahl, Coulbeck, Howes & Kille [Page 6] - -INTERNET-DRAFT LDAP Standard and Pilot Attributes October 1996 - - Servers may implement additional matching rules not listed in this - document, and if they do so, must publish the definitions of the - matching rules in the matchingRules attribute of their - subschema subentries. - -5. Mandatory Definitions - - Section 5 contains definitions which must be implemented by all servers. - - -5.1. Attribute Types - - Servers must recognize all the attributes of this section (5.1.1 - 5.1.5). - -5.1.1. Standard User Attributes - - The attributes listed in this section are those defined in X.520(1993), - likely to be present in user entries. Servers must recognize all the - attributes of this section. The semantics of attributes 2.5.4.0 through - 2.5.4.40 are summarized in RFC 1274. - - ( 2.5.4.0 NAME 'objectClass' EQUALITY objectIdentifierMatch SYNTAX 'OID' ) - - ( 2.5.4.1 NAME 'aliasedObjectName' EQUALITY distinguishedNameMatch - SYNTAX 'DN' SINGLE-VALUE ) - - ( 2.5.4.2 NAME 'knowledgeInformation' EQUALITY caseIgnoreMatch - SYNTAX 'DirectoryString{32768}' ) - - ( 2.5.4.3 NAME 'cn' SUP name ) - - ( 2.5.4.4 NAME 'sn' SUP name ) - - ( 2.5.4.5 NAME 'serialNumber' EQUALITY caseIgnoreMatch - SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 'PrintableString{64}' ) - - ( 2.5.4.6 NAME 'c' SUP name SINGLE-VALUE ) - - ( 2.5.4.7 NAME 'l' SUP name ) - - ( 2.5.4.8 NAME 'st' SUP name ) - - ( 2.5.4.9 NAME 'street' EQUALITY caseIgnoreMatch - SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 'DirectoryString{128}' ) - - ( 2.5.4.10 NAME 'o' SUP name ) - - ( 2.5.4.11 NAME 'ou' SUP name ) - - ( 2.5.4.12 NAME 'title' SUP name ) - - ( 2.5.4.13 NAME 'description' EQUALITY caseIgnoreMatch - SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 'DirectoryString{1024}' ) - -Wahl, Coulbeck, Howes & Kille [Page 7] - -INTERNET-DRAFT LDAP Standard and Pilot Attributes October 1996 - - ( 2.5.4.14 NAME 'searchGuide' SYNTAX 'Guide' ) - - ( 2.5.4.15 NAME 'businessCategory' EQUALITY caseIgnoreMatch - SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 'DirectoryString{128}' ) - - ( 2.5.4.16 NAME 'postalAddress' EQUALITY caseIgnoreListMatch - SUBSTRINGS caseIgnoreListSubstringsMatch SYNTAX 'PostalAddress' ) - - ( 2.5.4.17 NAME 'postalCode' EQUALITY caseIgnoreMatch - SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 'DirectoryString{40}' ) - - ( 2.5.4.18 NAME 'postOfficeBox' EQUALITY caseIgnoreMatch - SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 'DirectoryString{40}' ) - - ( 2.5.4.19 NAME 'physicalDeliveryOfficeName' EQUALITY caseIgnoreMatch - SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 'DirectoryString{128}' ) - - ( 2.5.4.20 NAME 'telephoneNumber' EQUALITY telephoneNumberMatch - SUBSTRINGS telephoneNumberSubstringsMatch SYNTAX 'TelephoneNumber{32}' ) - - ( 2.5.4.21 NAME 'telexNumber' SYNTAX 'TelexNumber' ) - - ( 2.5.4.22 NAME 'teletexTerminalIdentifier' - SYNTAX 'TeletexTerminalIdentifier' ) - - ( 2.5.4.23 NAME 'facsimileTelephoneNumber' - SYNTAX 'FacsimileTelephoneNumber' ) - - ( 2.5.4.24 NAME 'x121Address' EQUALITY numericStringMatch - SUBSTRINGS numericStringSubstringsMatch SYNTAX 'NumericString{15}' ) - - ( 2.5.4.25 NAME 'internationaliSDNNumber' EQUALITY numericStringMatch - SUBSTRINGS numericStringSubstringsMatch SYNTAX 'NumericString{16}' ) - - ( 2.5.4.26 NAME 'registeredAddress' SUP postalAddress - SYNTAX 'PostalAddress' ) - - ( 2.5.4.27 NAME 'destinationIndicator' EQUALITY caseIgnoreMatch - SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 'PrintableString{128}' ) - - ( 2.5.4.28 NAME 'preferredDeliveryMethod' SYNTAX 'DeliveryMethod' - SINGLE-VALUE ) - - ( 2.5.4.29 NAME 'presentationAddress' EQUALITY presentationAddressMatch - SYNTAX 'PresentationAddress' SINGLE-VALUE ) - - ( 2.5.4.30 NAME 'supportedApplicationContext' - EQUALITY objectIdentifierMatch SYNTAX 'OID' ) - - ( 2.5.4.31 NAME 'member' SUP distinguishedName ) - - ( 2.5.4.32 NAME 'owner' SUP distinguishedName ) - - -Wahl, Coulbeck, Howes & Kille [Page 8] - -INTERNET-DRAFT LDAP Standard and Pilot Attributes October 1996 - - ( 2.5.4.33 NAME 'roleOccupant' SUP distinguishedName ) - - ( 2.5.4.34 NAME 'seeAlso' SUP distinguishedName ) - - ( 2.5.4.35 NAME 'userPassword' EQUALITY octetStringMatch - SYNTAX 'Password{128}' ) - - ( 2.5.4.36 NAME 'userCertificate' SYNTAX 'Certificate' ) - - ( 2.5.4.37 NAME 'cACertificate' SYNTAX 'Certificate' ) - - ( 2.5.4.38 NAME 'authorityRevocationList' SYNTAX 'CertificateList' ) - - ( 2.5.4.39 NAME 'certificateRevocationList' SYNTAX 'CertificateList' ) - - ( 2.5.4.40 NAME 'crossCertificatePair' SYNTAX 'CertificatePair' ) - - ( 2.5.4.41 NAME 'name' - DESC 'The name attribute type is the attribute supertype from which - string attribute types typically used for naming may be formed.' - EQUALITY caseIgnoreMatch - SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 'DirectoryString{32768}' ) - - ( 2.5.4.42 NAME 'givenName' SUP name ) - - ( 2.5.4.43 NAME 'initials' - DESC 'The initials attribute type contains the initials of some or all - of an individuals names, but not the surname(s).' - SUP name ) - - ( 2.5.4.44 NAME 'generationQualifier' - DESC 'e.g. Jr or II.' - SUP name ) - - ( 2.5.4.45 NAME 'x500UniqueIdentifier' - DESC 'used to distinguish between objects when a distinguished name has - been reused.' - EQUALITY bitStringMatch SYNTAX 'BitString' ) - - ( 2.5.4.46 NAME 'dnQualifier' - DESC 'The dnQualifier attribute type specifies disambiguating - information to add to the relative distinguished name of an - entry. It is intended to be used for entries held in multiple - DSAs which would otherwise have the same name, and that its - value be the same in a given DSA for all entries to which this - information has been added.' - EQUALITY caseIgnoreMatch - ORDERING caseIgnoreOrderingMatch SUBSTRINGS caseIgnoreSubstringsMatch - SYNTAX 'PrintableString' ) - - ( 2.5.4.47 NAME 'enhancedSearchGuide' SYNTAX 'EnhancedGuide' ) - - - -Wahl, Coulbeck, Howes & Kille [Page 9] - -INTERNET-DRAFT LDAP Standard and Pilot Attributes October 1996 - - ( 2.5.4.48 NAME 'protocolInformation' EQUALITY protocolInformationMatch - SYNTAX 'ProtocolInformation' ) - - ( 2.5.4.49 NAME 'distinguishedName' - DESC 'This is not the name of the object itself, but a base type - from which attributes with DN syntax inherit.' - EQUALITY distinguishedNameMatch - SYNTAX 'DN' ) - - ( 2.5.4.50 NAME 'uniqueMember' EQUALITY uniqueMemberMatch - SYNTAX 'NameAndOptionalUID' ) - - ( 2.5.4.51 NAME 'houseIdentifier' EQUALITY caseIgnoreMatch - SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 'DirectoryString{32768}' ) - -5.1.2. Pilot User Attributes - - These attributes are defined in RFC 1274. Servers must recognize all the - attributes of this section. - - ( 0.9.2342.19200300.100.1.1 NAME 'uid' EQUALITY caseIgnoreMatch - SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 'DirectoryString{256}' ) - - ( 0.9.2342.19200300.100.1.2 NAME 'textEncodedORaddress' - EQUALITY caseIgnoreMatch SUBSTRINGS caseIgnoreSubstringsMatch - SYNTAX 'DirectoryString{256}' ) - - ( 0.9.2342.19200300.100.1.3 NAME 'mail' EQUALITY caseIgnoreIA5Match - SUBSTRINGS caseIgnoreIA5SubstringsMatch SYNTAX 'IA5String{256}' ) - - ( 0.9.2342.19200300.100.1.4 NAME 'info' EQUALITY caseIgnoreMatch - SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 'DirectoryString{2048}' ) - - ( 0.9.2342.19200300.100.1.5 NAME 'drink' EQUALITY caseIgnoreMatch - SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 'DirectoryString{256}' ) - - ( 0.9.2342.19200300.100.1.6 NAME 'roomNumber' EQUALITY caseIgnoreMatch - SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 'DirectoryString{256}' ) - - ( 0.9.2342.19200300.100.1.7 NAME 'photo' SYNTAX 'Fax{250000}' ) - - ( 0.9.2342.19200300.100.1.8 NAME 'userClass' EQUALITY caseIgnoreMatch - SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 'DirectoryString{256}' ) - - ( 0.9.2342.19200300.100.1.9 NAME 'host' EQUALITY caseIgnoreMatch - SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 'DirectoryString{256}' ) - - ( 0.9.2342.19200300.100.1.10 NAME 'manager' - EQUALITY distinguishedNameMatch SYNTAX 'DN' ) - - ( 0.9.2342.19200300.100.1.11 NAME 'documentIdentifier' - EQUALITY caseIgnoreMatch SUBSTRINGS caseIgnoreSubstringsMatch - SYNTAX 'DirectoryString{256}' ) - -Wahl, Coulbeck, Howes & Kille [Page 10] - -INTERNET-DRAFT LDAP Standard and Pilot Attributes October 1996 - - ( 0.9.2342.19200300.100.1.12 NAME 'documentTitle' EQUALITY caseIgnoreMatch - SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 'DirectoryString{256}' ) - - ( 0.9.2342.19200300.100.1.13 NAME 'documentVersion' - EQUALITY caseIgnoreMatch SUBSTRINGS caseIgnoreSubstringsMatch - SYNTAX 'DirectoryString{256}' ) - - ( 0.9.2342.19200300.100.1.14 NAME 'documentAuthor' - EQUALITY distinguishedNameMatch SYNTAX 'DN' ) - - ( 0.9.2342.19200300.100.1.15 NAME 'documentLocation' - EQUALITY caseIgnoreMatch SUBSTRINGS caseIgnoreSubstringsMatch - SYNTAX 'DirectoryString{256}' ) - - ( 0.9.2342.19200300.100.1.20 NAME 'homePhone' EQUALITY telephoneNumberMatch - SUBSTRINGS telephoneNumberSubstringsMatch SYNTAX 'TelephoneNumber{32}' ) - - ( 0.9.2342.19200300.100.1.21 NAME 'secretary' - EQUALITY distinguishedNameMatch SYNTAX 'DN' ) - - ( 0.9.2342.19200300.100.1.22 NAME 'otherMailbox' SYNTAX 'OtherMailbox' ) - - ( 0.9.2342.19200300.100.1.25 NAME 'dc' EQUALITY caseIgnoreIA5Match - SUBSTRINGS caseIgnoreIA5SubstringsMatch SYNTAX 'IA5String' ) - - ( 0.9.2342.19200300.100.1.26 NAME 'dNSRecord' - EQUALITY caseExactIA5Match SYNTAX 'IA5String' ) - - ( 0.9.2342.19200300.100.1.37 NAME 'associatedDomain' - EQUALITY caseIgnoreIA5Match SUBSTRINGS caseIgnoreIA5SubstringsMatch - SYNTAX 'IA5String' ) - - ( 0.9.2342.19200300.100.1.38 NAME 'associatedName' - EQUALITY distinguishedNameMatch SYNTAX 'DN' ) - - ( 0.9.2342.19200300.100.1.39 NAME 'homePostalAddress' - EQUALITY caseIgnoreListMatch - SUBSTRINGS caseIgnoreListSubstringsMatch SYNTAX 'PostalAddress' ) - - ( 0.9.2342.19200300.100.1.40 NAME 'personalTitle' - EQUALITY caseIgnoreMatch SUBSTRINGS caseIgnoreSubstringsMatch - SYNTAX 'DirectoryString' ) - - ( 0.9.2342.19200300.100.1.41 NAME 'mobile' EQUALITY telephoneNumberMatch - SUBSTRINGS telephoneNumberSubstringsMatch SYNTAX 'TelephoneNumber{32}' ) - - ( 0.9.2342.19200300.100.1.42 NAME 'pager' EQUALITY telephoneNumberMatch - SUBSTRINGS telephoneNumberSubstringsMatch SYNTAX 'TelephoneNumber{32}' ) - - ( 0.9.2342.19200300.100.1.43 NAME 'co' EQUALITY caseIgnoreMatch - SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 'DirectoryString' ) - - - -Wahl, Coulbeck, Howes & Kille [Page 11] - -INTERNET-DRAFT LDAP Standard and Pilot Attributes October 1996 - - ( 0.9.2342.19200300.100.1.44 NAME 'uniqueIdentifier' - EQUALITY caseIgnoreMatch SUBSTRINGS caseIgnoreSubstringsMatch - SYNTAX 'DirectoryString' ) - - ( 0.9.2342.19200300.100.1.45 NAME 'organizationalStatus' - EQUALITY caseIgnoreMatch SUBSTRINGS caseIgnoreSubstringsMatch - SYNTAX 'DirectoryString{256}' ) - - ( 0.9.2342.19200300.100.1.46 NAME 'janetMailbox' - EQUALITY caseIgnoreIA5Match SUBSTRINGS caseIgnoreIA5SubstringsMatch - SYNTAX 'IA5String{256}' ) - - ( 0.9.2342.19200300.100.1.47 NAME 'mailPreferenceOption' - SYNTAX 'INTEGER' SINGLE-VALUE } - - ( 0.9.2342.19200300.100.1.48 NAME 'buildingName' - EQUALITY caseIgnoreMatch SUBSTRINGS caseIgnoreSubstringsMatch - SYNTAX 'DirectoryString{256}' ) - - ( 0.9.2342.19200300.100.1.49 NAME 'dSAQuality' - SYNTAX 'DSAQualitySyntax' SINGLE-VALUE ) - - ( 0.9.2342.19200300.100.1.50 NAME 'singleLevelQuality' - SYNTAX 'DataQualitySyntax' SINGLE-VALUE ) - - ( 0.9.2342.19200300.100.1.51 NAME 'subtreeMinimumQuality' - SYNTAX 'DataQualitySyntax' SINGLE-VALUE ) - - ( 0.9.2342.19200300.100.1.52 NAME 'subtreeMaximumQuality' - SYNTAX 'DataQualitySyntax' SINGLE-VALUE ) - - ( 0.9.2342.19200300.100.1.53 NAME 'personalSignature' - SYNTAX 'Fax{50000}' ) - - ( 0.9.2342.19200300.100.1.54 NAME 'dITRedirect' - EQUALITY distinguishedNameMatch SYNTAX 'DN' ) - - ( 0.9.2342.19200300.100.1.55 NAME 'audio' SYNTAX 'Audio{250000}' ) - - ( 0.9.2342.19200300.100.1.56 NAME 'documentPublisher' - EQUALITY caseIgnoreMatch SUBSTRINGS caseIgnoreSubstringsMatch - SYNTAX 'DirectoryString' ) - - ( 0.9.2342.19200300.100.1.60 NAME 'jpegPhoto' SYNTAX 'JPEG' ) - - - - - - - - - - -Wahl, Coulbeck, Howes & Kille [Page 12] - -INTERNET-DRAFT LDAP Standard and Pilot Attributes October 1996 - -5.1.3. Standard Operational Attributes - - All servers must recognize the attribute types defined in this - section. - - ( 2.5.18.1 NAME 'createTimestamp' EQUALITY generalizedTimeMatch - ORDERING generalizedTimeOrderingMatch SYNTAX 'GeneralizedTime' - SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) - - ( 2.5.18.2 NAME 'modifyTimestamp' EQUALITY generalizedTimeMatch - ORDERING generalizedTimeOrderingMatch SYNTAX 'GeneralizedTime' - SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) - - ( 2.5.18.3 NAME 'creatorsName' EQUALITY distinguishedNameMatch SYNTAX 'DN' - SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) - - ( 2.5.18.4 NAME 'modifiersName' EQUALITY distinguishedNameMatch SYNTAX 'DN' - SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) - - ( 2.5.18.10 NAME 'subschemaSubentry' - DESC 'The value of this attribute is the name of a subschema subentry, - an entry in which the server makes available attributes specifying - the schema.' - EQUALITY distinguishedNameMatch SYNTAX 'DN' NO-USER-MODIFICATION - SINGLE-VALUE USAGE directoryOperation ) - - ( 2.5.21.5 NAME 'attributeTypes' - EQUALITY objectIdentifierFirstComponentMatch - SYNTAX 'AttributeTypeDescription' USAGE directoryOperation ) - - ( 2.5.21.6 NAME 'objectClasses' - EQUALITY objectIdentifierFirstComponentMatch - SYNTAX 'ObjectClassDescription' USAGE directoryOperation ) - -5.1.4. LDAP Operational Attributes - - All servers must recognize the attribute types defined in this section. - (Of course, it is not required that the server provide values for these - attributes, when the attribute corresponds to a feature which the server - does not implement.) - - ( 1.3.6.1.4.1.1466.101.120.1 NAME 'administratorsAddress' - DESC 'This attribute\27s values are string containing the addresses of - the LDAP server\27s human administrator. This information may - be of use when tracking down problems in an Internet distributed - directory. For simplicity the syntax of the values are limited to - being URLs of the mailto form with an RFC 822 address: - "mailto:user@domain". Future versions of this protocol may permit - other forms of addresses.' - SYNTAX 'IA5String' USAGE dSAOperation ) - - - - -Wahl, Coulbeck, Howes & Kille [Page 13] - -INTERNET-DRAFT LDAP Standard and Pilot Attributes October 1996 - - ( 1.3.6.1.4.1.1466.101.120.2 NAME 'currentTime' - DESC 'This attribute has a single value, a string containing a - GeneralizedTime character string. This attribute need only - be present if the server supports LDAP strong or protected - simple authentication. Otherwise if the server does not know - the current time, or does not choose to present it to clients, - this attribute need not be present. The client may wish to - use this value to detect whether a strong or protected bind - is failing because the client and server clocks are not - sufficiently synchronized. Clients must not use this time - field for setting their own system clock.' - SYNTAX 'GeneralizedTime' SINGLE-VALUE USAGE dSAOperation ) - - ( 1.3.6.1.4.1.1466.101.120.3 NAME 'serverName' - DESC 'This attribute\27s value is the server\27s Distinguished Name. - If the server does not have a Distinguished Name it will not - be able to accept X.509-style strong authentication, and this - attribute must be absent. However the presence of this - attribute does not guarantee that the server will be able to - perform strong authentication. If the server acts as a - gateway to more than one X.500 DSA capable of strong - authentication, there may be multiple values of this - attribute, one per DSA. (Note: this attribute is distinct - from myAccessPoint, for it is not required that a server - have a presentation address in order to perform strong - authentication.) (Note: it is likely that clients will - retrieve this attribute in binary.)' - SYNTAX 'DN' USAGE dSAOperation ) - - ( 1.3.6.1.4.1.1466.101.120.4 NAME 'certificationPath' - DESC 'This attribute contains a binary DER encoding of an - AF.CertificatePath data type, which is the certificate - path for a server. If the server does not have a certificate - path this attribute must be absent. (Note: this attribute - may only be retrieved in binary.)' - SYNTAX 'CertificatePath' USAGE dSAOperation ) - - ( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts' - DESC 'The values of this attribute correspond to naming contexts - which this server masters or shadows. If the server does - not master any information (e.g. it is an LDAP gateway to a - public X.500 directory) this attribute must be absent. If - the server believes it contains the entire directory, the - attribute must have a single value, and that value must - be the empty string (indicating the null DN of the root). - This attribute will allow clients to choose suitable base - objects for searching when it has contacted a server.' - SYNTAX 'DN' USAGE dSAOperation ) - - - - - - -Wahl, Coulbeck, Howes & Kille [Page 14] - -INTERNET-DRAFT LDAP Standard and Pilot Attributes October 1996 - - ( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer' - DESC 'The values of this attribute are URLs of other servers which - may be contacted when this server becomes unavailable. If - the server does not know of any other servers which could be - used this attribute must be absent. Clients may cache this - information in case their preferred LDAP server later becomes - unavailable.' - SYNTAX 'IA5String' USAGE dSAOperation ) - - ( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension' - DESC 'The values of this attribute are OBJECT IDENTIFIERs, - the names of supported extended operations - which the server supports. If the server does not support - any extensions this attribute must be absent.' - SYNTAX 'OID' USAGE dSAOperation ) - - ( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl' - DESC 'The values of this attribute are the names of supported session - controls which the server supports. If the server does not - support any controls this attribute must be absent.' - SYNTAX 'LDAPString' USAGE dSAOperation ) - - ( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms' - DESC 'The values of this attribute are the names of supported SASL - mechanisms which the server supports. If the server does not - support any mechanisms this attribute must be absent.' - SYNTAX 'LDAPString' USAGE dSAOperation ) - - ( 1.3.6.1.4.1.1466.101.120.8 NAME 'entryName' - SYNTAX 'DN' SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) - - ( 1.3.6.1.4.1.1466.101.120.9 NAME 'modifyRights' - SYNTAX 'ModifyRight' NO-USER-MODIFICATION USAGE dSAOperation ) - - ( 1.3.6.1.4.1.1466.101.120.10 NAME 'incompleteEntry' - SYNTAX 'BOOLEAN' NO-USER-MODIFICATION USAGE dSAOperation ) - - ( 1.3.6.1.4.1.1466.101.120.11 NAME 'fromEntry' - SYNTAX 'BOOLEAN' NO-USER-MODIFICATION USAGE dSAOperation ) - -5.1.5. LDAP User Attributes - - The following attributes may be of use in naming entries, or as - descriptive attributes in entries. - - ( 1.3.6.1.4.1.1466.101.121.1 NAME 'url' - DESC 'Uniform Resource Locator' - EQUALITY caseExactIA5Match SYNTAX 'IA5String' ) - - Note that the associatedDomain attribute may be used to hold a DNS name. - - - - -Wahl, Coulbeck, Howes & Kille [Page 15] - -INTERNET-DRAFT LDAP Standard and Pilot Attributes October 1996 - -5.2. Syntaxes - -5.2.1. Standard User Syntaxes - - Servers must recognize all the syntaxes described in this section. - -5.2.1.1. BitString - - The encoding of a value with BitString syntax is according to the - following BNF: - - ::= ''' ''B' - - ::= '0' | '1' | - empty - - -5.2.1.2. PrintableString - - The encoding of a value with PrintableString syntax is the string - value itself. PrintableString is limited to the characters in - production

of section 4.1. - -5.2.1.3. DirectoryString - - A string with DirectoryString syntax is encoded in the UTF-8 form of - ISO 10646 (a superset of Unicode). Servers and clients must be prepared to - receive arbitrary Unicode characters in values. - - For characters in the PrintableString form, the value is encoded as the - string value itself. - - If it is of the TeletexString form, then the characters are transliterated - to their equivalents in UniversalString, and encoded in UTF-8 [11]. - - If it is of the UniversalString or BMPString forms [12], UTF-8 is used to - encode them. - - Note: the form of DirectoryString is not indicated in protocol unless the - attribute value is carried in binary. Servers which convert to DAP must - choose an appropriate form. Servers must not reject values merely because - they contain legal Unicode characters outside of the range of printable - ASCII. - -5.2.1.4. Certificate - - Because of the changes from X.509(1988) and X.509(1993) and additional - changes to the ASN.1 definition to support certificate extensions, no - string representation is defined, and values with Certificate syntax - must only be transferred using the binary encoding, by requesting or - returning the attributes with descriptions "userCertificate;binary" or - "caCertificate;binary". The BNF notation in RFC 1778 for - "User Certificate" is not recommended to be used. - -Wahl, Coulbeck, Howes & Kille [Page 16] - -INTERNET-DRAFT LDAP Standard and Pilot Attributes October 1996 - -5.2.1.5. CertificateList - - Because of the incompatibility of the X.509(1988) and X.509(1993) - definitions of revocation lists, values with CertificateList syntax - must only be transferred using a binary encoding, by requesting or - returning the attributes with descriptions - "certificateRevocationList;binary" or "authorityRevocationList;binary". - The BNF notation in RFC 1778 for "Authority Revocation List" is not - recommended to be used. - -5.2.1.6. CertificatePair - - Because the Certificate is being carried in binary, values with - CertificatePair syntax must only be transferred using a binary encoding, - by requesting or returning the attribute description - "crossCertificatePair;binary". The BNF notation in RFC 1778 for - "Certificate Pair" is not recommended to be used. - -5.2.1.7. CountryString - - A value of CountryString syntax is encoded the same as a value of - DirectoryString syntax. Note that this syntax is limited to values of - exactly two printable string characters. - - ::=

- -5.2.1.8. DN - - Values with DN (Distinguished Name) syntax are encoded to have the - representation defined in [5]. Note that this representation is not - reversible to the original ASN.1 encoding as the CHOICE of any - DirectoryString element in an RDN is no longer known. - -5.2.1.9. DeliveryMethod - - Values with DeliveryMethod syntax are encoded according to the - following BNF: - - ::= | '$' - - ::= 'any' | 'mhs' | 'physical' | 'telex' | 'teletex' | - 'g3fax' | 'g4fax' | 'ia5' | 'videotex' | 'telephone' - -5.2.1.10. EnhancedGuide - - Values with the EnhancedGuide syntax are encoded according to the - following BNF: - - ::= '#' '#' - - ::= "baseobject" | "oneLevel" | "wholeSubtree" - - - -Wahl, Coulbeck, Howes & Kille [Page 17] - -INTERNET-DRAFT LDAP Standard and Pilot Attributes October 1996 - - The production is defined in the Guide syntax below. - This syntax has been added subsequent to RFC 1778. - -5.2.1.11. FacsimileTelephoneNumber - - Values with the FacsimileTelephoneNumber syntax are encoded according - to the following BNF: - - ::= [ '$' ] - - ::= | '$' - - ::= 'twoDimensional' | 'fineResolution' | 'unlimitedLength' | - 'b4Length' | 'a3Width' | 'b4Width' | 'uncompressed' - - In the above, the first is the actual fax number, - and the tokens represent fax parameters. - -5.2.1.12. Guide - - Values with the Guide syntax are encoded according to the following - BNF: - - ::= [ '#' ] - - ::= an encoded value with OID syntax - - ::= | | '!' - - ::= [ '(' ] '&' [ ')' ] | - [ '(' ] '|' [ ')' ] - - ::= [ '(' ] '$' [ ')' ] - - ::= "EQ" | "SUBSTR" | "GE" | "LE" | "APPROX" - -5.2.1.13. NameAndOptionalUID - - The encoding of a value with the NameAndOptionalUID syntax is according - to the following BNF: - - ::= - [ '#' ] - - Although the '#' character may occur in a string representation of a - distinguished name, no additional special quoting is done in the - distinguished name other than that of [5]. - - This syntax has been added subsequent to RFC 1778. - - - - - -Wahl, Coulbeck, Howes & Kille [Page 18] - -INTERNET-DRAFT LDAP Standard and Pilot Attributes October 1996 - -5.2.1.14. NumericString - - The encoding of a string with the NumericString syntax is the string - value itself. - -5.2.1.15. OID - - Values with OID (Object Identifier) syntax are encoded according to the - following BNF: - - ::= | - - ::= - - ::= | '.' - - In the above BNF, is the syntactic representation of an - object descriptor, which must consist of letters and digits, starting - with a letter. When encoding values with OID syntax, the first encoding - option must be used in preference to the second. That is, in encoding - object identifiers, object descriptors (where assigned and known by - the implementation) must be used in preference to numeric oids to - the greatest extent possible. All permitted object descriptors for use - in LDAP are given in this document. No other object descriptors may be - used. (Note that clients must expect that LDAPv2 implementations - will return object descriptors other than those listed.) - -5.2.1.16. Password - - Values with Password syntax are encoded as octet strings. - -5.2.1.17. PostalAddress - - Values with the PostalAddress syntax are encoded according to the - following BNF: - - ::= | '$' - - In the above, each component of a postal address value is - encoded as a value of type DirectoryString syntax. Backslashes and - dollar characters, if they occur in the component, are quoted as - described in section 4.2. - -5.2.1.18. PresentationAddress - - Values with the PresentationAddress syntax are encoded to have the - representation described in [6]. - -5.2.1.20. TelephoneNumber - - Values with the TelephoneNumber syntax are encoded as if they were - Printable String types. Telephone numbers are recommended in X.520 to - be in international form, e.g. "+1 512 305 0280". - -Wahl, Coulbeck, Howes & Kille [Page 19] - -INTERNET-DRAFT LDAP Standard and Pilot Attributes October 1996 - -5.2.1.21. TeletexTerminalIdentifier - - Values with the TeletexTerminalIdentifier syntax are encoded according - to the following BNF: - - ::= 0*('$' ) - - ::= - - ::= ':' - - ::= 'graphic' | 'control' | 'misc' | 'page' | 'private' - - ::= - - In the above, the first is the encoding of the - first portion of the teletex terminal identifier to be encoded, and - the subsequent 0 or more are subsequent portions - of the teletex terminal identifier. - -5.2.1.22. TelexNumber - - Values with the TelexNumber syntax are encoded according to the - following BNF: - - ::= '$' '$' - - ::= - - ::= - - ::= - - In the above, is the syntactic representation of the - number portion of the TELEX number being encoded, is the - TELEX country code, and is the answerback code of a - TELEX terminal. - -5.2.1.23. UTCTime - - Values with UTCTime syntax are encoded as if they were printable - strings with the strings containing a UTCTime value. This is historical; - new attribute definitions must use GeneralizedTime instead. - -5.2.1.24. Boolean - - Values with Boolean syntax are encoded according to the following - BNF: - - ::= "TRUE" | "FALSE" - - Boolean values have an encoding of "TRUE" if they are logically true, - and have an encoding of "FALSE" otherwise. - -Wahl, Coulbeck, Howes & Kille [Page 20] - -INTERNET-DRAFT LDAP Standard and Pilot Attributes October 1996 - -5.2.2. Pilot Syntaxes - - Servers must recognize all the syntaxes described in this section. - -5.2.2.1. Audio - - The encoding of a value with Audio syntax is the octets of the value - itself, an 8KHz uncompressed encoding compatible with the SunOS - 4.1.3 'play' utility. - -5.2.2.2. DSAQualitySyntax - - Values with this syntax are encoded according to the following BNF: - - ::= [ '#' ] - - ::= 'DEFUNCT' | 'EXPERIMENTAL' | 'BEST-EFFORT' | - 'PILOT-SERVICE' | 'FULL-SERVICE' - - ::= encoded as a PrintableString - -5.2.2.3. DataQualitySyntax - - Values with this syntax are encoded according to the following BNF: - - ::= '#' '#' - [ '#' ] - - ::= '+' - - ::= '$' - - ::= '+' - - ::= 'NONE' | 'SAMPLE' | 'SELECTED' | - 'SUBSTANTIAL' | 'FULL' - - ::= 'UNKNOWN' | 'EXTERNAL' | 'SYSTEM-MAINTAINED' | - 'USER-SUPPLIED' - -5.2.2.4. IA5String - - The encoding of a value with IA5String syntax is the string value - itself. - -5.2.2.5. JPEG - - Values with JPEG syntax are encoded as if they were octet strings - containing JPEG images in the JPEG File Interchange Format (JFIF), as - described in [8]. - - - - -Wahl, Coulbeck, Howes & Kille [Page 21] - -INTERNET-DRAFT LDAP Standard and Pilot Attributes October 1996 - -5.2.2.6. MailPreference - - Values with MailPreference syntax are encoded according to the - following BNF: - - ::= "NO-LISTS" | "ANY-LIST" | "PROFESSIONAL-LISTS" - -5.2.2.7. OtherMailbox - - Values of the OtherMailbox syntax are encoded according to the - following BNF: - - ::= '$' - - ::= an encoded Printable String - - ::= an encoded IA5 String - - In the above, represents the type of mail system in - which the mailbox resides, for example "MCIMail"; and is the - actual mailbox in the mail system defined by . - -5.2.2.8. Fax - - Values with Fax syntax are encoded as if they were octet strings - containing Group 3 Fax images as defined in [7]. - -5.2.3. Operational Syntaxes - - Servers must recognize all the syntaxes described in this section. - -5.2.3.1. AttributeTypeDescription - - Values with this syntax are encoded according to the BNF given at the - start of section 4.1. For example, - - ( 2.5.4.0 NAME 'objectClass' SYNTAX 'OID' ) - -5.2.3.2. GeneralizedTime - - Values of this syntax are encoded as printable strings, represented - as specified in X.208. Note that the time zone must be specified. - It is strongly recommended that Zulu time zone be used. For example, - - 199412161032Z - -5.2.3.3. INTEGER - - Values with INTEGER syntax are encoded as the decimal representation - of their values, with each decimal digit represented by the its - character equivalent. So the number 1321 is represented by the character - string "1321". - - -Wahl, Coulbeck, Howes & Kille [Page 22] - -INTERNET-DRAFT LDAP Standard and Pilot Attributes October 1996 - -5.2.3.4. ObjectClassDescription - - Values of this syntax are encoded according to the BNF in section 4.3. - -5.3. Object Classes - -5.3.1. Standard Classes - - Servers must recognize the object classes listed here as values of - the objectClass attribute. With the exception of groupOfUniqueNames, - they are described in RFC 1274. - - ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass ) - - ( 2.5.6.1 NAME 'alias' SUP top STRUCTURAL MUST aliasedObjectName ) - - ( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c - MAY ( searchGuide $ description ) ) - - ( 2.5.6.3 NAME 'locality' SUP top STRUCTURAL - MAY ( street $ seeAlso $ searchGuide $ st $ l $ description ) ) - - ( 2.5.6.4 NAME 'organization' SUP top STRUCTURAL MUST o - MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ - x121Address $ registeredAddress $ destinationIndicator $ - preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ - telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ - street $ postOfficeBox $ postalCode $ postalAddress $ - physicalDeliveryOfficeName $ st $ l $ description ) ) - - ( 2.5.6.5 NAME 'organizationalUnit' SUP top STRUCTURAL MUST ou - MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ - x121Address $ registeredAddress $ destinationIndicator $ - preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ - telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ - street $ postOfficeBox $ postalCode $ postalAddress $ - physicalDeliveryOfficeName $ st $ l $ description ) ) - - ( 2.5.6.6 NAME 'person' SUP top STRUCTURAL MUST ( sn $ cn ) - MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) ) - - ( 2.5.6.7 NAME 'organizationalPerson' SUP person STRUCTURAL - MAY ( title $ x121Address $ registeredAddress $ destinationIndicator $ - preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ - telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ - street $ postOfficeBox $ postalCode $ postalAddress $ - physicalDeliveryOfficeName $ ou $ st $ l ) ) - - - - - - - -Wahl, Coulbeck, Howes & Kille [Page 23] - -INTERNET-DRAFT LDAP Standard and Pilot Attributes October 1996 - - ( 2.5.6.8 NAME 'organizationalRole' SUP top STRUCTURAL MUST cn - MAY ( x121Address $ registeredAddress $ destinationIndicator $ - preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ - telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ - seeAlso $ roleOccupant $ preferredDeliveryMethod $ street $ - postOfficeBox $ postalCode $ postalAddress $ - physicalDeliveryOfficeName $ ou $ st $ l $ description ) ) - - ( 2.5.6.9 NAME 'groupOfNames' SUP top STRUCTURAL MUST ( member $ cn ) - MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) ) - - ( 2.5.6.10 NAME 'residentialPerson' SUP person STRUCTURAL MUST l - MAY ( businessCategory $ x121Address $ registeredAddress $ - destinationIndicator $ preferredDeliveryMethod $ telexNumber $ - teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ - facsimileTelephoneNumber $ preferredDeliveryMethod $ street $ - postOfficeBox $ postalCode $ postalAddress $ - physicalDeliveryOfficeName $ st $ l ) ) - - ( 2.5.6.11 NAME 'applicationProcess' SUP top STRUCTURAL MUST cn - MAY ( seeAlso $ ou $ l $ description ) ) - - ( 2.5.6.12 NAME 'applicationEntity' SUP top STRUCTURAL - MUST ( presentationAddress $ cn ) - MAY ( supportedApplicationContext $ seeAlso $ ou $ o $ l $ - description ) ) - - ( 2.5.6.13 NAME 'dSA' SUP applicationEntity STRUCTURAL - MAY knowledgeInformation ) - - ( 2.5.6.14 NAME 'device' SUP top STRUCTURAL MUST cn - MAY ( serialNumber $ seeAlso $ owner $ ou $ o $ l $ description ) ) - - ( 2.5.6.15 NAME 'strongAuthenticationUser' SUP top STRUCTURAL - MUST userCertificate ) - - ( 2.5.6.16 NAME 'certificationAuthority' SUP top STRUCTURAL - MUST ( authorityRevocationList $ certificateRevocationList $ - cACertificate ) MAY crossCertificatePair ) - - ( 2.5.6.17 NAME 'groupOfUniqueNames' SUP top STRUCTURAL - MUST ( uniqueMember $ cn ) - MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) ) - -5.3.2. Pilot Classes - - These object classes are defined in RFC 1274. All servers must recognize - these object class names. - - ( 0.9.2342.19200300.100.4.3 NAME 'pilotObject' SUP top STRUCTURAL - MAY ( jpegPhoto $ audio $ dITRedirect $ lastModifiedBy $ - lastModifiedTime $ uniqueIdentifier $ manager $ photo $ info ) ) - - -Wahl, Coulbeck, Howes & Kille [Page 24] - -INTERNET-DRAFT LDAP Standard and Pilot Attributes October 1996 - - ( 0.9.2342.19200300.100.4.4 NAME 'newPilotPerson' SUP person - STRUCTURAL MAY ( personalSignature $ mailPreferenceOption $ - organizationalStatus $ pagerTelephoneNumber $ mobileTelephoneNumber $ - otherMailbox $ janetMailbox $ businessCategory $ - preferredDeliveryMethod $ personalTitle $ secretary $ - homePostalAddress $ homePhone $ userClass $ roomNumber $ - favouriteDrink $ rfc822Mailbox $ textEncodedORaddress $ userid ) ) - - ( 0.9.2342.19200300.100.4.5 NAME 'account' SUP top STRUCTURAL - MUST userid MAY ( host $ ou $ o $ l $ seeAlso $ description ) ) - - ( 0.9.2342.19200300.100.4.6 NAME 'document' SUP ( top $ pilotObject ) - STRUCTURAL MUST documentIdentifier - MAY ( documentPublisher $ documentStore $ documentAuthorSurName $ - documentAuthorCommonName $ abstract $ subject $ keywords $ - updatedByDocument $ updatesDocument $ obsoletedByDocument $ - obsoletesDocument $ documentLocation $ documentAuthor $ - documentVersion $ documentTitle $ ou $ o $ l $ seeAlso $ description $ - cn ) ) - - ( 0.9.2342.19200300.100.4.7 NAME 'room' SUP top STRUCTURAL MUST cn - MAY ( telephoneNumber $ seeAlso $ description $ roomNumber ) ) - - ( 0.9.2342.19200300.100.4.9 NAME 'documentSeries' SUP top STRUCTURAL - MUST cn MAY ( ou $ o $ l $ telephoneNumber $ seeAlso $ description ) ) - - ( 0.9.2342.19200300.100.4.13 NAME 'domain' SUP top STRUCTURAL - MUST dc - MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ - x121Address $ registeredAddress $ destinationIndicator $ - preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ - telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ - street $ postOfficeBox $ postalCode $ postalAddress $ - physicalDeliveryOfficeName $ st $ l $ description $ o $ - associatedName ) ) - - ( 0.9.2342.19200300.100.4.14 NAME 'rFC822localPart' SUP domain - STRUCTURAL - MAY ( x121Address $ registeredAddress $ destinationIndicator $ - preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ - telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ - streetAddress $ postOfficeBox $ postalCode $ postalAddress $ - physicalDeliveryOfficeName $ telephoneNumber $ seeAlso $ description $ - sn $ cn ) ) - - ( 0.9.2342.19200300.100.4.15 NAME 'dNSDomain' SUP domain STRUCTURAL - MAY dNSRecord ) - - ( 0.9.2342.19200300.100.4.17 NAME 'domainRelatedObject' SUP top - STRUCTURAL MUST associatedDomain ) - - ( 0.9.2342.19200300.100.4.18 NAME 'friendlyCountry' SUP country - STRUCTURAL MUST co ) - -Wahl, Coulbeck, Howes & Kille [Page 25] - -INTERNET-DRAFT LDAP Standard and Pilot Attributes October 1996 - - ( 0.9.2342.19200300.100.4.19 NAME 'simpleSecurityObject' SUP top - STRUCTURAL MUST userPassword ) - - ( 0.9.2342.19200300.100.4.20 NAME 'pilotOrganization' - SUP ( organization $ organizationalUnit ) STRUCTURAL - MAY buildingName ) - - ( 0.9.2342.19200300.100.4.21 NAME 'pilotDSA' SUP dSA STRUCTURAL - MUST dSAQuality ) - - ( 0.9.2342.19200300.100.4.23 NAME 'qualityLabelledData' SUP top - STRUCTURAL MUST singleLevelQuality - MAY ( subtreeMaximumQuality $ subtreeMinimumQuality ) ) - -5.4. Matching Rules - - Servers must recognize the following matching rules, used for equality - matching, and must be capable of performing the matching rules. - For all these rules, the assertion syntax is the same as the value syntax. - - ( 2.5.13.0 NAME 'objectIdentifierMatch' SYNTAX 'OID' ) - ( 2.5.13.1 NAME 'distinguishedNameMatch' SYNTAX 'DN' ) - ( 2.5.13.2 NAME 'caseIgnoreMatch' SYNTAX 'DirectoryString' ) - ( 2.5.13.8 NAME 'numericStringMatch' SYNTAX 'NumericString' ) - ( 2.5.13.11 NAME 'caseIgnoreListMatch' SYNTAX 'PostalAddress' ) - ( 2.5.13.14 NAME 'integerMatch' SYNTAX 'INTEGER' ) - ( 2.5.13.16 NAME 'bitStringMatch' SYNTAX 'BitString' ) - ( 2.5.13.17 NAME 'octetStringMatch' SYNTAX 'Password' ) - ( 2.5.13.20 NAME 'telephoneNumberMatch' SYNTAX 'TelephoneNumber' ) - ( 2.5.13.27 NAME 'generalizedTimeMatch' SYNTAX 'GeneralizedTime' ) - ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match' SYNTAX 'IA5String' ) - ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match' SYNTAX 'IA5String' ) - - When performing the caseIgnoreMatch, caseIgnoreListMatch, - telephoneNumberMatch, caseExactIA5Match and caseIgnoreIA5Match, - multiple adjoining whitespace characters are treated the same as - an individual space, and leading and trailing whitespace is ignored. - -6. X.500 Definitions - - Servers which implement the X.500(1993) protocols are required to recognize - these attributes types, syntaxes, object classes and matching rules, where - they correspond to X.500 features implemented by that server. No other - servers are required to implement any definitions in section 6, although - they may do so. - - Clients must not assume these definitions are recognized by all servers. - -6.1. Attribute Types - -6.1.1. User Attributes - - All user attributes of X.500 are listed in section 5.1.1. - -Wahl, Coulbeck, Howes & Kille [Page 26] - -INTERNET-DRAFT LDAP Standard and Pilot Attributes October 1996 - -6.1.2. Collective Attributes - - These attributes are stored in collective attribute subentries, but may - be visible in user entries if requested. - - Each of these collective attributes is a subtype of the attribute which - has the OID without the final ".1", e.g. "collectivePostalCode" is a - subtype of "postalCode". - - ( 2.5.4.7.1 NAME 'collectiveLocalityName' SUP l COLLECTIVE ) - - ( 2.5.4.8.1 NAME 'collectiveStateOrProvinceName' SUP st COLLECTIVE ) - - ( 2.5.4.9.1 NAME 'collectiveStreetAddress' SUP street COLLECTIVE ) - - ( 2.5.4.10.1 NAME 'collectiveOrganizationName' SUP o COLLECTIVE ) - - ( 2.5.4.11.1 NAME 'collectiveOrganizationalUnitName' SUP ou COLLECTIVE ) - - ( 2.5.4.16.1 NAME 'collectivePostalAddress' SUP postalAddress COLLECTIVE ) - - ( 2.5.4.17.1 NAME 'collectivePostalCode' SUP postalCode COLLECTIVE ) - - ( 2.5.4.18.1 NAME 'collectivePostOfficeBox' SUP postOfficeBox COLLECTIVE ) - - ( 2.5.4.19.1 NAME 'collectivePhysicalDeliveryOfficeName' - SUP physicalDeliveryOfficeName COLLECTIVE ) - - ( 2.5.4.20.1 NAME 'collectiveTelephoneNumber' SUP telephoneNumber - COLLECTIVE ) - - ( 2.5.4.21.1 NAME 'collectiveTelexNumber' SUP 'TelexNumber' COLLECTIVE ) - - ( 2.5.4.22.1 NAME 'collectiveTeletexTerminalIdentifier' - SUP teletexTerminalIdentifier COLLECTIVE ) - - ( 2.5.4.23.1 NAME 'collectiveFacsimileTelephoneNumber' - SUP facsimileTelephoneNumber COLLECTIVE ) - - ( 2.5.4.25.1 NAME 'collectiveInternationaliSDNNumber' - SUP internationaliSDNNumber COLLECTIVE ) - -6.1.3. Standard Operational Attributes - - These attributes are defined in X.501(1993) Annexes B through E. - - ( 2.5.18.5 NAME 'administrativeRole' EQUALITY objectIdentifierMatch - SYNTAX 'OID' USAGE directoryOperation ) - - ( 2.5.18.6 NAME 'subtreeSpecification' SYNTAX 'SubtreeSpecification' - SINGLE-VALUE USAGE directoryOperation ) - - - -Wahl, Coulbeck, Howes & Kille [Page 27] - -INTERNET-DRAFT LDAP Standard and Pilot Attributes October 1996 - - ( 2.5.18.7 NAME 'collectiveExclusions' EQUALITY objectIdentifierMatch - SYNTAX 'OID' USAGE directoryOperation ) - - ( 2.5.21.1 NAME 'dITStructureRules' EQUALITY integerFirstComponentMatch - SYNTAX 'DITStructureRuleDescription' USAGE directoryOperation ) - - ( 2.5.21.2 NAME 'dITContentRules' - EQUALITY objectIdentifierFirstComponentMatch - SYNTAX 'DITContentRuleDescription' USAGE directoryOperation ) - - ( 2.5.21.4 NAME 'matchingRules' - EQUALITY objectIdentifierFirstComponentMatch - SYNTAX 'MatchingRuleDescription' USAGE directoryOperation ) - - ( 2.5.21.7 NAME 'nameForms' - EQUALITY objectIdentifierFirstComponentMatch - SYNTAX 'NameFormDescription' USAGE directoryOperation ) - - ( 2.5.21.8 NAME 'matchingRuleUse' - EQUALITY objectIdentifierFirstComponentMatch - SYNTAX 'MatchingRuleUseDescription' USAGE directoryOperation ) - - ( 2.5.21.9 NAME 'structuralObjectClass' EQUALITY objectIdentifierMatch - SYNTAX 'OID' SINGLE-VALUE NO-USER-MODIFICATION - USAGE directoryOperation ) - - ( 2.5.21.10 NAME 'governingStructuralRule' EQUALITY integerMatch - SYNTAX 'INTEGER' SINGLE-VALUE NO-USER-MODIFICATION - USAGE directoryOperation ) - - ( 2.5.24.1 NAME 'accessControlScheme' EQUALITY objectIdentifierMatch - SYNTAX 'OID' SINGLE-VALUE USAGE directoryOperation ) - - ( 2.5.24.4 NAME 'prescriptiveACI' - EQUALITY directoryStringFirstComponentMatch SYNTAX 'ACIItem' - USAGE directoryOperation ) - - ( 2.5.24.5 NAME 'entryACI' - EQUALITY directoryStringFirstComponentMatch SYNTAX 'ACIItem' - USAGE directoryOperation ) - - ( 2.5.24.6 NAME 'subentryACI' - EQUALITY directoryStringFirstComponentMatch SYNTAX 'ACIItem' - USAGE directoryOperation ) - - ( 2.5.12.0 NAME 'dseType' EQUALITY bitStringMatch SYNTAX 'DSEType' - SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation ) - - ( 2.5.12.1 NAME 'myAccessPoint' EQUALITY accessPointMatch - SYNTAX 'AccessPoint' SINGLE-VALUE NO-USER-MODIFICATION - USAGE dSAOperation ) - - - -Wahl, Coulbeck, Howes & Kille [Page 28] - -INTERNET-DRAFT LDAP Standard and Pilot Attributes October 1996 - - ( 2.5.12.2 NAME 'superiorKnowledge' EQUALITY accessPointMatch - SYNTAX 'AccessPoint' SINGLE-VALUE NO-USER-MODIFICATION - USAGE dSAOperation ) - - ( 2.5.12.3 NAME 'specificKnowledge' - EQUALITY masterAndShadowAccessPointsMatch - SYNTAX 'MasterAndShadowAccessPoints' - SINGLE-VALUE NO-USER-MODIFICATION USAGE distributedOperation ) - - ( 2.5.12.4 NAME 'nonSpecificKnowledge' - EQUALITY masterAndShadowAccessPointsMatch - SYNTAX 'MasterAndShadowAccessPoints' NO-USER-MODIFICATION - USAGE distributedOperation ) - - ( 2.5.12.5 NAME 'supplierKnowledge' - EQUALITY supplierOrConsumerInformationMatch - SYNTAX 'SupplierInformation' - NO-USER-MODIFICATION USAGE dSAOperation ) - - ( 2.5.12.6 NAME 'consumerKnowledge' - EQUALITY supplierOrConsumerInformationMatch - SYNTAX 'SupplierOrConsumer' - NO-USER-MODIFICATION USAGE dSAOperation ) - - ( 2.5.12.7 NAME 'secondaryShadows' - EQUALITY supplierAndConsumersMatch - SYNTAX 'SupplierAndConsumers' - NO-USER-MODIFICATION USAGE dSAOperation ) - -6.1.4. LDAP-defined Operational Attributes - -6.1.4.1. targetSystem - - ( 1.3.6.1.4.1.1466.101.120.12 NAME 'targetSystem' - SYNTAX 'AccessPoint' SINGLE-VALUE NO-USER-MODIFICATION - USAGE distributedOperation ) - - The value of this attribute may be supplied in an AddEntry operation - to inform the Directory of the target server on which the entry is to - be held. This is used to create a new naming context in the directory - tree. A server which does not permit the use of this attribute must - return an appropriate error code if it is present in the attribute list. - This attribute will generally not be present in the entry after the add - is completed. - - - - - - - - - - -Wahl, Coulbeck, Howes & Kille [Page 29] - -INTERNET-DRAFT LDAP Standard and Pilot Attributes October 1996 - -6.2. Syntaxes - -6.2.1. Standard Syntaxes - -6.2.1.1. ACIItem - - This syntax appears too complicated for a compact string representation - to be useful. Clients must only request and servers must only return - values which use the the binary encoding of the value, e.g. - "entryACI;binary". - - It is recommended that clients that wish to only determine whether they - have been granted permission to modify an entry use the "modifyRights" - attribute rather than attempt to parse this syntax. - -6.2.1.2. AccessPoint - - Values with AccessPoint syntax are encoded according to the - following BNF: - - ::= ( '(' '#' - ')' ) | - -- Optional protocol info absent, parenthesis required - ( '(' '#' - '#' - ::= | - '(' ')' - - ::= | - '$' - - -6.2.1.3. DITContentRuleDescription - - Values with this syntax are encoded according to the following BNF: - - ::= "(" - -- Structural ObjectClass identifier - [ "NAME" ] - [ "DESC" ] - [ "OBSOLETE" ] - [ "AUX" ] -- Auxiliary ObjectClasses - [ "MUST" ] -- AttributeType identifiers - [ "MAY" ] -- AttributeType identifiers - [ "NOT" ] -- AttributeType identifiers - ")" - - - - - - -Wahl, Coulbeck, Howes & Kille [Page 30] - -INTERNET-DRAFT LDAP Standard and Pilot Attributes October 1996 - -6.2.1.4. DITStructureRuleDescription - - Values with this syntax are encoded according to the following BNF: - - ::= "(" - -- DITStructureRule identifier - [ "NAME" ] - [ "DESC" ] - [ "OBSOLETE" ] - "FORM" -- NameForm - [ "SUP" ] -- superior DITStructureRules - ")" - - ::= - - ::= - | - "(" ")" - - ::= - - | - -- empty list - -6.2.1.5. DSEType - - Values with DSEType syntax are encoded according to the following BNF: - - ::= '(' ')' - - ::= | '$' - - ::= 'root' | 'glue' | 'cp' | 'entry' | 'alias' | 'subr' | - 'nssr' | 'supr' | 'xr' | 'admPoint' | 'subentry' | - 'shadow' | 'zombie' | 'immSupr' | 'rhob' | 'sa' - -6.2.1.6. MasterAndShadowAccessPoints - - Values of this syntax are encoded according to the following BNF: - - ::= | - '(' ::= | - '$' - - ::= '#' - - ::= 'master' | 'shadow' - -6.2.1.7. MatchingRuleDescription - - Values of this syntax are encoded according to the BNF of section 4.4. - -Wahl, Coulbeck, Howes & Kille [Page 31] - -INTERNET-DRAFT LDAP Standard and Pilot Attributes October 1996 - -6.2.1.8. MatchingRuleUseDescription - - Values of this syntax are encoded according to the following BNF: - - ::= "(" - -- MatchingRule identifier - [ "NAME" ] - [ "DESC" ] - [ "OBSOLETE" ] - "APPLIES" -- AttributeType identifiers - ")" - -6.2.1.9. NameFormDescription - - Values of this syntax are encoded according to the following BNF: - - ::= "(" - -- NameForm identifier - [ "NAME" ] - [ "DESC" ] - [ "OBSOLETE" ] - "OC" -- Structural ObjectClass - "MUST" -- AttributeTypes - [ "MAY" ] -- AttributeTypes - ")" - -6.2.1.10. SubtreeSpecification - - Values of this syntax are encoded according to the following BNF: - - ::= '(' [] '#' - [] '#' - [] '#' [] '#' - [] ')' - - ::= - - ::= '(' ')' - - ::= | '$' - - ::= ( 'before ' ) | - ( 'after ' ) - - ::= - - ::= - - ::= | '!' | - '( &' ')' | - '( |' ')' - - ::= | '$' - -Wahl, Coulbeck, Howes & Kille [Page 32] - -INTERNET-DRAFT LDAP Standard and Pilot Attributes October 1996 - -6.2.1.11. SupplierInformation - - Values of this syntax are encoded according to the following BNF: - - ::= - -- supplier is master -- - '(' 'master' '#' ')' | - - -- supplier is not master, master unspecified -- - '(' 'shadow' '#' ')' | - - -- supplier not master, master specified -- - ['('] 'shadow' '#' '#' [')'] - -6.2.1.12. SupplierOrConsumer - - Values of this syntax are encoded according to the following BNF: - - ::= '#' - - ::= '.' - - ::= - - ::= - -6.2.1.13. SupplierAndConsumers - - Values of this syntax are encoded according to the following BNF: - - ::= '#' - - ::= - - ::= | '(' ')' - - ::= | - '$' - -6.2.1.14. ProtocolInformation - - A value with the ProtocolInformation syntax is encoded according to the - following BNF: - - ::= '#' - - - ::= As appears in PresentationAddress - - ::= | - '(' ')' - - - -Wahl, Coulbeck, Howes & Kille [Page 33] - -INTERNET-DRAFT LDAP Standard and Pilot Attributes October 1996 - - ::= | - '$' - - ::= - - For example, - - NS+12345678 # 1.2.3.4.5 - -6.2.2. LDAP-defined Syntaxes - - There is currently one syntax defined here. - -6.2.2.1 ModifyRight - - This syntax is a printable encoding of the following ASN.1 data type: - - ModifyRight ::= SEQUENCE { - item CHOICE { - entry [0] NULL, - attribute [1] AttributeType, - value [2] AttributeValueAssertion }, - permission [3] BIT STRING { add(0), remove(1), rename(2), move(3) } } - - The syntax is encoded according to the following BNF: - - ::= [] - -- perm list is absent when none of the bits set in permission - - ::= | | - - ::= 'entry' - - ::= 'attribute' - - ::= 'value' - - -- is the string encoding of the value - - ::= | - -- one or more of the bits in permission, if set - - ::= 'add' | 'remove' | 'rename' | 'move' - - ::= [ ] '#' [ ] - - ::= [ ] '$' [ ] - - - - - - - -Wahl, Coulbeck, Howes & Kille [Page 34] - -INTERNET-DRAFT LDAP Standard and Pilot Attributes October 1996 - - For example, - - # entry - add $ remove # attribute $ cn - add $ remove # attribute $ sn - remove # value $ memberName $ CN=Babs, O=Michigan, C=US - -6.3. Object Classes - - The following object classes may be recognized. - - ( 2.5.17.0 NAME 'subentry' SUP top STRUCTURAL - MUST ( cn $ subtreeSpecification ) ) - - ( 2.5.17.1 NAME 'accessControlSubentry' AUXILIARY ) - - ( 2.5.17.2 NAME 'collectiveAttributeSubentry' AUXILIARY ) - - ( 2.5.20.1 NAME 'subschema' AUXILIARY - MAY ( dITStructureRules $ nameForms $ ditContentRules $ - objectClasses $ attributeTypes $ matchingRules $ matchingRuleUse ) ) - -6.4. Matching Rules - - Only servers which implement the attribute types which reference these - matching rules in their definition are required to implement these rules. - - The definitions of the rules can be found in [2] and [3]. - - Name OID - ===================================== =========== - caseIgnoreOrderingMatch 2.5.13.3 - caseIgnoreSubstringsMatch 2.5.13.4 - caseExactMatch 2.5.13.5 - caseExactOrderingMatch 2.5.13.6 - caseExactSubstringsMatch 2.5.13.7 - numericStringOrderingMatch 2.5.13.9 - numericStringSubstringsMatch 2.5.13.10 - caseIgnoreListSubstringsMatch 2.5.13.12 - booleanMatch 2.5.13.13 - integerOrderingMatch 2.5.13.15 - octetStringOrderingMatch 2.5.13.18 - octetStringSubstringsMatch 2.5.13.19 - telephoneNumberSubstringsMatch 2.5.13.21 - presentationAddressMatch 2.5.13.22 - uniqueMemberMatch 2.5.13.23 - protocolInformationMatch 2.5.13.24 - uTCTimeMatch 2.5.13.25 - uTCTimeOrderingMatch 2.5.13.26 - generalizedTimeOrderingMatch 2.5.13.28 - integerFirstComponentMatch 2.5.13.29 - objectIdentifierFirstComponentMatch 2.5.13.30 - directoryStringFirstComponentMatch 2.5.13.31 - -Wahl, Coulbeck, Howes & Kille [Page 35] - -INTERNET-DRAFT LDAP Standard and Pilot Attributes October 1996 - - wordMatch 2.5.13.32 - keywordMatch 2.5.13.33 - accessPointMatch 2.5.14.0 - masterAndShadowAccessPointsMatch 2.5.14.1 - supplierOrConsumerInformationMatch 2.5.14.2 - supplierAndConsumersMatch 2.5.14.3 - -6.5. Other - - The string 'excludeAllCollectiveAttributes' is defined as a synonym - for the OID 2.5.18.0. It would typically be used as a value of the - collectiveExclusions attribute. - -7. Other Optional Definitions - -7.1. Attribute Types - -7.1.1. Obsolete Attributes - - Implementors must use modifyTimestamp and modifiersName instead. - - ( 0.9.2342.19200300.100.1.23 NAME 'lastModifiedTime' OBSOLETE - SYNTAX 'UTCTime' ) - - ( 0.9.2342.19200300.100.1.24 NAME 'lastModifiedBy' OBSOLETE - EQUALITY distinguishedNameMatch SYNTAX 'DN' ) - -7.2. Syntaxes - -7.2.1 MHSORAddress - - Values of type MHSORAddress are encoded as strings, according to - the format defined in [10]. - -7.2.2 DLSubmitPermission - - Values of type DLSubmitPermission are encoded as strings, according - to the following BNF: - - ::= ':' - | ':' - - ::= 'group_member' - - ::= - - ::= an encoded Distinguished Name - - ::= 'individual' | 'dl_member' | 'pattern' - - ::= - - - -Wahl, Coulbeck, Howes & Kille [Page 36] - -INTERNET-DRAFT LDAP Standard and Pilot Attributes October 1996 - - ::=

'#' - |
- -
::= ':' - - ::= ':' - - = 'X400' - - = 'X500' - - where is as defined in RFC 1327. - -7.3. Object Classes - -7.3.1. Obsolete Classes - - ( 0.9.2342.19200300.100.4.22 NAME 'oldQualityLabelledData' SUP top - STRUCTURAL MUST dSAQuality - MAY ( subtreeMaximumQuality $ subtreeMinimumQuality ) ) - - The oldQualityLabelledData object class is historical and must not be - used for defining new objects. - -7.3.2. extensibleObject - - ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject' - SUP top AUXILIARY ) - - This class, if present in an entry, permits that entry to optionally - hold any attribute. The MAY attribute list of this class is implicitly - the set of all attributes known to the server. The mandatory attributes - of the other object classes of this entry are still required to be - present. - - Note that not all servers will implement this object class, and those - which do not will reject requests to add entries which contain this - object class, or modify an entry to add this object class. - -7.4. Matching Rules - -7.4.1. caseIgnoreIA5SubstringsMatch - - ( 1.3.6.1.4.1.1466.109.114.3 - NAME 'caseIgnoreIA5SubstringsMatch' SYNTAX 'IA5String' ) - - This matching rule may be used to compare components of an IA5 string - against an attribute whose values have IA5 string syntax. - -8. Security Considerations - - Security issues are not discussed in this memo. - - -Wahl, Coulbeck, Howes & Kille [Page 37] - -INTERNET-DRAFT LDAP Standard and Pilot Attributes October 1996 - -9. Acknowledgements - - This document is based substantially on RFC 1778, written by Tim Howes, - Steve Kille, Wengyik Yeong and Colin Robbins. - - Many of the attribute syntax encodings defined in this document are - adapted from those used in the QUIPU and the IC R3 X.500 - implementations. The contributions of the authors of both these - implementations in the specification of syntaxes in this document are - gratefully acknowledged. - -10. Authors Addresses - - Mark Wahl - Critical Angle Inc. - 4815 West Braker Lane #502-385 - Austin, TX 78759 - USA - - EMail: M.Wahl@critical-angle.com - - - Andy Coulbeck - ISODE Consortium - The Dome, The Square - Richmond TW9 1DT - United Kingdom - - Phone: +44 181-332-9091 - EMail: A.Coulbeck@isode.com - - - - - Tim Howes - Netscape Communications Corp. - 501 E. Middlefield Rd - Mountain View, CA 94043 - USA - - Phone: +1 415 254-1900 - EMail: howes@netscape.com - - - Steve Kille - ISODE Consortium - The Dome, The Square - Richmond - TW9 1DT - UK - - Phone: +44-181-332-9091 - EMail: S.Kille@isode.com - -Wahl, Coulbeck, Howes & Kille [Page 38] - -INTERNET-DRAFT LDAP Standard and Pilot Attributes October 1996 - -11. Bibliography - - [1] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol - (Version 3)", INTERNET-DRAFT , - October 1996. - - [2] The Directory: Selected Attribute Types. ITU-T Recommendation - X.520, 1993. - - [3] The Directory: Models. ITU-T Recommendation X.501, 1993. - - [4] P. Barker, S. Kille, "The COSINE and Internet X.500 Schema", RFC - 1274, November 1991. - - [5] M. Wahl, S. Kille, "A UTF-8 String Representation of Distinguished - Names", INTERNET-DRAFT , August 1996. - - [6] S. Kille, "A String Representation for Presentation Addresses", - RFC 1278, University College London, November 1991. - - [7] Terminal Equipment and Protocols for Telematic Services - - Standardization of Group 3 facsimile apparatus for document - transmission. CCITT, Recommendation T.4. - - [8] JPEG File Interchange Format (Version 1.02). Eric Hamilton, - C-Cube Microsystems, Milpitas, CA, September 1, 1992. - - [9] The Directory: Selected Object Classes. ITU-T Recommendation - X.521, 1993. - - [10] H. Alvestrand, S. Kille, R. Miles, M. Rose, S. Thompson, - "Mapping between X.400 and RFC-822 Message Bodies", RFC 1495, - August 1993. - - [11] M. Davis, UTF-8, (WG2 N1036) DAM for ISO/IEC 10646-1. - - [12] Universal Multiple-Octet Coded Character Set (UCS) - Architecture - and Basic Multilingual Plane, ISO/IEC 10646-1 : 1993. - - [13] The Directory: Authentication Framework. ITU-T Recommendation - X.509 (1993). - - [14] Abstract Syntax Notation One (ASN.1) - Specification of Basic - Notation. ITU-T Recommendation X.680, 1994. - - - - - - - - - -Expires: April 1997 -Wahl, Coulbeck, Howes & Kille [Page 39] diff --git a/doc/drafts/draft-just-ldapv3-rescodes-xx.txt b/doc/drafts/draft-just-ldapv3-rescodes-xx.txt deleted file mode 100644 index 5003e57062..0000000000 --- a/doc/drafts/draft-just-ldapv3-rescodes-xx.txt +++ /dev/null @@ -1,1785 +0,0 @@ - -Internet Draft Mike Just, Entrust - K. Leclair, Entrust - Jim Sermersheim, Novell - Mark Smith, Netscape -Document: April, 2000 -Category: Standards Track - - - LDAPv3 Result Codes: Definitions and Appropriate Use - - - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026 [RFC2026]. - - 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. - -1. Abstract - - The purpose of this document is to describe, in some detail, the - meaning and use of the result codes used with the LDAPv3 protocol. - Of particular importance are the error codes, which represent the - majority of the result codes. This document provides definitions for - each result code, and outlines the expected behaviour of the various - operations with respect to how result codes and in particular, error - conditions should be handled and which specific error code should be - returned. - - It is hoped that this document will facilitate interoperability - between clients and servers and the development of intelligent LDAP - clients capable of acting upon the results received from the server. - -1.1 Relationship to X.500 - - The LDAPv3 RFC [RFC2251] states that "An LDAP server MUST act in - accordance with the X.500(1993) series of ITU recommendations when - providing the service. However, it is not required that an LDAP - server make use of any X.500 protocols in providing this service, - e.g. LDAP can be mapped onto any other directory system so long as - the X.500 data and service model as used in LDAP is not violated in - the LDAP interface." This means that there are two types of LDAP - -Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 1 - - - LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000 - - servers, those that act as a front end to an X.500 directory, and - stand alone LDAP servers which use some other form of repository as - the back end. - - Because of differences between X.500 and LDAP there may be some - differences in behaviour between LDAP-only servers and LDAP servers - that act as front ends to X.500 DSAs. One such difference is the - definition of specific access controls for X.500. X.500 defines the - discloseOnError permission, an access control parameter for which - there is currently no equivalent defined for LDAP. If an LDAP server - is acting as a front end to an X.500 DSA then it may return - noSuchObject when the target entry is found but the client does not - have permission to view or modify the entry. Unless the server - implements X.500 style access controls LDAP-only servers should only - return noSuchObject when the target entry is not found until such - time that similar access controls are defined for LDAP only servers. - Because the client may not know what sort of LDAP server it is - communicating with it should not rely on the behaviour of the server - in this respect. - -2. Conventions used in this document - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC-2119 [RFC2119]. - -3. Overview - - This document collects and refines the definitions and descriptions - for LDAPv3 result codes, as found in a variety of sources (see - Section 8). In some cases, material from these sources was absent, - inadequate or ambiguous. It is the hope of this document to present - consistent definitions and descriptions of LDAPv3 result codes. - - This document consists of two major sections facilitating information - searches based on either a particular result code, or LDAP operation. - - Section 5 presents a glossary for the result codes. Firstly, each is - classified as either an erroneous or non-erroneous result. The - erroneous results, or error codes, are further classified based on - the types of error codes defined in X.511 [X511]. Some - reclassification was performed where appropriate. For each result - code, a definition, and list of operations that could return this - code are given. - - Section 6 describes, for each operation, the result codes that could - be returned for that operation. Firstly, Section 6.1 enumerates - those result codes that are applicable to all operations. Within - each remaining section (which is specific to each operation), the - error codes that are specific to that operation (in addition to the - result codes specified in Section 6.1) are presented. - - Also, Appendix A (Section 11) presents a simple matrix that indicates - valid operation/result code pairs in LDAPv3. - -Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 2 - - - LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000 - - -4. Table of Contents - - 1. Abstract........................................................1 - 1.1 Relationship to X.500...........................................1 - 2. Conventions used in this document...............................2 - 3. Overview........................................................2 - 4. Table of Contents...............................................3 - 5. Result Codes in LDAPv3..........................................4 - 5.1 Description of Non-Erroneous Result Codes.......................6 - 5.1.1 success(0)...................................................6 - 5.1.2 compareFalse(5)..............................................6 - 5.1.3 compareTrue(6)...............................................6 - 5.1.4 referral(10).................................................7 - 5.1.5 saslBindInProgress(14).......................................7 - 5.2 Description of Error Codes......................................7 - 5.2.1 General Error Codes..........................................7 - 5.2.1.1 other(80)................................................7 - 5.2.2 Specific Error Codes.........................................7 - 5.2.2.1 Attribute Problem Error Codes............................7 - 5.2.2.1.1 noSuchAttribute(16)...................................8 - 5.2.2.1.2 undefinedAttributeType(17)............................8 - 5.2.2.1.3 inappropriateMatching(18).............................8 - 5.2.2.1.4 constraintViolation(19)...............................8 - 5.2.2.1.5 attributeOrValueExists(20)............................8 - 5.2.2.1.6 invalidAttributeSyntax(21)............................8 - 5.2.2.2 NameProblem Error Codes..................................9 - 5.2.2.2.1 noSuchObject(32)......................................9 - 5.2.2.2.2 aliasProblem(33)......................................9 - 5.2.2.2.3 invalidDNSyntax(34)...................................9 - 5.2.2.3 SecurityProblem Error Codes..............................9 - 5.2.2.3.1 authMethodNotSupported(7).............................9 - 5.2.2.3.2 strongAuthRequired(8)................................10 - 5.2.2.3.3 confidentialityRequired(13)..........................10 - 5.2.2.3.4 aliasDereferencingProblem(36)........................10 - 5.2.2.3.5 inappropriateAuthentication(48)......................10 - 5.2.2.3.6 invalidCredentials(49)...............................11 - 5.2.2.3.7 insufficientAccessRights(50).........................11 - 5.2.2.4 ServiceProblem Error Codes..............................11 - 5.2.2.4.1 operationsError(1)...................................11 - 5.2.2.4.2 protocolError(2).....................................11 - 5.2.2.4.3 timeLimitExceeded(3).................................12 - 5.2.2.4.4 sizeLimitExceeded(4).................................12 - 5.2.2.4.5 adminLimitExceeded(11)...............................12 - 5.2.2.4.6 unavailableCriticalExtension(12).....................12 - 5.2.2.4.7 busy(51).............................................13 - 5.2.2.4.8 unavailable(52)......................................13 - 5.2.2.4.9 unwillingToPerform(53)...............................13 - 5.2.2.4.10 loopDetect(54)......................................13 - 5.2.2.5 UpdateProblem Error Codes...............................13 - 5.2.2.5.1 namingViolation(64)..................................13 - 5.2.2.5.2 objectClassViolation(65).............................14 - 5.2.2.5.3 notAllowedOnNonLeaf(66)..............................14 - 5.2.2.5.4 notAllowedOnRDN(67)..................................14 - -Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 3 - - - LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000 - - 5.2.2.5.5 entryAlreadyExists(68)...............................14 - 5.2.2.5.6 objectClassModsProhibited(69)........................14 - 5.2.2.5.7 affectsMultipleDSAs(71)..............................15 - 6 LDAP Operations.................................................15 - 6.1 Common Result Codes............................................16 - 6.1.1 Non-erroneous results.......................................16 - 6.1.2 Security Errors.............................................16 - 6.1.3 Service Errors..............................................16 - 6.1.4 General Errors..............................................16 - 6.2 Bind Operation Errors..........................................16 - 6.2.1 Non-erroneous results.......................................17 - 6.2.2 Name Errors.................................................17 - 6.2.3 Security Errors.............................................17 - 6.3 Search Operation Errors........................................17 - 6.3.1 Name Errors.................................................18 - 6.3.2 Attribute Errors............................................18 - 6.3.3 Security Errors.............................................18 - 6.3.4 Service Errors..............................................18 - 6.4 Modify Operation Errors........................................18 - 6.4.1 Name Errors.................................................19 - 6.4.2 Update Errors...............................................19 - 6.4.3 Attribute Errors............................................19 - 6.4.4 Security Errors.............................................19 - 6.5 Add Operation Errors...........................................19 - 6.5.1 Name Errors.................................................20 - 6.5.2 Update Errors...............................................20 - 6.5.3 Attribute Errors............................................20 - 6.5.4 Security Errors.............................................20 - 6.6 Delete Operation Errors........................................21 - 6.6.1 Name Errors.................................................21 - 6.6.2 Update Errors...............................................21 - 6.6.3 Security Errors.............................................21 - 6.7 ModifyDN Operation Errors......................................21 - 6.7.1 Name Errors.................................................22 - 6.7.2 Update Errors...............................................22 - 6.7.3 Attribute Errors............................................22 - 6.7.4 Security Errors.............................................22 - 6.8 Compare Operation Errors.......................................22 - 6.8.1 Name Errors.................................................23 - 6.8.2 Attribute Errors............................................23 - 6.8.3 Security Errors.............................................23 - 6.8.4 Example.....................................................23 - 6.9 Extended Operation Errors......................................24 - 6.10 Operations with no Server Response............................24 - 6.11 Unsolicited Notification......................................24 - 6.12 Controls......................................................25 - 7. Security Considerations........................................25 - 8. References.....................................................25 - 9. Acknowledgments................................................25 - 10. Author's Addresses............................................26 - 11 Appendix A: Operation/Response Matrix..........................27 - 12 Full Copyright Statement.......................................29 - -5. Result Codes in LDAPv3 - -Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 4 - - - LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000 - - - In this section, a glossary of the result codes that may be returned - from a server to a client is provided. This section is meant to - provide a central, unified source for these definitions. RFC 2251 - [RFC2251] and X.511 [X511] were primary sources, forming the basis - for the definitions given in this section. - - LDAP v3 [RFC2251] defines the following result message for return - from the server to the client, where "new" indicates those codes that - were not used in LDAP v2. - - LDAPResult ::= SEQUENCE { - resultCode ENUMERATED { - success (0), - operationsError (1), - protocolError (2), - timeLimitExceeded (3), - sizeLimitExceeded (4), - compareFalse (5), - compareTrue (6), - authMethodNotSupported (7), - strongAuthRequired (8), - -- 9 reserved -- - referral (10), -- new - adminLimitExceeded (11), -- new - unavailableCriticalExtension (12), -- new - confidentialityRequired (13), -- new - saslBindInProgress (14), -- new - noSuchAttribute (16), - undefinedAttributeType (17), - inappropriateMatching (18), - constraintViolation (19), - attributeOrValueExists (20), - invalidAttributeSyntax (21), - -- 22-31 unused -- - noSuchObject (32), - aliasProblem (33), - invalidDNSyntax (34), - -- 35 reserved for undefined isLeaf -- - aliasDereferencingProblem (36), - -- 37-47 unused -- - inappropriateAuthentication (48), - invalidCredentials (49), - insufficientAccessRights (50), - busy (51), - unavailable (52), - unwillingToPerform (53), - loopDetect (54), - -- 55-63 unused -- - namingViolation (64), - objectClassViolation (65), - notAllowedOnNonLeaf (66), - notAllowedOnRDN (67), - entryAlreadyExists (68), - -Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 5 - - - LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000 - - objectClassModsProhibited (69), - -- 70 reserved for CLDAP -- - affectsMultipleDSAs (71), -- new - -- 72-79 unused -- - other (80) }, - -- 81-90 reserved for APIs -- - matchedDN LDAPDN, - errorMessage LDAPString, - referral [3] Referral OPTIONAL } - - If a client receives a result code that is not listed above, it is to - be treated as an unknown error condition. A server MUST NOT return an - API result code (81-90). - - The LDAP result includes an errorMessage field, which may, at the - server's option, be used to return a string containing a textual, - human-readable error diagnostic. As this error diagnostic is not - standardized, implementations MUST NOT rely on the values returned. - If the server chooses not to return a textual diagnostic, the - errorMessage field of the LDAPResult type MUST contain a zero length - string. - - In the following subsections, definitions for each result code are - provided. In addition, the operations that may return each result - code are also identified. The set of all operations consists of the - following: Bind; Search; Modify; Add; Delete; ModifyDN; Extended; and - Compare. - -5.1 Description of Non-Erroneous Result Codes - - Five result codes that may be returned in LDAPResult are not used to - indicate an error. These result codes are listed below. The first - three codes, indicate to the client that no further action is - required in order to satisfy their request. In contrast, the last - two errors require further action by the client in order to complete - their original operation request. - -5.1.1 success(0) - - Applicable operations: all except for Compare. - - This result code does not indicate an error. It is returned when the - client operation completed successfully. - -5.1.2 compareFalse(5) - - Applicable operations: Compare. - - This result code does not indicate an error. It is used to indicate - that the result of a Compare operation is FALSE. - -5.1.3 compareTrue(6) - - Applicable operations: Compare. - -Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 6 - - - LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000 - - - This result code does not indicate an error. It is used to indicate - that the result of a Compare operation is TRUE. - -5.1.4 referral(10) - - Applicable operations: all. - - This result code is new in LDAPv3. Rather than indicating an error, - this result code is used to indicate that the server does not hold - the target entry of the request but is able to provide alternative - servers that may. A set of server(s) URLs may be returned in the - referral field, which the client may subsequently query to attempt to - complete their operation. - -5.1.5 saslBindInProgress(14) - - Applicable operations: Bind. - - This result code is new in LDAPv3. This result code is not an error - response from the server, but rather, is a request for bind - continuation. The server requires the client to send a new bind - request, with the same SASL mechanism, to continue the authentication - process [RFC2251, Section 4.2.3]. - -5.2 Description of Error Codes - - General error codes (see Section 5.2.1) are typically returned only - when no suitable specific error exists. Specific error codes (see - Section 5.2.2) are meant to capture situations that are specific to - the requested operation. - -5.2.1 General Error Codes - - A general error code typically specifies an error condition for which - there is no suitable specific error code. If the server can return an - error, which is more specific than the following general errors, then - the specific error should be returned instead. - -5.2.1.1 other(80) - - Applicable operations: all. - - This error code should be returned only if no other error code is - suitable. Use of this error code should be avoided if possible. - Details of the error should be provided in the error message. - -5.2.2 Specific Error Codes - - Specific errors are used to indicate that a particular type of error - has occurred. These error types are Name, Update, Attribute, - Security, and Service. - -5.2.2.1 Attribute Problem Error Codes - -Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 7 - - - LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000 - - - An attribute error reports a problem related to an attribute - specified by the client in their request message. - -5.2.2.1.1 noSuchAttribute(16) - - Applicable operations: Modify, Compare. - - This error may be returned if the attribute specified as an argument - of the operation does not exist in the entry. - -5.2.2.1.2 undefinedAttributeType(17) - - Applicable operations: Modify, Add. - - This error may be returned if the specified attribute is unrecognized - by the server, since it is not present in the serverÆs defined - schema. If the server doesnÆt recognize an attribute specified in a - search request as the attribute to be returned the server should not - return an error in this case - it should just return values for the - requested attributes it does recognize. Note that this result code - only applies to the Add and Modify operations [X.511, Section 12.4]. - -5.2.2.1.3 inappropriateMatching(18) - - Applicable operations: Search. - - An attempt was made, e.g., in a filter, to use a matching rule not - defined for the attribute type concerned [X511, Section 12.4]. - -5.2.2.1.4 constraintViolation(19) - - Applicable operations: Modify, Add, ModifyDN. - - This error should be returned by the server if an attribute value - specified by the client violates the constraints placed on the - attribute as it was defined in the DSA - this may be a size - constraint or a constraint on the content. - -5.2.2.1.5 attributeOrValueExists(20) - - Applicable operations: Modify, Add. - - This error should be returned by the server if the value specified by - the client already exists within the attribute. - -5.2.2.1.6 invalidAttributeSyntax(21) - - Applicable operations: Modify, Add. - - This error should be returned by the server if the attribute syntax - for the attribute value, specified as an argument of the operation, - is unrecognized or invalid. - - -Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 8 - - - LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000 - -5.2.2.2 NameProblem Error Codes - - A name error reports a problem related to the distinguished name - provided as an argument to an operation [X511, Section 12.5]. - - For result codes of noSuchObject, aliasProblem, invalidDNSyntax and - aliasDereferencingProblem (see Section 5.2.2.3.7), the matchedDN - field is set to the name of the lowest entry (object or alias) in the - directory that was matched. If no aliases were dereferenced while - attempting to locate the entry, this will be a truncated form of the - name provided, or if aliases were dereferenced, of the resulting - name, as defined in section 12.5 of X.511 [X511]. The matchedDN field - is to be set to a zero length string with all other result codes - [RFC2251, Section 4.1.10]. - -5.2.2.2.1 noSuchObject(32) - - Applicable operations: all except for Bind. - - This error should only be returned if the target object cannot be - found. For example, in a search operation if the search base can not - be located in the DSA the server should return noSuchObject. If, - however, the search base is found but does not match the search - filter, success, with no resultant objects, should be returned - instead of noSuchObject. - - If the LDAP server is a front end for an X.500 DSA then noSuchObject - may also be returned if discloseOnError is not granted for an entry - and the client does not have permission to view or modify the entry. - -5.2.2.2.2 aliasProblem(33) - - Applicable operations: Search. - - An alias has been dereferenced which names no object [X511, Section - 12.5]. - -5.2.2.2.3 invalidDNSyntax(34) - - Applicable operations: all. - - This error should be returned by the server if the DN syntax is - incorrect. It should not be returned if the DN is correctly formed - but represents an entry which is not permitted by the structure rules - at the DSA; in this case namingViolation should be returned instead. - -5.2.2.3 SecurityProblem Error Codes - - A security error reports a problem in carrying out an operation for - security reasons [X511, Section 12.7]. - -5.2.2.3.1 authMethodNotSupported(7) - - Applicable operations: Bind. - -Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 9 - - - LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000 - - - This error code should be returned if the client requests, in a Bind - request, an authentication method which is not supported or - recognized by the server. - -5.2.2.3.2 strongAuthRequired(8) - - Applicable operations: all. - - This error may be returned on a bind request if the server only - accepts strong authentication or it may be returned when a client - attempts an operation which requires the client to be strongly - authenticated - for example Delete. - - This result code may also be returned in an unsolicited notice of - disconnection if the server detects that an established underlying - security association protecting communication between the client and - server has unexpectedly failed or been compromised. [RFC2251, Section - 4.4.1] - -5.2.2.3.3 confidentialityRequired(13) - - Applicable operations: all. - - This error code is new in LDAPv3. This error code may be returned if - the session is not protected by a protocol which provides session - confidentiality. For example, if the client did not establish a TLS - connection using a cipher suite which provides confidentiality of the - session before sending any other requests, and the server requires - session confidentiality then the server may reject that request with - a result code of confidentialityRequired. - -5.2.2.3.4 aliasDereferencingProblem(36) - - Applicable operations: Search. - - An alias was encountered in a situation where it was not allowed or - where access was denied [X511, Section 12.5]. For example, if the - client does not have read permission for the aliasedObjectName - attribute and its value then the error aliasDereferencingProblem - should be returned. [X511, Section 7.11.1.1] - - Notice that this error has similar meaning to - insufficientAccessRights(50) (see Section 5.2.2.3.7), but is specific - to Searching on an alias. - - (See note at start of Section 5.2.2.2 regarding this error code.) - -5.2.2.3.5 inappropriateAuthentication(48) - - Applicable operations: Bind. - - This error should be returned by the server when the client has tried - to use a method of authentication that is inappropriate, that is a - -Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 10 - - - LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000 - - method of authentication which the client is unable to use correctly. - In other words, the level of security associated with the requestorÆs - credentials is inconsistent with the level of protection requested, - e.g. simple credentials were supplied while strong credentials were - required [X511, Section 12.7]. - -5.2.2.3.6 invalidCredentials(49) - - Applicable operations: Bind. - - This error code is returned if the DN or password used in a simple - bind operation is incorrect, or if the DN or password is incorrect - for some other reason, e.g. the password has expired. This result - code only applies to Bind operations -- it should not be returned for - other operations if the client does not have sufficient permission to - perform the requested operation - in this case the return code should - be insufficientAccessRights. - -5.2.2.3.7 insufficientAccessRights(50) - - Applicable operations: all except for Bind. - - The requestor does not have the right to carry out the requested - operation [X511, Section 12.7]. Note that the more specific - aliasDereferencingProblem (see Section 5.2.2.3.4) is returned in case - of a Search on an alias where the requestor has - insufficientAccessRights. - -5.2.2.4 ServiceProblem Error Codes - - A service error reports a problem related to the provision of the - service [X511, Section 12.8]. - -5.2.2.4.1 operationsError(1) - - Applicable operations: all except Bind. - - If the server requires that the client bind before browsing or - modifying the directory, the server MAY reject a request other than - binding, unbinding or an extended request with the "operationsError" - result. [RFC2251, Section 4.2.1] - -5.2.2.4.2 protocolError(2) - - Applicable operations: all. - - A protocol error should be returned by the server when an invalid or - malformed request is received from the client. This may be a request - that is not recognized as an LDAP request, for example, if a - nonexistent operation were specified in LDAPMessage. As well, it may - be the result of a request that is missing a required parameter, such - as a search filter in a search request. If the server can return an - error, which is more specific than protocolError, then this error - should be returned instead. For example if the server does not - -Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 11 - - - LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000 - - recognize the authentication method requested by the client then the - error authMethodNotSupported should be returned instead of - protocolError. The server may return details of the error in the - error string. - -5.2.2.4.3 timeLimitExceeded(3) - - Applicable operations: all. - - This error should be returned when the time to perform an operation - has exceeded either the time limit specified by the client (which may - only be set by the client in a search operation) or the limit - specified by the server. If the time limit is exceeded on a search - operation then the result is an arbitrary selection of the - accumulated results [X511, Section 7.5]. Note that an arbitrary - selection of results may mean that no results are returned to the - client. - - If the LDAP server is a front end for an X.500 server, any operation - that is chained may exceed the timelimit, therefore clients can - expect to receive timelimitExceeded for all operations. For stand - alone LDAP-Servers that do not implement chaining it is unlikely that - operations other than search operations will exceed the defined - timelimit. - -5.2.2.4.4 sizeLimitExceeded(4) - - Applicable operations: Search. - - This error should be returned when the number of results generated by - a search exceeds the maximum number of results specified by either - the client or the server. If the size limit is exceeded then the - results of a search operation will be an arbitrary selection of the - accumulated results, equal in number to the size limit [X511, Section - 7.5]. - -5.2.2.4.5 adminLimitExceeded(11) - - Applicable operations: all. - - This error code is new in LDAPv3. The server has reached some limit - set by an administrative authority, and no partial results are - available to return to the user [X511, Section 12.8]. For example, - there may be an administrative limit to the number of entries a - server will check when gathering potential search result candidates - [Net]. - -5.2.2.4.6 unavailableCriticalExtension(12) - - Applicable operations: all. - - This error code is new in LDAPv3. The server was unable to satisfy - the request because one or more critical extensions were not - available [X511, Section 12.8]. This error is returned, for example, - -Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 12 - - - LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000 - - when a control submitted with a request is marked critical but is not - recognized by a server or when such a control is not appropriate for - the operation type. [RFC2251 section 4.1.12]. - -5.2.2.4.7 busy(51) - - Applicable operations: all. - - This error code may be returned if the server is unable to process - the clientÆs request at this time. This implies that if the client - retries the request shortly the server will be able to process it - then. - -5.2.2.4.8 unavailable(52) - - Applicable operations: all. - - This error code is returned when the server is unavailable to process - the clientÆs request. This usually means that the LDAP server is - shutting down [RFC2251, Section 4.2.3]. - -5.2.2.4.9 unwillingToPerform(53) - - Applicable operations: all. - - This error code should be returned by the server when a client - request is properly formed but which the server is unable to complete - due to server-defined restrictions. For example, the server, or some - part of it, is not prepared to execute this request, e.g. because it - would lead to excessive consumption of resources or violates the - policy of an Administrative Authority involved [X511, Section 12.8]. - If the server is able to return a more specific error code such as - adminLimitExceeded it should. This error may also be returned if the - client attempts to modify attributes which can not be modified by - users, e.g., operational attributes such as creatorsName or - createTimestamp [X511, Section 7.12]. If appropriate, details of the - error should be provided in the error message. - -5.2.2.4.10 loopDetect(54) - - Applicable operations: all. - - This error may be returned by the server if it detects an alias or - referral loop, and is unable to satisfy the clientÆs request. - -5.2.2.5 UpdateProblem Error Codes - - An update error reports problems related to attempts to add, delete, - or modify information in the DIB [X511, Section 12.9]. - -5.2.2.5.1 namingViolation(64) - - Applicable operations: Add, ModifyDN. - - -Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 13 - - - LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000 - - The attempted addition or modification would violate the structure - rules of the DIT as defined in the directory schema and X.501. That - is, it would place an entry as the subordinate of an alias entry, or - in a region of the DIT not permitted to a member of its object class, - or would define an RDN for an entry to include a forbidden attribute - type [X511, Section 12.9]. - -5.2.2.5.2 objectClassViolation(65) - - Applicable operations: Modify, Add, ModifyDN. - - This error should be returned if the operation requested by the user - would violate the objectClass requirements for the entry if carried - out. On an add or modify operation this would result from trying to - add an object class without a required attribute, or by trying to add - an attribute which is not permitted by the current object class set - in the entry. On a modify operation this may result from trying to - remove a required attribute without removing the associated auxiliary - object class, or by attempting to remove an object class while the - attributes it permits are still present. - -5.2.2.5.3 notAllowedOnNonLeaf(66) - - Applicable operations: Delete, ModifyDN. - - This operation should be returned if the client attempts to perform - an operation which is permitted only on leaf entries - e.g., if the - client attempts to delete a non-leaf entry. If the directory does - not permit ModifyDN for non-leaf entries then this error may be - returned if the client attempts to change the DN of a non-leaf entry. - (Note that 1988 edition X.500 servers only permitted change of the - RDN of an entry's DN [X.511, Section 11.4.1]). - -5.2.2.5.4 notAllowedOnRDN(67) - - Applicable operations: Modify. - - The attempted operation would affect the RDN (e.g., removal of an - attribute which is a part of the RDN) [X511, Section 12.9]. If the - client attempts to remove from an entry any of its distinguished - values, those values which form the entry's relative distinguished - name the server should return the error notAllowedOnRDN. [RFC2251, - Section 4.6] - -5.2.2.5.5 entryAlreadyExists(68) - - Applicable operations: Add, ModifyDN. - - This error should be returned by the server when the client attempts - to add an entry which already exists, or if the client attempts to - rename an entry with the name of an entry which exists. - -5.2.2.5.6 objectClassModsProhibited(69) - - -Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 14 - - - LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000 - - Applicable operations: Modify. - - An operation attempted to modify an object class that should not be - modified, e.g., the structural object class of an entry. Some - servers may not permit object class modifications, especially - modifications to the structural object class since this may change - the entry entirely, name forms, structure rules etc. [X.511, Section - 12.9]. - -5.2.2.5.7 affectsMultipleDSAs(71) - - Applicable operations: ModifyDN. - - This error code is new for LDAPv3. This error code should be returned - to indicate that the operation could not be performed since it - affects more than one DSA. - - X.500 restricts the ModifyDN operation to only affect entries that - are contained within a single server. If the LDAP server is mapped - onto DAP, then this restriction will apply, and the resultCode - affectsMultipleDSAs will be returned if this error occurred. In - general clients MUST NOT expect to be able to perform arbitrary - movements of entries and subtrees between servers [RFC2251, Section - 4.9]. - -6 LDAP Operations - - LDAP v3 [RFC2251] defines the following LDAPMessage for conveyance of - the intended operation request from the client to the server. - - LDAPMessage ::= SEQUENCE { - messageID MessageID, - protocolOp CHOICE { - bindRequest BindRequest, - bindResponse BindResponse, - unbindRequest UnbindRequest, - searchRequest SearchRequest, - searchResEntry SearchResultEntry, - searchResDone SearchResultDone, - searchResRef SearchResultReference, - modifyRequest ModifyRequest, - modifyResponse ModifyResponse, - addRequest AddRequest, - addResponse AddResponse, - delRequest DelRequest, - delResponse DelResponse, - modDNRequest ModifyDNRequest, - modDNResponse ModifyDNResponse, - compareRequest CompareRequest, - compareResponse CompareResponse, - abandonRequest AbandonRequest, - extendedReq ExtendedRequest, - extendedResp ExtendedResponse }, - controls [0] Controls OPTIONAL } - -Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 15 - - - LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000 - - - MessageID ::= INTEGER (0 .. maxInt) - - maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) - - - Starting in Section 6.2, behaviour regarding the return of each - result code is specified for each operation. Section 6.1 indicates - those result codes that are typically applicable to all operations. - -6.1 Common Result Codes - - The following result codes are applicable to, and may be returned in - response to all operations (except where stated otherwise). - -6.1.1 Non-erroneous results - - For all but a Compare operation, a success(0) result code will be - returned in the case that the requested operation succeeds; a - compareTrue would be returned for a Compare operation. For each - operation, the server may return referral(10), as defined in Section - 5.1.4. - -6.1.2 Security Errors - - Of the six possible security errors, two may be returned in response - to every operation. These two errors are strongAuthRequired(8) and - confidentialityRequired(13). - -6.1.3 Service Errors - - All service errors, except operationsError(1), and - sizeLimitExceeded(4) may be returned in response to any LDAP v3 - operation. operationsError(1) is applicable to all operations except - Bind. sizeLimitExceeded is only applicable to the Search operation. - -6.1.4 General Errors - - The general error other(80)is applicable to all operations. - -6.2 Bind Operation Errors - - If the bind operation succeeds then a result code of success will be - returned to the client. If the server does not hold the target entry - of the request, a referral(10) may be returned. If the operation - fails then the result code will be one of the following from the set - of non-erroneous result, name errors, security errors, service - errors, and general errors. - - If the server does not support the client's requested protocol - version, it MUST set the resultCode to protocolError. - If the client receives a BindResponse response where the resultCode - was protocolError, it MUST close the connection as the server will be - unwilling to accept further operations. (This is for compatibility - - -Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 16 - - - LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000 - - with earlier versions of LDAP, in which the bind was always the first - operation, and there was no negotiation.) [RFC2251, Section 5.2.3] - - The remaining errors listed in this section are operation-specific. - An operation may also result in the return of any of the common - errors, as listed in Section 6.1. - -6.2.1 Non-erroneous results - - In addition to success or referral, the following non-erroneous - result code may be returned: - - saslBindInProgress: the server requires the client to send a new bind - request, with the same sasl mechanism, to continue the authentication - process, - -6.2.2 Name Errors - - invalidDNSyntax: the DN provided does not have the correct syntax, - -6.2.3 Security Errors - - As stated in Section 6.1.2, strongAuthRequired(8) and - confidentialityRequired(13) may be returned for any operation. - - authMethodNotSupported: unrecognized SASL mechanism name, - - inappropriateAuthentication: the server requires the client which had - attempted to bind anonymously or without supplying credentials to - provide some form of credentials, - - invalidCredentials: the wrong password was supplied or the SASL - credentials could not be processed, [RFC2251, Section 4.2.3] - -6.3 Search Operation Errors - - X.500 provides three separate operations for searching the directory - - Read of a single entry, List of an entryÆs children and search of - an entire sub-tree. LDAP provides a single search operation, however - the X.500 operations can be simulated by using base, one-level and - sub-tree scope restrictions respectively. - - If the Search operation succeeds then zero or more search entries - will be returned followed by a search result of success. If the - server does not hold the target entry of the request, a referral(10) - may be returned. If the search operation fails then zero or more - search entries will be returned followed by a search result - containing one of the following result codes from the set of name - errors, attribute errors, security errors, service errors, and - general errors. - - The remaining errors listed in this section are operation-specific. - An operation may also result in the return of any of the common - errors, as listed in Section 6.1. - -Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 17 - - - LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000 - - -6.3.1 Name Errors - - noSuchObject: the base object, for the search, does not exist. - - aliasProblem: an alias was dereferenced which named no object. - - invalidDNSyntax: the DN provided for the search base does not have - the correct syntax, - -6.3.2 Attribute Errors - - inappropriateMatching: an attempt was made to use a matching rule not - defined for an attribute in the search filter. - -6.3.3 Security Errors - - As stated in Section 6.1.2, strongAuthRequired(8) and - confidentialityRequired(13) may be returned for any operation. - - aliasDereferenceProblem: The client does not have permission for the - aliasedObjectName attribute or to search the dereferenced alias - object. - - insufficientAccessRights: The requestor does not have sufficient - permissions to perform the search. aliasDereferenceProblem should be - returned in this case, if applicable. - -6.3.4 Service Errors - - In addition to the common service errors indicated in Section 6.1.3, - the following service error may also be returned: - - sizeLimitExceeded: the number of search results exceeds the size - limit specified by the client or the server. If the server has - defined a maximum PDU size, this error may also be returned if the - size of the combined results exceeds this limit. - -6.4 Modify Operation Errors - - The Modify operation cannot be used to remove from an entry any of - its distinguished values, those values that form the entry's relative - distinguished name. An attempt to do so will result in the server - returning the error notAllowedOnRDN. The Modify DN Operation - described in section 5.9 is used to rename an entry. [RFC2251, - Section 4.6] - - If the modify operation succeeds, a result code of success will be - returned to the client. If the server does not hold the target entry - of the request, a referral(10) may be returned. If the operation - fails, the result code will be one of the following from the set of - name errors, update errors, attribute errors, security errors, - service errors, and general errors. - - -Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 18 - - - LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000 - - The remaining errors listed in this section, are operation-specific. - An operation may also result in the return of any of the common - errors, as listed in Section 6.1. - -6.4.1 Name Errors - - noSuchObject: the target object does not exist. - - invalidDNSyntax: the DN provided does not have the correct syntax, - -6.4.2 Update Errors - - objectClassViolation: An attempt was made to modify an object which - is illegal according to its object class definition in the schema or - DIT content rules for that object class. - - notAllowedOnRDN: An attempt was made to modify the object entryÆs - distinguished name - - objectClassModsProhibited: The modification attempted to change an - entryÆs object class which is not allowed. - -6.4.3 Attribute Errors - - noSuchAttribute: the attribute to be modified does not exist in the - target entry. - - undefinedAttributeType: The attribute specified does not exist in the - server's defined schema. - - constraintViolation: The modification would create an attribute value - outside the normal bounds. - - attributeOrValueExists: The modification would create a value which - already exists within the attribute. - - invalidAttributeSyntax: The value specified doesnÆt adhere to the - syntax definition for that attribute. - -6.4.4 Security Errors - - As stated in Section 6.1.2, strongAuthRequired(8) and - confidentialityRequired(13) may be returned for any operation. - - insufficientAccessRights: The requestor does not have sufficient - permissions to modify the entry. - -6.5 Add Operation Errors - - The superior of the entry must exist for the operation to succeed. If - not, a noSuchObject error is returned and the matchedDN field will - contain the name of the lowest entry in the directory that was - matched. - - -Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 19 - - - LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000 - - If the add operation succeeds, a result code of success will be - returned to the client. If the server does not hold the target entry - of the request, a referral(10) may be returned. If the operation - fails, the result code will be one of the following from the set of - name errors, update errors, attribute errors, security errors, - service errors, and general errors. - - The remaining errors listed in this section, are operation-specific. - An operation may also result in the return of any of the common - errors, as listed in Section 6.1. - -6.5.1 Name Errors - - noSuchObject: One or more superiors to the target entry do not exist. - - invalidDNSyntax: the DN provided does not have the correct syntax, - -6.5.2 Update Errors - - namingViolation: Either the target entry cannot be created under the - specified superior due to DIT structure rules, or the target entry is - named by an RDN not permitted by the DIT name form rule for its - object class. - - objectClassViolation: An attempt was made to add an entry and one of - the following conditions existed: A required attribute was not - specified; an attribute was specified which is not permitted by the - current object class set in the entry; a structural object class - value was not specified; an object class value was specified that - doesnÆt exist in the schema. - - entryAlreadyExists: The target entry already exists. - -6.5.3 Attribute Errors - - undefinedAttributeType: The attribute specified does not exist in the - server's defined schema. - - constraintViolation: The attribute value falls outside the bounds - specified by the attribute syntax. - - attributeOrValueExists: A duplicate attribute value appears in the - list of attributes for the entry. - - invalidAttributeSyntax: The value specified doesnÆt adhere to the - syntax definition for that attribute. - -6.5.4 Security Errors - - As stated in Section 6.1.2, strongAuthRequired(8) and - confidentialityRequired(13) may be returned for any operation. - - - - -Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 20 - - - LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000 - - insufficientAccessRights: The requestor does not have sufficient - permissions to either add the entry or to add one or more of the - attributes specified. - -6.6 Delete Operation Errors - - If the delete operation succeeds, a result code of success will be - returned to the client. If the server does not hold the target entry - of the request, a referral(10) may be returned. If the operation - fails, the result code will be one of the following from the set of - name errors, update errors, security errors, service errors, and - general errors. - - The remaining errors listed in this section, are operation-specific. - An operation may also result in the return of any of the common - errors, as listed in Section 6.1. - -6.6.1 Name Errors - - noSuchObject: The target entry does not exist. - - invalidDNSyntax: the DN provided does not have the correct syntax, - -6.6.2 Update Errors - - notAllowedOnNonLeaf: The target entry is not a leaf object. Only - objects having no subordinate objects in the tree may be deleted. - -6.6.3 Security Errors - - As stated in Section 6.1.2, strongAuthRequired(8) and - confidentialityRequired(13) may be returned for any operation. - - insufficientAccessRights: The requestor does not have sufficient - permissions to delete the entry. - -6.7 ModifyDN Operation Errors - - Note that X.500 restricts the ModifyDN operation to only affect - entries that are contained within a single server. If the LDAP server - is mapped onto DAP, then this restriction will apply, and the - resultCode affectsMultipleDSAs will be returned if this error - occurred. In general clients MUST NOT expect to be able to perform - arbitrary movements of entries and subtrees between servers. - [RFC2251, Section 4.9] - - If the Modify DN operation succeeds then a result code of success - will be returned to the client. If the server does not hold the - target entry of the request, a referral(10) may be returned. If the - operation fails then the result code will be one of the following - from the set of name errors, update errors, attribute errors, - security errors, service errors, and general errors. - - - -Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 21 - - - LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000 - - The remaining errors listed in this section, are operation-specific. - An operation may also result in the return of any of the common - errors, as listed in Section 6.1. - -6.7.1 Name Errors - - noSuchObject: the target object does not exist or a new superior - object was specified that does not exist. - - invalidDNSyntax: the DN provided does not have the correct syntax. - -6.7.2 Update Errors - - namingViolation: Either the target entry cannot be moved to the - specified superior due to DIT structure rules, or the target entry is - named by an RDN not permitted by the DIT name form rule for its - object class. - - objectClassViolation: The client has specified that the old RDN - values should be removed from the entry (using the 'deleteOldRdn' - parameter) but the removal of these values would violate the entry's - schema. [RFC 2251 Section 4.9] - - notAllowedOnNonLeaf: If the server does not permit the ModifyDN - operation on non-leaf entries this error will be returned if the - client attempts to rename a non-leaf entry - - entryAlreadyExists: The target entry already exists. - - AffectsMultipleDSAs: X.500 restricts the ModifyDN operation to only - affect entries that are contained within a single server. If the LDAP - server is mapped onto DAP, then this restriction will apply, and the - resultCode affectsMultipleDSAs will be returned if this error - occurred. In general clients MUST NOT expect to be able to perform - arbitrary movements of entries and sub-trees between servers. - [RFC2251, Section 4.9] - -6.7.3 Attribute Errors - - constraintViolation: The operation would create an attribute value - outside the normal bounds. - -6.7.4 Security Errors - - As stated in Section 6.1.2, strongAuthRequired(8) and - confidentialityRequired(13) may be returned for any operation. - - insufficientAccessRights: The requestor does not have sufficient - permissions to either add the entry or to add one or more of the - attributes specified. - -6.8 Compare Operation Errors - - - -Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 22 - - - LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000 - - If there exists a value within the attribute being compared that - matches the purported argument and for which compare permissions is - granted, the operation returns the value compareTrue in the result, - otherwise, the operation returns compareFalse. [X511, Section 9.2.4] - If the server does not hold the target entry of the request, a - referral(10) may be returned. - - If the compare operation can not be completed, then the server may - return one of the following results from the set of name errors, - attribute errors, security errors, service errors, and general - errors. - - The remaining errors listed in this section are operation-specific. - An operation may also result in the return of any of the common - errors, as listed in Section 6.1. - -6.8.1 Name Errors - - noSuchObject: the entry to be compared does not exist in the - directory. - - invalidDNSyntax: the DN provided for the entry to be compared does - not have the correct syntax. - -6.8.2 Attribute Errors - - noSuchAttribute: the attribute to be compared does not exist in the - target entry. - - invalidAttributeSyntax: The value specified doesnÆt adhere to the - syntax definition for that attribute. - -6.8.3 Security Errors - - As stated in Section 6.1.2, strongAuthRequired(8) and - confidentialityRequired(13) may be returned for any operation. - - insufficientAccessRights: If the client does not have read permission - for the entry to be compared, or for the attribute then - insufficientAccessRights should be returned, [X511, Section 9.2.4] - -6.8.4 Example - - The following example is included to demonstrate the expected - responses for the compare operation. - Given the following entry: - - dn: cn=Foo - objectClass: top - objectClass: person - sn: bar - userPassword: xyz - - - -Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 23 - - - LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000 - - i) Compare with userPassword=xyz results in a compareTrue because the - requested value exists in the entry. - - ii) Compare with userPassword=abc results in a compareFalse because - the entry contains a userPassword attribute but the value abc is not - present. - - iii) Compare with telephoneNumber=123-456-7890 results in a - noSuchAttribute. The attribute telephoneNumber is permissible in the - entry based on the schema defined in the server but because it is - empty it does not exist in the target entry. - - iv) Compare with ou=myOrg results in noSuchAttribute. The requested - attribute is a recognized attribute but it is neither present nor is - it valid for the target entry. - - v) Compare with bogusAttr=abc results in noSuchAttribute. The - requested attribute is not a recognized attribute nor is it present - in the target entry. - - Note that the response for scenarios 3 through 5 is always - noSuchAttribute. The semantics of the compare operation is simply - "does the target entry contain the specified value?" and so no - distinction is made between a request for an unknown, invalid, or, - valid but empty attribute. In all cases if the attribute is not - present in the entry then the result is noSuchAttribute. - -6.9 Extended Operation Errors - - The results returned for an extended operation vary, depending on the - particular operation. In any case, extended Operations MAY return any - result code (excepting 81-90). - - If the server does not recognize the request name, it MUST return - only the response fields from LDAPResult, containing the - protocolError result code [RFC2251, Section 4.12] - -6.10 Operations with no Server Response - - The LDAP v3 protocol has two client operations for which no server - response is returned. Specifically, these are unbindRequest, and - abandonRequest. Since no response is returned, there is no need to - consider possible result codes for these operations. - -6.11 Unsolicited Notification - - In some situations, a server may issue a "response" to a client for - which there was no client request. This notification "is used to - signal an extraordinary condition in the server or in the connection - between the client and the server. The notification is of an - advisory nature, and the server will not expect any response to be - returned from the client." [RFC2251, Section 4.4] - - - -Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 24 - - - LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000 - - RFC 2251 [RFC2251] describes a notice of disconnection in which a - protocolError, strongAuthRequired, or unavailable result code may be - returned. The reader is directed there for further information. - -6.12 Controls - - Section 4.1.12 of [RFC2251] specifies the syntax for controls that - may be sent as part of a request. [RFC2251] defines no specific - controls. It should be noted that the semantics of a control may - alter the result code that might otherwise have been returned for the - requested operation (see Section 5.2.2.4.6 for example). - -7. Security Considerations - - This draft is meant to complement and enhance the coverage of result - codes for LDAP v3, as described in RFC 2251 [RFC2251]. Section 7 of - RFC 2251 [RFC2251] lists a number of security considerations specific - to LDAP v3. - - Note that in X.500 if the discloseOnError permission is not granted - then many operations will return noSuchObject instead of a more - specific error. As there is currently no equivalent for this - permission in LDAP, LDAP-only servers should return the appropriate - error code in the event of an error. - -8. References - - [RFC2026] S. Bradner, "The Internet Standards Process - Revision - 3", RFC 2026, October 1996. - - [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate - Requirement Levels", RFC 2119, March 1997. - - [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory - Access Protocol", RFC 2251, December 1997. - - [X511] ITU-T Recommendation X.511, "The Directory: Abstract - Service Definition", 1993. - - [TLS] J. Hodges, R.L. Morgan, M. Wahl, "Lightweight Directory - Access Protocol (v3): Extension for Transport Layer - Security", June 1999. "work in progress" - - [Net] Netscape Directory SDK 3.0 for C ProgrammerÆs Guide, - Chapter 19: Result Codes. Available at Error! Bookmark - not defined. - - -9. Acknowledgments - - The production of this document relied heavily on the information - available from RFC 2251 [RFC2251] and ITU-T Recommendation X.511 - [X511]. - -Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 25 - - - LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000 - - -10. Author's Addresses - - Mike Just - Entrust Technologies - 750 Heron Rd, Tower E - Ottawa, Ontario, Canada - mike.just@entrust.com - - Kristianne Leclair - Entrust Technologies - 750 Heron Rd, Tower E - Ottawa, Ontario, Canada - kristianne.leclair@entrust.com - - Jim Sermersheim - Novell - 122 East 1700 South - Provo, Utah 84606, USA - Error! Bookmark not defined. - - Mark Smith - Netscape - 501 Ellis Street - Mountain View, CA 94043 - Error! Bookmark not defined. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 26 - - - LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000 - - -11 Appendix A: Operation/Response Matrix - - - Result Codes Operations - - B S M A D M C - i e o d e o o - n a d d l d m - d r i e D p - c f t N a - h y e r - e - - Non-erroneous results - - success (0) X X X X X X - - compareFalse (5) X - - compareTrue (6) X - - referral (10) X X X X X X X - - saslBindInProgress (14) X - - Name errors - - noSuchObject (32) X X X X X X - - aliasProblem (33) X - - invalidDNSyntax (34) X X X X X X X - - Update errors - - namingViolation (64) X X - - objectClassViolation (65) X X X - - notAllowedOnNonLeaf (66) X X - - notAllowedonRDN (67) X - - entryAlreadyExists (68) X X - - objectClassModesProhibite X - d (69) - - affectsMultipleDSAs (71) X - - Attribute errors - - noSuchAttribute(16) X X - - undefinedAttributeType X X - (17) - - inappropriateMatching X - (18) - - constraintViolation (19) X X X - - attributeOrValueExists X X - (20) - - invalidAttributeSyntax X X - (21) - - Security errors - - authMethodNotSupported X - (7) - - strongAuthRequired (8) X X X X X X X - - confidentialityRequred(13 X X X X X X X - ) - - aliasDereferencingProblem X - (36) - - inappropriateAuthenticati X - on (48) - - - -Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 27 - - - LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000 - - - invalidCredentials (49) X - - insufficientAccessRights X X X X X X - (50) - - Service errors - - operationsError (1) X X X X X X - - protocolError (2) X X X X X X X - - timeLimitExceeded (3) X X X X X X X - - sizeLimitExceeded (4) X - - adminLimitExceeded (11) X X X X X X X - - unavailableCriticialExten X X X X X X X - sion (12) - - busy (51) X X X X X X X - - unavailable (52) X X X X X X X - - unwillingToPerform (53) X X X X X X X - - loopDetect (54) X X X X X X X - - General errors - - other (80) X X X X X X X - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 28 - - - LDAPv3 Result Codes: Definitions and Appropriate Use Apr, 2000 - - -12 Full Copyright Statement - - Copyright (C) The Internet Society (Oct 1999). All Rights Reserved. - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET - ENGINEERINGTASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDINGBUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATIONHEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Just, Leclair, Sermersheim, Smith INTERNET-DRAFT 29 -