+++ /dev/null
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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
- <URL:ftp://ftp.ietf.org/internet-drafts/draft-good-ldap-ldif-06.txt>
-
- [2] Wahl, M., Howes, T., Kille, S., "Lightweight Directory Access
- Protocol (v3)", RFC 2251 Critical Angle, Inc., Netscape Communications Corp.,
- ISODE Consortium, July, 1997,
- <URL:ftp://ftp.isi.edu/in-notes/rfc2251.txt>
-
- [3] S. Bradner, "Key Words for use in RFCs to Indicate Requirement
- Levels", Harvard University, RFC 2119, March 1997,
- <URL:http://ds.internic.net/rfc/rfc2119.txt>
-
-
-Author's Address
-
- Gordon Good
- Netscape Communications Corp.
- 501 E. Middlefield Rd.
- Mailstop MV068
-
-
-
-Good March 9, 2000 [Page 7]
-\f
-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]
-\f
+++ /dev/null
-
-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
- <draft-ietf-asid-ldapv3-attributes-03.txt>
-
-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]
-\f
-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 <oid>, <DirectoryStrings> and <DirectoryString>
- are given in sections 4.2.1.
-
- <AttributeTypeDescription> ::= "("
- <oid> -- AttributeType identifier
- [ "NAME" <DirectoryStrings> ] -- name used in AttributeType
- [ "DESC" <DirectoryString> ]
- [ "OBSOLETE" ]
- [ "SUP" <oid> ] -- derived from this other AttributeType
- [ "EQUALITY" <oid> ] -- Matching Rule name
- [ "ORDERING" <oid> ] -- Matching Rule name
- [ "SUBSTR" <oid> ] -- Matching Rule name
- [ "SYNTAX" <DirectoryString> ] -- see section 4.2
- [ "SINGLE-VALUE" ] -- default multi-valued
- [ "COLLECTIVE" ] -- default not collective
- [ "NO-USER-MODIFICATION" ] -- default user modifiable
- [ "USAGE" <AttributeUsage> ] -- default user applications
- ")"
-
- <AttributeUsage> ::=
- "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]
-\f
-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> ::= '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'
-
- <d> ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'
-
- <hex-digit> ::= <d> | 'a' | 'b' | 'c' | 'd' | 'e' | 'f' |
- 'A' | 'B' | 'C' | 'D' | 'E' | 'F'
-
- <k> ::= <a> | <d> | '-'
-
- <p> ::= <a> | <d> | ''' | '(' | ')' | '+' | ',' | '-' | '.' |
- '/' | ':' | '?' | ' '
-
- <letterstring> ::= <a> | <a> <letterstring>
-
- <numericstring> ::= <d> | <d> <numericstring>
-
- <keystring> ::= <a> | <a> <anhstring>
-
- <anhstring> ::= <k> | <k> <anhstring>
-
-Wahl, Coulbeck, Howes & Kille [Page 3]
-\f
-INTERNET-DRAFT LDAP Standard and Pilot Attributes October 1996
-
- <printablestring> ::= <p> | <p> <printablestring>
-
- <space> ::= ' ' | ' ' <space>
-
- <whsp> ::= <space> | empty
-
- <utf8> ::= any sequence of octets formed from the UTF-8 [11]
- transformation of a character from ISO 10646 [12]
-
- <dstring> ::= <utf8> | <utf8> <dstring>
-
- <DirectoryStrings> ::= <DirectoryString> | '(' <DirectoryStringList> ')'
-
- <DirectoryStringList> ::= <DirectoryStringList> <DirectoryString> | ""
-
- <DirectoryString> ::= ''' <dstring> '''
-
- <oids> ::= <oid> | '(' <oidlist> ')'
-
- <oidlist> ::= <oidlist> '$' <oid> | <oid>
-
- -- <oid> 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]
-\f
-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:
-
- <ObjectClassDescription> ::= "("
- <oid> -- ObjectClass identifier
- [ "NAME" <DirectoryStrings> ]
- [ "DESC" <DirectoryString> ]
- [ "OBSOLETE" ]
- [ "SUP" <oids> ] -- Superior ObjectClasses
- [ ( "ABSTRACT" | "STRUCTURAL" | "AUXILIARY" ) ] -- default structural
- [ "MUST" <oids> ] -- AttributeTypes
- [ "MAY" <oids> ] -- AttributeTypes
- ")"
-
-Wahl, Coulbeck, Howes & Kille [Page 5]
-\f
-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:
-
- <MatchingRuleDescription> ::= "("
- <oid> -- MatchingRule identifier
- [ "NAME" <DirectoryStrings> ]
- [ "DESC" <DirectoryString> ]
- [ "OBSOLETE" ]
- "SYNTAX" <DirectoryString>
- ")"
-
- 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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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:
-
- <bitstring> ::= ''' <binary-digits> ''B'
-
- <binary-digits> ::= '0' <binary-digits> | '1' <binary-digits> |
- 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 <p> 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]
-\f
-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.
-
- <CountryString> ::= <p> <p>
-
-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:
-
- <delivery-value> ::= <pdm> | <pdm> '$' <delivery-value>
-
- <pdm> ::= '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:
-
- <EnhancedGuide> ::= <objectclass> '#' <criteria> '#' <subset>
-
- <subset> ::= "baseobject" | "oneLevel" | "wholeSubtree"
-
-
-
-Wahl, Coulbeck, Howes & Kille [Page 17]
-\f
-INTERNET-DRAFT LDAP Standard and Pilot Attributes October 1996
-
- The <criteria> 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:
-
- <fax-number> ::= <printablestring> [ '$' <faxparameters> ]
-
- <faxparameters> ::= <faxparm> | <faxparm> '$' <faxparameters>
-
- <faxparm> ::= 'twoDimensional' | 'fineResolution' | 'unlimitedLength' |
- 'b4Length' | 'a3Width' | 'b4Width' | 'uncompressed'
-
- In the above, the first <printablestring> is the actual fax number,
- and the <faxparm> tokens represent fax parameters.
-
-5.2.1.12. Guide
-
- Values with the Guide syntax are encoded according to the following
- BNF:
-
- <guide-value> ::= [ <object-class> '#' ] <criteria>
-
- <object-class> ::= an encoded value with OID syntax
-
- <criteria> ::= <criteria-item> | <criteria-set> | '!' <criteria>
-
- <criteria-set> ::= [ '(' ] <criteria> '&' <criteria-set> [ ')' ] |
- [ '(' ] <criteria> '|' <criteria-set> [ ')' ]
-
- <criteria-item> ::= [ '(' ] <attributetype> '$' <match-type> [ ')' ]
-
- <match-type> ::= "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:
-
- <NameAndOptionalUID> ::=
- <DistinguishedName> [ '#' <BitString> ]
-
- 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]
-\f
-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:
-
- <oid> ::= <descr> | <numericoid>
-
- <descr> ::= <keystring>
-
- <numericoid> ::= <numericstring> | <numericstring> '.' <numericoid>
-
- In the above BNF, <descr> 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:
-
- <postal-address> ::= <dstring> | <dstring> '$' <postal-address>
-
- In the above, each <dstring> 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]
-\f
-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:
-
- <teletex-id> ::= <ttx-term> 0*('$' <ttx-param>)
-
- <ttx-term> ::= <printablestring>
-
- <ttx-param> ::= <ttx-key> ':' <ttx-value>
-
- <ttx-key> ::= 'graphic' | 'control' | 'misc' | 'page' | 'private'
-
- <ttx-value> ::= <octetstring>
-
- In the above, the first <printablestring> is the encoding of the
- first portion of the teletex terminal identifier to be encoded, and
- the subsequent 0 or more <octetstrings> 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:
-
- <telex-number> ::= <actual-number> '$' <country> '$' <answerback>
-
- <actual-number> ::= <printablestring>
-
- <country> ::= <printablestring>
-
- <answerback> ::= <printablestring>
-
- In the above, <actual-number> is the syntactic representation of the
- number portion of the TELEX number being encoded, <country> is the
- TELEX country code, and <answerback> 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:
-
- <boolean> ::= "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]
-\f
-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:
-
- <DsaQualitySyntax> ::= <DSAKeyword> [ '#' <description> ]
-
- <DSAKeyword> ::= 'DEFUNCT' | 'EXPERIMENTAL' | 'BEST-EFFORT' |
- 'PILOT-SERVICE' | 'FULL-SERVICE'
-
- <description> ::= encoded as a PrintableString
-
-5.2.2.3. DataQualitySyntax
-
- Values with this syntax are encoded according to the following BNF:
-
- <DataQualitySyntax> ::= <compKeyword> '#' <attrQuality> '#'
- <listQuality> [ '#' <description> ]
-
- <attrQuality> ::= <levelKeyword> '+' <compKeyword>
-
- <listQuality> ::= <list> '$' <list><listQuality>
-
- <list> ::= <attribute> '+' <attrQuality>
-
- <compKeyword> ::= 'NONE' | 'SAMPLE' | 'SELECTED' |
- 'SUBSTANTIAL' | 'FULL'
-
- <levelKeyword> ::= '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]
-\f
-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:
-
- <mail-preference> ::= "NO-LISTS" | "ANY-LIST" | "PROFESSIONAL-LISTS"
-
-5.2.2.7. OtherMailbox
-
- Values of the OtherMailbox syntax are encoded according to the
- following BNF:
-
- <otherMailbox> ::= <mailbox-type> '$' <mailbox>
-
- <mailbox-type> ::= an encoded Printable String
-
- <mailbox> ::= an encoded IA5 String
-
- In the above, <mailbox-type> represents the type of mail system in
- which the mailbox resides, for example "MCIMail"; and <mailbox> is the
- actual mailbox in the mail system defined by <mailbox-type>.
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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:
-
- <AccessPoint> ::= ( '(' <DistinguishedName> '#'
- <PresentationAddress> ')' ) |
- -- Optional protocol info absent, parenthesis required
- ( '(' <DistinguishedName> '#'
- <PresentationAddress> '#'
- <SetOfProtocolInformation ')' )
-
- <SetOfProtocolInformation> ::= <ProtocolInformation> |
- '(' <ProtocolInformationList> ')'
-
- <ProtocolInformationList> ::= <ProtocolInformation> |
- <ProtocolInformation> '$'
- <ProtocolInformationList>
-
-6.2.1.3. DITContentRuleDescription
-
- Values with this syntax are encoded according to the following BNF:
-
- <DITContentRuleDescription> ::= "("
- <oid> -- Structural ObjectClass identifier
- [ "NAME" <DirectoryStrings> ]
- [ "DESC" <DirectoryString> ]
- [ "OBSOLETE" ]
- [ "AUX" <oids> ] -- Auxiliary ObjectClasses
- [ "MUST" <oids> ] -- AttributeType identifiers
- [ "MAY" <oids> ] -- AttributeType identifiers
- [ "NOT" <oids> ] -- AttributeType identifiers
- ")"
-
-
-
-
-
-
-Wahl, Coulbeck, Howes & Kille [Page 30]
-\f
-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:
-
- <DITStructureRuleDescription> ::= "("
- <RuleIdentifier> -- DITStructureRule identifier
- [ "NAME" <DirectoryStrings> ]
- [ "DESC" <DirectoryString> ]
- [ "OBSOLETE" ]
- "FORM" <oid> -- NameForm
- [ "SUP" <RuleIdentifiers> ] -- superior DITStructureRules
- ")"
-
- <RuleIdentifier> ::= <integer>
-
- <RuleIdentifiers> ::=
- <RuleIdentifier> |
- "(" <RuleIdentifierList> ")"
-
- <RuleIdentifierList> ::=
- <RuleIdentifierList> <RuleIdentifier>
- |
- -- empty list
-
-6.2.1.5. DSEType
-
- Values with DSEType syntax are encoded according to the following BNF:
-
- <DSEType> ::= '(' <DSEBitList> ')'
-
- <DSEBitList> ::= <DSEBit> | <DSEBit> '$' <DSEBitList>
-
- <DSEBit> ::= '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:
-
- <MasterAndShadowAccessPoints> ::= <MasterOrShadowAccessPoint> |
- '(' <MasterAndShadowAccessPointList ')'
-
- <MasterAndShadowAccessPointList> ::= <MasterOrShadowAccessPoint> |
- <MasterOrShadowAccessPoint> '$' <MasterAndShadowAccessPointList>
-
- <MasterOrShadowAccessPoint> ::= <category> '#' <AccessPoint>
-
- <category> ::= '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]
-\f
-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:
-
- <MatchingRuleUseDescription> ::= "("
- <oid> -- MatchingRule identifier
- [ "NAME" <DirectoryStrings> ]
- [ "DESC" <DirectoryString> ]
- [ "OBSOLETE" ]
- "APPLIES" <oids> -- AttributeType identifiers
- ")"
-
-6.2.1.9. NameFormDescription
-
- Values of this syntax are encoded according to the following BNF:
-
- <NameFormDescription> ::= "("
- <oid> -- NameForm identifier
- [ "NAME" <DirectoryStrings> ]
- [ "DESC" <DirectoryString> ]
- [ "OBSOLETE" ]
- "OC" <oid> -- Structural ObjectClass
- "MUST" <oids> -- AttributeTypes
- [ "MAY" <oids> ] -- AttributeTypes
- ")"
-
-6.2.1.10. SubtreeSpecification
-
- Values of this syntax are encoded according to the following BNF:
-
- <SubtreeSpecification> ::= '(' [<localname>] '#'
- [<exclusionlist>] '#'
- [<minimum>] '#' [<maximum>] '#'
- [<refinement>] ')'
-
- <localname> ::= <DistinguishedName>
-
- <exclusionlist> ::= '(' <exclusions> ')'
-
- <exclusions> ::= <exclusion> | <exclusion> '$' <exclusionlist>
-
- <exclusion> ::= ( 'before ' <DistinguishedName> ) |
- ( 'after ' <DistinguishedName> )
-
- <minimum> ::= <numericstring>
-
- <maximum> ::= <numericstring>
-
- <refinement> ::= <oid> | '!' <refinement> |
- '( &' <refinements> ')' |
- '( |' <refinements> ')'
-
- <refinements> ::= <refinement> | <refinement> '$' <refinements>
-
-Wahl, Coulbeck, Howes & Kille [Page 32]
-\f
-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:
-
- <SupplierInformation> ::=
- -- supplier is master --
- '(' 'master' '#' <SupplierOrConsumer> ')' |
-
- -- supplier is not master, master unspecified --
- '(' 'shadow' '#' <SupplierOrConsumer> ')' |
-
- -- supplier not master, master specified --
- ['('] 'shadow' '#' <SupplierOrConsumer> '#' <AccessPoint> [')']
-
-6.2.1.12. SupplierOrConsumer
-
- Values of this syntax are encoded according to the following BNF:
-
- <SupplierOrConsumer> ::= <Agreement> '#' <AccessPoint>
-
- <Agreement> ::= <bindingid> '.' <bindingversion>
-
- <bindingid> ::= <numericstring>
-
- <bindingversion> ::= <numericstring>
-
-6.2.1.13. SupplierAndConsumers
-
- Values of this syntax are encoded according to the following BNF:
-
- <SupplierAndConsumers> ::= <Supplier> '#' <Consumers>
-
- <Suppliers> ::= <AccessPoint>
-
- <Consumers> ::= <AccessPoint> | '(' <AccessPointList> ')'
-
- <AccessPointList> ::= <AccessPoint> |
- <AccessPoint> '$' <AccessPointList>
-
-6.2.1.14. ProtocolInformation
-
- A value with the ProtocolInformation syntax is encoded according to the
- following BNF:
-
- <ProtocolInformation> ::= <NetworkAddress> <space> '#'
- <SetOfProtocolIdentifier>
-
- <NetworkAddress> ::= As appears in PresentationAddress
-
- <SetOfProtocolIdentifiers> ::= <ProtocolIdentifier> |
- '(' <ProtocolIdentifiers> ')'
-
-
-
-Wahl, Coulbeck, Howes & Kille [Page 33]
-\f
-INTERNET-DRAFT LDAP Standard and Pilot Attributes October 1996
-
- <ProtocolIdentifiers> ::= <ProtocolIdentifier> |
- <ProtocolIdentifier> '$' <ProtocolIdentifiers>
-
- <ProtocolIdentifier> ::= <oid>
-
- 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:
-
- <ModifyRight> ::= [<perm-list>] <octo> <item>
- -- perm list is absent when none of the bits set in permission
-
- <item> ::= <entry> | <attribute> | <value>
-
- <entry> ::= 'entry'
-
- <attribute> ::= 'attribute' <dollar> <attributetype>
-
- <value> ::= 'value' <dollar> <attributetype> <dollar> <strvalue>
-
- -- <strvalue> is the string encoding of the value
-
- <perm-list> ::= <perm> | <perm> <dollar> <perm-list>
- -- one or more of the bits in permission, if set
-
- <perm> ::= 'add' | 'remove' | 'rename' | 'move'
-
- <octo> ::= [ <whsp> ] '#' [ <whsp> ]
-
- <dollar> ::= [ <whsp> ] '$' [ <whsp> ]
-
-
-
-
-
-
-
-Wahl, Coulbeck, Howes & Kille [Page 34]
-\f
-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]
-\f
-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:
-
- <dlsubmit-perm> ::= <dlgroup_label> ':' <dlgroup-value>
- | <dl-label> ':' <dl-value>
-
- <dlgroup-label> ::= 'group_member'
-
- <dlgroup-value> ::= <name>
-
- <name> ::= an encoded Distinguished Name
-
- <dl-label> ::= 'individual' | 'dl_member' | 'pattern'
-
- <dl-value> ::= <orname>
-
-
-
-Wahl, Coulbeck, Howes & Kille [Page 36]
-\f
-INTERNET-DRAFT LDAP Standard and Pilot Attributes October 1996
-
- <orname> ::= <address> '#' <dn>
- | <address>
-
- <address> ::= <add-label> ':' <oraddress>
-
- <dn> ::= <dn-label> ':' <name>
-
- <add-label> = 'X400'
-
- <dn-label> = 'X500'
-
- where <oraddress> 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]
-\f
-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]
-\f
-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 <draft-ietf-asid-ldapv3-protocol-03.txt>,
- 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 <draft-ietf-asid-ldapv3-dn-00.txt>, 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.
-
-
-
-
-
-
-
-
-<draft-ietf-asid-ldapv3-attributes-03.txt>
-Expires: April 1997
-Wahl, Coulbeck, Howes & Kille [Page 39]
+++ /dev/null
-
-Internet Draft Mike Just, Entrust
- K. Leclair, Entrust
- Jim Sermersheim, Novell
- Mark Smith, Netscape
-Document: <draft-just-ldapv3-rescodes-02.txt> April, 2000
-Category: Standards Track
-
-
- LDAPv3 Result Codes: Definitions and Appropriate Use
- <draft-just-ldapv3-rescodes-02.txt>
-
-
-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. <draft-ietf-ldapext-ldapv3-tls-
- 05.txt> "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
-
projects / openldap / commitdiff