From 6bd5c856529984b35c7a8afdb4254acdf018d44f Mon Sep 17 00:00:00 2001
From: Kurt Zeilenga <kurt@openldap.org>
Date: Tue, 4 Apr 2006 03:12:37 +0000
Subject: [PATCH] Sync with HEAD
---
doc/drafts/draft-ietf-ldapbis-protocol-xx.txt | 7418 ++++++++---------
.../draft-zeilenga-ldap-dontusecopy-xx.txt | 24 +-
.../draft-zeilenga-ldap-grouping-xx.txt | 843 --
.../draft-zeilenga-ldap-managedit-xx.txt | 675 ++
doc/drafts/draft-zeilenga-ldap-noop-xx.txt | 18 +-
doc/drafts/draft-zeilenga-ldap-txn-xx.txt | 512 +-
doc/rfc/INDEX | 1 +
doc/rfc/rfc4403.txt | 2355 ++++++
8 files changed, 7073 insertions(+), 4773 deletions(-)
delete mode 100644 doc/drafts/draft-zeilenga-ldap-grouping-xx.txt
create mode 100644 doc/drafts/draft-zeilenga-ldap-managedit-xx.txt
create mode 100644 doc/rfc/rfc4403.txt
diff --git a/doc/drafts/draft-ietf-ldapbis-protocol-xx.txt b/doc/drafts/draft-ietf-ldapbis-protocol-xx.txt
index a04954d258..575f1dc529 100644
--- a/doc/drafts/draft-ietf-ldapbis-protocol-xx.txt
+++ b/doc/drafts/draft-ietf-ldapbis-protocol-xx.txt
@@ -1,3709 +1,3709 @@
-
-
-Internet-Draft Editor: J. Sermersheim
-Intended Category: Standard Track Novell, Inc
-Document: draft-ietf-ldapbis-protocol-32.txt Oct 2005
-Obsoletes: RFCs 2251, 2830, 3771
-
-
- LDAP: The Protocol
-
-
-Status of this Memo
-
- By submitting this Internet-Draft, each
- author represents that any applicable patent or other IPR claims of
- which he or she is aware have been or will be disclosed, and any of
- which he or she becomes aware will be disclosed, in accordance with
- Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress".
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire in February 2005.
-
- Technical discussion of this document will take place on the IETF
- LDAP Revision Working Group (LDAPbis) mailing list <ietf-
- ldapbis@openldap.org>. Please send editorial comments directly to the
- editor <jimse@novell.com>.
-
-
-Abstract
-
- This document describes the protocol elements, along with their
- semantics and encodings, of the Lightweight Directory Access Protocol
- (LDAP). LDAP provides access to distributed directory services that
- act in accordance with X.500 data and service models. These protocol
- elements are based on those described in the X.500 Directory Access
- Protocol (DAP).
-
-
-Table of Contents
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 1
- Lightweight Directory Access Protocol Version 3
-
- 1. Introduction....................................................3
- 1.1. Relationship to Other LDAP Specifications.....................3
- 2. Conventions.....................................................3
- 3. Protocol Model..................................................4
- 3.1 Operation and LDAP Message Layer Relationship..................5
- 4. Elements of Protocol............................................5
- 4.1. Common Elements...............................................5
- 4.1.1. Message Envelope............................................5
- 4.1.2. String Types................................................7
- 4.1.3. Distinguished Name and Relative Distinguished Name..........7
- 4.1.4. Attribute Descriptions......................................8
- 4.1.5. Attribute Value.............................................8
- 4.1.6. Attribute Value Assertion...................................8
- 4.1.7. Attribute and PartialAttribute..............................9
- 4.1.8. Matching Rule Identifier....................................9
- 4.1.9. Result Message..............................................9
- 4.1.10. Referral..................................................11
- 4.1.11. Controls..................................................13
- 4.2. Bind Operation...............................................14
- 4.3. Unbind Operation.............................................17
- 4.4. Unsolicited Notification.....................................17
- 4.5. Search Operation.............................................18
- 4.6. Modify Operation.............................................29
- 4.7. Add Operation................................................31
- 4.8. Delete Operation.............................................31
- 4.9. Modify DN Operation..........................................32
- 4.10. Compare Operation...........................................33
- 4.11. Abandon Operation...........................................34
- 4.12. Extended Operation..........................................35
- 4.13. IntermediateResponse Message................................36
- 4.14. StartTLS Operation..........................................37
- 5. Protocol Encoding, Connection, and Transfer....................39
- 5.1. Protocol Encoding............................................39
- 5.2. Transmission Control Protocol (TCP)..........................40
- 5.3. Termination of the LDAP session..............................40
- 6. Security Considerations........................................40
- 7. Acknowledgements...............................................42
- 8. Normative References...........................................42
- 9. Informative References.........................................44
- 10. IANA Considerations...........................................44
- 11. Editor's Address..............................................45
- Appendix A - LDAP Result Codes....................................46
- A.1 Non-Error Result Codes........................................46
- A.2 Result Codes..................................................46
- Appendix B - Complete ASN.1 Definition............................51
- Appendix C - Changes..............................................57
- C.1 Changes made to RFC 2251:.....................................57
- C.2 Changes made to RFC 2830:.....................................62
- C.3 Changes made to RFC 3771:.....................................63
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 2
- Lightweight Directory Access Protocol Version 3
-
-1. Introduction
-
- The Directory is "a collection of open systems cooperating to provide
- directory services" [X.500]. A directory user, which may be a human
- or other entity, accesses the Directory through a client (or
- Directory User Agent (DUA)). The client, on behalf of the directory
- user, interacts with one or more servers (or Directory System Agents
- (DSA)). Clients interact with servers using a directory access
- protocol.
-
- This document details the protocol elements of the Lightweight
- Directory Access Protocol (LDAP), along with their semantics.
- Following the description of protocol elements, it describes the way
- in which the protocol elements are encoded and transferred.
-
-
-1.1. Relationship to Other LDAP Specifications
-
- This document is an integral part of the LDAP Technical Specification
- [Roadmap] which obsoletes the previously defined LDAP technical
- specification, RFC 3377, in its entirety.
-
- This document, together with [Roadmap], [AuthMeth], and [Models],
- obsoletes RFC 2251 in its entirety. Section 3.3 is obsoleted by
- [Roadmap]. Sections 4.2.1 (portions), and 4.2.2 are obsoleted by
- [AuthMeth]. Sections 3.2, 3.4, 4.1.3 (last paragraph), 4.1.4, 4.1.5,
- 4.1.5.1, 4.1.9 (last paragraph), 5.1, 6.1, and 6.2 (last paragraph)
- are obsoleted by [Models]. The remainder of RFC 2251 is obsoleted by
- this document. Appendix C.1 summarizes substantive changes in the
- remainder.
-
- This document obsoletes RFC 2830, Sections 2 and 4. The remainder of
- RFC 2830 is obsoleted by [AuthMeth]. Appendix C.2 summarizes
- substantive changes to the remaining sections.
-
- This document also obsoletes RFC 3771 in entirety.
-
-
-2. Conventions
-
- 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 [Keyword].
-
- Character names in this document use the notation for code points and
- names from the Unicode Standard [Unicode]. For example, the letter
- "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
-
- Note: a glossary of terms used in Unicode can be found in [Glossary].
- Information on the Unicode character encoding model can be found in
- [CharModel].
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 3
- Lightweight Directory Access Protocol Version 3
-
- The term "transport connection" refers to the underlying transport
- services used to carry the protocol exchange, as well as associations
- established by these services.
-
- The term "TLS layer" refers to TLS services used in providing
- security services, as well as associations established by these
- services.
-
- The term "SASL layer" refers to SASL services used in providing
- security services, as well as associations established by these
- services.
-
- The term "LDAP message layer" refers to the LDAP Message Protocol
- Data Unit (PDU) services used in providing directory services, as
- well as associations established by these services.
-
- The term "LDAP session" refers to combined services (transport
- connection, TLS layer, SASL layer, LDAP message layer) and their
- associations.
-
- See the table in Section 5 for an illustration of these four terms.
-
-
-3. Protocol Model
-
- The general model adopted by this protocol is one of clients
- performing protocol operations against servers. In this model, a
- client transmits a protocol request describing the operation to be
- performed to a server. The server is then responsible for performing
- the necessary operation(s) in the Directory. Upon completion of an
- operation, the server typically returns a response containing
- appropriate data to the requesting client.
-
- Protocol operations are generally independent of one another. Each
- operation is processed as an atomic action, leaving the directory in
- a consistent state.
-
- Although servers are required to return responses whenever such
- responses are defined in the protocol, there is no requirement for
- synchronous behavior on the part of either clients or servers.
- Requests and responses for multiple operations generally may be
- exchanged between a client and server in any order. If required,
- synchronous behavior may be controlled by client applications.
-
- The core protocol operations defined in this document can be mapped
- to a subset of the X.500 (1993) Directory Abstract Service [X.511].
- However there is not a one-to-one mapping between LDAP operations and
- X.500 Directory Access Protocol (DAP) operations. Server
- implementations acting as a gateway to X.500 directories may need to
- make multiple DAP requests to service a single LDAP request.
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 4
- Lightweight Directory Access Protocol Version 3
-
-
-3.1. Operation and LDAP Message Layer Relationship
-
- Protocol operations are exchanged at the LDAP message layer. When the
- transport connection is closed, any uncompleted operations at the
- LDAP message layer, when possible, are abandoned, and when not
- possible, are completed without transmission of the response. Also,
- when the transport connection is closed, the client MUST NOT assume
- that any uncompleted update operations have succeeded or failed.
-
-
-4. Elements of Protocol
-
- The protocol is described using Abstract Syntax Notation One
- ([ASN.1]), and is transferred using a subset of ASN.1 Basic Encoding
- Rules ([BER]). Section 5 specifies how the protocol elements are
- encoded and transferred.
-
- In order to support future extensions to this protocol, extensibility
- is implied where it is allowed per ASN.1 (i.e. sequence, set, choice,
- and enumerated types are extensible). In addition, ellipses (...)
- have been supplied in ASN.1 types that are explicitly extensible as
- discussed in [LDAPIANA]. Because of the implied extensibility,
- clients and servers MUST (unless otherwise specified) ignore trailing
- SEQUENCE components whose tags they do not recognize.
-
- Changes to the protocol other than through the extension mechanisms
- described here require a different version number. A client indicates
- the version it is using as part of the BindRequest, described in
- Section 4.2. If a client has not sent a Bind, the server MUST assume
- the client is using version 3 or later.
-
- Clients may attempt to determine the protocol versions a server
- supports by reading the 'supportedLDAPVersion' attribute from the
- root DSE (DSA-Specific Entry) [Models].
-
-
-4.1. Common Elements
-
- This section describes the LDAPMessage envelope Protocol Data Unit
- (PDU) format, as well as data type definitions, which are used in the
- protocol operations.
-
-
-4.1.1. Message Envelope
-
- For the purposes of protocol exchanges, all protocol operations are
- encapsulated in a common envelope, the LDAPMessage, which is defined
- as follows:
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 5
- Lightweight Directory Access Protocol Version 3
-
- 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,
- ...,
- intermediateResponse IntermediateResponse },
- controls [0] Controls OPTIONAL }
-
- MessageID ::= INTEGER (0 .. maxInt)
-
- maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
-
- The ASN.1 type Controls is defined in Section 4.1.11.
-
- The function of the LDAPMessage is to provide an envelope containing
- common fields required in all protocol exchanges. At this time the
- only common fields are the messageID and the controls.
-
- If the server receives an LDAPMessage from the client in which the
- LDAPMessage SEQUENCE tag cannot be recognized, the messageID cannot
- be parsed, the tag of the protocolOp is not recognized as a request,
- or the encoding structures or lengths of data fields are found to be
- incorrect, then the server SHOULD return the Notice of Disconnection
- described in Section 4.4.1, with the resultCode set to protocolError,
- and MUST immediately terminate the LDAP session as described in
- Section 5.3.
-
- In other cases where the client or server cannot parse an LDAP PDU,
- it SHOULD abruptly terminate the LDAP session (Section 5.3) where
- further communication (including providing notice) would be
- pernicious. Otherwise, server implementations MUST return an
- appropriate response to the request, with the resultCode set to
- protocolError.
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 6
- Lightweight Directory Access Protocol Version 3
-
-4.1.1.1. Message ID
-
- All LDAPMessage envelopes encapsulating responses contain the
- messageID value of the corresponding request LDAPMessage.
-
- The message ID of a request MUST have a non-zero value different from
- the messageID of any other request in progress in the same LDAP
- session. The zero value is reserved for the unsolicited notification
- message.
-
- Typical clients increment a counter for each request.
-
- A client MUST NOT send a request with the same message ID as an
- earlier request in the same LDAP session unless it can be determined
- that the server is no longer servicing the earlier request (e.g.
- after the final response is received, or a subsequent Bind
- completes). Otherwise the behavior is undefined. For this purpose,
- note that Abandon and successfully abandoned operations do not send
- responses.
-
-
-4.1.2. String Types
-
- The LDAPString is a notational convenience to indicate that, although
- strings of LDAPString type encode as ASN.1 OCTET STRING types, the
- [ISO10646] character set (a superset of [Unicode]) is used, encoded
- following the [UTF-8] algorithm. Note that Unicode characters U+0000
- through U+007F are the same as ASCII 0 through 127, respectively, and
- have the same single octet UTF-8 encoding. Other Unicode characters
- have a multiple octet UTF-8 encoding.
-
- LDAPString ::= OCTET STRING -- UTF-8 encoded,
- -- [ISO10646] characters
-
- The LDAPOID is a notational convenience to indicate that the
- permitted value of this string is a (UTF-8 encoded) dotted-decimal
- representation of an OBJECT IDENTIFIER. Although an LDAPOID is
- encoded as an OCTET STRING, values are limited to the definition of
- <numericoid> given in Section 1.4 of [Models].
-
- LDAPOID ::= OCTET STRING -- Constrained to <numericoid> [Models]
-
- For example,
-
- 1.3.6.1.4.1.1466.1.2.3
-
-
-4.1.3. Distinguished Name and Relative Distinguished Name
-
- An LDAPDN is defined to be the representation of a Distinguished Name
- (DN) after encoding according to the specification in [LDAPDN].
-
- LDAPDN ::= LDAPString
- -- Constrained to <distinguishedName> [LDAPDN]
-
-Sermersheim Internet-Draft - Expires April 2006 Page 7
- Lightweight Directory Access Protocol Version 3
-
-
- A RelativeLDAPDN is defined to be the representation of a Relative
- Distinguished Name (RDN) after encoding according to the
- specification in [LDAPDN].
-
- RelativeLDAPDN ::= LDAPString
- -- Constrained to <name-component> [LDAPDN]
-
-
-4.1.4. Attribute Descriptions
-
- The definition and encoding rules for attribute descriptions are
- defined in Section 2.5 of [Models]. Briefly, an attribute description
- is an attribute type and zero or more options.
-
- AttributeDescription ::= LDAPString
- -- Constrained to <attributedescription>
- -- [Models]
-
-
-4.1.5. Attribute Value
-
- A field of type AttributeValue is an OCTET STRING containing an
- encoded attribute value. The attribute value is encoded according to
- the LDAP-specific encoding definition of its corresponding syntax.
- The LDAP-specific encoding definitions for different syntaxes and
- attribute types may be found in other documents and in particular
- [Syntaxes].
-
- AttributeValue ::= OCTET STRING
-
- Note that there is no defined limit on the size of this encoding;
- thus protocol values may include multi-megabyte attribute values
- (e.g. photographs).
-
- Attribute values may be defined which have arbitrary and non-
- printable syntax. Implementations MUST NOT display nor attempt to
- decode an attribute value if its syntax is not known. The
- implementation may attempt to discover the subschema of the source
- entry, and retrieve the descriptions of 'attributeTypes' from it
- [Models].
-
- Clients MUST only send attribute values in a request that are valid
- according to the syntax defined for the attributes.
-
-
-4.1.6. Attribute Value Assertion
-
- The AttributeValueAssertion (AVA) type definition is similar to the
- one in the X.500 Directory standards. It contains an attribute
- description and a matching rule ([Models] Section 4.1.3) assertion
- value suitable for that type. Elements of this type are typically
- used to assert that the value in assertionValue matches a value of an
- attribute.
-
-Sermersheim Internet-Draft - Expires April 2006 Page 8
- Lightweight Directory Access Protocol Version 3
-
-
- AttributeValueAssertion ::= SEQUENCE {
- attributeDesc AttributeDescription,
- assertionValue AssertionValue }
-
- AssertionValue ::= OCTET STRING
-
- The syntax of the AssertionValue depends on the context of the LDAP
- operation being performed. For example, the syntax of the EQUALITY
- matching rule for an attribute is used when performing a Compare
- operation. Often this is the same syntax used for values of the
- attribute type, but in some cases the assertion syntax differs from
- the value syntax. See objectIdentiferFirstComponentMatch in
- [Syntaxes] for an example.
-
-
-4.1.7. Attribute and PartialAttribute
-
- Attributes and partial attributes consist of an attribute description
- and attribute values. A PartialAttribute allows zero values, while
- Attribute requires at least one value.
-
- PartialAttribute ::= SEQUENCE {
- type AttributeDescription,
- vals SET OF value AttributeValue }
-
- Attribute ::= PartialAttribute(WITH COMPONENTS {
- ...,
- vals (SIZE(1..MAX))})
-
- No two of the attribute values may be equivalent as described by
- Section 2.3 of [Models]. The set of attribute values is unordered.
- Implementations MUST NOT rely upon the ordering being repeatable.
-
-
-4.1.8. Matching Rule Identifier
-
- Matching rules are defined in Section 4.1.3 of [Models]. A matching
- rule is identified in the protocol by the printable representation of
- either its <numericoid>, or one of its short name descriptors
- [Models], e.g. 'caseIgnoreMatch' or '2.5.13.2'.
-
- MatchingRuleId ::= LDAPString
-
-
-4.1.9. Result Message
-
- The LDAPResult is the construct used in this protocol to return
- success or failure indications from servers to clients. To various
- requests, servers will return responses containing the elements found
- in LDAPResult to indicate the final status of the protocol operation
- request.
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 9
- Lightweight Directory Access Protocol Version 3
-
- LDAPResult ::= SEQUENCE {
- resultCode ENUMERATED {
- success (0),
- operationsError (1),
- protocolError (2),
- timeLimitExceeded (3),
- sizeLimitExceeded (4),
- compareFalse (5),
- compareTrue (6),
- authMethodNotSupported (7),
- strongerAuthRequired (8),
- -- 9 reserved --
- referral (10),
- adminLimitExceeded (11),
- unavailableCriticalExtension (12),
- confidentialityRequired (13),
- saslBindInProgress (14),
- 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),
- objectClassModsProhibited (69),
- -- 70 reserved for CLDAP --
- affectsMultipleDSAs (71),
- -- 72-79 unused --
- other (80),
- ... },
- matchedDN LDAPDN,
- diagnosticMessage LDAPString,
- referral [3] Referral OPTIONAL }
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 10
- Lightweight Directory Access Protocol Version 3
-
- The resultCode enumeration is extensible as defined in Section 3.6 of
- [LDAPIANA]. The meanings of the listed result codes are given in
- Appendix A. If a server detects multiple errors for an operation,
- only one result code is returned. The server should return the result
- code that best indicates the nature of the error encountered. Servers
- may return substituted result codes to prevent unauthorized
- disclosures.
-
- The diagnosticMessage field of this construct may, at the server's
- option, be used to return a string containing a textual, human-
- readable (terminal control and page formatting characters should be
- avoided) diagnostic message. As this diagnostic message is not
- standardized, implementations MUST NOT rely on the values returned.
- Diagnostic messages typically supplement the resultCode with
- additional information. If the server chooses not to return a textual
- diagnostic, the diagnosticMessage field MUST be empty.
-
- For certain result codes (typically, but not restricted to
- noSuchObject, aliasProblem, invalidDNSyntax and
- aliasDereferencingProblem), the matchedDN field is set (subject to
- access controls) to the name of the last entry (object or alias) used
- in finding the target (or base) object. This will be a truncated form
- of the provided name or, if an alias was dereferenced while
- attempting to locate the entry, of the resulting name. Otherwise the
- matchedDN field is empty.
-
-
-4.1.10. Referral
-
- The referral result code indicates that the contacted server cannot
- or will not perform the operation and that one or more other servers
- may be able to. Reasons for this include:
-
- - The target entry of the request is not held locally, but the
- server has knowledge of its possible existence elsewhere.
-
- - The operation is restricted on this server -- perhaps due to a
- read-only copy of an entry to be modified.
-
- The referral field is present in an LDAPResult if the resultCode is
- set to referral, and absent with all other result codes. It contains
- one or more references to one or more servers or services that may be
- accessed via LDAP or other protocols. Referrals can be returned in
- response to any operation request (except Unbind and Abandon which do
- not have responses). At least one URI MUST be present in the
- Referral.
-
- During a Search operation, after the baseObject is located, and
- entries are being evaluated, the referral is not returned. Instead,
- continuation references, described in Section 4.5.3, are returned
- when other servers would need to be contacted to complete the
- operation.
-
- Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI
-
-Sermersheim Internet-Draft - Expires April 2006 Page 11
- Lightweight Directory Access Protocol Version 3
-
-
- URI ::= LDAPString -- limited to characters permitted in
- -- URIs
-
- If the client wishes to progress the operation, it contacts one of
- the supported services found in the referral. If multiple URIs are
- present, the client assumes that any supported URI may be used to
- progress the operation.
-
- Clients that follow referrals MUST ensure that they do not loop
- between servers. They MUST NOT repeatedly contact the same server for
- the same request with the same parameters. Some clients use a counter
- that is incremented each time referral handling occurs for an
- operation, and these kinds of clients MUST be able to handle at least
- ten nested referrals while progressing the operation.
-
- A URI for a server implementing LDAP and accessible via [TCP]/[IP]
- (v4 or v6) is written as an LDAP URL according to [LDAPURL].
-
- Referral values which are LDAP URLs follow these rules:
-
- - If an alias was dereferenced, the <dn> part of the LDAP URL MUST
- be present, with the new target object name.
-
- - It is RECOMMENDED that the <dn> part be present to avoid
- ambiguity.
-
- - If the <dn> part is present, the client uses this name in its next
- request to progress the operation, and if it is not present the
- client uses the same name as in the original request.
-
- - Some servers (e.g. participating in distributed indexing) may
- provide a different filter in a URL of a referral for a Search
- operation.
-
- - If the <filter> part of the LDAP URL is present, the client uses
- this filter in its next request to progress this Search, and if it
- is not present the client uses the same filter as it used for that
- Search.
-
- - For Search, it is RECOMMENDED that the <scope> part be present to
- avoid ambiguity.
-
- - If the <scope> part is missing, the scope of the original Search
- is used by the client to progress the operation.
-
- - Other aspects of the new request may be the same as or different
- from the request which generated the referral.
-
- Other kinds of URIs may be returned. The syntax and semantics of such
- URIs is left to future specifications. Clients may ignore URIs that
- they do not support.
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 12
- Lightweight Directory Access Protocol Version 3
-
- UTF-8 encoded characters appearing in the string representation of a
- DN, search filter, or other fields of the referral value may not be
- legal for URIs (e.g. spaces) and MUST be escaped using the % method
- in [URI].
-
-
-4.1.11. Controls
-
- Controls provide a mechanism whereby the semantics and arguments of
- existing LDAP operations may be extended. One or more controls may be
- attached to a single LDAP message. A control only affects the
- semantics of the message it is attached to.
-
- Controls sent by clients are termed 'request controls' and those sent
- by servers are termed 'response controls'.
-
- Controls ::= SEQUENCE OF control Control
-
- Control ::= SEQUENCE {
- controlType LDAPOID,
- criticality BOOLEAN DEFAULT FALSE,
- controlValue OCTET STRING OPTIONAL }
-
- The controlType field is the dotted-decimal representation of an
- OBJECT IDENTIFIER which uniquely identifies the control. This
- provides unambiguous naming of controls. Often, response control(s)
- solicited by a request control share controlType values with the
- request control.
-
- The criticality field only has meaning in controls attached to
- request messages (except UnbindRequest). For controls attached to
- response messages and the UnbindRequest, the criticality field SHOULD
- be FALSE, and MUST be ignored by the receiving protocol peer. A value
- of TRUE indicates that it is unacceptable to perform the operation
- without applying the semantics of the control. Specifically, the
- criticality field is applied as follows:
-
- - If the server does not recognize the control type, determines that
- it is not appropriate for the operation, or is otherwise unwilling
- to perform the operation with the control, and the criticality
- field is TRUE, the server MUST NOT perform the operation, and for
- operations that have a response message, MUST return with the
- resultCode set to unavailableCriticalExtension.
-
- - If the server does not recognize the control type, determines that
- it is not appropriate for the operation, or is otherwise unwilling
- to perform the operation with the control, and the criticality
- field is FALSE, the server MUST ignore the control.
-
- - Regardless of criticality, if a control is applied to an
- operation, it is applied consistently and impartially to the
- entire operation.
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 13
- Lightweight Directory Access Protocol Version 3
-
- The controlValue may contain information associated with the
- controlType. Its format is defined by the specification of the
- control. Implementations MUST be prepared to handle arbitrary
- contents of the controlValue octet string, including zero bytes. It
- is absent only if there is no value information which is associated
- with a control of its type. When a controlValue is defined in terms
- of ASN.1, and BER encoded according to Section 5.1, it also follows
- the extensibility rules in Section 4.
-
- Servers list the controlType of request controls they recognize in
- the 'supportedControl' attribute in the root DSE (Section 5.1 of
- [Models]).
-
- Controls SHOULD NOT be combined unless the semantics of the
- combination has been specified. The semantics of control
- combinations, if specified, are generally found in the control
- specification most recently published. When a combination of controls
- is encountered whose semantics are invalid, not specified (or not
- known), the message is considered to be not well-formed, thus the
- operation fails with protocolError. Controls with a criticality of
- FALSE may be ignored in order to arrive at a valid combination.
- Additionally, unless order-dependent semantics are given in a
- specification, the order of a combination of controls in the SEQUENCE
- is ignored. Where the order is to be ignored but cannot be ignored by
- the server, the message is considered not well-formed and the
- operation fails with protocolError. Again, controls with a
- criticality of FALSE may be ignored in order to arrive at a valid
- combination.
-
- This document does not specify any controls. Controls may be
- specified in other documents. Documents detailing control extensions
- are to provide for each control:
-
- - the OBJECT IDENTIFIER assigned to the control,
-
- - direction as to what value the sender should provide for the
- criticality field (note: the semantics of the criticality field
- are defined above should not be altered by the control's
- specification),
-
- - whether the controlValue field is present, and if so, the format
- of its contents,
-
- - the semantics of the control, and
-
- - optionally, semantics regarding the combination of the control
- with other controls.
-
-
-4.2. Bind Operation
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 14
- Lightweight Directory Access Protocol Version 3
-
- The function of the Bind operation is to allow authentication
- information to be exchanged between the client and server. The Bind
- operation should be thought of as the "authenticate" operation.
- Operational, authentication, and security-related semantics of this
- operation are given in [AuthMeth].
-
- The Bind request is defined as follows:
-
- BindRequest ::= [APPLICATION 0] SEQUENCE {
- version INTEGER (1 .. 127),
- name LDAPDN,
- authentication AuthenticationChoice }
-
- AuthenticationChoice ::= CHOICE {
- simple [0] OCTET STRING,
- -- 1 and 2 reserved
- sasl [3] SaslCredentials,
- ... }
-
- SaslCredentials ::= SEQUENCE {
- mechanism LDAPString,
- credentials OCTET STRING OPTIONAL }
-
- Fields of the BindRequest are:
-
- - version: A version number indicating the version of the protocol
- to be used at the LDAP message layer. This document describes
- version 3 of the protocol. There is no version negotiation. The
- client sets this field to the version it desires. If the server
- does not support the specified version, it MUST respond with a
- BindResponse where the resultCode is set to protocolError.
-
- - name: If not empty, the name of the Directory object that the
- client wishes to bind as. This field may take on a null value (a
- zero length string) for the purposes of anonymous binds
- ([AuthMeth] Section 5.1) or when using Simple Authentication and
- Security Layer [SASL] authentication ([AuthMeth] Section 5.2).
- Where the server attempts to locate the named object, it SHALL NOT
- perform alias dereferencing.
-
- - authentication: information used in authentication. This type is
- extensible as defined in Section 3.7 of [LDAPIANA]. Servers that
- do not support a choice supplied by a client return a BindResponse
- with the resultCode set to authMethodNotSupported.
-
- Textual passwords (consisting of a character sequence with a known
- character set and encoding) transferred to the server using the
- simple AuthenticationChoice SHALL be transferred as [UTF-8]
- encoded [Unicode]. Prior to transfer, clients SHOULD prepare text
- passwords as "query" strings by applying the [SASLprep] profile of
- the [Stringprep] algorithm. Passwords consisting of other data
- (such as random octets) MUST NOT be altered. The determination of
- whether a password is textual is a local client matter.
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 15
- Lightweight Directory Access Protocol Version 3
-
-
-4.2.1. Processing of the Bind Request
-
- Before processing a BindRequest, all uncompleted operations MUST
- either complete or be abandoned. The server may either wait for the
- uncompleted operations to complete, or abandon them. The server then
- proceeds to authenticate the client in either a single-step, or
- multi-step Bind process. Each step requires the server to return a
- BindResponse to indicate the status of authentication.
-
- After sending a BindRequest, clients MUST NOT send further LDAP PDUs
- until receiving the BindResponse. Similarly, servers SHOULD NOT
- process or respond to requests received while processing a
- BindRequest.
-
- If the client did not bind before sending a request and receives an
- operationsError to that request, it may then send a BindRequest. If
- this also fails or the client chooses not to bind on the existing
- LDAP session, it may terminate the LDAP session, re-establish it and
- begin again by first sending a BindRequest. This will aid in
- interoperating with servers implementing other versions of LDAP.
-
- Clients may send multiple Bind requests to change the authentication
- and/or security associations or to complete a multi-stage Bind
- process. Authentication from earlier binds is subsequently ignored.
-
- For some SASL authentication mechanisms, it may be necessary for the
- client to invoke the BindRequest multiple times ([AuthMeth] Section
- 5.2). Clients MUST NOT invoke operations between two Bind requests
- made as part of a multi-stage Bind.
-
- A client may abort a SASL bind negotiation by sending a BindRequest
- with a different value in the mechanism field of SaslCredentials, or
- an AuthenticationChoice other than sasl.
-
- If the client sends a BindRequest with the sasl mechanism field as an
- empty string, the server MUST return a BindResponse with the
- resultCode set to authMethodNotSupported. This will allow clients to
- abort a negotiation if it wishes to try again with the same SASL
- mechanism.
-
-
-4.2.2. Bind Response
-
- The Bind response is defined as follows.
-
- BindResponse ::= [APPLICATION 1] SEQUENCE {
- COMPONENTS OF LDAPResult,
- serverSaslCreds [7] OCTET STRING OPTIONAL }
-
- BindResponse consists simply of an indication from the server of the
- status of the client's request for authentication.
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 16
- Lightweight Directory Access Protocol Version 3
-
- A successful Bind operation is indicated by a BindResponse with a
- resultCode set to success. Otherwise, an appropriate result code is
- set in the BindResponse. For BindResponse, the protocolError result
- code may be used to indicate that the version number supplied by the
- client is unsupported.
-
- If the client receives a BindResponse where the resultCode is set to
- protocolError, it is to assume that the server does not support this
- version of LDAP. While the client may be able proceed with another
- version of this protocol (this may or may not require closing and re-
- establishing the transport connection), how to proceed with another
- version of this protocol is beyond the scope of this document.
- Clients which are unable or unwilling to proceed SHOULD terminate the
- LDAP session.
-
- The serverSaslCreds field is used as part of a SASL-defined bind
- mechanism to allow the client to authenticate the server to which it
- is communicating, or to perform "challenge-response" authentication.
- If the client bound with the simple choice, or the SASL mechanism
- does not require the server to return information to the client, then
- this field SHALL NOT be included in the BindResponse.
-
-
-4.3. Unbind Operation
-
- The function of the Unbind operation is to terminate an LDAP session.
- The Unbind operation is not the antithesis of the Bind operation as
- the name implies. The naming of these operations are historical. The
- Unbind operation should be thought of as the "quit" operation.
-
- The Unbind operation is defined as follows:
-
- UnbindRequest ::= [APPLICATION 2] NULL
-
- The client, upon transmission of the UnbindRequest, and the server,
- upon receipt of the UnbindRequest are to gracefully terminate the
- LDAP session as described in Section 5.3.
-
- Uncompleted operations are handled as specified in Section 3.1.
-
-
-4.4. Unsolicited Notification
-
- An unsolicited notification is an LDAPMessage sent from the server to
- the client which is not in response to any LDAPMessage received by
- the server. It is used to signal an extraordinary condition in the
- server or in the LDAP session 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.
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 17
- Lightweight Directory Access Protocol Version 3
-
- The unsolicited notification is structured as an LDAPMessage in which
- the messageID is zero and protocolOp is set to the extendedResp
- choice using the ExtendedResponse type (See Section 4.12). The
- responseName field of the ExtendedResponse always contains an LDAPOID
- which is unique for this notification.
-
- One unsolicited notification (Notice of Disconnection) is defined in
- this document. The specification of an unsolicited notification
- consists of:
-
- - the OBJECT IDENTIFIER assigned to the notification (to be
- specified in the responseName,
-
- - the format of the contents of the responseValue (if any),
-
- - the circumstances which will cause the notification to be sent,
- and
-
- - the semantics of the message.
-
-
-4.4.1. Notice of Disconnection
-
- This notification may be used by the server to advise the client that
- the server is about to terminate the LDAP session on its own
- initiative. This notification is intended to assist clients in
- distinguishing between an exceptional server condition and a
- transient network failure. Note that this notification is not a
- response to an Unbind requested by the client. Uncompleted operations
- are handled as specified in Section 3.1.
-
- The responseName is 1.3.6.1.4.1.1466.20036, the responseValue field
- is absent, and the resultCode is used to indicate the reason for the
- disconnection. When the strongerAuthRequired resultCode is returned
- with this message, it indicates that the server has detected that an
- established security association between the client and server has
- unexpectedly failed or been compromised.
-
- Upon transmission of the Notice of Disconnection, the server
- gracefully terminates the LDAP session as described in Section 5.3.
-
-
-4.5. Search Operation
-
- The Search operation is used to request a server to return, subject
- to access controls and other restrictions, a set of entries matching
- a complex search criterion. This can be used to read attributes from
- a single entry, from entries immediately subordinate to a particular
- entry, or a whole subtree of entries.
-
-
-4.5.1. Search Request
-
- The Search request is defined as follows:
-
-Sermersheim Internet-Draft - Expires April 2006 Page 18
- Lightweight Directory Access Protocol Version 3
-
-
- SearchRequest ::= [APPLICATION 3] SEQUENCE {
- baseObject LDAPDN,
- scope ENUMERATED {
- baseObject (0),
- singleLevel (1),
- wholeSubtree (2),
- ... },
- derefAliases ENUMERATED {
- neverDerefAliases (0),
- derefInSearching (1),
- derefFindingBaseObj (2),
- derefAlways (3) },
- sizeLimit INTEGER (0 .. maxInt),
- timeLimit INTEGER (0 .. maxInt),
- typesOnly BOOLEAN,
- filter Filter,
- attributes AttributeSelection }
-
- AttributeSelection ::= SEQUENCE OF selector LDAPString
- -- The LDAPString is constrained to
- -- <attributeSelector> in Section 4.5.1.7
-
- Filter ::= CHOICE {
- and [0] SET SIZE (1..MAX) OF filter Filter,
- or [1] SET SIZE (1..MAX) OF filter Filter,
- not [2] Filter,
- equalityMatch [3] AttributeValueAssertion,
- substrings [4] SubstringFilter,
- greaterOrEqual [5] AttributeValueAssertion,
- lessOrEqual [6] AttributeValueAssertion,
- present [7] AttributeDescription,
- approxMatch [8] AttributeValueAssertion,
- extensibleMatch [9] MatchingRuleAssertion,
- ... }
-
- SubstringFilter ::= SEQUENCE {
- type AttributeDescription,
- substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE {
- initial [0] AssertionValue, -- can occur at most once
- any [1] AssertionValue,
- final [2] AssertionValue } -- can occur at most once
- }
-
- MatchingRuleAssertion ::= SEQUENCE {
- matchingRule [1] MatchingRuleId OPTIONAL,
- type [2] AttributeDescription OPTIONAL,
- matchValue [3] AssertionValue,
- dnAttributes [4] BOOLEAN DEFAULT FALSE }
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 19
- Lightweight Directory Access Protocol Version 3
-
- Note that an X.500 "list"-like operation can be emulated by the
- client requesting a singleLevel Search operation with a filter
- checking for the presence of the 'objectClass' attribute, and that an
- X.500 "read"-like operation can be emulated by a baseObject Search
- operation with the same filter. A server which provides a gateway to
- X.500 is not required to use the Read or List operations, although it
- may choose to do so, and if it does, it must provide the same
- semantics as the X.500 Search operation.
-
-
-4.5.1.1. SearchRequest.baseObject
-
- The name of the base object entry (or possibly the root) relative to
- which the Search is to be performed.
-
-
-4.5.1.2. SearchRequest.scope
-
- Specifies the scope of the Search to be performed. The semantics (as
- described in [X.511]) of the defined values of this field are:
-
- baseObject: The scope is constrained to the entry named by
- baseObject.
-
- singleLevel: The scope is constrained to the immediate
- subordinates of the entry named by baseObject.
-
- wholeSubtree: the scope is constrained to the entry named by the
- baseObject, and all its subordinates.
-
-
-4.5.1.3. SearchRequest.derefAliases
-
- An indicator as to whether or not alias entries (as defined in
- [Models]) are to be dereferenced during stages of the Search
- operation.
-
- The act of dereferencing an alias includes recursively dereferencing
- aliases which refer to aliases.
-
- Servers MUST detect looping while dereferencing aliases in order to
- prevent denial of service attacks of this nature.
-
- The semantics of the defined values of this field are:
-
- neverDerefAliases: Do not dereference aliases in searching or in
- locating the base object of the Search.
-
-
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 20
- Lightweight Directory Access Protocol Version 3
-
- derefInSearching: While searching subordinates of the base object,
- dereference any alias within the search scope. Dereferenced
- objects become the vertices of further search scopes where the
- Search operation is also applied. If the search scope is
- wholeSubtree, the Search continues in the subtree(s) of any
- dereferenced object. If the search scope is singleLevel, the
- search is applied to any dereferenced objects, and is not applied
- to their subordinates. Servers SHOULD eliminate duplicate entries
- that arise due to alias dereferencing while searching.
-
- derefFindingBaseObj: Dereference aliases in locating the base
- object of the Search, but not when searching subordinates of the
- base object.
-
- derefAlways: Dereference aliases both in searching and in locating
- the base object of the Search.
-
-
-4.5.1.4. SearchRequest.sizeLimit
-
- A size limit that restricts the maximum number of entries to be
- returned as a result of the Search. A value of zero in this field
- indicates that no client-requested size limit restrictions are in
- effect for the Search. Servers may also enforce a maximum number of
- entries to return.
-
-
-4.5.1.5. SearchRequest.timeLimit
-
- A time limit that restricts the maximum time (in seconds) allowed for
- a Search. A value of zero in this field indicates that no client-
- requested time limit restrictions are in effect for the Search.
- Servers may also enforce a maximum time limit for the Search.
-
-
-4.5.1.6. SearchRequest.typesOnly
-
- An indicator as to whether Search results are to contain both
- attribute descriptions and values, or just attribute descriptions.
- Setting this field to TRUE causes only attribute descriptions (no
- values) to be returned. Setting this field to FALSE causes both
- attribute descriptions and values to be returned.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 21
- Lightweight Directory Access Protocol Version 3
-
-4.5.1.7. SearchRequest.filter
-
- A filter that defines the conditions that must be fulfilled in order
- for the Search to match a given entry.
-
- The 'and', 'or' and 'not' choices can be used to form combinations of
- filters. At least one filter element MUST be present in an 'and' or
- 'or' choice. The others match against individual attribute values of
- entries in the scope of the Search. (Implementor's note: the 'not'
- filter is an example of a tagged choice in an implicitly-tagged
- module. In BER this is treated as if the tag was explicit.)
-
- A server MUST evaluate filters according to the three-valued logic of
- [X.511] (1993) Clause 7.8.1. In summary, a filter is evaluated to
- either "TRUE", "FALSE" or "Undefined". If the filter evaluates to
- TRUE for a particular entry, then the attributes of that entry are
- returned as part of the Search result (subject to any applicable
- access control restrictions). If the filter evaluates to FALSE or
- Undefined, then the entry is ignored for the Search.
-
- A filter of the "and" choice is TRUE if all the filters in the SET OF
- evaluate to TRUE, FALSE if at least one filter is FALSE, and
- otherwise Undefined. A filter of the "or" choice is FALSE if all of
- the filters in the SET OF evaluate to FALSE, TRUE if at least one
- filter is TRUE, and Undefined otherwise. A filter of the 'not' choice
- is TRUE if the filter being negated is FALSE, FALSE if it is TRUE,
- and Undefined if it is Undefined.
-
- A filter item evaluates to Undefined when the server would not be
- able to determine whether the assertion value matches an entry.
- Examples include:
-
- - An attribute description in an equalityMatch, substrings,
- greaterOrEqual, lessOrEqual, approxMatch or extensibleMatch
- filter is not recognized by the server.
-
- - The attribute type does not define the appropriate matching
- rule.
-
- - A MatchingRuleId in the extensibleMatch is not recognized by
- the server or is not valid for the attribute type.
-
- - The type of filtering requested is not implemented.
-
- - The assertion value is invalid.
-
- For example, if a server did not recognize the attribute type
- shoeSize, the filters (shoeSize=*), (shoeSize=12), (shoeSize>=12) and
- (shoeSize<=12) would each evaluate to Undefined.
-
- Servers MUST NOT return errors if attribute descriptions or matching
- rule ids are not recognized, assertion values are invalid, or the
- assertion syntax is not supported. More details of filter processing
- are given in Clause 7.8 of [X.511].
-
-Sermersheim Internet-Draft - Expires April 2006 Page 22
- Lightweight Directory Access Protocol Version 3
-
-
-
-4.5.1.7.1. SearchRequest.filter.equalityMatch
-
- The matching rule for an equalityMatch filter is defined by the
- EQUALITY matching rule for the attribute type or subtype. The filter
- is TRUE when the EQUALITY rule returns TRUE as applied to the
- attribute or subtype and the asserted value.
-
-
-4.5.1.7.2. SearchRequest.filter.substrings
-
- There SHALL be at most one 'initial', and at most one 'final' in the
- 'substrings' of a SubstringFilter. If 'initial' is present, it SHALL
- be the first element of 'substrings'. If 'final' is present, it SHALL
- be the last element of 'substrings'.
-
- The matching rule for an AssertionValue in a substrings filter item
- is defined by the SUBSTR matching rule for the attribute type or
- subtype. The filter is TRUE when the SUBSTR rule returns TRUE as
- applied to the attribute or subtype and the asserted value.
-
- Note that the AssertionValue in a substrings filter item conforms to
- the assertion syntax of the EQUALITY matching rule for the attribute
- type rather than the assertion syntax of the SUBSTR matching rule for
- the attribute type. Conceptually, the entire SubstringFilter is
- converted into an assertion value of the substrings matching rule
- prior to applying the rule.
-
-
-4.5.1.7.3. SearchRequest.filter.greaterOrEqual
-
- The matching rule for a greaterOrEqual filter is defined by the
- ORDERING matching rule for the attribute type or subtype. The filter
- is TRUE when the ORDERING rule returns FALSE as applied to the
- attribute or subtype and the asserted value.
-
-
-4.5.1.7.4. SearchRequest.filter.lessOrEqual
-
- The matching rules for a lessOrEqual filter are defined by the
- ORDERING and EQUALITY matching rules for the attribute type or
- subtype. The filter is TRUE when either the ORDERING or EQUALITY rule
- returns TRUE as applied to the attribute or subtype and the asserted
- value.
-
-
-4.5.1.7.5. SearchRequest.filter.present
-
- A present filter is TRUE when there is an attribute or subtype of the
- specified attribute description present in an entry, FALSE when no
- attribute or subtype of the specified attribute description is
- present in an entry, and Undefined otherwise.
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 23
- Lightweight Directory Access Protocol Version 3
-
-
-4.5.1.7.6. SearchRequest.filter.approxMatch
-
- An approxMatch filter is TRUE when there is a value of the attribute
- type or subtype for which some locally-defined approximate matching
- algorithm (e.g. spelling variations, phonetic match, etc.) returns
- TRUE. If a value matches for equality, it also satisfies an
- approximate match. If approximate matching is not supported for the
- attribute, this filter item should be treated as an equalityMatch.
-
-
-4.5.1.7.7. SearchRequest.filter.extensibleMatch
-
- The fields of the extensibleMatch filter item are evaluated as
- follows:
-
- - If the matchingRule field is absent, the type field MUST be
- present, and an equality match is performed for that type.
-
- - If the type field is absent and the matchingRule is present, the
- matchValue is compared against all attributes in an entry which
- support that matchingRule.
-
- - If the type field is present and the matchingRule is present, the
- matchValue is compared against the specified attribute type and
- its subtypes.
-
- - If the dnAttributes field is set to TRUE, the match is
- additionally applied against all the AttributeValueAssertions in
- an entry's distinguished name, and evaluates to TRUE if there is
- at least one attribute or subtype in the distinguished name for
- which the filter item evaluates to TRUE. The dnAttributes field is
- present to alleviate the need for multiple versions of generic
- matching rules (such as word matching), where one applies to
- entries and another applies to entries and DN attributes as well.
-
- The matchingRule used for evaluation determines the syntax for the
- assertion value. Once the matchingRule and attribute(s) have been
- determined, the filter item evaluates to TRUE if it matches at least
- one attribute type or subtype in the entry, FALSE if it does not
- match any attribute type or subtype in the entry, and Undefined if
- the matchingRule is not recognized, the matchingRule is unsuitable
- for use with the specified type, or the assertionValue is invalid.
-
-
-4.5.1.7. SearchRequest.attributes
-
- A selection list of the attributes to be returned from each entry
- which matches the search filter. Attributes which are subtypes of
- listed attributes are implicitly included. LDAPString values of this
- field are constrained to the following Augmented Backus-Naur Form
- ([ABNF]):
-
- attributeSelector = attributedescription / selectorspecial
-
-Sermersheim Internet-Draft - Expires April 2006 Page 24
- Lightweight Directory Access Protocol Version 3
-
-
- selectorspecial = noattrs / alluserattrs
-
- noattrs = %x31.2E.31 ; "1.1"
-
- alluserattrs = %x2A ; asterisk ("*")
-
- The <attributedescription> production is defined in Section 2.5 of
- [Models].
-
- There are three special cases which may appear in the attributes
- selection list:
-
- - an empty list with no attributes,
-
- - a list containing "*" (with zero or more attribute
- descriptions), and
-
- - a list containing only "1.1".
-
- An empty list requests the return of all user attributes.
-
- A list containing "*" requests the return of all user attributes
- in addition to other listed (operational) attributes.
-
- A list containing only the OID "1.1" indicates that no attributes
- are to be returned. If "1.1" is provided with other
- attributeSelector values, the "1.1" attributeSelector is ignored.
- This OID was chosen because it does not (and can not) correspond
- to any attribute in use.
-
- Client implementors should note that even if all user attributes are
- requested, some attributes and/or attribute values of the entry may
- not be included in Search results due to access controls or other
- restrictions. Furthermore, servers will not return operational
- attributes, such as objectClasses or attributeTypes, unless they are
- listed by name. Operational attributes are described in [Models].
-
- Attributes are returned at most once in an entry. If an attribute
- description is named more than once in the list, the subsequent names
- are ignored. If an attribute description in the list is not
- recognized, it is ignored by the server.
-
-
-4.5.2. Search Result
-
- The results of the Search operation are returned as zero or more
- SearchResultEntry and/or SearchResultReference messages, followed by
- a single SearchResultDone message.
-
- SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
- objectName LDAPDN,
- attributes PartialAttributeList }
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 25
- Lightweight Directory Access Protocol Version 3
-
- PartialAttributeList ::= SEQUENCE OF
- partialAttribute PartialAttribute
-
- SearchResultReference ::= [APPLICATION 19] SEQUENCE
- SIZE (1..MAX) OF uri URI
-
- SearchResultDone ::= [APPLICATION 5] LDAPResult
-
- Each SearchResultEntry represents an entry found during the Search.
- Each SearchResultReference represents an area not yet explored during
- the Search. The SearchResultEntry and SearchResultReference messages
- may come in any order. Following all the SearchResultReference and
- SearchResultEntry responses, the server returns a SearchResultDone
- response, which contains an indication of success, or detailing any
- errors that have occurred.
-
- Each entry returned in a SearchResultEntry will contain all
- appropriate attributes as specified in the attributes field of the
- Search Request, subject to access control and other administrative
- policy. Note that the PartialAttributeList may hold zero elements.
- This may happen when none of the attributes of an entry were
- requested, or could be returned. Note also that the partialAttribute
- vals set may hold zero elements. This may happen when typesOnly is
- requested, access controls prevent the return of values, or other
- reasons.
-
- Some attributes may be constructed by the server and appear in a
- SearchResultEntry attribute list, although they are not stored
- attributes of an entry. Clients SHOULD NOT assume that all attributes
- can be modified, even if permitted by access control.
-
- If the server's schema defines short names [Models] for an attribute
- type then the server SHOULD use one of those names in attribute
- descriptions for that attribute type (in preference to using the
- <numericoid> [Models] format of the attribute type's object
- identifier). The server SHOULD NOT use the short name if that name is
- known by the server to be ambiguous, or otherwise likely to cause
- interoperability problems.
-
-
-4.5.3. Continuation References in the Search Result
-
- If the server was able to locate the entry referred to by the
- baseObject but was unable or unwilling to search one or more non-
- local entries, the server may return one or more
- SearchResultReference messages, each containing a reference to
- another set of servers for continuing the operation. A server MUST
- NOT return any SearchResultReference messages if it has not located
- the baseObject and thus has not searched any entries; in this case it
- would return a SearchResultDone containing either a referral or
- noSuchObject result code (depending on the server's knowledge of the
- entry named in the baseObject).
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 26
- Lightweight Directory Access Protocol Version 3
-
- If a server holds a copy or partial copy of the subordinate naming
- context (Section 5 of [Models]), it may use the search filter to
- determine whether or not to return a SearchResultReference response.
- Otherwise SearchResultReference responses are always returned when in
- scope.
-
- The SearchResultReference is of the same data type as the Referral.
-
- If the client wishes to progress the Search, it issues a new Search
- operation for each SearchResultReference that is returned. If
- multiple URIs are present, the client assumes that any supported URI
- may be used to progress the operation.
-
- Clients that follow search continuation references MUST ensure that
- they do not loop between servers. They MUST NOT repeatedly contact
- the same server for the same request with the same parameters. Some
- clients use a counter that is incremented each time search result
- reference handling occurs for an operation, and these kinds of
- clients MUST be able to handle at least ten nested referrals while
- progressing the operation.
-
- Note that the Abandon operation described in Section 4.11 applies
- only to a particular operation sent at the LDAP message layer between
- a client and server. The client must abandon subsequent Search
- operations it wishes to individually.
-
- A URI for a server implementing LDAP and accessible via [TCP]/[IP]
- (v4 or v6) is written as an LDAP URL according to [LDAPURL].
-
- SearchResultReference values which are LDAP URLs follow these rules:
-
- - The <dn> part of the LDAP URL MUST be present, with the new target
- object name. The client uses this name when following the
- reference.
-
- - Some servers (e.g. participating in distributed indexing) may
- provide a different filter in the LDAP URL.
-
- - If the <filter> part of the LDAP URL is present, the client uses
- this filter in its next request to progress this Search, and if it
- is not present the client uses the same filter as it used for that
- Search.
-
- - If the originating search scope was singleLevel, the <scope> part
- of the LDAP URL will be "base".
-
- - It is RECOMMENDED that the <scope> part be present to avoid
- ambiguity. In the absence of a <scope> part, the scope of the
- original Search request is assumed.
-
- - Other aspects of the new Search request may be the same as or
- different from the Search request which generated the
- SearchResultReference.
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 27
- Lightweight Directory Access Protocol Version 3
-
- - The name of an unexplored subtree in a SearchResultReference need
- not be subordinate to the base object.
-
- Other kinds of URIs may be returned. The syntax and semantics of such
- URIs is left to future specifications. Clients may ignore URIs that
- they do not support.
-
- UTF-8 encoded characters appearing in the string representation of a
- DN, search filter, or other fields of the referral value may not be
- legal for URIs (e.g. spaces) and MUST be escaped using the % method
- in [URI].
-
-
-
-4.5.3.1. Examples
-
- For example, suppose the contacted server (hosta) holds the entry
- <DC=Example,DC=NET> and the entry <CN=Manager,DC=Example,DC=NET>. It
- knows that both LDAP servers (hostb) and (hostc) hold
- <OU=People,DC=Example,DC=NET> (one is the master and the other server
- a shadow), and that LDAP-capable server (hostd) holds the subtree
- <OU=Roles,DC=Example,DC=NET>. If a wholeSubtree Search of
- <DC=Example,DC=NET> is requested to the contacted server, it may
- return the following:
-
- SearchResultEntry for DC=Example,DC=NET
- SearchResultEntry for CN=Manager,DC=Example,DC=NET
- SearchResultReference {
- ldap://hostb/OU=People,DC=Example,DC=NET??sub
- ldap://hostc/OU=People,DC=Example,DC=NET??sub }
- SearchResultReference {
- ldap://hostd/OU=Roles,DC=Example,DC=NET??sub }
- SearchResultDone (success)
-
- Client implementors should note that when following a
- SearchResultReference, additional SearchResultReference may be
- generated. Continuing the example, if the client contacted the server
- (hostb) and issued the Search request for the subtree
- <OU=People,DC=Example,DC=NET>, the server might respond as follows:
-
- SearchResultEntry for OU=People,DC=Example,DC=NET
- SearchResultReference {
- ldap://hoste/OU=Managers,OU=People,DC=Example,DC=NET??sub }
- SearchResultReference {
- ldap://hostf/OU=Consultants,OU=People,DC=Example,DC=NET??sub }
- SearchResultDone (success)
-
- Similarly, if a singleLevel Search of <DC=Example,DC=NET> is
- requested to the contacted server, it may return the following:
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 28
- Lightweight Directory Access Protocol Version 3
-
- SearchResultEntry for CN=Manager,DC=Example,DC=NET
- SearchResultReference {
- ldap://hostb/OU=People,DC=Example,DC=NET??base
- ldap://hostc/OU=People,DC=Example,DC=NET??base }
- SearchResultReference {
- ldap://hostd/OU=Roles,DC=Example,DC=NET??base }
- SearchResultDone (success)
-
- If the contacted server does not hold the base object for the Search,
- but has knowledge of its possible location, then it may return a
- referral to the client. In this case, if the client requests a
- subtree Search of <DC=Example,DC=ORG> to hosta, the server returns a
- SearchResultDone containing a referral.
-
- SearchResultDone (referral) {
- ldap://hostg/DC=Example,DC=ORG??sub }
-
-
-4.6. Modify Operation
-
- The Modify operation allows a client to request that a modification
- of an entry be performed on its behalf by a server. The Modify
- Request is defined as follows:
-
- ModifyRequest ::= [APPLICATION 6] SEQUENCE {
- object LDAPDN,
- changes SEQUENCE OF change SEQUENCE {
- operation ENUMERATED {
- add (0),
- delete (1),
- replace (2),
- ... },
- modification PartialAttribute } }
-
- Fields of the Modify Request are:
-
- - object: The value of this field contains the name of the entry to
- be modified. The server SHALL NOT perform any alias dereferencing
- in determining the object to be modified.
-
- - changes: A list of modifications to be performed on the entry. The
- entire list of modifications MUST be performed in the order they
- are listed as a single atomic operation. While individual
- modifications may violate certain aspects of the directory schema
- (such as the object class definition and DIT content rule), the
- resulting entry after the entire list of modifications is
- performed MUST conform to the requirements of the directory model
- and controlling schema [Models].
-
- - operation: Used to specify the type of modification being
- performed. Each operation type acts on the following
- modification. The values of this field have the following
- semantics respectively:
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 29
- Lightweight Directory Access Protocol Version 3
-
- add: add values listed to the modification attribute,
- creating the attribute if necessary;
-
- delete: delete values listed from the modification attribute.
- If no values are listed, or if all current values of the
- attribute are listed, the entire attribute is removed;
-
- replace: replace all existing values of the modification
- attribute with the new values listed, creating the attribute
- if it did not already exist. A replace with no value will
- delete the entire attribute if it exists, and is ignored if
- the attribute does not exist.
-
- - modification: A PartialAttribute (which may have an empty SET
- of vals) used to hold the attribute type or attribute type and
- values being modified.
-
- Upon receipt of a Modify Request, the server attempts to perform the
- necessary modifications to the DIT and returns the result in a Modify
- Response, defined as follows:
-
- ModifyResponse ::= [APPLICATION 7] LDAPResult
-
- The server will return to the client a single Modify Response
- indicating either the successful completion of the DIT modification,
- or the reason that the modification failed. Due to the requirement
- for atomicity in applying the list of modifications in the Modify
- Request, the client may expect that no modifications of the DIT have
- been performed if the Modify Response received indicates any sort of
- error, and that all requested modifications have been performed if
- the Modify Response indicates successful completion of the Modify
- operation. Whether the modification was applied or not cannot be
- determined by the client if the Modify Response was not received
- (e.g. the LDAP session was terminated or the Modify operation was
- abandoned).
-
- Servers MUST ensure that entries conform to user and system schema
- rules or other data model constraints. The Modify operation cannot be
- used to remove from an entry any of its distinguished values, i.e.
- those values which form the entry's relative distinguished name. An
- attempt to do so will result in the server returning the
- notAllowedOnRDN result code. The Modify DN operation described in
- Section 4.9 is used to rename an entry.
-
- For attribute types which specify no equality matching, the rules in
- Section 2.5.1 of [Models] are followed.
-
- Note that due to the simplifications made in LDAP, there is not a
- direct mapping of the changes in an LDAP ModifyRequest onto the
- changes of a DAP ModifyEntry operation, and different implementations
- of LDAP-DAP gateways may use different means of representing the
- change. If successful, the final effect of the operations on the
- entry MUST be identical.
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 30
- Lightweight Directory Access Protocol Version 3
-
-
-4.7. Add Operation
-
- The Add operation allows a client to request the addition of an entry
- into the Directory. The Add Request is defined as follows:
-
- AddRequest ::= [APPLICATION 8] SEQUENCE {
- entry LDAPDN,
- attributes AttributeList }
-
- AttributeList ::= SEQUENCE OF attribute Attribute
-
- Fields of the Add Request are:
-
- - entry: the name of the entry to be added. The server SHALL NOT
- dereference any aliases in locating the entry to be added.
-
- - attributes: the list of attributes that, along with those from the
- RDN, make up the content of the entry being added. Clients MAY or
- MAY NOT include the RDN attribute(s) in this list. Clients MUST
- NOT supply NO-USER-MODIFICATION attributes such as the
- createTimestamp or creatorsName attributes, since the server
- maintains these automatically.
-
- Servers MUST ensure that entries conform to user and system schema
- rules or other data model constraints. For attribute types which
- specify no equality matching, the rules in Section 2.5.1 of [Models]
- are followed (this applies to the naming attribute in addition to any
- multi-valued attributes being added).
-
- The entry named in the entry field of the AddRequest MUST NOT exist
- for the AddRequest to succeed. The immediate superior (parent) of an
- object or alias entry to be added MUST exist. For example, if the
- client attempted to add <CN=JS,DC=Example,DC=NET>, the
- <DC=Example,DC=NET> entry did not exist, and the <DC=NET> entry did
- exist, then the server would return the noSuchObject result code with
- the matchedDN field containing <DC=NET>.
-
- Upon receipt of an Add Request, a server will attempt to add the
- requested entry. The result of the Add attempt will be returned to
- the client in the Add Response, defined as follows:
-
- AddResponse ::= [APPLICATION 9] LDAPResult
-
- A response of success indicates that the new entry has been added to
- the Directory.
-
-
-4.8. Delete Operation
-
- The Delete operation allows a client to request the removal of an
- entry from the Directory. The Delete Request is defined as follows:
-
- DelRequest ::= [APPLICATION 10] LDAPDN
-
-Sermersheim Internet-Draft - Expires April 2006 Page 31
- Lightweight Directory Access Protocol Version 3
-
-
- The Delete Request consists of the name of the entry to be deleted.
- The server SHALL NOT dereference aliases while resolving the name of
- the target entry to be removed.
-
- Only leaf entries (those with no subordinate entries) can be deleted
- with this operation.
-
- Upon receipt of a Delete Request, a server will attempt to perform
- the entry removal requested and return the result in the Delete
- Response defined as follows:
-
- DelResponse ::= [APPLICATION 11] LDAPResult
-
-
-4.9. Modify DN Operation
-
- The Modify DN operation allows a client to change the Relative
- Distinguished Name (RDN) of an entry in the Directory, and/or to move
- a subtree of entries to a new location in the Directory. The Modify
- DN Request is defined as follows:
-
- ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
- entry LDAPDN,
- newrdn RelativeLDAPDN,
- deleteoldrdn BOOLEAN,
- newSuperior [0] LDAPDN OPTIONAL }
-
- Fields of the Modify DN Request are:
-
- - entry: the name of the entry to be changed. This entry may or may
- not have subordinate entries.
-
- - newrdn: the new RDN of the entry. The value of the old RDN is
- supplied when moving the entry to a new superior without changing
- its RDN. Attribute values of the new RDN not matching any
- attribute value of the entry are added to the entry and an
- appropriate error is returned if this fails.
-
- - deleteoldrdn: a boolean field that controls whether the old RDN
- attribute values are to be retained as attributes of the entry, or
- deleted from the entry.
-
- - newSuperior: if present, this is the name of an existing object
- entry which becomes the immediate superior (parent) of the
- existing entry.
-
- The server SHALL NOT dereference any aliases in locating the objects
- named in entry or newSuperior.
-
- Upon receipt of a ModifyDNRequest, a server will attempt to perform
- the name change and return the result in the Modify DN Response,
- defined as follows:
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 32
- Lightweight Directory Access Protocol Version 3
-
- ModifyDNResponse ::= [APPLICATION 13] LDAPResult
-
- For example, if the entry named in the entry field was <cn=John
- Smith,c=US>, the newrdn field was <cn=John Cougar Smith>, and the
- newSuperior field was absent, then this operation would attempt to
- rename the entry to be <cn=John Cougar Smith,c=US>. If there was
- already an entry with that name, the operation would fail with the
- entryAlreadyExists result code.
-
- Servers MUST ensure that entries conform to user and system schema
- rules or other data model constraints. For attribute types which
- specify no equality matching, the rules in Section 2.5.1 of [Models]
- are followed (this pertains to newrdn and deleteoldrdn).
-
- The object named in newSuperior MUST exist. For example, if the
- client attempted to add <CN=JS,DC=Example,DC=NET>, the
- <DC=Example,DC=NET> entry did not exist, and the <DC=NET> entry did
- exist, then the server would return the noSuchObject result code with
- the matchedDN field containing <DC=NET>.
-
- If the deleteoldrdn field is TRUE, the attribute values forming the
- old RDN but not the new RDN are deleted from the entry. If the
- deleteoldrdn field is FALSE, the attribute values forming the old RDN
- will be retained as non-distinguished attribute values of the entry.
-
- 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
- affectsMultipleDSAs result code 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 or
- between naming contexts.
-
-
-4.10. Compare Operation
-
- The Compare operation allows a client to compare an assertion value
- with the values of a particular attribute in a particular entry in
- the Directory. The Compare Request is defined as follows:
-
- CompareRequest ::= [APPLICATION 14] SEQUENCE {
- entry LDAPDN,
- ava AttributeValueAssertion }
-
- Fields of the Compare Request are:
-
- - entry: the name of the entry to be compared. The server SHALL NOT
- dereference any aliases in locating the entry to be compared.
-
- - ava: holds the attribute value assertion to be compared.
-
- Upon receipt of a Compare Request, a server will attempt to perform
- the requested comparison and return the result in the Compare
- Response, defined as follows:
-
-Sermersheim Internet-Draft - Expires April 2006 Page 33
- Lightweight Directory Access Protocol Version 3
-
-
- CompareResponse ::= [APPLICATION 15] LDAPResult
-
- The resultCode is set to compareTrue, compareFalse, or an appropriate
- error. compareTrue indicates that the assertion value in the ava
- field matches a value of the attribute or subtype according to the
- attribute's EQUALITY matching rule. compareFalse indicates that the
- assertion value in the ava field and the values of the attribute or
- subtype did not match. Other result codes indicate either that the
- result of the comparison was Undefined (Section 4.5.1), or that some
- error occurred.
-
- Note that some directory systems may establish access controls which
- permit the values of certain attributes (such as userPassword) to be
- compared but not interrogated by other means.
-
-
-4.11. Abandon Operation
-
- The function of the Abandon operation is to allow a client to request
- that the server abandon an uncompleted operation. The Abandon Request
- is defined as follows:
-
- AbandonRequest ::= [APPLICATION 16] MessageID
-
- The MessageID is that of an operation which was requested earlier at
- this LDAP message layer. The Abandon request itself has its own
- MessageID. This is distinct from the MessageID of the earlier
- operation being abandoned.
-
- There is no response defined in the Abandon operation. Upon receipt
- of an AbandonRequest, the server MAY abandon the operation identified
- by the MessageID. Since the client cannot tell the difference between
- a successfully abandoned operation and an uncompleted operation, the
- application of the Abandon operation is limited to uses where the
- client does not require an indication of its outcome.
-
- Abandon, Bind, Unbind, and StartTLS operations cannot be abandoned.
-
- In the event that a server receives an Abandon Request on a Search
- operation in the midst of transmitting responses to the Search, that
- server MUST cease transmitting entry responses to the abandoned
- request immediately, and MUST NOT send the SearchResultDone. Of
- course, the server MUST ensure that only properly encoded LDAPMessage
- PDUs are transmitted.
-
- The ability to abandon other (particularly update) operations is at
- the discretion of the server.
-
- Clients should not send Abandon requests for the same operation
- multiple times, and MUST also be prepared to receive results from
- operations it has abandoned (since these may have been in transit
- when the Abandon was requested, or are not able to be abandoned).
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 34
- Lightweight Directory Access Protocol Version 3
-
- Servers MUST discard Abandon requests for message IDs they do not
- recognize, for operations which cannot be abandoned, and for
- operations which have already been abandoned.
-
-
-4.12. Extended Operation
-
- The Extended operation allows additional operations to be defined for
- services not already available in the protocol. For example, to Add
- operations to install transport layer security (see Section 4.14).
-
- The Extended operation allows clients to make requests and receive
- responses with predefined syntaxes and semantics. These may be
- defined in RFCs or be private to particular implementations.
-
- Each Extended operation consists of an Extended request and an
- Extended response.
-
- ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
- requestName [0] LDAPOID,
- requestValue [1] OCTET STRING OPTIONAL }
-
- The requestName is a dotted-decimal representation of the unique
- OBJECT IDENTIFIER corresponding to the request. The requestValue is
- information in a form defined by that request, encapsulated inside an
- OCTET STRING.
-
- The server will respond to this with an LDAPMessage containing an
- ExtendedResponse.
-
- ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
- COMPONENTS OF LDAPResult,
- responseName [10] LDAPOID OPTIONAL,
- responseValue [11] OCTET STRING OPTIONAL }
-
- The responseName field, when present, contains an LDAPOID which is
- unique for this extended operation or response. This field is
- optional (even when the extension specification specifies an LDAPOID
- to be returned in the field). The field will be absent whenever the
- server is unable or unwilling to determine the appropriate LDAPOID to
- return, for instance when the requestName cannot be parsed or its
- value is not recognized.
-
- Where the requestName is not recognized, the server returns
- protocolError (The server may return protocolError in other cases).
-
- The requestValue and responseValue fields contain information
- associated with the operation. The format of these fields is defined
- by the specification of the Extended operation. Implementations MUST
- be prepared to handle arbitrary contents of these fields, including
- zero bytes. Values that are defined in terms of ASN.1 and BER encoded
- according to Section 5.1, also follow the extensibility rules in
- Section 4.
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 35
- Lightweight Directory Access Protocol Version 3
-
- Servers list the requestName of Extended Requests they recognize in
- the 'supportedExtension' attribute in the root DSE (Section 5.1 of
- [Models]).
-
- Extended operations may be specified in other documents. The
- specification of an Extended operation consists of:
-
- - the OBJECT IDENTIFIER assigned to the requestName,
-
- - the OBJECT IDENTIFIER (if any) assigned to the responseName (note
- that the same OBJECT IDENTIFIER may be used for both the
- requestName and responseName),
-
- - the format of the contents of the requestValue and responseValue
- (if any), and
-
- - the semantics of the operation.
-
-
-4.13. IntermediateResponse Message
-
- While the Search operation provides a mechanism to return multiple
- response messages for a single Search request, other operations, by
- nature, do not provide for multiple response messages.
-
- The IntermediateResponse message provides a general mechanism for
- defining single-request/multiple-response operations in LDAP. This
- message is intended to be used in conjunction with the Extended
- operation to define new single-request/multiple-response operations
- or in conjunction with a control when extending existing LDAP
- operations in a way that requires them to return Intermediate
- response information.
-
- It is intended that the definitions and descriptions of Extended
- operations and controls that make use of the IntermediateResponse
- message will define the circumstances when an IntermediateResponse
- message can be sent by a server and the associated meaning of an
- IntermediateResponse message sent in a particular circumstance.
-
- IntermediateResponse ::= [APPLICATION 25] SEQUENCE {
- responseName [0] LDAPOID OPTIONAL,
- responseValue [1] OCTET STRING OPTIONAL }
-
- IntermediateResponse messages SHALL NOT be returned to the client
- unless the client issues a request that specifically solicits their
- return. This document defines two forms of solicitation: Extended
- operation and request control. IntermediateResponse messages are
- specified in documents describing the manner in which they are
- solicited (i.e. in the Extended operation or request control
- specification that uses them). These specifications include:
-
- - the OBJECT IDENTIFIER (if any) assigned to the responseName,
-
- - the format of the contents of the responseValue (if any), and
-
-Sermersheim Internet-Draft - Expires April 2006 Page 36
- Lightweight Directory Access Protocol Version 3
-
-
- - the semantics associated with the IntermediateResponse message.
-
- Extensions that allow the return of multiple types of
- IntermediateResponse messages SHALL identify those types using unique
- responseName values (note that one of these may specify no value).
-
- Sections 4.13.1 and 4.13.2 describe additional requirements on the
- inclusion of responseName and responseValue in IntermediateResponse
- messages.
-
-
-4.13.1. Usage with LDAP ExtendedRequest and ExtendedResponse
-
- A single-request/multiple-response operation may be defined using a
- single ExtendedRequest message to solicit zero or more
- IntermediateResponse messages of one or more kinds followed by an
- ExtendedResponse message.
-
-
-4.13.2. Usage with LDAP Request Controls
-
- A control's semantics may include the return of zero or more
- IntermediateResponse messages prior to returning the final result
- code for the operation. One or more kinds of IntermediateResponse
- messages may be sent in response to a request control.
-
- All IntermediateResponse messages associated with request controls
- SHALL include a responseName. This requirement ensures that the
- client can correctly identify the source of IntermediateResponse
- messages when:
-
- - two or more controls using IntermediateResponse messages are
- included in a request for any LDAP operation or
-
- - one or more controls using IntermediateResponse messages are
- included in a request with an LDAP Extended operation that uses
- IntermediateResponse messages.
-
-
-4.14. StartTLS Operation
-
- The Start Transport Layer Security (StartTLS) operation's purpose is
- to initiate installation of a TLS layer. The StartTLS operation is
- defined using the Extended operation mechanism described in Section
- 4.12.
-
-
-
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 37
- Lightweight Directory Access Protocol Version 3
-
-4.14.1. StartTLS Request
-
- A client requests TLS establishment by transmitting a StartTLS
- request message to the server. The StartTLS request is defined in
- terms of an ExtendedRequest. The requestName is
- "1.3.6.1.4.1.1466.20037", and the requestValue field is always
- absent.
-
- The client MUST NOT send any LDAP PDUs at this LDAP message layer
- following this request until it receives a StartTLS Extended response
- and, in the case of a successful response, completes TLS
- negotiations.
-
- Detected sequencing problems (particularly those detailed in Section
- 3.1.1 of [AuthMeth]) result in the resultCode being set to
- operationsError.
-
- If the server does not support TLS (whether by design or by current
- configuration), it returns with the resultCode set to protocolError
- as described in Section 4.12.
-
-
-4.14.2. StartTLS Response
-
- When a StartTLS request is received, servers supporting the operation
- MUST return a StartTLS response message to the requestor. The
- responseName is "1.3.6.1.4.1.1466.20037" when provided (See 4.12).
- The responseValue is always absent.
-
- If the server is willing and able to negotiate TLS, it returns the
- StartTLS response with the resultCode set to success. Upon client
- receipt of a successful StartTLS response, protocol peers may
- commence with TLS negotiation as discussed in Section 3 of
- [AuthMeth].
-
- If the server is otherwise unwilling or unable to perform this
- operation, the server is to return an appropriate result code
- indicating the nature of the problem. For example, if the TLS
- subsystem is not presently available, the server may indicate so by
- returning with the resultCode set to unavailable. In cases where a
- non-success result code is returned, the LDAP session is left without
- a TLS layer.
-
-
-4.14.3. Removal of the TLS Layer
-
- Either the client or server MAY remove the TLS layer and leave the
- LDAP message layer intact by sending and receiving a TLS closure
- alert.
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 38
- Lightweight Directory Access Protocol Version 3
-
- The initiating protocol peer sends the TLS closure alert and MUST
- wait until it receives a TLS closure alert from the other peer before
- sending further LDAP PDUs.
-
- When a protocol peer receives the initial TLS closure alert, it may
- choose to allow the LDAP message layer to remain intact. In this
- case, it MUST immediately transmit a TLS closure alert. Following
- this, it MAY send and receive LDAP PDUs.
-
- Protocol peers MAY terminate the LDAP session after sending or
- receiving a TLS closure alert.
-
-
-5. Protocol Encoding, Connection, and Transfer
-
- This protocol is designed to run over connection-oriented, reliable
- transports, where the data stream is divided into octets (8-bit
- units), with each octet and each bit being significant.
-
- One underlying service, LDAP over TCP, is defined in Section
- 5.2. This service is generally applicable to applications providing
- or consuming X.500-based directory services on the Internet. This
- specification was generally written with the TCP mapping in mind.
- Specifications detailing other mappings may encounter various
- obstacles.
-
- Implementations of LDAP over TCP MUST implement the mapping as
- described in Section 5.2.
-
- This table illustrates the relationship between the different layers
- involved in an exchange between two protocol peers:
-
- +----------------------+
- | LDAP message layer |
- +----------------------+ > LDAP PDUs
- +----------------------+ < data
- | SASL layer |
- +----------------------+ > SASL-protected data
- +----------------------+ < data
- | TLS layer |
- Application +----------------------+ > TLS-protected data
- ------------+----------------------+ < data
- Transport | transport connection |
- +----------------------+
-
-
-5.1. Protocol Encoding
-
- The protocol elements of LDAP SHALL be encoded for exchange using the
- Basic Encoding Rules [BER] of [ASN.1] with the following
- restrictions:
-
- - Only the definite form of length encoding is used.
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 39
- Lightweight Directory Access Protocol Version 3
-
-
- - OCTET STRING values are encoded in the primitive form only.
-
- - If the value of a BOOLEAN type is true, the encoding of the value
- octet is set to hex "FF".
-
- - If a value of a type is its default value, it is absent. Only some
- BOOLEAN and INTEGER types have default values in this protocol
- definition.
-
- These restrictions are meant to ease the overhead of encoding and
- decoding certain elements in BER.
-
- These restrictions do not apply to ASN.1 types encapsulated inside of
- OCTET STRING values, such as attribute values, unless otherwise
- stated.
-
-
-5.2. Transmission Control Protocol (TCP)
-
- The encoded LDAPMessage PDUs are mapped directly onto the [TCP]
- bytestream using the BER-based encoding described in Section 5.1. It
- is recommended that server implementations running over the TCP
- provide a protocol listener on the Internet Assigned Numbers
- Authority (IANA)-assigned LDAP port, 389 [PortReg]. Servers may
- instead provide a listener on a different port number. Clients MUST
- support contacting servers on any valid TCP port.
-
-
-5.3. Termination of the LDAP session
-
- Termination of the LDAP session is typically initiated by the client
- sending an UnbindRequest (Section 4.3), or by the server sending a
- Notice of Disconnection (Section 4.4.1). In these cases each protocol
- peer gracefully terminates the LDAP session by ceasing exchanges at
- the LDAP message layer, tearing down any SASL layer, tearing down any
- TLS layer, and closing the transport connection.
-
- A protocol peer may determine that the continuation of any
- communication would be pernicious, and in this case may abruptly
- terminate the session by ceasing communication and closing the
- transport connection.
-
- In either case, when the LDAP session is terminated, uncompleted
- operations are handled as specified in Section 3.1.
-
-
-6. Security Considerations
-
- This version of the protocol provides facilities for simple
- authentication using a cleartext password, as well as any [SASL]
- mechanism. Installing SASL and/or TLS layers can provide integrity
- and other data security services.
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 40
- Lightweight Directory Access Protocol Version 3
-
- It is also permitted that the server can return its credentials to
- the client, if it chooses to do so.
-
- Use of cleartext password is strongly discouraged where the
- underlying transport service cannot guarantee confidentiality and may
- result in disclosure of the password to unauthorized parties.
-
- Servers are encouraged to prevent directory modifications by clients
- that have authenticated anonymously [AuthMeth].
-
- Security considerations for authentication methods, SASL mechanisms,
- and TLS are described in [AuthMeth].
-
- It should be noted that SASL authentication exchanges do not provide
- data confidentiality nor integrity protection for the version or name
- fields of the BindRequest nor the resultCode, diagnosticMessage, or
- referral fields of the BindResponse nor of any information contained
- in controls attached to Bind requests or responses. Thus information
- contained in these fields SHOULD NOT be relied on unless otherwise
- protected (such as by establishing protections at the transport
- layer).
-
- Implementors should note that various security factors, including
- authentication and authorization information and data security
- services may change during the course of the LDAP session, or even
- during the performance of a particular operation. For instance,
- credentials could expire, authorization identities or access controls
- could change, or the underlying security layer(s) could be replaced
- or terminated. Implementations should be robust in the handling of
- changing security factors.
- In some cases, it may be appropriate to continue the operation even
- in light of security factor changes. For instance, it may be
- appropriate to continue an Abandon operation regardless of the
- change, or to continue an operation when the change upgraded (or
- maintained) the security factor. In other cases, it may be
- appropriate to fail, or alter the processing of the operation. For
- instance, if confidential protections were removed, it would be
- appropriate to either fail a request to return sensitive data, or
- minimally, to exclude the return of sensitive data.
-
- Implementations which cache attributes and entries obtained via LDAP
- MUST ensure that access controls are maintained if that information
- is to be provided to multiple clients, since servers may have access
- control policies which prevent the return of entries or attributes in
- Search results except to particular authenticated clients. For
- example, caches could serve result information only to the client
- whose request caused it to be in the cache.
-
-
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 41
- Lightweight Directory Access Protocol Version 3
-
- Servers may return referrals or Search result references which
- redirect clients to peer servers. It is possible for a rogue
- application to inject such referrals into the data stream in an
- attempt to redirect a client to a rogue server. Clients are advised
- to be aware of this, and possibly reject referrals when
- confidentiality measures are not in place. Clients are advised to
- reject referrals from the StartTLS operation.
-
- The matchedDN and diagnosticMessage fields, as well as some
- resultCode values (e.g., attributeOrValueExists and
- entryAlreadyExists), could disclose the presence or absence of
- specific data in the directory which is subject to access and other
- administrative controls. Server implementations should restrict
- access to protected information equally under both normal and error
- conditions.
-
- Protocol peers MUST be prepared to handle invalid and arbitrary
- length protocol encodings. Invalid protocol encodings include: BER
- encoding exceptions, format string and UTF-8 encoding exceptions,
- overflow exceptions, integer value exceptions, and binary mode on/off
- flag exceptions. The LDAPv3 PROTOS [PROTOS-LDAP] test suite provides
- excellent examples of these exceptions and test cases used to
- discover flaws.
-
- In the event that a protocol peer senses an attack which in its
- nature could cause damage due to further communication at any layer
- in the LDAP session, the protocol peer should abruptly terminate the
- LDAP session as described in Section 5.3.
-
-
-7. Acknowledgements
-
- This document is based on RFC 2251 by Mark Wahl, Tim Howes, and Steve
- Kille. RFC 2251 was a product of the IETF ASID Working Group.
-
- It is also based on RFC 2830 by Jeff Hodges, RL "Bob" Morgan, and
- Mark Wahl. RFC 2830 was a product of the IETF LDAPEXT Working Group.
-
- It is also based on RFC 3771 by Roger Harrison, and Kurt Zeilenga.
- RFC 3771 was an individual submission to the IETF.
-
- This document is a product of the IETF LDAPBIS Working Group.
- Significant contributors of technical review and content include Kurt
- Zeilenga, Steven Legg, and Hallvard Furuseth.
-
-
-8. Normative References
-
- [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", draft-crocker-abnf-rfc2234bis-
- xx.txt, (a work in progress).
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 42
- Lightweight Directory Access Protocol Version 3
-
- [ASN.1] ITU-T Recommendation X.680 (07/2002) | ISO/IEC 8824-1:2002
- "Information Technology - Abstract Syntax Notation One
- (ASN.1): Specification of basic notation"
-
- [AuthMeth] Harrison, R., "LDAP: Authentication Methods and Connection
- Level Security Mechanisms", draft-ietf-ldapbis-authmeth-
- xx.txt, (a work in progress).
-
- [BER] ITU-T Rec. X.690 (07/2002) | ISO/IEC 8825-1:2002,
- "Information technology - ASN.1 encoding rules:
- Specification of Basic Encoding Rules (BER), Canonical
- Encoding Rules (CER) and Distinguished Encoding Rules
- (DER)", 2002.
-
- [IP] Postel, J., "Internet Protocol", STD5 and RFC 791,
- September 1981
-
- [ISO10646] Universal Multiple-Octet Coded Character Set (UCS) -
- Architecture and Basic Multilingual Plane, ISO/IEC 10646-1
- : 1993.
-
- [Keyword] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", RFC 2119, March 1997.
-
- [LDAPDN] Zeilenga, K., "LDAP: String Representation of
- Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, (a
- work in progress).
-
- [LDAPIANA] Zeilenga, K., "IANA Considerations for LDAP", draft-ietf-
- ldapbis-bcp64-xx.txt, (a work in progress).
-
- [LDAPURL] Smith, M., "LDAP: Uniform Resource Locator", draft-ietf-
- ldapbis-url-xx.txt, (a work in progress).
-
- [Models] Zeilenga, K., "LDAP: Directory Information Models", draft-
- ietf-ldapbis-models-xx.txt (a work in progress).
-
- [Roadmap] Zeilenga, K., "LDAP: Technical Specification Road Map",
- draft-ietf-ldapbis-roadmap-xx.txt (a work in progress).
-
- [SASL] Melnikov, A., "Simple Authentication and Security Layer",
- draft-ietf-sasl-rfc2222bis-xx.txt (a work in progress).
-
- [SASLPrep] Zeilenga, K., "Stringprep profile for user names and
- passwords", draft-ietf-sasl-saslprep-xx.txt, (a work in
- progress).
-
- [StringPrep] Hoffman P. and M. Blanchet, "Preparation of
- Internationalized Strings ('stringprep')", draft-hoffman-
- rfc3454bis-xx.txt, a work in progress.
-
- [Syntaxes] Legg, S., and K. Dally, "LDAP: Syntaxes and Matching
- Rules", draft-ietf-ldapbis-syntaxes-xx.txt, (a work in
- progress).
-
-Sermersheim Internet-Draft - Expires April 2006 Page 43
- Lightweight Directory Access Protocol Version 3
-
-
- [TCP] Postel, J., "Transmission Control Protocol", STD7 and RFC
- 793, September 1981
-
- [TLS] Dierks, T. and C. Allen. "The TLS Protocol Version 1.1",
- draft-ietf-tls-rfc2246-bis-xx.txt, a work in progress.
-
- [Unicode] The Unicode Consortium, "The Unicode Standard, Version
- 3.2.0" is defined by "The Unicode Standard, Version 3.0"
- (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
- as amended by the "Unicode Standard Annex #27: Unicode
- 3.1" (http://www.unicode.org/reports/tr27/) and by the
- "Unicode Standard Annex #28: Unicode 3.2"
- (http://www.unicode.org/reports/tr28/).
-
- [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
- Resource Identifiers (URI): Generic Syntax", RFC 2396,
- August 1998.
-
- [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
- 10646", STD63 and RFC3629, November 2003.
-
- [X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts,
- Models and Service", 1993.
-
- [X.501] ITU-T Rec. X.501, "The Directory: Models", 1993.
-
- [X.511] ITU-T Rec. X.511, "The Directory: Abstract Service
- Definition", 1993.
-
-
-9. Informative References
-
- [Glossary] The Unicode Consortium, "Unicode Glossary",
- <http://www.unicode.org/glossary/>.
-
- [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report
- #17, Character Encoding Model", UTR17,
- <http://www.unicode.org/unicode/reports/tr17/>, August
- 2000.
-
- [PROTOS-LDAP] University of Oulu, "PROTOS Test-Suite: c06-ldapv3"
- <http://www.ee.oulu.fi/research/ouspg/protos/testing/c06/l
- dapv3/>
-
- [PortReg] IANA, "Port Numbers",
- http://www.iana.org/assignments/port-numbers
-
-
-10. IANA Considerations
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 44
- Lightweight Directory Access Protocol Version 3
-
- It is requested that the Internet Assigned Numbers Authority (IANA)
- update the LDAP result code registry to indicate that this document
- provides the definitive technical specification for result codes 0-
- 36, 48-54, 64-70, 80-90. It is also noted that one resultCode value
- (strongAuthRequired) has been renamed (to strongerAuthRequired).
-
- It is requested that the IANA update the LDAP Protocol Mechanism
- registry to indicate that this document and [AuthMeth] provides the
- definitive technical specification for the StartTLS
- (1.3.6.1.4.1.1466.20037) Extended operation.
-
- It is requested that the IANA update the occurrence of "RFC XXXX" in
- this section and Appendix B with this RFC number at publication.
-
- It is requested that IANA assign upon Standards Action an LDAP Object
- Identifier [LDAPIANA] to identify the ASN.1 module defined in this
- document.
-
- Subject: Request for LDAP Object Identifier Registration
- Person & email address to contact for further information:
- Jim Sermersheim <jimse@novell.com>
- Specification: RFC XXXX
- Author/Change Controller: IESG
- Comments:
- Identifies the LDAP ASN.1 module
-
- [[Note to RFC Editor: please replace the occurrence of <IANA-
- ASSIGNED-DIRECTORY-NUMBER> in Appendix B with the IANA assigned
- OID.]]
-
-
-11. Editor's Address
-
- Jim Sermersheim
- Novell, Inc.
- 1800 South Novell Place
- Provo, Utah 84606, USA
- jimse@novell.com
- +1 801 861-3088
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 45
- Lightweight Directory Access Protocol Version 3
-
-Appendix A. LDAP Result Codes
-
- This normative appendix details additional considerations regarding
- LDAP result codes and provides a brief, general description of each
- LDAP result code enumerated in Section 4.1.9.
-
- Additional result codes MAY be defined for use with extensions
- [LDAPIANA]. Client implementations SHALL treat any result code which
- they do not recognize as an unknown error condition.
-
- The descriptions provided here do not fully account for result code
- substitutions used to prevent unauthorized disclosures (such as
- substitution of noSuchObject for insufficientAccessRights, or
- invalidCredentials for insufficientAccessRights).
-
-
-A.1. Non-Error Result Codes
-
- These result codes (called "non-error" result codes) do not indicate
- an error condition:
- success (0),
- compareFalse (5),
- compareTrue (6),
- referral (10), and
- saslBindInProgress (14).
-
- The success, compareTrue, and compareFalse result codes indicate
- successful completion (and, hence, are referred to as "successful"
- result codes).
-
- The referral and saslBindInProgress result codes indicate the client
- needs to take additional action to complete the operation.
-
-
-A.2. Result Codes
-
- Existing LDAP result codes are described as follows:
-
- success (0)
- Indicates the successful completion of an operation. Note:
- this code is not used with the Compare operation. See
- compareFalse (5) and compareTrue (6).
-
- operationsError (1)
- Indicates that the operation is not properly sequenced with
- relation to other operations (of same or different type).
-
- For example, this code is returned if the client attempts to
- StartTLS [TLS] while there are other uncompleted operations
- or if a TLS layer was already installed.
-
- protocolError (2)
- Indicates the server received data which is not well-formed.
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 46
- Lightweight Directory Access Protocol Version 3
-
- For Bind operation only, this code is also used to indicate
- that the server does not support the requested protocol
- version.
-
- For Extended operations only, this code is also used to
- indicate that the server does not support (by design or
- configuration) the Extended operation associated with the
- requestName.
-
- For request operations specifying multiple controls, this may
- be used to indicate that the server cannot ignore the order
- of the controls as specified, or that the combination of the
- specified controls is invalid or unspecified.
-
- timeLimitExceeded (3)
- Indicates that the time limit specified by the client was
- exceeded before the operation could be completed.
-
- sizeLimitExceeded (4)
- Indicates that the size limit specified by the client was
- exceeded before the operation could be completed.
-
- compareFalse (5)
- Indicates that the Compare operation has successfully
- completed and the assertion has evaluated to FALSE or
- Undefined.
-
- compareTrue (6)
- Indicates that the Compare operation has successfully
- completed and the assertion has evaluated to TRUE.
-
- authMethodNotSupported (7)
- Indicates that the authentication method or mechanism is not
- supported.
-
- strongerAuthRequired (8)
- Indicates the server requires strong(er) authentication in
- order to complete the operation.
-
- When used with the Notice of Disconnection operation, this
- code indicates that the server has detected that an
- established security association between the client and
- server has unexpectedly failed or been compromised.
-
- referral (10)
- Indicates that a referral needs to be chased to complete the
- operation (see Section 4.1.10).
-
- adminLimitExceeded (11)
- Indicates that an administrative limit has been exceeded.
-
- unavailableCriticalExtension (12)
- Indicates a critical control is unrecognized (see Section
- 4.1.11).
-
-Sermersheim Internet-Draft - Expires April 2006 Page 47
- Lightweight Directory Access Protocol Version 3
-
-
- confidentialityRequired (13)
- Indicates that data confidentiality protections are required.
-
- saslBindInProgress (14)
- Indicates the server requires the client to send a new bind
- request, with the same SASL mechanism, to continue the
- authentication process (see Section 4.2).
-
- noSuchAttribute (16)
- Indicates that the named entry does not contain the specified
- attribute or attribute value.
-
- undefinedAttributeType (17)
- Indicates that a request field contains an unrecognized
- attribute description.
-
- inappropriateMatching (18)
- Indicates that an attempt was made (e.g. in an assertion) to
- use a matching rule not defined for the attribute type
- concerned.
-
- constraintViolation (19)
- Indicates that the client supplied an attribute value which
- does not conform to the constraints placed upon it by the
- data model.
-
- For example, this code is returned when multiple values are
- supplied to an attribute which has a SINGLE-VALUE constraint.
-
- attributeOrValueExists (20)
- Indicates that the client supplied an attribute or value to
- be added to an entry, but the attribute or value already
- exists.
-
- invalidAttributeSyntax (21)
- Indicates that a purported attribute value does not conform
- to the syntax of the attribute.
-
- noSuchObject (32)
- Indicates that the object does not exist in the DIT.
-
- aliasProblem (33)
- Indicates that an alias problem has occurred. For example,
- the code may used to indicate an alias has been dereferenced
- which names no object.
-
- invalidDNSyntax (34)
- Indicates that an LDAPDN or RelativeLDAPDN field (e.g. search
- base, target entry, ModifyDN newrdn, etc.) of a request does
- not conform to the required syntax or contains attribute
- values which do not conform to the syntax of the attribute's
- type.
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 48
- Lightweight Directory Access Protocol Version 3
-
-
- aliasDereferencingProblem (36)
- Indicates that a problem occurred while dereferencing an
- alias. Typically an alias was encountered in a situation
- where it was not allowed or where access was denied.
-
- inappropriateAuthentication (48)
- Indicates the server requires the client which had attempted
- to bind anonymously or without supplying credentials to
- provide some form of credentials.
-
- invalidCredentials (49)
- Indicates that the provided credentials (e.g. the user's name
- and password) are invalid.
-
- insufficientAccessRights (50)
- Indicates that the client does not have sufficient access
- rights to perform the operation.
-
- busy (51)
- Indicates that the server is too busy to service the
- operation.
-
- unavailable (52)
- Indicates that the server is shutting down or a subsystem
- necessary to complete the operation is offline.
-
- unwillingToPerform (53)
- Indicates that the server is unwilling to perform the
- operation.
-
- loopDetect (54)
- Indicates that the server has detected an internal loop (e.g.
- while dereferencing aliases or chaining an operation).
-
- namingViolation (64)
- Indicates that the entry's name violates naming restrictions.
-
- objectClassViolation (65)
- Indicates that the entry violates object class restrictions.
-
- notAllowedOnNonLeaf (66)
- Indicates that the operation is inappropriately acting upon a
- non-leaf entry.
-
- notAllowedOnRDN (67)
- Indicates that the operation is inappropriately attempting to
- remove a value which forms the entry's relative distinguished
- name.
-
- entryAlreadyExists (68)
- Indicates that the request cannot be fulfilled (added, moved,
- or renamed) as the target entry already exists.
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 49
- Lightweight Directory Access Protocol Version 3
-
-
- objectClassModsProhibited (69)
- Indicates that an attempt to modify the object class(es) of
- an entry's 'objectClass' attribute is prohibited.
-
- For example, this code is returned when a client attempts to
- modify the structural object class of an entry.
-
- affectsMultipleDSAs (71)
- Indicates that the operation cannot be performed as it would
- affect multiple servers (DSAs).
-
- other (80)
- Indicates the server has encountered an internal error.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 50
- Lightweight Directory Access Protocol Version 3
-
-Appendix B. Complete ASN.1 Definition
-
- This appendix is normative.
-
- Lightweight-Directory-Access-Protocol-V3 {1 3 6 1 1 <IANA-
- ASSIGNED-DIRECTORY-NUMBER>}
- -- Copyright (C) The Internet Society (2005). This version of
- -- this ASN.1 module is part of RFC XXXX; see the RFC itself
- -- for full legal notices.
- DEFINITIONS
- IMPLICIT TAGS
- EXTENSIBILITY IMPLIED ::=
-
- BEGIN
-
- 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,
- ...,
- intermediateResponse IntermediateResponse },
- controls [0] Controls OPTIONAL }
-
- MessageID ::= INTEGER (0 .. maxInt)
-
- maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
-
- LDAPString ::= OCTET STRING -- UTF-8 encoded,
- -- [ISO10646] characters
-
- LDAPOID ::= OCTET STRING -- Constrained to <numericoid> [Models]
-
- LDAPDN ::= LDAPString -- Constrained to <distinguishedName>
- -- [LDAPDN]
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 51
- Lightweight Directory Access Protocol Version 3
-
- RelativeLDAPDN ::= LDAPString -- Constrained to <name-component>
- -- [LDAPDN]
-
- AttributeDescription ::= LDAPString
- -- Constrained to <attributedescription>
- -- [Models]
-
- AttributeValue ::= OCTET STRING
-
- AttributeValueAssertion ::= SEQUENCE {
- attributeDesc AttributeDescription,
- assertionValue AssertionValue }
-
- AssertionValue ::= OCTET STRING
-
- PartialAttribute ::= SEQUENCE {
- type AttributeDescription,
- vals SET OF value AttributeValue }
-
- Attribute ::= PartialAttribute(WITH COMPONENTS {
- ...,
- vals (SIZE(1..MAX))})
-
- MatchingRuleId ::= LDAPString
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 52
- Lightweight Directory Access Protocol Version 3
-
- LDAPResult ::= SEQUENCE {
- resultCode ENUMERATED {
- success (0),
- operationsError (1),
- protocolError (2),
- timeLimitExceeded (3),
- sizeLimitExceeded (4),
- compareFalse (5),
- compareTrue (6),
- authMethodNotSupported (7),
- strongerAuthRequired (8),
- -- 9 reserved --
- referral (10),
- adminLimitExceeded (11),
- unavailableCriticalExtension (12),
- confidentialityRequired (13),
- saslBindInProgress (14),
- 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),
- objectClassModsProhibited (69),
- -- 70 reserved for CLDAP --
- affectsMultipleDSAs (71),
- -- 72-79 unused --
- other (80),
- ... },
- matchedDN LDAPDN,
- diagnosticMessage LDAPString,
- referral [3] Referral OPTIONAL }
-
- Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI
-
-Sermersheim Internet-Draft - Expires April 2006 Page 53
- Lightweight Directory Access Protocol Version 3
-
-
- URI ::= LDAPString -- limited to characters permitted in
- -- URIs
-
- Controls ::= SEQUENCE OF control Control
-
- Control ::= SEQUENCE {
- controlType LDAPOID,
- criticality BOOLEAN DEFAULT FALSE,
- controlValue OCTET STRING OPTIONAL }
-
- BindRequest ::= [APPLICATION 0] SEQUENCE {
- version INTEGER (1 .. 127),
- name LDAPDN,
- authentication AuthenticationChoice }
-
- AuthenticationChoice ::= CHOICE {
- simple [0] OCTET STRING,
- -- 1 and 2 reserved
- sasl [3] SaslCredentials,
- ... }
-
- SaslCredentials ::= SEQUENCE {
- mechanism LDAPString,
- credentials OCTET STRING OPTIONAL }
-
- BindResponse ::= [APPLICATION 1] SEQUENCE {
- COMPONENTS OF LDAPResult,
- serverSaslCreds [7] OCTET STRING OPTIONAL }
-
- UnbindRequest ::= [APPLICATION 2] NULL
-
- SearchRequest ::= [APPLICATION 3] SEQUENCE {
- baseObject LDAPDN,
- scope ENUMERATED {
- baseObject (0),
- singleLevel (1),
- wholeSubtree (2),
- ... },
- derefAliases ENUMERATED {
- neverDerefAliases (0),
- derefInSearching (1),
- derefFindingBaseObj (2),
- derefAlways (3) },
- sizeLimit INTEGER (0 .. maxInt),
- timeLimit INTEGER (0 .. maxInt),
- typesOnly BOOLEAN,
- filter Filter,
- attributes AttributeSelection }
-
- AttributeSelection ::= SEQUENCE OF selector LDAPString
- -- The LDAPString is constrained to
- -- <attributeSelector> in Section 4.5.1.7
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 54
- Lightweight Directory Access Protocol Version 3
-
- Filter ::= CHOICE {
- and [0] SET SIZE (1..MAX) OF filter Filter,
- or [1] SET SIZE (1..MAX) OF filter Filter,
- not [2] Filter,
- equalityMatch [3] AttributeValueAssertion,
- substrings [4] SubstringFilter,
- greaterOrEqual [5] AttributeValueAssertion,
- lessOrEqual [6] AttributeValueAssertion,
- present [7] AttributeDescription,
- approxMatch [8] AttributeValueAssertion,
- extensibleMatch [9] MatchingRuleAssertion,
- ... }
-
- SubstringFilter ::= SEQUENCE {
- type AttributeDescription,
- substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE {
- initial [0] AssertionValue, -- can occur at most once
- any [1] AssertionValue,
- final [2] AssertionValue } -- can occur at most once
- }
-
- MatchingRuleAssertion ::= SEQUENCE {
- matchingRule [1] MatchingRuleId OPTIONAL,
- type [2] AttributeDescription OPTIONAL,
- matchValue [3] AssertionValue,
- dnAttributes [4] BOOLEAN DEFAULT FALSE }
-
- SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
- objectName LDAPDN,
- attributes PartialAttributeList }
-
- PartialAttributeList ::= SEQUENCE OF
- partialAttribute PartialAttribute
-
- SearchResultReference ::= [APPLICATION 19] SEQUENCE
- SIZE (1..MAX) OF uri URI
-
- SearchResultDone ::= [APPLICATION 5] LDAPResult
-
- ModifyRequest ::= [APPLICATION 6] SEQUENCE {
- object LDAPDN,
- changes SEQUENCE OF change SEQUENCE {
- operation ENUMERATED {
- add (0),
- delete (1),
- replace (2),
- ... },
- modification PartialAttribute } }
-
- ModifyResponse ::= [APPLICATION 7] LDAPResult
-
- AddRequest ::= [APPLICATION 8] SEQUENCE {
- entry LDAPDN,
- attributes AttributeList }
-
-Sermersheim Internet-Draft - Expires April 2006 Page 55
- Lightweight Directory Access Protocol Version 3
-
-
- AttributeList ::= SEQUENCE OF attribute Attribute
-
- AddResponse ::= [APPLICATION 9] LDAPResult
-
- DelRequest ::= [APPLICATION 10] LDAPDN
-
- DelResponse ::= [APPLICATION 11] LDAPResult
-
- ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
- entry LDAPDN,
- newrdn RelativeLDAPDN,
- deleteoldrdn BOOLEAN,
- newSuperior [0] LDAPDN OPTIONAL }
-
- ModifyDNResponse ::= [APPLICATION 13] LDAPResult
-
- CompareRequest ::= [APPLICATION 14] SEQUENCE {
- entry LDAPDN,
- ava AttributeValueAssertion }
-
- CompareResponse ::= [APPLICATION 15] LDAPResult
-
- AbandonRequest ::= [APPLICATION 16] MessageID
-
- ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
- requestName [0] LDAPOID,
- requestValue [1] OCTET STRING OPTIONAL }
-
- ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
- COMPONENTS OF LDAPResult,
- responseName [10] LDAPOID OPTIONAL,
- responseValue [11] OCTET STRING OPTIONAL }
-
- IntermediateResponse ::= [APPLICATION 25] SEQUENCE {
- responseName [0] LDAPOID OPTIONAL,
- responseValue [1] OCTET STRING OPTIONAL }
-
- END
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 56
- Lightweight Directory Access Protocol Version 3
-
-Appendix C. Changes
-
- This appendix is non-normative.
-
- This appendix summarizes substantive changes made to RFC 2251, RFC
- 2830, and RFC 3771.
-
-
-C.1. Changes made to RFC 2251:
-
- This section summarizes the substantive changes made to Sections 1,
- 2, 3.1, and 4 through the remainder of RFC 2251. Readers should
- consult [Models] and [AuthMeth] for summaries of changes to other
- sections.
-
-
-C.1.1. Section 1 (Status of this Memo)
-
- - Removed IESG note. Post publication of RFC 2251, mandatory LDAP
- authentication mechanisms have been standardized which are
- sufficient to remove this note. See [AuthMeth] for authentication
- mechanisms.
-
-
-C.1.2. Section 3.1 (Protocol Model) and others
-
- - Removed notes giving history between LDAP v1, v2 and v3. Instead,
- added sufficient language so that this document can stand on its
- own.
-
-
-C.1.3. Section 4 (Elements of Protocol)
-
- - Clarified where the extensibility features of ASN.1 apply to the
- protocol. This change affected various ASN.1 types by the
- inclusion of ellipses (...) to certain elements.
- - Removed the requirement that servers which implement version 3 or
- later MUST provide the 'supportedLDAPVersion' attribute. This
- statement provided no interoperability advantages.
-
-
-C.1.4. Section 4.1.1 (Message Envelope)
-
- - There was a mandatory requirement for the server to return a
- Notice of Disconnection and drop the transport connection when a
- PDU is malformed in a certain way. This has been updated such that
- the server SHOULD return the Notice of Disconnection, and MUST
- terminate the LDAP Session.
-
-
-C.1.5. Section 4.1.1.1 (Message ID)
-
- - Required that the messageID of requests MUST be non-zero as the
- zero is reserved for Notice of Disconnection.
-
-Sermersheim Internet-Draft - Expires April 2006 Page 57
- Lightweight Directory Access Protocol Version 3
-
- - Specified when it is and isn't appropriate to return an already
- used message id. RFC 2251 accidentally imposed synchronous server
- behavior in its wording of this.
-
-
-C.1.6. Section 4.1.2 (String Types)
-
- - Stated that LDAPOID is constrained to <numericoid> from [Models].
-
-
-C.1.7. Section 4.1.5.1 (Binary Option) and others
-
- - Removed the Binary Option from the specification. There are
- numerous interoperability problems associated with this method of
- alternate attribute type encoding. Work to specify a suitable
- replacement is ongoing.
-
-
-C.1.8. Section 4.1.8 (Attribute)
-
- - Combined the definitions of PartialAttribute and Attribute here,
- and defined Attribute in terms of PartialAttribute.
-
-
-C.1.9. Section 4.1.10 (Result Message)
-
- - Renamed "errorMessage" to "diagnosticMessage" as it is allowed to
- be sent for non-error results.
- - Moved some language into Appendix A, and refer the reader there.
- - Allowed matchedDN to be present for other result codes than those
- listed in RFC 2251.
- - renamed the code "strongAuthRequired" to "strongerAuthRequired" to
- clarify that this code may often be returned to indicate that a
- stronger authentication is needed to perform a given operation.
-
-
-C.1.10. Section 4.1.11 (Referral)
-
- - Defined referrals in terms of URIs rather than URLs.
- - Removed the requirement that all referral URIs MUST be equally
- capable of progressing the operation. The statement was ambiguous
- and provided no instructions on how to carry it out.
- - Added the requirement that clients MUST NOT loop between servers.
- - Clarified the instructions for using LDAPURLs in referrals, and in
- doing so added a recommendation that the scope part be present.
- - Removed imperatives which required clients to use URLs in specific
- ways to progress an operation. These did nothing for
- interoperability.
-
-
-C.1.11. Section 4.1.12 (Controls)
-
- - Specified how control values defined in terms of ASN.1 are to be
- encoded.
-
-Sermersheim Internet-Draft - Expires April 2006 Page 58
- Lightweight Directory Access Protocol Version 3
-
- - Noted that the criticality field is only applied to request
- messages (except UnbindRequest), and must be ignored when present
- on response messages and UnbindRequest.
- - Specified that non-critical controls may be ignored at the
- server's discretion. There was confusion in the original wording
- which led some to believe that recognized controls may not be
- ignored as long as they were associated with a proper request.
- - Added language regarding combinations of controls and the ordering
- of controls on a message.
- - Specified that when the semantics of the combination of controls
- is undefined or unknown, it results in a protocolError.
- - Changed "The server MUST be prepared" to "Implementations MUST be
- prepared" in the eighth paragraph to reflect that both client and
- server implementations must be able to handle this (as both parse
- controls).
-
-
-C.1.12. Section 4.2 (Bind Operation)
-
- - Mandated that servers return protocolError when the version is not
- supported.
- - Disambiguated behavior when the simple authentication is used, the
- name is empty and the password is non-empty.
- - Required servers to not dereference aliases for Bind. This was
- added for consistency with other operations and to help ensure
- data consistency.
- - Required that textual passwords be transferred as UTF-8 encoded
- Unicode, and added recommendations on string preparation. This was
- to help ensure interoperability of passwords being sent from
- different clients.
-
-
-C.1.13. Section 4.2.1 (Sequencing of the Bind Request)
-
- - This section was largely reorganized for readability and language
- was added to clarify the authentication state of failed and
- abandoned Bind operations.
- - Removed: "If a SASL transfer encryption or integrity mechanism has
- been negotiated, that mechanism does not support the changing of
- credentials from one identity to another, then the client MUST
- instead establish a new connection."
- If there are dependencies between multiple negotiations of a
- particular SASL mechanism, the technical specification for that
- SASL mechanism details how applications are to deal with them.
- LDAP should not require any special handling.
- - Dropped MUST imperative in paragraph 3 to align with [Keywords].
- - Mandated that clients not send non-Bind operations while a Bind is
- in progress, and suggested that servers not process them if they
- are received. This is needed to ensure proper sequencing of the
- Bind in relationship to other operations.
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 59
- Lightweight Directory Access Protocol Version 3
-
-C.1.14. Section 4.2.3 (Bind Response)
-
- - Moved most error-related text to Appendix A, and added text
- regarding certain errors used in conjunction with the Bind
- operation.
- - Prohibited the server from specifying serverSaslCreds when not
- appropriate.
-
-
-C.1.15. Section 4.3 (Unbind Operation)
-
- - Specified that both peers are to cease transmission and terminate
- the LDAP session for the Unbind operation.
-
-
-C.1.16. Section 4.4 (Unsolicited Notification)
-
- - Added instructions for future specifications of Unsolicited
- Notifications.
-
-
-C.1.17. Section 4.5.1 (Search Request)
-
- - SearchRequest attributes is now defined as an AttributeSelection
- type rather than AttributeDescriptionList, and an ABNF is
- provided.
- - SearchRequest attributes may contain duplicate attribute
- descriptions. This was previously prohibited. Now servers are
- instructed to ignore subsequent names when they are duplicated.
- This was relaxed in order to allow different short names and also
- OIDs to be requested for an attribute.
- - The present search filter now evaluates to Undefined when the
- specified attribute is not known to the server. It used to
- evaluate to FALSE, which caused behavior inconsistent with what
- most would expect, especially when the not operator was used.
- - The Filter choice SubstringFilter substrings type is now defined
- with a lower bound of 1.
- - The SubstringFilter substrings 'initial, 'any', and 'final' types
- are now AssertionValue rather than LDAPString. Also, added
- imperatives stating that 'initial' (if present) must be listed
- first, and 'final' (if present) must be listed last.
- - Disambiguated the semantics of the derefAliases choices. There was
- question as to whether derefInSearching applied to the base object
- in a wholeSubtree Search.
- - Added instructions for equalityMatch, substrings, greaterOrEqual,
- lessOrEqual, and approxMatch.
-
-
-C.1.18. Section 4.5.2 (Search Result)
-
- - Recommended that servers not use attribute short names when it
- knows they are ambiguous or may cause interoperability problems.
- - Removed all mention of ExtendedResponse due to lack of
- implementation.
-
-Sermersheim Internet-Draft - Expires April 2006 Page 60
- Lightweight Directory Access Protocol Version 3
-
-
-
-C.1.19. Section 4.5.3 (Continuation References in the Search Result)
-
- - Made changes similar to those made to Section 4.1.11.
-
-
-C.1.20. Section 4.5.3.1 (Example)
-
- - Fixed examples to adhere to changes made to Section 4.5.3.
-
-
-C.1.21. Section 4.6 (Modify Operation)
-
- - Replaced AttributeTypeAndValues with Attribute as they are
- equivalent.
- - Specified the types of modification changes which might
- temporarily violate schema. Some readers were under the impression
- that any temporary schema violation was allowed.
-
-
-C.1.22. Section 4.7 (Add Operation)
-
- - Aligned Add operation with X.511 in that the attributes of the RDN
- are used in conjunction with the listed attributes to create the
- entry. Previously, Add required that the distinguished values be
- present in the listed attributes.
- - Removed requirement that the objectClass attribute MUST be
- specified as some DSE types do not require this attribute.
- Instead, generic wording was added, requiring the added entry to
- adhere to the data model.
- - Removed recommendation regarding placement of objects. This is
- covered in the data model document.
-
-
-C.1.23. Section 4.9 (Modify DN Operation)
-
- - Required servers to not dereference aliases for Modify DN. This
- was added for consistency with other operations and to help ensure
- data consistency.
- - Allow Modify DN to fail when moving between naming contexts.
- - Specified what happens when the attributes of the newrdn are not
- present on the entry.
-
-
-C.1.24. Section 4.10 (Compare Operation)
-
- - Specified that compareFalse means that the Compare took place and
- the result is false. There was confusion which lead people to
- believe that an Undefined match resulted in compareFalse.
- - Required servers to not dereference aliases for Compare. This was
- added for consistency with other operations and to help ensure
- data consistency.
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 61
- Lightweight Directory Access Protocol Version 3
-
-
-C.1.25. Section 4.11 (Abandon Operation)
-
- - Explained that since Abandon returns no response, clients should
- not use it if they need to know the outcome.
- - Specified that Abandon and Unbind cannot be abandoned.
-
-
-C.1.26. Section 4.12 (Extended Operation)
-
- - Specified how values of Extended operations defined in terms of
- ASN.1 are to be encoded.
- - Added instructions on what Extended operation specifications
- consist of.
- - Added a recommendation that servers advertise supported Extended
- operations.
-
-
-C.1.27. Section 5.2 (Transfer Protocols)
-
- - Moved referral-specific instructions into referral-related
- sections.
-
-
-C.1.28. Section 7 (Security Considerations)
-
- - Reworded notes regarding SASL not protecting certain aspects of
- the LDAP Bind messages.
- - Noted that Servers are encouraged to prevent directory
- modifications by clients that have authenticated anonymously
- [AuthMeth].
- - Added a note regarding the possibility of changes to security
- factors (authentication, authorization, data confidentiality).
- - Warned against following referrals that may have been injected in
- the data stream.
- - Noted that servers should protect information equally, whether in
- an error condition or not, and mentioned specifically; matchedDN,
- diagnosticMessage, and resultCodes.
- - Added a note regarding malformed and long encodings.
-
-
-C.1.29. Appendix A (Complete ASN.1 Definition)
-
- - Added "EXTENSIBILITY IMPLIED" to ASN.1 definition.
- - Removed AttributeType. It is not used.
-
-
-C.2. Changes made to RFC 2830:
-
- This section summarizes the substantive changes made to Sections of
- RFC 2830. Readers should consult [AuthMeth] for summaries of changes
- to other sections.
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 62
- Lightweight Directory Access Protocol Version 3
-
-C.2.1. Section 2.3 (Response other than "success")
-
- - Removed wording indicating that referrals can be returned from
- StartTLS.
- - Removed requirement that only a narrow set of result codes can be
- returned. Some result codes are required in certain scenarios, but
- any other may be returned if appropriate.
- - Removed requirement that the ExtendedResponse.responseName MUST be
- present. There are circumstances where this is impossible, and
- requiring this is at odds with language in Section 4.12.
-
-
-C.2.1. Section 4 (Closing a TLS Connection)
-
- - Reworded most of this section to align with definitions of the
- LDAP protocol layers.
- - Removed instructions on abrupt closure as this is covered in other
- areas of the document (specifically, Section 5.3)
-
-
-C.3. Changes made to RFC 3771:
-
- - Rewrote to fit into this document. In general, semantics were
- preserved. Supporting and background language seen as redundant
- due to its presence in this document was omitted.
- - Specified that Intermediate responses to a request may be of
- different types, and one of the response types may be specified to
- have no response value.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 63
- Lightweight Directory Access Protocol Version 3
-
-
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at ietf-
- ipr@ietf.org.
-
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2005).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 64
\ No newline at end of file
+
+
+Internet-Draft Editor: J. Sermersheim
+Intended Category: Standard Track Novell, Inc
+Document: draft-ietf-ldapbis-protocol-32.txt Oct 2005
+Obsoletes: RFCs 2251, 2830, 3771
+
+
+ LDAP: The Protocol
+
+
+Status of this Memo
+
+ By submitting this Internet-Draft, each
+ author represents that any applicable patent or other IPR claims of
+ which he or she is aware have been or will be disclosed, and any of
+ which he or she becomes aware will be disclosed, in accordance with
+ Section 6 of BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that other
+ groups may also distribute working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress".
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire in February 2005.
+
+ Technical discussion of this document will take place on the IETF
+ LDAP Revision Working Group (LDAPbis) mailing list <ietf-
+ ldapbis@openldap.org>. Please send editorial comments directly to the
+ editor <jimse@novell.com>.
+
+
+Abstract
+
+ This document describes the protocol elements, along with their
+ semantics and encodings, of the Lightweight Directory Access Protocol
+ (LDAP). LDAP provides access to distributed directory services that
+ act in accordance with X.500 data and service models. These protocol
+ elements are based on those described in the X.500 Directory Access
+ Protocol (DAP).
+
+
+Table of Contents
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 1
+ Lightweight Directory Access Protocol Version 3
+
+ 1. Introduction....................................................3
+ 1.1. Relationship to Other LDAP Specifications.....................3
+ 2. Conventions.....................................................3
+ 3. Protocol Model..................................................4
+ 3.1 Operation and LDAP Message Layer Relationship..................5
+ 4. Elements of Protocol............................................5
+ 4.1. Common Elements...............................................5
+ 4.1.1. Message Envelope............................................5
+ 4.1.2. String Types................................................7
+ 4.1.3. Distinguished Name and Relative Distinguished Name..........7
+ 4.1.4. Attribute Descriptions......................................8
+ 4.1.5. Attribute Value.............................................8
+ 4.1.6. Attribute Value Assertion...................................8
+ 4.1.7. Attribute and PartialAttribute..............................9
+ 4.1.8. Matching Rule Identifier....................................9
+ 4.1.9. Result Message..............................................9
+ 4.1.10. Referral..................................................11
+ 4.1.11. Controls..................................................13
+ 4.2. Bind Operation...............................................14
+ 4.3. Unbind Operation.............................................17
+ 4.4. Unsolicited Notification.....................................17
+ 4.5. Search Operation.............................................18
+ 4.6. Modify Operation.............................................29
+ 4.7. Add Operation................................................31
+ 4.8. Delete Operation.............................................31
+ 4.9. Modify DN Operation..........................................32
+ 4.10. Compare Operation...........................................33
+ 4.11. Abandon Operation...........................................34
+ 4.12. Extended Operation..........................................35
+ 4.13. IntermediateResponse Message................................36
+ 4.14. StartTLS Operation..........................................37
+ 5. Protocol Encoding, Connection, and Transfer....................39
+ 5.1. Protocol Encoding............................................39
+ 5.2. Transmission Control Protocol (TCP)..........................40
+ 5.3. Termination of the LDAP session..............................40
+ 6. Security Considerations........................................40
+ 7. Acknowledgements...............................................42
+ 8. Normative References...........................................42
+ 9. Informative References.........................................44
+ 10. IANA Considerations...........................................44
+ 11. Editor's Address..............................................45
+ Appendix A - LDAP Result Codes....................................46
+ A.1 Non-Error Result Codes........................................46
+ A.2 Result Codes..................................................46
+ Appendix B - Complete ASN.1 Definition............................51
+ Appendix C - Changes..............................................57
+ C.1 Changes made to RFC 2251:.....................................57
+ C.2 Changes made to RFC 2830:.....................................62
+ C.3 Changes made to RFC 3771:.....................................63
+
+
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 2
+ Lightweight Directory Access Protocol Version 3
+
+1. Introduction
+
+ The Directory is "a collection of open systems cooperating to provide
+ directory services" [X.500]. A directory user, which may be a human
+ or other entity, accesses the Directory through a client (or
+ Directory User Agent (DUA)). The client, on behalf of the directory
+ user, interacts with one or more servers (or Directory System Agents
+ (DSA)). Clients interact with servers using a directory access
+ protocol.
+
+ This document details the protocol elements of the Lightweight
+ Directory Access Protocol (LDAP), along with their semantics.
+ Following the description of protocol elements, it describes the way
+ in which the protocol elements are encoded and transferred.
+
+
+1.1. Relationship to Other LDAP Specifications
+
+ This document is an integral part of the LDAP Technical Specification
+ [Roadmap] which obsoletes the previously defined LDAP technical
+ specification, RFC 3377, in its entirety.
+
+ This document, together with [Roadmap], [AuthMeth], and [Models],
+ obsoletes RFC 2251 in its entirety. Section 3.3 is obsoleted by
+ [Roadmap]. Sections 4.2.1 (portions), and 4.2.2 are obsoleted by
+ [AuthMeth]. Sections 3.2, 3.4, 4.1.3 (last paragraph), 4.1.4, 4.1.5,
+ 4.1.5.1, 4.1.9 (last paragraph), 5.1, 6.1, and 6.2 (last paragraph)
+ are obsoleted by [Models]. The remainder of RFC 2251 is obsoleted by
+ this document. Appendix C.1 summarizes substantive changes in the
+ remainder.
+
+ This document obsoletes RFC 2830, Sections 2 and 4. The remainder of
+ RFC 2830 is obsoleted by [AuthMeth]. Appendix C.2 summarizes
+ substantive changes to the remaining sections.
+
+ This document also obsoletes RFC 3771 in entirety.
+
+
+2. Conventions
+
+ 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 [Keyword].
+
+ Character names in this document use the notation for code points and
+ names from the Unicode Standard [Unicode]. For example, the letter
+ "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
+
+ Note: a glossary of terms used in Unicode can be found in [Glossary].
+ Information on the Unicode character encoding model can be found in
+ [CharModel].
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 3
+ Lightweight Directory Access Protocol Version 3
+
+ The term "transport connection" refers to the underlying transport
+ services used to carry the protocol exchange, as well as associations
+ established by these services.
+
+ The term "TLS layer" refers to TLS services used in providing
+ security services, as well as associations established by these
+ services.
+
+ The term "SASL layer" refers to SASL services used in providing
+ security services, as well as associations established by these
+ services.
+
+ The term "LDAP message layer" refers to the LDAP Message Protocol
+ Data Unit (PDU) services used in providing directory services, as
+ well as associations established by these services.
+
+ The term "LDAP session" refers to combined services (transport
+ connection, TLS layer, SASL layer, LDAP message layer) and their
+ associations.
+
+ See the table in Section 5 for an illustration of these four terms.
+
+
+3. Protocol Model
+
+ The general model adopted by this protocol is one of clients
+ performing protocol operations against servers. In this model, a
+ client transmits a protocol request describing the operation to be
+ performed to a server. The server is then responsible for performing
+ the necessary operation(s) in the Directory. Upon completion of an
+ operation, the server typically returns a response containing
+ appropriate data to the requesting client.
+
+ Protocol operations are generally independent of one another. Each
+ operation is processed as an atomic action, leaving the directory in
+ a consistent state.
+
+ Although servers are required to return responses whenever such
+ responses are defined in the protocol, there is no requirement for
+ synchronous behavior on the part of either clients or servers.
+ Requests and responses for multiple operations generally may be
+ exchanged between a client and server in any order. If required,
+ synchronous behavior may be controlled by client applications.
+
+ The core protocol operations defined in this document can be mapped
+ to a subset of the X.500 (1993) Directory Abstract Service [X.511].
+ However there is not a one-to-one mapping between LDAP operations and
+ X.500 Directory Access Protocol (DAP) operations. Server
+ implementations acting as a gateway to X.500 directories may need to
+ make multiple DAP requests to service a single LDAP request.
+
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 4
+ Lightweight Directory Access Protocol Version 3
+
+
+3.1. Operation and LDAP Message Layer Relationship
+
+ Protocol operations are exchanged at the LDAP message layer. When the
+ transport connection is closed, any uncompleted operations at the
+ LDAP message layer, when possible, are abandoned, and when not
+ possible, are completed without transmission of the response. Also,
+ when the transport connection is closed, the client MUST NOT assume
+ that any uncompleted update operations have succeeded or failed.
+
+
+4. Elements of Protocol
+
+ The protocol is described using Abstract Syntax Notation One
+ ([ASN.1]), and is transferred using a subset of ASN.1 Basic Encoding
+ Rules ([BER]). Section 5 specifies how the protocol elements are
+ encoded and transferred.
+
+ In order to support future extensions to this protocol, extensibility
+ is implied where it is allowed per ASN.1 (i.e. sequence, set, choice,
+ and enumerated types are extensible). In addition, ellipses (...)
+ have been supplied in ASN.1 types that are explicitly extensible as
+ discussed in [LDAPIANA]. Because of the implied extensibility,
+ clients and servers MUST (unless otherwise specified) ignore trailing
+ SEQUENCE components whose tags they do not recognize.
+
+ Changes to the protocol other than through the extension mechanisms
+ described here require a different version number. A client indicates
+ the version it is using as part of the BindRequest, described in
+ Section 4.2. If a client has not sent a Bind, the server MUST assume
+ the client is using version 3 or later.
+
+ Clients may attempt to determine the protocol versions a server
+ supports by reading the 'supportedLDAPVersion' attribute from the
+ root DSE (DSA-Specific Entry) [Models].
+
+
+4.1. Common Elements
+
+ This section describes the LDAPMessage envelope Protocol Data Unit
+ (PDU) format, as well as data type definitions, which are used in the
+ protocol operations.
+
+
+4.1.1. Message Envelope
+
+ For the purposes of protocol exchanges, all protocol operations are
+ encapsulated in a common envelope, the LDAPMessage, which is defined
+ as follows:
+
+
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 5
+ Lightweight Directory Access Protocol Version 3
+
+ 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,
+ ...,
+ intermediateResponse IntermediateResponse },
+ controls [0] Controls OPTIONAL }
+
+ MessageID ::= INTEGER (0 .. maxInt)
+
+ maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
+
+ The ASN.1 type Controls is defined in Section 4.1.11.
+
+ The function of the LDAPMessage is to provide an envelope containing
+ common fields required in all protocol exchanges. At this time the
+ only common fields are the messageID and the controls.
+
+ If the server receives an LDAPMessage from the client in which the
+ LDAPMessage SEQUENCE tag cannot be recognized, the messageID cannot
+ be parsed, the tag of the protocolOp is not recognized as a request,
+ or the encoding structures or lengths of data fields are found to be
+ incorrect, then the server SHOULD return the Notice of Disconnection
+ described in Section 4.4.1, with the resultCode set to protocolError,
+ and MUST immediately terminate the LDAP session as described in
+ Section 5.3.
+
+ In other cases where the client or server cannot parse an LDAP PDU,
+ it SHOULD abruptly terminate the LDAP session (Section 5.3) where
+ further communication (including providing notice) would be
+ pernicious. Otherwise, server implementations MUST return an
+ appropriate response to the request, with the resultCode set to
+ protocolError.
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 6
+ Lightweight Directory Access Protocol Version 3
+
+4.1.1.1. Message ID
+
+ All LDAPMessage envelopes encapsulating responses contain the
+ messageID value of the corresponding request LDAPMessage.
+
+ The message ID of a request MUST have a non-zero value different from
+ the messageID of any other request in progress in the same LDAP
+ session. The zero value is reserved for the unsolicited notification
+ message.
+
+ Typical clients increment a counter for each request.
+
+ A client MUST NOT send a request with the same message ID as an
+ earlier request in the same LDAP session unless it can be determined
+ that the server is no longer servicing the earlier request (e.g.
+ after the final response is received, or a subsequent Bind
+ completes). Otherwise the behavior is undefined. For this purpose,
+ note that Abandon and successfully abandoned operations do not send
+ responses.
+
+
+4.1.2. String Types
+
+ The LDAPString is a notational convenience to indicate that, although
+ strings of LDAPString type encode as ASN.1 OCTET STRING types, the
+ [ISO10646] character set (a superset of [Unicode]) is used, encoded
+ following the [UTF-8] algorithm. Note that Unicode characters U+0000
+ through U+007F are the same as ASCII 0 through 127, respectively, and
+ have the same single octet UTF-8 encoding. Other Unicode characters
+ have a multiple octet UTF-8 encoding.
+
+ LDAPString ::= OCTET STRING -- UTF-8 encoded,
+ -- [ISO10646] characters
+
+ The LDAPOID is a notational convenience to indicate that the
+ permitted value of this string is a (UTF-8 encoded) dotted-decimal
+ representation of an OBJECT IDENTIFIER. Although an LDAPOID is
+ encoded as an OCTET STRING, values are limited to the definition of
+ <numericoid> given in Section 1.4 of [Models].
+
+ LDAPOID ::= OCTET STRING -- Constrained to <numericoid> [Models]
+
+ For example,
+
+ 1.3.6.1.4.1.1466.1.2.3
+
+
+4.1.3. Distinguished Name and Relative Distinguished Name
+
+ An LDAPDN is defined to be the representation of a Distinguished Name
+ (DN) after encoding according to the specification in [LDAPDN].
+
+ LDAPDN ::= LDAPString
+ -- Constrained to <distinguishedName> [LDAPDN]
+
+Sermersheim Internet-Draft - Expires April 2006 Page 7
+ Lightweight Directory Access Protocol Version 3
+
+
+ A RelativeLDAPDN is defined to be the representation of a Relative
+ Distinguished Name (RDN) after encoding according to the
+ specification in [LDAPDN].
+
+ RelativeLDAPDN ::= LDAPString
+ -- Constrained to <name-component> [LDAPDN]
+
+
+4.1.4. Attribute Descriptions
+
+ The definition and encoding rules for attribute descriptions are
+ defined in Section 2.5 of [Models]. Briefly, an attribute description
+ is an attribute type and zero or more options.
+
+ AttributeDescription ::= LDAPString
+ -- Constrained to <attributedescription>
+ -- [Models]
+
+
+4.1.5. Attribute Value
+
+ A field of type AttributeValue is an OCTET STRING containing an
+ encoded attribute value. The attribute value is encoded according to
+ the LDAP-specific encoding definition of its corresponding syntax.
+ The LDAP-specific encoding definitions for different syntaxes and
+ attribute types may be found in other documents and in particular
+ [Syntaxes].
+
+ AttributeValue ::= OCTET STRING
+
+ Note that there is no defined limit on the size of this encoding;
+ thus protocol values may include multi-megabyte attribute values
+ (e.g. photographs).
+
+ Attribute values may be defined which have arbitrary and non-
+ printable syntax. Implementations MUST NOT display nor attempt to
+ decode an attribute value if its syntax is not known. The
+ implementation may attempt to discover the subschema of the source
+ entry, and retrieve the descriptions of 'attributeTypes' from it
+ [Models].
+
+ Clients MUST only send attribute values in a request that are valid
+ according to the syntax defined for the attributes.
+
+
+4.1.6. Attribute Value Assertion
+
+ The AttributeValueAssertion (AVA) type definition is similar to the
+ one in the X.500 Directory standards. It contains an attribute
+ description and a matching rule ([Models] Section 4.1.3) assertion
+ value suitable for that type. Elements of this type are typically
+ used to assert that the value in assertionValue matches a value of an
+ attribute.
+
+Sermersheim Internet-Draft - Expires April 2006 Page 8
+ Lightweight Directory Access Protocol Version 3
+
+
+ AttributeValueAssertion ::= SEQUENCE {
+ attributeDesc AttributeDescription,
+ assertionValue AssertionValue }
+
+ AssertionValue ::= OCTET STRING
+
+ The syntax of the AssertionValue depends on the context of the LDAP
+ operation being performed. For example, the syntax of the EQUALITY
+ matching rule for an attribute is used when performing a Compare
+ operation. Often this is the same syntax used for values of the
+ attribute type, but in some cases the assertion syntax differs from
+ the value syntax. See objectIdentiferFirstComponentMatch in
+ [Syntaxes] for an example.
+
+
+4.1.7. Attribute and PartialAttribute
+
+ Attributes and partial attributes consist of an attribute description
+ and attribute values. A PartialAttribute allows zero values, while
+ Attribute requires at least one value.
+
+ PartialAttribute ::= SEQUENCE {
+ type AttributeDescription,
+ vals SET OF value AttributeValue }
+
+ Attribute ::= PartialAttribute(WITH COMPONENTS {
+ ...,
+ vals (SIZE(1..MAX))})
+
+ No two of the attribute values may be equivalent as described by
+ Section 2.3 of [Models]. The set of attribute values is unordered.
+ Implementations MUST NOT rely upon the ordering being repeatable.
+
+
+4.1.8. Matching Rule Identifier
+
+ Matching rules are defined in Section 4.1.3 of [Models]. A matching
+ rule is identified in the protocol by the printable representation of
+ either its <numericoid>, or one of its short name descriptors
+ [Models], e.g. 'caseIgnoreMatch' or '2.5.13.2'.
+
+ MatchingRuleId ::= LDAPString
+
+
+4.1.9. Result Message
+
+ The LDAPResult is the construct used in this protocol to return
+ success or failure indications from servers to clients. To various
+ requests, servers will return responses containing the elements found
+ in LDAPResult to indicate the final status of the protocol operation
+ request.
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 9
+ Lightweight Directory Access Protocol Version 3
+
+ LDAPResult ::= SEQUENCE {
+ resultCode ENUMERATED {
+ success (0),
+ operationsError (1),
+ protocolError (2),
+ timeLimitExceeded (3),
+ sizeLimitExceeded (4),
+ compareFalse (5),
+ compareTrue (6),
+ authMethodNotSupported (7),
+ strongerAuthRequired (8),
+ -- 9 reserved --
+ referral (10),
+ adminLimitExceeded (11),
+ unavailableCriticalExtension (12),
+ confidentialityRequired (13),
+ saslBindInProgress (14),
+ 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),
+ objectClassModsProhibited (69),
+ -- 70 reserved for CLDAP --
+ affectsMultipleDSAs (71),
+ -- 72-79 unused --
+ other (80),
+ ... },
+ matchedDN LDAPDN,
+ diagnosticMessage LDAPString,
+ referral [3] Referral OPTIONAL }
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 10
+ Lightweight Directory Access Protocol Version 3
+
+ The resultCode enumeration is extensible as defined in Section 3.6 of
+ [LDAPIANA]. The meanings of the listed result codes are given in
+ Appendix A. If a server detects multiple errors for an operation,
+ only one result code is returned. The server should return the result
+ code that best indicates the nature of the error encountered. Servers
+ may return substituted result codes to prevent unauthorized
+ disclosures.
+
+ The diagnosticMessage field of this construct may, at the server's
+ option, be used to return a string containing a textual, human-
+ readable (terminal control and page formatting characters should be
+ avoided) diagnostic message. As this diagnostic message is not
+ standardized, implementations MUST NOT rely on the values returned.
+ Diagnostic messages typically supplement the resultCode with
+ additional information. If the server chooses not to return a textual
+ diagnostic, the diagnosticMessage field MUST be empty.
+
+ For certain result codes (typically, but not restricted to
+ noSuchObject, aliasProblem, invalidDNSyntax and
+ aliasDereferencingProblem), the matchedDN field is set (subject to
+ access controls) to the name of the last entry (object or alias) used
+ in finding the target (or base) object. This will be a truncated form
+ of the provided name or, if an alias was dereferenced while
+ attempting to locate the entry, of the resulting name. Otherwise the
+ matchedDN field is empty.
+
+
+4.1.10. Referral
+
+ The referral result code indicates that the contacted server cannot
+ or will not perform the operation and that one or more other servers
+ may be able to. Reasons for this include:
+
+ - The target entry of the request is not held locally, but the
+ server has knowledge of its possible existence elsewhere.
+
+ - The operation is restricted on this server -- perhaps due to a
+ read-only copy of an entry to be modified.
+
+ The referral field is present in an LDAPResult if the resultCode is
+ set to referral, and absent with all other result codes. It contains
+ one or more references to one or more servers or services that may be
+ accessed via LDAP or other protocols. Referrals can be returned in
+ response to any operation request (except Unbind and Abandon which do
+ not have responses). At least one URI MUST be present in the
+ Referral.
+
+ During a Search operation, after the baseObject is located, and
+ entries are being evaluated, the referral is not returned. Instead,
+ continuation references, described in Section 4.5.3, are returned
+ when other servers would need to be contacted to complete the
+ operation.
+
+ Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI
+
+Sermersheim Internet-Draft - Expires April 2006 Page 11
+ Lightweight Directory Access Protocol Version 3
+
+
+ URI ::= LDAPString -- limited to characters permitted in
+ -- URIs
+
+ If the client wishes to progress the operation, it contacts one of
+ the supported services found in the referral. If multiple URIs are
+ present, the client assumes that any supported URI may be used to
+ progress the operation.
+
+ Clients that follow referrals MUST ensure that they do not loop
+ between servers. They MUST NOT repeatedly contact the same server for
+ the same request with the same parameters. Some clients use a counter
+ that is incremented each time referral handling occurs for an
+ operation, and these kinds of clients MUST be able to handle at least
+ ten nested referrals while progressing the operation.
+
+ A URI for a server implementing LDAP and accessible via [TCP]/[IP]
+ (v4 or v6) is written as an LDAP URL according to [LDAPURL].
+
+ Referral values which are LDAP URLs follow these rules:
+
+ - If an alias was dereferenced, the <dn> part of the LDAP URL MUST
+ be present, with the new target object name.
+
+ - It is RECOMMENDED that the <dn> part be present to avoid
+ ambiguity.
+
+ - If the <dn> part is present, the client uses this name in its next
+ request to progress the operation, and if it is not present the
+ client uses the same name as in the original request.
+
+ - Some servers (e.g. participating in distributed indexing) may
+ provide a different filter in a URL of a referral for a Search
+ operation.
+
+ - If the <filter> part of the LDAP URL is present, the client uses
+ this filter in its next request to progress this Search, and if it
+ is not present the client uses the same filter as it used for that
+ Search.
+
+ - For Search, it is RECOMMENDED that the <scope> part be present to
+ avoid ambiguity.
+
+ - If the <scope> part is missing, the scope of the original Search
+ is used by the client to progress the operation.
+
+ - Other aspects of the new request may be the same as or different
+ from the request which generated the referral.
+
+ Other kinds of URIs may be returned. The syntax and semantics of such
+ URIs is left to future specifications. Clients may ignore URIs that
+ they do not support.
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 12
+ Lightweight Directory Access Protocol Version 3
+
+ UTF-8 encoded characters appearing in the string representation of a
+ DN, search filter, or other fields of the referral value may not be
+ legal for URIs (e.g. spaces) and MUST be escaped using the % method
+ in [URI].
+
+
+4.1.11. Controls
+
+ Controls provide a mechanism whereby the semantics and arguments of
+ existing LDAP operations may be extended. One or more controls may be
+ attached to a single LDAP message. A control only affects the
+ semantics of the message it is attached to.
+
+ Controls sent by clients are termed 'request controls' and those sent
+ by servers are termed 'response controls'.
+
+ Controls ::= SEQUENCE OF control Control
+
+ Control ::= SEQUENCE {
+ controlType LDAPOID,
+ criticality BOOLEAN DEFAULT FALSE,
+ controlValue OCTET STRING OPTIONAL }
+
+ The controlType field is the dotted-decimal representation of an
+ OBJECT IDENTIFIER which uniquely identifies the control. This
+ provides unambiguous naming of controls. Often, response control(s)
+ solicited by a request control share controlType values with the
+ request control.
+
+ The criticality field only has meaning in controls attached to
+ request messages (except UnbindRequest). For controls attached to
+ response messages and the UnbindRequest, the criticality field SHOULD
+ be FALSE, and MUST be ignored by the receiving protocol peer. A value
+ of TRUE indicates that it is unacceptable to perform the operation
+ without applying the semantics of the control. Specifically, the
+ criticality field is applied as follows:
+
+ - If the server does not recognize the control type, determines that
+ it is not appropriate for the operation, or is otherwise unwilling
+ to perform the operation with the control, and the criticality
+ field is TRUE, the server MUST NOT perform the operation, and for
+ operations that have a response message, MUST return with the
+ resultCode set to unavailableCriticalExtension.
+
+ - If the server does not recognize the control type, determines that
+ it is not appropriate for the operation, or is otherwise unwilling
+ to perform the operation with the control, and the criticality
+ field is FALSE, the server MUST ignore the control.
+
+ - Regardless of criticality, if a control is applied to an
+ operation, it is applied consistently and impartially to the
+ entire operation.
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 13
+ Lightweight Directory Access Protocol Version 3
+
+ The controlValue may contain information associated with the
+ controlType. Its format is defined by the specification of the
+ control. Implementations MUST be prepared to handle arbitrary
+ contents of the controlValue octet string, including zero bytes. It
+ is absent only if there is no value information which is associated
+ with a control of its type. When a controlValue is defined in terms
+ of ASN.1, and BER encoded according to Section 5.1, it also follows
+ the extensibility rules in Section 4.
+
+ Servers list the controlType of request controls they recognize in
+ the 'supportedControl' attribute in the root DSE (Section 5.1 of
+ [Models]).
+
+ Controls SHOULD NOT be combined unless the semantics of the
+ combination has been specified. The semantics of control
+ combinations, if specified, are generally found in the control
+ specification most recently published. When a combination of controls
+ is encountered whose semantics are invalid, not specified (or not
+ known), the message is considered to be not well-formed, thus the
+ operation fails with protocolError. Controls with a criticality of
+ FALSE may be ignored in order to arrive at a valid combination.
+ Additionally, unless order-dependent semantics are given in a
+ specification, the order of a combination of controls in the SEQUENCE
+ is ignored. Where the order is to be ignored but cannot be ignored by
+ the server, the message is considered not well-formed and the
+ operation fails with protocolError. Again, controls with a
+ criticality of FALSE may be ignored in order to arrive at a valid
+ combination.
+
+ This document does not specify any controls. Controls may be
+ specified in other documents. Documents detailing control extensions
+ are to provide for each control:
+
+ - the OBJECT IDENTIFIER assigned to the control,
+
+ - direction as to what value the sender should provide for the
+ criticality field (note: the semantics of the criticality field
+ are defined above should not be altered by the control's
+ specification),
+
+ - whether the controlValue field is present, and if so, the format
+ of its contents,
+
+ - the semantics of the control, and
+
+ - optionally, semantics regarding the combination of the control
+ with other controls.
+
+
+4.2. Bind Operation
+
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 14
+ Lightweight Directory Access Protocol Version 3
+
+ The function of the Bind operation is to allow authentication
+ information to be exchanged between the client and server. The Bind
+ operation should be thought of as the "authenticate" operation.
+ Operational, authentication, and security-related semantics of this
+ operation are given in [AuthMeth].
+
+ The Bind request is defined as follows:
+
+ BindRequest ::= [APPLICATION 0] SEQUENCE {
+ version INTEGER (1 .. 127),
+ name LDAPDN,
+ authentication AuthenticationChoice }
+
+ AuthenticationChoice ::= CHOICE {
+ simple [0] OCTET STRING,
+ -- 1 and 2 reserved
+ sasl [3] SaslCredentials,
+ ... }
+
+ SaslCredentials ::= SEQUENCE {
+ mechanism LDAPString,
+ credentials OCTET STRING OPTIONAL }
+
+ Fields of the BindRequest are:
+
+ - version: A version number indicating the version of the protocol
+ to be used at the LDAP message layer. This document describes
+ version 3 of the protocol. There is no version negotiation. The
+ client sets this field to the version it desires. If the server
+ does not support the specified version, it MUST respond with a
+ BindResponse where the resultCode is set to protocolError.
+
+ - name: If not empty, the name of the Directory object that the
+ client wishes to bind as. This field may take on a null value (a
+ zero length string) for the purposes of anonymous binds
+ ([AuthMeth] Section 5.1) or when using Simple Authentication and
+ Security Layer [SASL] authentication ([AuthMeth] Section 5.2).
+ Where the server attempts to locate the named object, it SHALL NOT
+ perform alias dereferencing.
+
+ - authentication: information used in authentication. This type is
+ extensible as defined in Section 3.7 of [LDAPIANA]. Servers that
+ do not support a choice supplied by a client return a BindResponse
+ with the resultCode set to authMethodNotSupported.
+
+ Textual passwords (consisting of a character sequence with a known
+ character set and encoding) transferred to the server using the
+ simple AuthenticationChoice SHALL be transferred as [UTF-8]
+ encoded [Unicode]. Prior to transfer, clients SHOULD prepare text
+ passwords as "query" strings by applying the [SASLprep] profile of
+ the [Stringprep] algorithm. Passwords consisting of other data
+ (such as random octets) MUST NOT be altered. The determination of
+ whether a password is textual is a local client matter.
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 15
+ Lightweight Directory Access Protocol Version 3
+
+
+4.2.1. Processing of the Bind Request
+
+ Before processing a BindRequest, all uncompleted operations MUST
+ either complete or be abandoned. The server may either wait for the
+ uncompleted operations to complete, or abandon them. The server then
+ proceeds to authenticate the client in either a single-step, or
+ multi-step Bind process. Each step requires the server to return a
+ BindResponse to indicate the status of authentication.
+
+ After sending a BindRequest, clients MUST NOT send further LDAP PDUs
+ until receiving the BindResponse. Similarly, servers SHOULD NOT
+ process or respond to requests received while processing a
+ BindRequest.
+
+ If the client did not bind before sending a request and receives an
+ operationsError to that request, it may then send a BindRequest. If
+ this also fails or the client chooses not to bind on the existing
+ LDAP session, it may terminate the LDAP session, re-establish it and
+ begin again by first sending a BindRequest. This will aid in
+ interoperating with servers implementing other versions of LDAP.
+
+ Clients may send multiple Bind requests to change the authentication
+ and/or security associations or to complete a multi-stage Bind
+ process. Authentication from earlier binds is subsequently ignored.
+
+ For some SASL authentication mechanisms, it may be necessary for the
+ client to invoke the BindRequest multiple times ([AuthMeth] Section
+ 5.2). Clients MUST NOT invoke operations between two Bind requests
+ made as part of a multi-stage Bind.
+
+ A client may abort a SASL bind negotiation by sending a BindRequest
+ with a different value in the mechanism field of SaslCredentials, or
+ an AuthenticationChoice other than sasl.
+
+ If the client sends a BindRequest with the sasl mechanism field as an
+ empty string, the server MUST return a BindResponse with the
+ resultCode set to authMethodNotSupported. This will allow clients to
+ abort a negotiation if it wishes to try again with the same SASL
+ mechanism.
+
+
+4.2.2. Bind Response
+
+ The Bind response is defined as follows.
+
+ BindResponse ::= [APPLICATION 1] SEQUENCE {
+ COMPONENTS OF LDAPResult,
+ serverSaslCreds [7] OCTET STRING OPTIONAL }
+
+ BindResponse consists simply of an indication from the server of the
+ status of the client's request for authentication.
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 16
+ Lightweight Directory Access Protocol Version 3
+
+ A successful Bind operation is indicated by a BindResponse with a
+ resultCode set to success. Otherwise, an appropriate result code is
+ set in the BindResponse. For BindResponse, the protocolError result
+ code may be used to indicate that the version number supplied by the
+ client is unsupported.
+
+ If the client receives a BindResponse where the resultCode is set to
+ protocolError, it is to assume that the server does not support this
+ version of LDAP. While the client may be able proceed with another
+ version of this protocol (this may or may not require closing and re-
+ establishing the transport connection), how to proceed with another
+ version of this protocol is beyond the scope of this document.
+ Clients which are unable or unwilling to proceed SHOULD terminate the
+ LDAP session.
+
+ The serverSaslCreds field is used as part of a SASL-defined bind
+ mechanism to allow the client to authenticate the server to which it
+ is communicating, or to perform "challenge-response" authentication.
+ If the client bound with the simple choice, or the SASL mechanism
+ does not require the server to return information to the client, then
+ this field SHALL NOT be included in the BindResponse.
+
+
+4.3. Unbind Operation
+
+ The function of the Unbind operation is to terminate an LDAP session.
+ The Unbind operation is not the antithesis of the Bind operation as
+ the name implies. The naming of these operations are historical. The
+ Unbind operation should be thought of as the "quit" operation.
+
+ The Unbind operation is defined as follows:
+
+ UnbindRequest ::= [APPLICATION 2] NULL
+
+ The client, upon transmission of the UnbindRequest, and the server,
+ upon receipt of the UnbindRequest are to gracefully terminate the
+ LDAP session as described in Section 5.3.
+
+ Uncompleted operations are handled as specified in Section 3.1.
+
+
+4.4. Unsolicited Notification
+
+ An unsolicited notification is an LDAPMessage sent from the server to
+ the client which is not in response to any LDAPMessage received by
+ the server. It is used to signal an extraordinary condition in the
+ server or in the LDAP session 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.
+
+
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 17
+ Lightweight Directory Access Protocol Version 3
+
+ The unsolicited notification is structured as an LDAPMessage in which
+ the messageID is zero and protocolOp is set to the extendedResp
+ choice using the ExtendedResponse type (See Section 4.12). The
+ responseName field of the ExtendedResponse always contains an LDAPOID
+ which is unique for this notification.
+
+ One unsolicited notification (Notice of Disconnection) is defined in
+ this document. The specification of an unsolicited notification
+ consists of:
+
+ - the OBJECT IDENTIFIER assigned to the notification (to be
+ specified in the responseName,
+
+ - the format of the contents of the responseValue (if any),
+
+ - the circumstances which will cause the notification to be sent,
+ and
+
+ - the semantics of the message.
+
+
+4.4.1. Notice of Disconnection
+
+ This notification may be used by the server to advise the client that
+ the server is about to terminate the LDAP session on its own
+ initiative. This notification is intended to assist clients in
+ distinguishing between an exceptional server condition and a
+ transient network failure. Note that this notification is not a
+ response to an Unbind requested by the client. Uncompleted operations
+ are handled as specified in Section 3.1.
+
+ The responseName is 1.3.6.1.4.1.1466.20036, the responseValue field
+ is absent, and the resultCode is used to indicate the reason for the
+ disconnection. When the strongerAuthRequired resultCode is returned
+ with this message, it indicates that the server has detected that an
+ established security association between the client and server has
+ unexpectedly failed or been compromised.
+
+ Upon transmission of the Notice of Disconnection, the server
+ gracefully terminates the LDAP session as described in Section 5.3.
+
+
+4.5. Search Operation
+
+ The Search operation is used to request a server to return, subject
+ to access controls and other restrictions, a set of entries matching
+ a complex search criterion. This can be used to read attributes from
+ a single entry, from entries immediately subordinate to a particular
+ entry, or a whole subtree of entries.
+
+
+4.5.1. Search Request
+
+ The Search request is defined as follows:
+
+Sermersheim Internet-Draft - Expires April 2006 Page 18
+ Lightweight Directory Access Protocol Version 3
+
+
+ SearchRequest ::= [APPLICATION 3] SEQUENCE {
+ baseObject LDAPDN,
+ scope ENUMERATED {
+ baseObject (0),
+ singleLevel (1),
+ wholeSubtree (2),
+ ... },
+ derefAliases ENUMERATED {
+ neverDerefAliases (0),
+ derefInSearching (1),
+ derefFindingBaseObj (2),
+ derefAlways (3) },
+ sizeLimit INTEGER (0 .. maxInt),
+ timeLimit INTEGER (0 .. maxInt),
+ typesOnly BOOLEAN,
+ filter Filter,
+ attributes AttributeSelection }
+
+ AttributeSelection ::= SEQUENCE OF selector LDAPString
+ -- The LDAPString is constrained to
+ -- <attributeSelector> in Section 4.5.1.7
+
+ Filter ::= CHOICE {
+ and [0] SET SIZE (1..MAX) OF filter Filter,
+ or [1] SET SIZE (1..MAX) OF filter Filter,
+ not [2] Filter,
+ equalityMatch [3] AttributeValueAssertion,
+ substrings [4] SubstringFilter,
+ greaterOrEqual [5] AttributeValueAssertion,
+ lessOrEqual [6] AttributeValueAssertion,
+ present [7] AttributeDescription,
+ approxMatch [8] AttributeValueAssertion,
+ extensibleMatch [9] MatchingRuleAssertion,
+ ... }
+
+ SubstringFilter ::= SEQUENCE {
+ type AttributeDescription,
+ substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE {
+ initial [0] AssertionValue, -- can occur at most once
+ any [1] AssertionValue,
+ final [2] AssertionValue } -- can occur at most once
+ }
+
+ MatchingRuleAssertion ::= SEQUENCE {
+ matchingRule [1] MatchingRuleId OPTIONAL,
+ type [2] AttributeDescription OPTIONAL,
+ matchValue [3] AssertionValue,
+ dnAttributes [4] BOOLEAN DEFAULT FALSE }
+
+
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 19
+ Lightweight Directory Access Protocol Version 3
+
+ Note that an X.500 "list"-like operation can be emulated by the
+ client requesting a singleLevel Search operation with a filter
+ checking for the presence of the 'objectClass' attribute, and that an
+ X.500 "read"-like operation can be emulated by a baseObject Search
+ operation with the same filter. A server which provides a gateway to
+ X.500 is not required to use the Read or List operations, although it
+ may choose to do so, and if it does, it must provide the same
+ semantics as the X.500 Search operation.
+
+
+4.5.1.1. SearchRequest.baseObject
+
+ The name of the base object entry (or possibly the root) relative to
+ which the Search is to be performed.
+
+
+4.5.1.2. SearchRequest.scope
+
+ Specifies the scope of the Search to be performed. The semantics (as
+ described in [X.511]) of the defined values of this field are:
+
+ baseObject: The scope is constrained to the entry named by
+ baseObject.
+
+ singleLevel: The scope is constrained to the immediate
+ subordinates of the entry named by baseObject.
+
+ wholeSubtree: the scope is constrained to the entry named by the
+ baseObject, and all its subordinates.
+
+
+4.5.1.3. SearchRequest.derefAliases
+
+ An indicator as to whether or not alias entries (as defined in
+ [Models]) are to be dereferenced during stages of the Search
+ operation.
+
+ The act of dereferencing an alias includes recursively dereferencing
+ aliases which refer to aliases.
+
+ Servers MUST detect looping while dereferencing aliases in order to
+ prevent denial of service attacks of this nature.
+
+ The semantics of the defined values of this field are:
+
+ neverDerefAliases: Do not dereference aliases in searching or in
+ locating the base object of the Search.
+
+
+
+
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 20
+ Lightweight Directory Access Protocol Version 3
+
+ derefInSearching: While searching subordinates of the base object,
+ dereference any alias within the search scope. Dereferenced
+ objects become the vertices of further search scopes where the
+ Search operation is also applied. If the search scope is
+ wholeSubtree, the Search continues in the subtree(s) of any
+ dereferenced object. If the search scope is singleLevel, the
+ search is applied to any dereferenced objects, and is not applied
+ to their subordinates. Servers SHOULD eliminate duplicate entries
+ that arise due to alias dereferencing while searching.
+
+ derefFindingBaseObj: Dereference aliases in locating the base
+ object of the Search, but not when searching subordinates of the
+ base object.
+
+ derefAlways: Dereference aliases both in searching and in locating
+ the base object of the Search.
+
+
+4.5.1.4. SearchRequest.sizeLimit
+
+ A size limit that restricts the maximum number of entries to be
+ returned as a result of the Search. A value of zero in this field
+ indicates that no client-requested size limit restrictions are in
+ effect for the Search. Servers may also enforce a maximum number of
+ entries to return.
+
+
+4.5.1.5. SearchRequest.timeLimit
+
+ A time limit that restricts the maximum time (in seconds) allowed for
+ a Search. A value of zero in this field indicates that no client-
+ requested time limit restrictions are in effect for the Search.
+ Servers may also enforce a maximum time limit for the Search.
+
+
+4.5.1.6. SearchRequest.typesOnly
+
+ An indicator as to whether Search results are to contain both
+ attribute descriptions and values, or just attribute descriptions.
+ Setting this field to TRUE causes only attribute descriptions (no
+ values) to be returned. Setting this field to FALSE causes both
+ attribute descriptions and values to be returned.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 21
+ Lightweight Directory Access Protocol Version 3
+
+4.5.1.7. SearchRequest.filter
+
+ A filter that defines the conditions that must be fulfilled in order
+ for the Search to match a given entry.
+
+ The 'and', 'or' and 'not' choices can be used to form combinations of
+ filters. At least one filter element MUST be present in an 'and' or
+ 'or' choice. The others match against individual attribute values of
+ entries in the scope of the Search. (Implementor's note: the 'not'
+ filter is an example of a tagged choice in an implicitly-tagged
+ module. In BER this is treated as if the tag was explicit.)
+
+ A server MUST evaluate filters according to the three-valued logic of
+ [X.511] (1993) Clause 7.8.1. In summary, a filter is evaluated to
+ either "TRUE", "FALSE" or "Undefined". If the filter evaluates to
+ TRUE for a particular entry, then the attributes of that entry are
+ returned as part of the Search result (subject to any applicable
+ access control restrictions). If the filter evaluates to FALSE or
+ Undefined, then the entry is ignored for the Search.
+
+ A filter of the "and" choice is TRUE if all the filters in the SET OF
+ evaluate to TRUE, FALSE if at least one filter is FALSE, and
+ otherwise Undefined. A filter of the "or" choice is FALSE if all of
+ the filters in the SET OF evaluate to FALSE, TRUE if at least one
+ filter is TRUE, and Undefined otherwise. A filter of the 'not' choice
+ is TRUE if the filter being negated is FALSE, FALSE if it is TRUE,
+ and Undefined if it is Undefined.
+
+ A filter item evaluates to Undefined when the server would not be
+ able to determine whether the assertion value matches an entry.
+ Examples include:
+
+ - An attribute description in an equalityMatch, substrings,
+ greaterOrEqual, lessOrEqual, approxMatch or extensibleMatch
+ filter is not recognized by the server.
+
+ - The attribute type does not define the appropriate matching
+ rule.
+
+ - A MatchingRuleId in the extensibleMatch is not recognized by
+ the server or is not valid for the attribute type.
+
+ - The type of filtering requested is not implemented.
+
+ - The assertion value is invalid.
+
+ For example, if a server did not recognize the attribute type
+ shoeSize, the filters (shoeSize=*), (shoeSize=12), (shoeSize>=12) and
+ (shoeSize<=12) would each evaluate to Undefined.
+
+ Servers MUST NOT return errors if attribute descriptions or matching
+ rule ids are not recognized, assertion values are invalid, or the
+ assertion syntax is not supported. More details of filter processing
+ are given in Clause 7.8 of [X.511].
+
+Sermersheim Internet-Draft - Expires April 2006 Page 22
+ Lightweight Directory Access Protocol Version 3
+
+
+
+4.5.1.7.1. SearchRequest.filter.equalityMatch
+
+ The matching rule for an equalityMatch filter is defined by the
+ EQUALITY matching rule for the attribute type or subtype. The filter
+ is TRUE when the EQUALITY rule returns TRUE as applied to the
+ attribute or subtype and the asserted value.
+
+
+4.5.1.7.2. SearchRequest.filter.substrings
+
+ There SHALL be at most one 'initial', and at most one 'final' in the
+ 'substrings' of a SubstringFilter. If 'initial' is present, it SHALL
+ be the first element of 'substrings'. If 'final' is present, it SHALL
+ be the last element of 'substrings'.
+
+ The matching rule for an AssertionValue in a substrings filter item
+ is defined by the SUBSTR matching rule for the attribute type or
+ subtype. The filter is TRUE when the SUBSTR rule returns TRUE as
+ applied to the attribute or subtype and the asserted value.
+
+ Note that the AssertionValue in a substrings filter item conforms to
+ the assertion syntax of the EQUALITY matching rule for the attribute
+ type rather than the assertion syntax of the SUBSTR matching rule for
+ the attribute type. Conceptually, the entire SubstringFilter is
+ converted into an assertion value of the substrings matching rule
+ prior to applying the rule.
+
+
+4.5.1.7.3. SearchRequest.filter.greaterOrEqual
+
+ The matching rule for a greaterOrEqual filter is defined by the
+ ORDERING matching rule for the attribute type or subtype. The filter
+ is TRUE when the ORDERING rule returns FALSE as applied to the
+ attribute or subtype and the asserted value.
+
+
+4.5.1.7.4. SearchRequest.filter.lessOrEqual
+
+ The matching rules for a lessOrEqual filter are defined by the
+ ORDERING and EQUALITY matching rules for the attribute type or
+ subtype. The filter is TRUE when either the ORDERING or EQUALITY rule
+ returns TRUE as applied to the attribute or subtype and the asserted
+ value.
+
+
+4.5.1.7.5. SearchRequest.filter.present
+
+ A present filter is TRUE when there is an attribute or subtype of the
+ specified attribute description present in an entry, FALSE when no
+ attribute or subtype of the specified attribute description is
+ present in an entry, and Undefined otherwise.
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 23
+ Lightweight Directory Access Protocol Version 3
+
+
+4.5.1.7.6. SearchRequest.filter.approxMatch
+
+ An approxMatch filter is TRUE when there is a value of the attribute
+ type or subtype for which some locally-defined approximate matching
+ algorithm (e.g. spelling variations, phonetic match, etc.) returns
+ TRUE. If a value matches for equality, it also satisfies an
+ approximate match. If approximate matching is not supported for the
+ attribute, this filter item should be treated as an equalityMatch.
+
+
+4.5.1.7.7. SearchRequest.filter.extensibleMatch
+
+ The fields of the extensibleMatch filter item are evaluated as
+ follows:
+
+ - If the matchingRule field is absent, the type field MUST be
+ present, and an equality match is performed for that type.
+
+ - If the type field is absent and the matchingRule is present, the
+ matchValue is compared against all attributes in an entry which
+ support that matchingRule.
+
+ - If the type field is present and the matchingRule is present, the
+ matchValue is compared against the specified attribute type and
+ its subtypes.
+
+ - If the dnAttributes field is set to TRUE, the match is
+ additionally applied against all the AttributeValueAssertions in
+ an entry's distinguished name, and evaluates to TRUE if there is
+ at least one attribute or subtype in the distinguished name for
+ which the filter item evaluates to TRUE. The dnAttributes field is
+ present to alleviate the need for multiple versions of generic
+ matching rules (such as word matching), where one applies to
+ entries and another applies to entries and DN attributes as well.
+
+ The matchingRule used for evaluation determines the syntax for the
+ assertion value. Once the matchingRule and attribute(s) have been
+ determined, the filter item evaluates to TRUE if it matches at least
+ one attribute type or subtype in the entry, FALSE if it does not
+ match any attribute type or subtype in the entry, and Undefined if
+ the matchingRule is not recognized, the matchingRule is unsuitable
+ for use with the specified type, or the assertionValue is invalid.
+
+
+4.5.1.7. SearchRequest.attributes
+
+ A selection list of the attributes to be returned from each entry
+ which matches the search filter. Attributes which are subtypes of
+ listed attributes are implicitly included. LDAPString values of this
+ field are constrained to the following Augmented Backus-Naur Form
+ ([ABNF]):
+
+ attributeSelector = attributedescription / selectorspecial
+
+Sermersheim Internet-Draft - Expires April 2006 Page 24
+ Lightweight Directory Access Protocol Version 3
+
+
+ selectorspecial = noattrs / alluserattrs
+
+ noattrs = %x31.2E.31 ; "1.1"
+
+ alluserattrs = %x2A ; asterisk ("*")
+
+ The <attributedescription> production is defined in Section 2.5 of
+ [Models].
+
+ There are three special cases which may appear in the attributes
+ selection list:
+
+ - an empty list with no attributes,
+
+ - a list containing "*" (with zero or more attribute
+ descriptions), and
+
+ - a list containing only "1.1".
+
+ An empty list requests the return of all user attributes.
+
+ A list containing "*" requests the return of all user attributes
+ in addition to other listed (operational) attributes.
+
+ A list containing only the OID "1.1" indicates that no attributes
+ are to be returned. If "1.1" is provided with other
+ attributeSelector values, the "1.1" attributeSelector is ignored.
+ This OID was chosen because it does not (and can not) correspond
+ to any attribute in use.
+
+ Client implementors should note that even if all user attributes are
+ requested, some attributes and/or attribute values of the entry may
+ not be included in Search results due to access controls or other
+ restrictions. Furthermore, servers will not return operational
+ attributes, such as objectClasses or attributeTypes, unless they are
+ listed by name. Operational attributes are described in [Models].
+
+ Attributes are returned at most once in an entry. If an attribute
+ description is named more than once in the list, the subsequent names
+ are ignored. If an attribute description in the list is not
+ recognized, it is ignored by the server.
+
+
+4.5.2. Search Result
+
+ The results of the Search operation are returned as zero or more
+ SearchResultEntry and/or SearchResultReference messages, followed by
+ a single SearchResultDone message.
+
+ SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
+ objectName LDAPDN,
+ attributes PartialAttributeList }
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 25
+ Lightweight Directory Access Protocol Version 3
+
+ PartialAttributeList ::= SEQUENCE OF
+ partialAttribute PartialAttribute
+
+ SearchResultReference ::= [APPLICATION 19] SEQUENCE
+ SIZE (1..MAX) OF uri URI
+
+ SearchResultDone ::= [APPLICATION 5] LDAPResult
+
+ Each SearchResultEntry represents an entry found during the Search.
+ Each SearchResultReference represents an area not yet explored during
+ the Search. The SearchResultEntry and SearchResultReference messages
+ may come in any order. Following all the SearchResultReference and
+ SearchResultEntry responses, the server returns a SearchResultDone
+ response, which contains an indication of success, or detailing any
+ errors that have occurred.
+
+ Each entry returned in a SearchResultEntry will contain all
+ appropriate attributes as specified in the attributes field of the
+ Search Request, subject to access control and other administrative
+ policy. Note that the PartialAttributeList may hold zero elements.
+ This may happen when none of the attributes of an entry were
+ requested, or could be returned. Note also that the partialAttribute
+ vals set may hold zero elements. This may happen when typesOnly is
+ requested, access controls prevent the return of values, or other
+ reasons.
+
+ Some attributes may be constructed by the server and appear in a
+ SearchResultEntry attribute list, although they are not stored
+ attributes of an entry. Clients SHOULD NOT assume that all attributes
+ can be modified, even if permitted by access control.
+
+ If the server's schema defines short names [Models] for an attribute
+ type then the server SHOULD use one of those names in attribute
+ descriptions for that attribute type (in preference to using the
+ <numericoid> [Models] format of the attribute type's object
+ identifier). The server SHOULD NOT use the short name if that name is
+ known by the server to be ambiguous, or otherwise likely to cause
+ interoperability problems.
+
+
+4.5.3. Continuation References in the Search Result
+
+ If the server was able to locate the entry referred to by the
+ baseObject but was unable or unwilling to search one or more non-
+ local entries, the server may return one or more
+ SearchResultReference messages, each containing a reference to
+ another set of servers for continuing the operation. A server MUST
+ NOT return any SearchResultReference messages if it has not located
+ the baseObject and thus has not searched any entries; in this case it
+ would return a SearchResultDone containing either a referral or
+ noSuchObject result code (depending on the server's knowledge of the
+ entry named in the baseObject).
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 26
+ Lightweight Directory Access Protocol Version 3
+
+ If a server holds a copy or partial copy of the subordinate naming
+ context (Section 5 of [Models]), it may use the search filter to
+ determine whether or not to return a SearchResultReference response.
+ Otherwise SearchResultReference responses are always returned when in
+ scope.
+
+ The SearchResultReference is of the same data type as the Referral.
+
+ If the client wishes to progress the Search, it issues a new Search
+ operation for each SearchResultReference that is returned. If
+ multiple URIs are present, the client assumes that any supported URI
+ may be used to progress the operation.
+
+ Clients that follow search continuation references MUST ensure that
+ they do not loop between servers. They MUST NOT repeatedly contact
+ the same server for the same request with the same parameters. Some
+ clients use a counter that is incremented each time search result
+ reference handling occurs for an operation, and these kinds of
+ clients MUST be able to handle at least ten nested referrals while
+ progressing the operation.
+
+ Note that the Abandon operation described in Section 4.11 applies
+ only to a particular operation sent at the LDAP message layer between
+ a client and server. The client must abandon subsequent Search
+ operations it wishes to individually.
+
+ A URI for a server implementing LDAP and accessible via [TCP]/[IP]
+ (v4 or v6) is written as an LDAP URL according to [LDAPURL].
+
+ SearchResultReference values which are LDAP URLs follow these rules:
+
+ - The <dn> part of the LDAP URL MUST be present, with the new target
+ object name. The client uses this name when following the
+ reference.
+
+ - Some servers (e.g. participating in distributed indexing) may
+ provide a different filter in the LDAP URL.
+
+ - If the <filter> part of the LDAP URL is present, the client uses
+ this filter in its next request to progress this Search, and if it
+ is not present the client uses the same filter as it used for that
+ Search.
+
+ - If the originating search scope was singleLevel, the <scope> part
+ of the LDAP URL will be "base".
+
+ - It is RECOMMENDED that the <scope> part be present to avoid
+ ambiguity. In the absence of a <scope> part, the scope of the
+ original Search request is assumed.
+
+ - Other aspects of the new Search request may be the same as or
+ different from the Search request which generated the
+ SearchResultReference.
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 27
+ Lightweight Directory Access Protocol Version 3
+
+ - The name of an unexplored subtree in a SearchResultReference need
+ not be subordinate to the base object.
+
+ Other kinds of URIs may be returned. The syntax and semantics of such
+ URIs is left to future specifications. Clients may ignore URIs that
+ they do not support.
+
+ UTF-8 encoded characters appearing in the string representation of a
+ DN, search filter, or other fields of the referral value may not be
+ legal for URIs (e.g. spaces) and MUST be escaped using the % method
+ in [URI].
+
+
+
+4.5.3.1. Examples
+
+ For example, suppose the contacted server (hosta) holds the entry
+ <DC=Example,DC=NET> and the entry <CN=Manager,DC=Example,DC=NET>. It
+ knows that both LDAP servers (hostb) and (hostc) hold
+ <OU=People,DC=Example,DC=NET> (one is the master and the other server
+ a shadow), and that LDAP-capable server (hostd) holds the subtree
+ <OU=Roles,DC=Example,DC=NET>. If a wholeSubtree Search of
+ <DC=Example,DC=NET> is requested to the contacted server, it may
+ return the following:
+
+ SearchResultEntry for DC=Example,DC=NET
+ SearchResultEntry for CN=Manager,DC=Example,DC=NET
+ SearchResultReference {
+ ldap://hostb/OU=People,DC=Example,DC=NET??sub
+ ldap://hostc/OU=People,DC=Example,DC=NET??sub }
+ SearchResultReference {
+ ldap://hostd/OU=Roles,DC=Example,DC=NET??sub }
+ SearchResultDone (success)
+
+ Client implementors should note that when following a
+ SearchResultReference, additional SearchResultReference may be
+ generated. Continuing the example, if the client contacted the server
+ (hostb) and issued the Search request for the subtree
+ <OU=People,DC=Example,DC=NET>, the server might respond as follows:
+
+ SearchResultEntry for OU=People,DC=Example,DC=NET
+ SearchResultReference {
+ ldap://hoste/OU=Managers,OU=People,DC=Example,DC=NET??sub }
+ SearchResultReference {
+ ldap://hostf/OU=Consultants,OU=People,DC=Example,DC=NET??sub }
+ SearchResultDone (success)
+
+ Similarly, if a singleLevel Search of <DC=Example,DC=NET> is
+ requested to the contacted server, it may return the following:
+
+
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 28
+ Lightweight Directory Access Protocol Version 3
+
+ SearchResultEntry for CN=Manager,DC=Example,DC=NET
+ SearchResultReference {
+ ldap://hostb/OU=People,DC=Example,DC=NET??base
+ ldap://hostc/OU=People,DC=Example,DC=NET??base }
+ SearchResultReference {
+ ldap://hostd/OU=Roles,DC=Example,DC=NET??base }
+ SearchResultDone (success)
+
+ If the contacted server does not hold the base object for the Search,
+ but has knowledge of its possible location, then it may return a
+ referral to the client. In this case, if the client requests a
+ subtree Search of <DC=Example,DC=ORG> to hosta, the server returns a
+ SearchResultDone containing a referral.
+
+ SearchResultDone (referral) {
+ ldap://hostg/DC=Example,DC=ORG??sub }
+
+
+4.6. Modify Operation
+
+ The Modify operation allows a client to request that a modification
+ of an entry be performed on its behalf by a server. The Modify
+ Request is defined as follows:
+
+ ModifyRequest ::= [APPLICATION 6] SEQUENCE {
+ object LDAPDN,
+ changes SEQUENCE OF change SEQUENCE {
+ operation ENUMERATED {
+ add (0),
+ delete (1),
+ replace (2),
+ ... },
+ modification PartialAttribute } }
+
+ Fields of the Modify Request are:
+
+ - object: The value of this field contains the name of the entry to
+ be modified. The server SHALL NOT perform any alias dereferencing
+ in determining the object to be modified.
+
+ - changes: A list of modifications to be performed on the entry. The
+ entire list of modifications MUST be performed in the order they
+ are listed as a single atomic operation. While individual
+ modifications may violate certain aspects of the directory schema
+ (such as the object class definition and DIT content rule), the
+ resulting entry after the entire list of modifications is
+ performed MUST conform to the requirements of the directory model
+ and controlling schema [Models].
+
+ - operation: Used to specify the type of modification being
+ performed. Each operation type acts on the following
+ modification. The values of this field have the following
+ semantics respectively:
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 29
+ Lightweight Directory Access Protocol Version 3
+
+ add: add values listed to the modification attribute,
+ creating the attribute if necessary;
+
+ delete: delete values listed from the modification attribute.
+ If no values are listed, or if all current values of the
+ attribute are listed, the entire attribute is removed;
+
+ replace: replace all existing values of the modification
+ attribute with the new values listed, creating the attribute
+ if it did not already exist. A replace with no value will
+ delete the entire attribute if it exists, and is ignored if
+ the attribute does not exist.
+
+ - modification: A PartialAttribute (which may have an empty SET
+ of vals) used to hold the attribute type or attribute type and
+ values being modified.
+
+ Upon receipt of a Modify Request, the server attempts to perform the
+ necessary modifications to the DIT and returns the result in a Modify
+ Response, defined as follows:
+
+ ModifyResponse ::= [APPLICATION 7] LDAPResult
+
+ The server will return to the client a single Modify Response
+ indicating either the successful completion of the DIT modification,
+ or the reason that the modification failed. Due to the requirement
+ for atomicity in applying the list of modifications in the Modify
+ Request, the client may expect that no modifications of the DIT have
+ been performed if the Modify Response received indicates any sort of
+ error, and that all requested modifications have been performed if
+ the Modify Response indicates successful completion of the Modify
+ operation. Whether the modification was applied or not cannot be
+ determined by the client if the Modify Response was not received
+ (e.g. the LDAP session was terminated or the Modify operation was
+ abandoned).
+
+ Servers MUST ensure that entries conform to user and system schema
+ rules or other data model constraints. The Modify operation cannot be
+ used to remove from an entry any of its distinguished values, i.e.
+ those values which form the entry's relative distinguished name. An
+ attempt to do so will result in the server returning the
+ notAllowedOnRDN result code. The Modify DN operation described in
+ Section 4.9 is used to rename an entry.
+
+ For attribute types which specify no equality matching, the rules in
+ Section 2.5.1 of [Models] are followed.
+
+ Note that due to the simplifications made in LDAP, there is not a
+ direct mapping of the changes in an LDAP ModifyRequest onto the
+ changes of a DAP ModifyEntry operation, and different implementations
+ of LDAP-DAP gateways may use different means of representing the
+ change. If successful, the final effect of the operations on the
+ entry MUST be identical.
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 30
+ Lightweight Directory Access Protocol Version 3
+
+
+4.7. Add Operation
+
+ The Add operation allows a client to request the addition of an entry
+ into the Directory. The Add Request is defined as follows:
+
+ AddRequest ::= [APPLICATION 8] SEQUENCE {
+ entry LDAPDN,
+ attributes AttributeList }
+
+ AttributeList ::= SEQUENCE OF attribute Attribute
+
+ Fields of the Add Request are:
+
+ - entry: the name of the entry to be added. The server SHALL NOT
+ dereference any aliases in locating the entry to be added.
+
+ - attributes: the list of attributes that, along with those from the
+ RDN, make up the content of the entry being added. Clients MAY or
+ MAY NOT include the RDN attribute(s) in this list. Clients MUST
+ NOT supply NO-USER-MODIFICATION attributes such as the
+ createTimestamp or creatorsName attributes, since the server
+ maintains these automatically.
+
+ Servers MUST ensure that entries conform to user and system schema
+ rules or other data model constraints. For attribute types which
+ specify no equality matching, the rules in Section 2.5.1 of [Models]
+ are followed (this applies to the naming attribute in addition to any
+ multi-valued attributes being added).
+
+ The entry named in the entry field of the AddRequest MUST NOT exist
+ for the AddRequest to succeed. The immediate superior (parent) of an
+ object or alias entry to be added MUST exist. For example, if the
+ client attempted to add <CN=JS,DC=Example,DC=NET>, the
+ <DC=Example,DC=NET> entry did not exist, and the <DC=NET> entry did
+ exist, then the server would return the noSuchObject result code with
+ the matchedDN field containing <DC=NET>.
+
+ Upon receipt of an Add Request, a server will attempt to add the
+ requested entry. The result of the Add attempt will be returned to
+ the client in the Add Response, defined as follows:
+
+ AddResponse ::= [APPLICATION 9] LDAPResult
+
+ A response of success indicates that the new entry has been added to
+ the Directory.
+
+
+4.8. Delete Operation
+
+ The Delete operation allows a client to request the removal of an
+ entry from the Directory. The Delete Request is defined as follows:
+
+ DelRequest ::= [APPLICATION 10] LDAPDN
+
+Sermersheim Internet-Draft - Expires April 2006 Page 31
+ Lightweight Directory Access Protocol Version 3
+
+
+ The Delete Request consists of the name of the entry to be deleted.
+ The server SHALL NOT dereference aliases while resolving the name of
+ the target entry to be removed.
+
+ Only leaf entries (those with no subordinate entries) can be deleted
+ with this operation.
+
+ Upon receipt of a Delete Request, a server will attempt to perform
+ the entry removal requested and return the result in the Delete
+ Response defined as follows:
+
+ DelResponse ::= [APPLICATION 11] LDAPResult
+
+
+4.9. Modify DN Operation
+
+ The Modify DN operation allows a client to change the Relative
+ Distinguished Name (RDN) of an entry in the Directory, and/or to move
+ a subtree of entries to a new location in the Directory. The Modify
+ DN Request is defined as follows:
+
+ ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
+ entry LDAPDN,
+ newrdn RelativeLDAPDN,
+ deleteoldrdn BOOLEAN,
+ newSuperior [0] LDAPDN OPTIONAL }
+
+ Fields of the Modify DN Request are:
+
+ - entry: the name of the entry to be changed. This entry may or may
+ not have subordinate entries.
+
+ - newrdn: the new RDN of the entry. The value of the old RDN is
+ supplied when moving the entry to a new superior without changing
+ its RDN. Attribute values of the new RDN not matching any
+ attribute value of the entry are added to the entry and an
+ appropriate error is returned if this fails.
+
+ - deleteoldrdn: a boolean field that controls whether the old RDN
+ attribute values are to be retained as attributes of the entry, or
+ deleted from the entry.
+
+ - newSuperior: if present, this is the name of an existing object
+ entry which becomes the immediate superior (parent) of the
+ existing entry.
+
+ The server SHALL NOT dereference any aliases in locating the objects
+ named in entry or newSuperior.
+
+ Upon receipt of a ModifyDNRequest, a server will attempt to perform
+ the name change and return the result in the Modify DN Response,
+ defined as follows:
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 32
+ Lightweight Directory Access Protocol Version 3
+
+ ModifyDNResponse ::= [APPLICATION 13] LDAPResult
+
+ For example, if the entry named in the entry field was <cn=John
+ Smith,c=US>, the newrdn field was <cn=John Cougar Smith>, and the
+ newSuperior field was absent, then this operation would attempt to
+ rename the entry to be <cn=John Cougar Smith,c=US>. If there was
+ already an entry with that name, the operation would fail with the
+ entryAlreadyExists result code.
+
+ Servers MUST ensure that entries conform to user and system schema
+ rules or other data model constraints. For attribute types which
+ specify no equality matching, the rules in Section 2.5.1 of [Models]
+ are followed (this pertains to newrdn and deleteoldrdn).
+
+ The object named in newSuperior MUST exist. For example, if the
+ client attempted to add <CN=JS,DC=Example,DC=NET>, the
+ <DC=Example,DC=NET> entry did not exist, and the <DC=NET> entry did
+ exist, then the server would return the noSuchObject result code with
+ the matchedDN field containing <DC=NET>.
+
+ If the deleteoldrdn field is TRUE, the attribute values forming the
+ old RDN but not the new RDN are deleted from the entry. If the
+ deleteoldrdn field is FALSE, the attribute values forming the old RDN
+ will be retained as non-distinguished attribute values of the entry.
+
+ 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
+ affectsMultipleDSAs result code 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 or
+ between naming contexts.
+
+
+4.10. Compare Operation
+
+ The Compare operation allows a client to compare an assertion value
+ with the values of a particular attribute in a particular entry in
+ the Directory. The Compare Request is defined as follows:
+
+ CompareRequest ::= [APPLICATION 14] SEQUENCE {
+ entry LDAPDN,
+ ava AttributeValueAssertion }
+
+ Fields of the Compare Request are:
+
+ - entry: the name of the entry to be compared. The server SHALL NOT
+ dereference any aliases in locating the entry to be compared.
+
+ - ava: holds the attribute value assertion to be compared.
+
+ Upon receipt of a Compare Request, a server will attempt to perform
+ the requested comparison and return the result in the Compare
+ Response, defined as follows:
+
+Sermersheim Internet-Draft - Expires April 2006 Page 33
+ Lightweight Directory Access Protocol Version 3
+
+
+ CompareResponse ::= [APPLICATION 15] LDAPResult
+
+ The resultCode is set to compareTrue, compareFalse, or an appropriate
+ error. compareTrue indicates that the assertion value in the ava
+ field matches a value of the attribute or subtype according to the
+ attribute's EQUALITY matching rule. compareFalse indicates that the
+ assertion value in the ava field and the values of the attribute or
+ subtype did not match. Other result codes indicate either that the
+ result of the comparison was Undefined (Section 4.5.1), or that some
+ error occurred.
+
+ Note that some directory systems may establish access controls which
+ permit the values of certain attributes (such as userPassword) to be
+ compared but not interrogated by other means.
+
+
+4.11. Abandon Operation
+
+ The function of the Abandon operation is to allow a client to request
+ that the server abandon an uncompleted operation. The Abandon Request
+ is defined as follows:
+
+ AbandonRequest ::= [APPLICATION 16] MessageID
+
+ The MessageID is that of an operation which was requested earlier at
+ this LDAP message layer. The Abandon request itself has its own
+ MessageID. This is distinct from the MessageID of the earlier
+ operation being abandoned.
+
+ There is no response defined in the Abandon operation. Upon receipt
+ of an AbandonRequest, the server MAY abandon the operation identified
+ by the MessageID. Since the client cannot tell the difference between
+ a successfully abandoned operation and an uncompleted operation, the
+ application of the Abandon operation is limited to uses where the
+ client does not require an indication of its outcome.
+
+ Abandon, Bind, Unbind, and StartTLS operations cannot be abandoned.
+
+ In the event that a server receives an Abandon Request on a Search
+ operation in the midst of transmitting responses to the Search, that
+ server MUST cease transmitting entry responses to the abandoned
+ request immediately, and MUST NOT send the SearchResultDone. Of
+ course, the server MUST ensure that only properly encoded LDAPMessage
+ PDUs are transmitted.
+
+ The ability to abandon other (particularly update) operations is at
+ the discretion of the server.
+
+ Clients should not send Abandon requests for the same operation
+ multiple times, and MUST also be prepared to receive results from
+ operations it has abandoned (since these may have been in transit
+ when the Abandon was requested, or are not able to be abandoned).
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 34
+ Lightweight Directory Access Protocol Version 3
+
+ Servers MUST discard Abandon requests for message IDs they do not
+ recognize, for operations which cannot be abandoned, and for
+ operations which have already been abandoned.
+
+
+4.12. Extended Operation
+
+ The Extended operation allows additional operations to be defined for
+ services not already available in the protocol. For example, to Add
+ operations to install transport layer security (see Section 4.14).
+
+ The Extended operation allows clients to make requests and receive
+ responses with predefined syntaxes and semantics. These may be
+ defined in RFCs or be private to particular implementations.
+
+ Each Extended operation consists of an Extended request and an
+ Extended response.
+
+ ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
+ requestName [0] LDAPOID,
+ requestValue [1] OCTET STRING OPTIONAL }
+
+ The requestName is a dotted-decimal representation of the unique
+ OBJECT IDENTIFIER corresponding to the request. The requestValue is
+ information in a form defined by that request, encapsulated inside an
+ OCTET STRING.
+
+ The server will respond to this with an LDAPMessage containing an
+ ExtendedResponse.
+
+ ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
+ COMPONENTS OF LDAPResult,
+ responseName [10] LDAPOID OPTIONAL,
+ responseValue [11] OCTET STRING OPTIONAL }
+
+ The responseName field, when present, contains an LDAPOID which is
+ unique for this extended operation or response. This field is
+ optional (even when the extension specification specifies an LDAPOID
+ to be returned in the field). The field will be absent whenever the
+ server is unable or unwilling to determine the appropriate LDAPOID to
+ return, for instance when the requestName cannot be parsed or its
+ value is not recognized.
+
+ Where the requestName is not recognized, the server returns
+ protocolError (The server may return protocolError in other cases).
+
+ The requestValue and responseValue fields contain information
+ associated with the operation. The format of these fields is defined
+ by the specification of the Extended operation. Implementations MUST
+ be prepared to handle arbitrary contents of these fields, including
+ zero bytes. Values that are defined in terms of ASN.1 and BER encoded
+ according to Section 5.1, also follow the extensibility rules in
+ Section 4.
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 35
+ Lightweight Directory Access Protocol Version 3
+
+ Servers list the requestName of Extended Requests they recognize in
+ the 'supportedExtension' attribute in the root DSE (Section 5.1 of
+ [Models]).
+
+ Extended operations may be specified in other documents. The
+ specification of an Extended operation consists of:
+
+ - the OBJECT IDENTIFIER assigned to the requestName,
+
+ - the OBJECT IDENTIFIER (if any) assigned to the responseName (note
+ that the same OBJECT IDENTIFIER may be used for both the
+ requestName and responseName),
+
+ - the format of the contents of the requestValue and responseValue
+ (if any), and
+
+ - the semantics of the operation.
+
+
+4.13. IntermediateResponse Message
+
+ While the Search operation provides a mechanism to return multiple
+ response messages for a single Search request, other operations, by
+ nature, do not provide for multiple response messages.
+
+ The IntermediateResponse message provides a general mechanism for
+ defining single-request/multiple-response operations in LDAP. This
+ message is intended to be used in conjunction with the Extended
+ operation to define new single-request/multiple-response operations
+ or in conjunction with a control when extending existing LDAP
+ operations in a way that requires them to return Intermediate
+ response information.
+
+ It is intended that the definitions and descriptions of Extended
+ operations and controls that make use of the IntermediateResponse
+ message will define the circumstances when an IntermediateResponse
+ message can be sent by a server and the associated meaning of an
+ IntermediateResponse message sent in a particular circumstance.
+
+ IntermediateResponse ::= [APPLICATION 25] SEQUENCE {
+ responseName [0] LDAPOID OPTIONAL,
+ responseValue [1] OCTET STRING OPTIONAL }
+
+ IntermediateResponse messages SHALL NOT be returned to the client
+ unless the client issues a request that specifically solicits their
+ return. This document defines two forms of solicitation: Extended
+ operation and request control. IntermediateResponse messages are
+ specified in documents describing the manner in which they are
+ solicited (i.e. in the Extended operation or request control
+ specification that uses them). These specifications include:
+
+ - the OBJECT IDENTIFIER (if any) assigned to the responseName,
+
+ - the format of the contents of the responseValue (if any), and
+
+Sermersheim Internet-Draft - Expires April 2006 Page 36
+ Lightweight Directory Access Protocol Version 3
+
+
+ - the semantics associated with the IntermediateResponse message.
+
+ Extensions that allow the return of multiple types of
+ IntermediateResponse messages SHALL identify those types using unique
+ responseName values (note that one of these may specify no value).
+
+ Sections 4.13.1 and 4.13.2 describe additional requirements on the
+ inclusion of responseName and responseValue in IntermediateResponse
+ messages.
+
+
+4.13.1. Usage with LDAP ExtendedRequest and ExtendedResponse
+
+ A single-request/multiple-response operation may be defined using a
+ single ExtendedRequest message to solicit zero or more
+ IntermediateResponse messages of one or more kinds followed by an
+ ExtendedResponse message.
+
+
+4.13.2. Usage with LDAP Request Controls
+
+ A control's semantics may include the return of zero or more
+ IntermediateResponse messages prior to returning the final result
+ code for the operation. One or more kinds of IntermediateResponse
+ messages may be sent in response to a request control.
+
+ All IntermediateResponse messages associated with request controls
+ SHALL include a responseName. This requirement ensures that the
+ client can correctly identify the source of IntermediateResponse
+ messages when:
+
+ - two or more controls using IntermediateResponse messages are
+ included in a request for any LDAP operation or
+
+ - one or more controls using IntermediateResponse messages are
+ included in a request with an LDAP Extended operation that uses
+ IntermediateResponse messages.
+
+
+4.14. StartTLS Operation
+
+ The Start Transport Layer Security (StartTLS) operation's purpose is
+ to initiate installation of a TLS layer. The StartTLS operation is
+ defined using the Extended operation mechanism described in Section
+ 4.12.
+
+
+
+
+
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 37
+ Lightweight Directory Access Protocol Version 3
+
+4.14.1. StartTLS Request
+
+ A client requests TLS establishment by transmitting a StartTLS
+ request message to the server. The StartTLS request is defined in
+ terms of an ExtendedRequest. The requestName is
+ "1.3.6.1.4.1.1466.20037", and the requestValue field is always
+ absent.
+
+ The client MUST NOT send any LDAP PDUs at this LDAP message layer
+ following this request until it receives a StartTLS Extended response
+ and, in the case of a successful response, completes TLS
+ negotiations.
+
+ Detected sequencing problems (particularly those detailed in Section
+ 3.1.1 of [AuthMeth]) result in the resultCode being set to
+ operationsError.
+
+ If the server does not support TLS (whether by design or by current
+ configuration), it returns with the resultCode set to protocolError
+ as described in Section 4.12.
+
+
+4.14.2. StartTLS Response
+
+ When a StartTLS request is received, servers supporting the operation
+ MUST return a StartTLS response message to the requestor. The
+ responseName is "1.3.6.1.4.1.1466.20037" when provided (See 4.12).
+ The responseValue is always absent.
+
+ If the server is willing and able to negotiate TLS, it returns the
+ StartTLS response with the resultCode set to success. Upon client
+ receipt of a successful StartTLS response, protocol peers may
+ commence with TLS negotiation as discussed in Section 3 of
+ [AuthMeth].
+
+ If the server is otherwise unwilling or unable to perform this
+ operation, the server is to return an appropriate result code
+ indicating the nature of the problem. For example, if the TLS
+ subsystem is not presently available, the server may indicate so by
+ returning with the resultCode set to unavailable. In cases where a
+ non-success result code is returned, the LDAP session is left without
+ a TLS layer.
+
+
+4.14.3. Removal of the TLS Layer
+
+ Either the client or server MAY remove the TLS layer and leave the
+ LDAP message layer intact by sending and receiving a TLS closure
+ alert.
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 38
+ Lightweight Directory Access Protocol Version 3
+
+ The initiating protocol peer sends the TLS closure alert and MUST
+ wait until it receives a TLS closure alert from the other peer before
+ sending further LDAP PDUs.
+
+ When a protocol peer receives the initial TLS closure alert, it may
+ choose to allow the LDAP message layer to remain intact. In this
+ case, it MUST immediately transmit a TLS closure alert. Following
+ this, it MAY send and receive LDAP PDUs.
+
+ Protocol peers MAY terminate the LDAP session after sending or
+ receiving a TLS closure alert.
+
+
+5. Protocol Encoding, Connection, and Transfer
+
+ This protocol is designed to run over connection-oriented, reliable
+ transports, where the data stream is divided into octets (8-bit
+ units), with each octet and each bit being significant.
+
+ One underlying service, LDAP over TCP, is defined in Section
+ 5.2. This service is generally applicable to applications providing
+ or consuming X.500-based directory services on the Internet. This
+ specification was generally written with the TCP mapping in mind.
+ Specifications detailing other mappings may encounter various
+ obstacles.
+
+ Implementations of LDAP over TCP MUST implement the mapping as
+ described in Section 5.2.
+
+ This table illustrates the relationship between the different layers
+ involved in an exchange between two protocol peers:
+
+ +----------------------+
+ | LDAP message layer |
+ +----------------------+ > LDAP PDUs
+ +----------------------+ < data
+ | SASL layer |
+ +----------------------+ > SASL-protected data
+ +----------------------+ < data
+ | TLS layer |
+ Application +----------------------+ > TLS-protected data
+ ------------+----------------------+ < data
+ Transport | transport connection |
+ +----------------------+
+
+
+5.1. Protocol Encoding
+
+ The protocol elements of LDAP SHALL be encoded for exchange using the
+ Basic Encoding Rules [BER] of [ASN.1] with the following
+ restrictions:
+
+ - Only the definite form of length encoding is used.
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 39
+ Lightweight Directory Access Protocol Version 3
+
+
+ - OCTET STRING values are encoded in the primitive form only.
+
+ - If the value of a BOOLEAN type is true, the encoding of the value
+ octet is set to hex "FF".
+
+ - If a value of a type is its default value, it is absent. Only some
+ BOOLEAN and INTEGER types have default values in this protocol
+ definition.
+
+ These restrictions are meant to ease the overhead of encoding and
+ decoding certain elements in BER.
+
+ These restrictions do not apply to ASN.1 types encapsulated inside of
+ OCTET STRING values, such as attribute values, unless otherwise
+ stated.
+
+
+5.2. Transmission Control Protocol (TCP)
+
+ The encoded LDAPMessage PDUs are mapped directly onto the [TCP]
+ bytestream using the BER-based encoding described in Section 5.1. It
+ is recommended that server implementations running over the TCP
+ provide a protocol listener on the Internet Assigned Numbers
+ Authority (IANA)-assigned LDAP port, 389 [PortReg]. Servers may
+ instead provide a listener on a different port number. Clients MUST
+ support contacting servers on any valid TCP port.
+
+
+5.3. Termination of the LDAP session
+
+ Termination of the LDAP session is typically initiated by the client
+ sending an UnbindRequest (Section 4.3), or by the server sending a
+ Notice of Disconnection (Section 4.4.1). In these cases each protocol
+ peer gracefully terminates the LDAP session by ceasing exchanges at
+ the LDAP message layer, tearing down any SASL layer, tearing down any
+ TLS layer, and closing the transport connection.
+
+ A protocol peer may determine that the continuation of any
+ communication would be pernicious, and in this case may abruptly
+ terminate the session by ceasing communication and closing the
+ transport connection.
+
+ In either case, when the LDAP session is terminated, uncompleted
+ operations are handled as specified in Section 3.1.
+
+
+6. Security Considerations
+
+ This version of the protocol provides facilities for simple
+ authentication using a cleartext password, as well as any [SASL]
+ mechanism. Installing SASL and/or TLS layers can provide integrity
+ and other data security services.
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 40
+ Lightweight Directory Access Protocol Version 3
+
+ It is also permitted that the server can return its credentials to
+ the client, if it chooses to do so.
+
+ Use of cleartext password is strongly discouraged where the
+ underlying transport service cannot guarantee confidentiality and may
+ result in disclosure of the password to unauthorized parties.
+
+ Servers are encouraged to prevent directory modifications by clients
+ that have authenticated anonymously [AuthMeth].
+
+ Security considerations for authentication methods, SASL mechanisms,
+ and TLS are described in [AuthMeth].
+
+ It should be noted that SASL authentication exchanges do not provide
+ data confidentiality nor integrity protection for the version or name
+ fields of the BindRequest nor the resultCode, diagnosticMessage, or
+ referral fields of the BindResponse nor of any information contained
+ in controls attached to Bind requests or responses. Thus information
+ contained in these fields SHOULD NOT be relied on unless otherwise
+ protected (such as by establishing protections at the transport
+ layer).
+
+ Implementors should note that various security factors, including
+ authentication and authorization information and data security
+ services may change during the course of the LDAP session, or even
+ during the performance of a particular operation. For instance,
+ credentials could expire, authorization identities or access controls
+ could change, or the underlying security layer(s) could be replaced
+ or terminated. Implementations should be robust in the handling of
+ changing security factors.
+ In some cases, it may be appropriate to continue the operation even
+ in light of security factor changes. For instance, it may be
+ appropriate to continue an Abandon operation regardless of the
+ change, or to continue an operation when the change upgraded (or
+ maintained) the security factor. In other cases, it may be
+ appropriate to fail, or alter the processing of the operation. For
+ instance, if confidential protections were removed, it would be
+ appropriate to either fail a request to return sensitive data, or
+ minimally, to exclude the return of sensitive data.
+
+ Implementations which cache attributes and entries obtained via LDAP
+ MUST ensure that access controls are maintained if that information
+ is to be provided to multiple clients, since servers may have access
+ control policies which prevent the return of entries or attributes in
+ Search results except to particular authenticated clients. For
+ example, caches could serve result information only to the client
+ whose request caused it to be in the cache.
+
+
+
+
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 41
+ Lightweight Directory Access Protocol Version 3
+
+ Servers may return referrals or Search result references which
+ redirect clients to peer servers. It is possible for a rogue
+ application to inject such referrals into the data stream in an
+ attempt to redirect a client to a rogue server. Clients are advised
+ to be aware of this, and possibly reject referrals when
+ confidentiality measures are not in place. Clients are advised to
+ reject referrals from the StartTLS operation.
+
+ The matchedDN and diagnosticMessage fields, as well as some
+ resultCode values (e.g., attributeOrValueExists and
+ entryAlreadyExists), could disclose the presence or absence of
+ specific data in the directory which is subject to access and other
+ administrative controls. Server implementations should restrict
+ access to protected information equally under both normal and error
+ conditions.
+
+ Protocol peers MUST be prepared to handle invalid and arbitrary
+ length protocol encodings. Invalid protocol encodings include: BER
+ encoding exceptions, format string and UTF-8 encoding exceptions,
+ overflow exceptions, integer value exceptions, and binary mode on/off
+ flag exceptions. The LDAPv3 PROTOS [PROTOS-LDAP] test suite provides
+ excellent examples of these exceptions and test cases used to
+ discover flaws.
+
+ In the event that a protocol peer senses an attack which in its
+ nature could cause damage due to further communication at any layer
+ in the LDAP session, the protocol peer should abruptly terminate the
+ LDAP session as described in Section 5.3.
+
+
+7. Acknowledgements
+
+ This document is based on RFC 2251 by Mark Wahl, Tim Howes, and Steve
+ Kille. RFC 2251 was a product of the IETF ASID Working Group.
+
+ It is also based on RFC 2830 by Jeff Hodges, RL "Bob" Morgan, and
+ Mark Wahl. RFC 2830 was a product of the IETF LDAPEXT Working Group.
+
+ It is also based on RFC 3771 by Roger Harrison, and Kurt Zeilenga.
+ RFC 3771 was an individual submission to the IETF.
+
+ This document is a product of the IETF LDAPBIS Working Group.
+ Significant contributors of technical review and content include Kurt
+ Zeilenga, Steven Legg, and Hallvard Furuseth.
+
+
+8. Normative References
+
+ [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", draft-crocker-abnf-rfc2234bis-
+ xx.txt, (a work in progress).
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 42
+ Lightweight Directory Access Protocol Version 3
+
+ [ASN.1] ITU-T Recommendation X.680 (07/2002) | ISO/IEC 8824-1:2002
+ "Information Technology - Abstract Syntax Notation One
+ (ASN.1): Specification of basic notation"
+
+ [AuthMeth] Harrison, R., "LDAP: Authentication Methods and Connection
+ Level Security Mechanisms", draft-ietf-ldapbis-authmeth-
+ xx.txt, (a work in progress).
+
+ [BER] ITU-T Rec. X.690 (07/2002) | ISO/IEC 8825-1:2002,
+ "Information technology - ASN.1 encoding rules:
+ Specification of Basic Encoding Rules (BER), Canonical
+ Encoding Rules (CER) and Distinguished Encoding Rules
+ (DER)", 2002.
+
+ [IP] Postel, J., "Internet Protocol", STD5 and RFC 791,
+ September 1981
+
+ [ISO10646] Universal Multiple-Octet Coded Character Set (UCS) -
+ Architecture and Basic Multilingual Plane, ISO/IEC 10646-1
+ : 1993.
+
+ [Keyword] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", RFC 2119, March 1997.
+
+ [LDAPDN] Zeilenga, K., "LDAP: String Representation of
+ Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, (a
+ work in progress).
+
+ [LDAPIANA] Zeilenga, K., "IANA Considerations for LDAP", draft-ietf-
+ ldapbis-bcp64-xx.txt, (a work in progress).
+
+ [LDAPURL] Smith, M., "LDAP: Uniform Resource Locator", draft-ietf-
+ ldapbis-url-xx.txt, (a work in progress).
+
+ [Models] Zeilenga, K., "LDAP: Directory Information Models", draft-
+ ietf-ldapbis-models-xx.txt (a work in progress).
+
+ [Roadmap] Zeilenga, K., "LDAP: Technical Specification Road Map",
+ draft-ietf-ldapbis-roadmap-xx.txt (a work in progress).
+
+ [SASL] Melnikov, A., "Simple Authentication and Security Layer",
+ draft-ietf-sasl-rfc2222bis-xx.txt (a work in progress).
+
+ [SASLPrep] Zeilenga, K., "Stringprep profile for user names and
+ passwords", draft-ietf-sasl-saslprep-xx.txt, (a work in
+ progress).
+
+ [StringPrep] Hoffman P. and M. Blanchet, "Preparation of
+ Internationalized Strings ('stringprep')", draft-hoffman-
+ rfc3454bis-xx.txt, a work in progress.
+
+ [Syntaxes] Legg, S., and K. Dally, "LDAP: Syntaxes and Matching
+ Rules", draft-ietf-ldapbis-syntaxes-xx.txt, (a work in
+ progress).
+
+Sermersheim Internet-Draft - Expires April 2006 Page 43
+ Lightweight Directory Access Protocol Version 3
+
+
+ [TCP] Postel, J., "Transmission Control Protocol", STD7 and RFC
+ 793, September 1981
+
+ [TLS] Dierks, T. and C. Allen. "The TLS Protocol Version 1.1",
+ draft-ietf-tls-rfc2246-bis-xx.txt, a work in progress.
+
+ [Unicode] The Unicode Consortium, "The Unicode Standard, Version
+ 3.2.0" is defined by "The Unicode Standard, Version 3.0"
+ (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
+ as amended by the "Unicode Standard Annex #27: Unicode
+ 3.1" (http://www.unicode.org/reports/tr27/) and by the
+ "Unicode Standard Annex #28: Unicode 3.2"
+ (http://www.unicode.org/reports/tr28/).
+
+ [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+ Resource Identifiers (URI): Generic Syntax", RFC 2396,
+ August 1998.
+
+ [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", STD63 and RFC3629, November 2003.
+
+ [X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts,
+ Models and Service", 1993.
+
+ [X.501] ITU-T Rec. X.501, "The Directory: Models", 1993.
+
+ [X.511] ITU-T Rec. X.511, "The Directory: Abstract Service
+ Definition", 1993.
+
+
+9. Informative References
+
+ [Glossary] The Unicode Consortium, "Unicode Glossary",
+ <http://www.unicode.org/glossary/>.
+
+ [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report
+ #17, Character Encoding Model", UTR17,
+ <http://www.unicode.org/unicode/reports/tr17/>, August
+ 2000.
+
+ [PROTOS-LDAP] University of Oulu, "PROTOS Test-Suite: c06-ldapv3"
+ <http://www.ee.oulu.fi/research/ouspg/protos/testing/c06/l
+ dapv3/>
+
+ [PortReg] IANA, "Port Numbers",
+ http://www.iana.org/assignments/port-numbers
+
+
+10. IANA Considerations
+
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 44
+ Lightweight Directory Access Protocol Version 3
+
+ It is requested that the Internet Assigned Numbers Authority (IANA)
+ update the LDAP result code registry to indicate that this document
+ provides the definitive technical specification for result codes 0-
+ 36, 48-54, 64-70, 80-90. It is also noted that one resultCode value
+ (strongAuthRequired) has been renamed (to strongerAuthRequired).
+
+ It is requested that the IANA update the LDAP Protocol Mechanism
+ registry to indicate that this document and [AuthMeth] provides the
+ definitive technical specification for the StartTLS
+ (1.3.6.1.4.1.1466.20037) Extended operation.
+
+ It is requested that the IANA update the occurrence of "RFC XXXX" in
+ this section and Appendix B with this RFC number at publication.
+
+ It is requested that IANA assign upon Standards Action an LDAP Object
+ Identifier [LDAPIANA] to identify the ASN.1 module defined in this
+ document.
+
+ Subject: Request for LDAP Object Identifier Registration
+ Person & email address to contact for further information:
+ Jim Sermersheim <jimse@novell.com>
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+ Comments:
+ Identifies the LDAP ASN.1 module
+
+ [[Note to RFC Editor: please replace the occurrence of <IANA-
+ ASSIGNED-DIRECTORY-NUMBER> in Appendix B with the IANA assigned
+ OID.]]
+
+
+11. Editor's Address
+
+ Jim Sermersheim
+ Novell, Inc.
+ 1800 South Novell Place
+ Provo, Utah 84606, USA
+ jimse@novell.com
+ +1 801 861-3088
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 45
+ Lightweight Directory Access Protocol Version 3
+
+Appendix A. LDAP Result Codes
+
+ This normative appendix details additional considerations regarding
+ LDAP result codes and provides a brief, general description of each
+ LDAP result code enumerated in Section 4.1.9.
+
+ Additional result codes MAY be defined for use with extensions
+ [LDAPIANA]. Client implementations SHALL treat any result code which
+ they do not recognize as an unknown error condition.
+
+ The descriptions provided here do not fully account for result code
+ substitutions used to prevent unauthorized disclosures (such as
+ substitution of noSuchObject for insufficientAccessRights, or
+ invalidCredentials for insufficientAccessRights).
+
+
+A.1. Non-Error Result Codes
+
+ These result codes (called "non-error" result codes) do not indicate
+ an error condition:
+ success (0),
+ compareFalse (5),
+ compareTrue (6),
+ referral (10), and
+ saslBindInProgress (14).
+
+ The success, compareTrue, and compareFalse result codes indicate
+ successful completion (and, hence, are referred to as "successful"
+ result codes).
+
+ The referral and saslBindInProgress result codes indicate the client
+ needs to take additional action to complete the operation.
+
+
+A.2. Result Codes
+
+ Existing LDAP result codes are described as follows:
+
+ success (0)
+ Indicates the successful completion of an operation. Note:
+ this code is not used with the Compare operation. See
+ compareFalse (5) and compareTrue (6).
+
+ operationsError (1)
+ Indicates that the operation is not properly sequenced with
+ relation to other operations (of same or different type).
+
+ For example, this code is returned if the client attempts to
+ StartTLS [TLS] while there are other uncompleted operations
+ or if a TLS layer was already installed.
+
+ protocolError (2)
+ Indicates the server received data which is not well-formed.
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 46
+ Lightweight Directory Access Protocol Version 3
+
+ For Bind operation only, this code is also used to indicate
+ that the server does not support the requested protocol
+ version.
+
+ For Extended operations only, this code is also used to
+ indicate that the server does not support (by design or
+ configuration) the Extended operation associated with the
+ requestName.
+
+ For request operations specifying multiple controls, this may
+ be used to indicate that the server cannot ignore the order
+ of the controls as specified, or that the combination of the
+ specified controls is invalid or unspecified.
+
+ timeLimitExceeded (3)
+ Indicates that the time limit specified by the client was
+ exceeded before the operation could be completed.
+
+ sizeLimitExceeded (4)
+ Indicates that the size limit specified by the client was
+ exceeded before the operation could be completed.
+
+ compareFalse (5)
+ Indicates that the Compare operation has successfully
+ completed and the assertion has evaluated to FALSE or
+ Undefined.
+
+ compareTrue (6)
+ Indicates that the Compare operation has successfully
+ completed and the assertion has evaluated to TRUE.
+
+ authMethodNotSupported (7)
+ Indicates that the authentication method or mechanism is not
+ supported.
+
+ strongerAuthRequired (8)
+ Indicates the server requires strong(er) authentication in
+ order to complete the operation.
+
+ When used with the Notice of Disconnection operation, this
+ code indicates that the server has detected that an
+ established security association between the client and
+ server has unexpectedly failed or been compromised.
+
+ referral (10)
+ Indicates that a referral needs to be chased to complete the
+ operation (see Section 4.1.10).
+
+ adminLimitExceeded (11)
+ Indicates that an administrative limit has been exceeded.
+
+ unavailableCriticalExtension (12)
+ Indicates a critical control is unrecognized (see Section
+ 4.1.11).
+
+Sermersheim Internet-Draft - Expires April 2006 Page 47
+ Lightweight Directory Access Protocol Version 3
+
+
+ confidentialityRequired (13)
+ Indicates that data confidentiality protections are required.
+
+ saslBindInProgress (14)
+ Indicates the server requires the client to send a new bind
+ request, with the same SASL mechanism, to continue the
+ authentication process (see Section 4.2).
+
+ noSuchAttribute (16)
+ Indicates that the named entry does not contain the specified
+ attribute or attribute value.
+
+ undefinedAttributeType (17)
+ Indicates that a request field contains an unrecognized
+ attribute description.
+
+ inappropriateMatching (18)
+ Indicates that an attempt was made (e.g. in an assertion) to
+ use a matching rule not defined for the attribute type
+ concerned.
+
+ constraintViolation (19)
+ Indicates that the client supplied an attribute value which
+ does not conform to the constraints placed upon it by the
+ data model.
+
+ For example, this code is returned when multiple values are
+ supplied to an attribute which has a SINGLE-VALUE constraint.
+
+ attributeOrValueExists (20)
+ Indicates that the client supplied an attribute or value to
+ be added to an entry, but the attribute or value already
+ exists.
+
+ invalidAttributeSyntax (21)
+ Indicates that a purported attribute value does not conform
+ to the syntax of the attribute.
+
+ noSuchObject (32)
+ Indicates that the object does not exist in the DIT.
+
+ aliasProblem (33)
+ Indicates that an alias problem has occurred. For example,
+ the code may used to indicate an alias has been dereferenced
+ which names no object.
+
+ invalidDNSyntax (34)
+ Indicates that an LDAPDN or RelativeLDAPDN field (e.g. search
+ base, target entry, ModifyDN newrdn, etc.) of a request does
+ not conform to the required syntax or contains attribute
+ values which do not conform to the syntax of the attribute's
+ type.
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 48
+ Lightweight Directory Access Protocol Version 3
+
+
+ aliasDereferencingProblem (36)
+ Indicates that a problem occurred while dereferencing an
+ alias. Typically an alias was encountered in a situation
+ where it was not allowed or where access was denied.
+
+ inappropriateAuthentication (48)
+ Indicates the server requires the client which had attempted
+ to bind anonymously or without supplying credentials to
+ provide some form of credentials.
+
+ invalidCredentials (49)
+ Indicates that the provided credentials (e.g. the user's name
+ and password) are invalid.
+
+ insufficientAccessRights (50)
+ Indicates that the client does not have sufficient access
+ rights to perform the operation.
+
+ busy (51)
+ Indicates that the server is too busy to service the
+ operation.
+
+ unavailable (52)
+ Indicates that the server is shutting down or a subsystem
+ necessary to complete the operation is offline.
+
+ unwillingToPerform (53)
+ Indicates that the server is unwilling to perform the
+ operation.
+
+ loopDetect (54)
+ Indicates that the server has detected an internal loop (e.g.
+ while dereferencing aliases or chaining an operation).
+
+ namingViolation (64)
+ Indicates that the entry's name violates naming restrictions.
+
+ objectClassViolation (65)
+ Indicates that the entry violates object class restrictions.
+
+ notAllowedOnNonLeaf (66)
+ Indicates that the operation is inappropriately acting upon a
+ non-leaf entry.
+
+ notAllowedOnRDN (67)
+ Indicates that the operation is inappropriately attempting to
+ remove a value which forms the entry's relative distinguished
+ name.
+
+ entryAlreadyExists (68)
+ Indicates that the request cannot be fulfilled (added, moved,
+ or renamed) as the target entry already exists.
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 49
+ Lightweight Directory Access Protocol Version 3
+
+
+ objectClassModsProhibited (69)
+ Indicates that an attempt to modify the object class(es) of
+ an entry's 'objectClass' attribute is prohibited.
+
+ For example, this code is returned when a client attempts to
+ modify the structural object class of an entry.
+
+ affectsMultipleDSAs (71)
+ Indicates that the operation cannot be performed as it would
+ affect multiple servers (DSAs).
+
+ other (80)
+ Indicates the server has encountered an internal error.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 50
+ Lightweight Directory Access Protocol Version 3
+
+Appendix B. Complete ASN.1 Definition
+
+ This appendix is normative.
+
+ Lightweight-Directory-Access-Protocol-V3 {1 3 6 1 1 <IANA-
+ ASSIGNED-DIRECTORY-NUMBER>}
+ -- Copyright (C) The Internet Society (2005). This version of
+ -- this ASN.1 module is part of RFC XXXX; see the RFC itself
+ -- for full legal notices.
+ DEFINITIONS
+ IMPLICIT TAGS
+ EXTENSIBILITY IMPLIED ::=
+
+ BEGIN
+
+ 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,
+ ...,
+ intermediateResponse IntermediateResponse },
+ controls [0] Controls OPTIONAL }
+
+ MessageID ::= INTEGER (0 .. maxInt)
+
+ maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
+
+ LDAPString ::= OCTET STRING -- UTF-8 encoded,
+ -- [ISO10646] characters
+
+ LDAPOID ::= OCTET STRING -- Constrained to <numericoid> [Models]
+
+ LDAPDN ::= LDAPString -- Constrained to <distinguishedName>
+ -- [LDAPDN]
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 51
+ Lightweight Directory Access Protocol Version 3
+
+ RelativeLDAPDN ::= LDAPString -- Constrained to <name-component>
+ -- [LDAPDN]
+
+ AttributeDescription ::= LDAPString
+ -- Constrained to <attributedescription>
+ -- [Models]
+
+ AttributeValue ::= OCTET STRING
+
+ AttributeValueAssertion ::= SEQUENCE {
+ attributeDesc AttributeDescription,
+ assertionValue AssertionValue }
+
+ AssertionValue ::= OCTET STRING
+
+ PartialAttribute ::= SEQUENCE {
+ type AttributeDescription,
+ vals SET OF value AttributeValue }
+
+ Attribute ::= PartialAttribute(WITH COMPONENTS {
+ ...,
+ vals (SIZE(1..MAX))})
+
+ MatchingRuleId ::= LDAPString
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 52
+ Lightweight Directory Access Protocol Version 3
+
+ LDAPResult ::= SEQUENCE {
+ resultCode ENUMERATED {
+ success (0),
+ operationsError (1),
+ protocolError (2),
+ timeLimitExceeded (3),
+ sizeLimitExceeded (4),
+ compareFalse (5),
+ compareTrue (6),
+ authMethodNotSupported (7),
+ strongerAuthRequired (8),
+ -- 9 reserved --
+ referral (10),
+ adminLimitExceeded (11),
+ unavailableCriticalExtension (12),
+ confidentialityRequired (13),
+ saslBindInProgress (14),
+ 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),
+ objectClassModsProhibited (69),
+ -- 70 reserved for CLDAP --
+ affectsMultipleDSAs (71),
+ -- 72-79 unused --
+ other (80),
+ ... },
+ matchedDN LDAPDN,
+ diagnosticMessage LDAPString,
+ referral [3] Referral OPTIONAL }
+
+ Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI
+
+Sermersheim Internet-Draft - Expires April 2006 Page 53
+ Lightweight Directory Access Protocol Version 3
+
+
+ URI ::= LDAPString -- limited to characters permitted in
+ -- URIs
+
+ Controls ::= SEQUENCE OF control Control
+
+ Control ::= SEQUENCE {
+ controlType LDAPOID,
+ criticality BOOLEAN DEFAULT FALSE,
+ controlValue OCTET STRING OPTIONAL }
+
+ BindRequest ::= [APPLICATION 0] SEQUENCE {
+ version INTEGER (1 .. 127),
+ name LDAPDN,
+ authentication AuthenticationChoice }
+
+ AuthenticationChoice ::= CHOICE {
+ simple [0] OCTET STRING,
+ -- 1 and 2 reserved
+ sasl [3] SaslCredentials,
+ ... }
+
+ SaslCredentials ::= SEQUENCE {
+ mechanism LDAPString,
+ credentials OCTET STRING OPTIONAL }
+
+ BindResponse ::= [APPLICATION 1] SEQUENCE {
+ COMPONENTS OF LDAPResult,
+ serverSaslCreds [7] OCTET STRING OPTIONAL }
+
+ UnbindRequest ::= [APPLICATION 2] NULL
+
+ SearchRequest ::= [APPLICATION 3] SEQUENCE {
+ baseObject LDAPDN,
+ scope ENUMERATED {
+ baseObject (0),
+ singleLevel (1),
+ wholeSubtree (2),
+ ... },
+ derefAliases ENUMERATED {
+ neverDerefAliases (0),
+ derefInSearching (1),
+ derefFindingBaseObj (2),
+ derefAlways (3) },
+ sizeLimit INTEGER (0 .. maxInt),
+ timeLimit INTEGER (0 .. maxInt),
+ typesOnly BOOLEAN,
+ filter Filter,
+ attributes AttributeSelection }
+
+ AttributeSelection ::= SEQUENCE OF selector LDAPString
+ -- The LDAPString is constrained to
+ -- <attributeSelector> in Section 4.5.1.7
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 54
+ Lightweight Directory Access Protocol Version 3
+
+ Filter ::= CHOICE {
+ and [0] SET SIZE (1..MAX) OF filter Filter,
+ or [1] SET SIZE (1..MAX) OF filter Filter,
+ not [2] Filter,
+ equalityMatch [3] AttributeValueAssertion,
+ substrings [4] SubstringFilter,
+ greaterOrEqual [5] AttributeValueAssertion,
+ lessOrEqual [6] AttributeValueAssertion,
+ present [7] AttributeDescription,
+ approxMatch [8] AttributeValueAssertion,
+ extensibleMatch [9] MatchingRuleAssertion,
+ ... }
+
+ SubstringFilter ::= SEQUENCE {
+ type AttributeDescription,
+ substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE {
+ initial [0] AssertionValue, -- can occur at most once
+ any [1] AssertionValue,
+ final [2] AssertionValue } -- can occur at most once
+ }
+
+ MatchingRuleAssertion ::= SEQUENCE {
+ matchingRule [1] MatchingRuleId OPTIONAL,
+ type [2] AttributeDescription OPTIONAL,
+ matchValue [3] AssertionValue,
+ dnAttributes [4] BOOLEAN DEFAULT FALSE }
+
+ SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
+ objectName LDAPDN,
+ attributes PartialAttributeList }
+
+ PartialAttributeList ::= SEQUENCE OF
+ partialAttribute PartialAttribute
+
+ SearchResultReference ::= [APPLICATION 19] SEQUENCE
+ SIZE (1..MAX) OF uri URI
+
+ SearchResultDone ::= [APPLICATION 5] LDAPResult
+
+ ModifyRequest ::= [APPLICATION 6] SEQUENCE {
+ object LDAPDN,
+ changes SEQUENCE OF change SEQUENCE {
+ operation ENUMERATED {
+ add (0),
+ delete (1),
+ replace (2),
+ ... },
+ modification PartialAttribute } }
+
+ ModifyResponse ::= [APPLICATION 7] LDAPResult
+
+ AddRequest ::= [APPLICATION 8] SEQUENCE {
+ entry LDAPDN,
+ attributes AttributeList }
+
+Sermersheim Internet-Draft - Expires April 2006 Page 55
+ Lightweight Directory Access Protocol Version 3
+
+
+ AttributeList ::= SEQUENCE OF attribute Attribute
+
+ AddResponse ::= [APPLICATION 9] LDAPResult
+
+ DelRequest ::= [APPLICATION 10] LDAPDN
+
+ DelResponse ::= [APPLICATION 11] LDAPResult
+
+ ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
+ entry LDAPDN,
+ newrdn RelativeLDAPDN,
+ deleteoldrdn BOOLEAN,
+ newSuperior [0] LDAPDN OPTIONAL }
+
+ ModifyDNResponse ::= [APPLICATION 13] LDAPResult
+
+ CompareRequest ::= [APPLICATION 14] SEQUENCE {
+ entry LDAPDN,
+ ava AttributeValueAssertion }
+
+ CompareResponse ::= [APPLICATION 15] LDAPResult
+
+ AbandonRequest ::= [APPLICATION 16] MessageID
+
+ ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
+ requestName [0] LDAPOID,
+ requestValue [1] OCTET STRING OPTIONAL }
+
+ ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
+ COMPONENTS OF LDAPResult,
+ responseName [10] LDAPOID OPTIONAL,
+ responseValue [11] OCTET STRING OPTIONAL }
+
+ IntermediateResponse ::= [APPLICATION 25] SEQUENCE {
+ responseName [0] LDAPOID OPTIONAL,
+ responseValue [1] OCTET STRING OPTIONAL }
+
+ END
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 56
+ Lightweight Directory Access Protocol Version 3
+
+Appendix C. Changes
+
+ This appendix is non-normative.
+
+ This appendix summarizes substantive changes made to RFC 2251, RFC
+ 2830, and RFC 3771.
+
+
+C.1. Changes made to RFC 2251:
+
+ This section summarizes the substantive changes made to Sections 1,
+ 2, 3.1, and 4 through the remainder of RFC 2251. Readers should
+ consult [Models] and [AuthMeth] for summaries of changes to other
+ sections.
+
+
+C.1.1. Section 1 (Status of this Memo)
+
+ - Removed IESG note. Post publication of RFC 2251, mandatory LDAP
+ authentication mechanisms have been standardized which are
+ sufficient to remove this note. See [AuthMeth] for authentication
+ mechanisms.
+
+
+C.1.2. Section 3.1 (Protocol Model) and others
+
+ - Removed notes giving history between LDAP v1, v2 and v3. Instead,
+ added sufficient language so that this document can stand on its
+ own.
+
+
+C.1.3. Section 4 (Elements of Protocol)
+
+ - Clarified where the extensibility features of ASN.1 apply to the
+ protocol. This change affected various ASN.1 types by the
+ inclusion of ellipses (...) to certain elements.
+ - Removed the requirement that servers which implement version 3 or
+ later MUST provide the 'supportedLDAPVersion' attribute. This
+ statement provided no interoperability advantages.
+
+
+C.1.4. Section 4.1.1 (Message Envelope)
+
+ - There was a mandatory requirement for the server to return a
+ Notice of Disconnection and drop the transport connection when a
+ PDU is malformed in a certain way. This has been updated such that
+ the server SHOULD return the Notice of Disconnection, and MUST
+ terminate the LDAP Session.
+
+
+C.1.5. Section 4.1.1.1 (Message ID)
+
+ - Required that the messageID of requests MUST be non-zero as the
+ zero is reserved for Notice of Disconnection.
+
+Sermersheim Internet-Draft - Expires April 2006 Page 57
+ Lightweight Directory Access Protocol Version 3
+
+ - Specified when it is and isn't appropriate to return an already
+ used message id. RFC 2251 accidentally imposed synchronous server
+ behavior in its wording of this.
+
+
+C.1.6. Section 4.1.2 (String Types)
+
+ - Stated that LDAPOID is constrained to <numericoid> from [Models].
+
+
+C.1.7. Section 4.1.5.1 (Binary Option) and others
+
+ - Removed the Binary Option from the specification. There are
+ numerous interoperability problems associated with this method of
+ alternate attribute type encoding. Work to specify a suitable
+ replacement is ongoing.
+
+
+C.1.8. Section 4.1.8 (Attribute)
+
+ - Combined the definitions of PartialAttribute and Attribute here,
+ and defined Attribute in terms of PartialAttribute.
+
+
+C.1.9. Section 4.1.10 (Result Message)
+
+ - Renamed "errorMessage" to "diagnosticMessage" as it is allowed to
+ be sent for non-error results.
+ - Moved some language into Appendix A, and refer the reader there.
+ - Allowed matchedDN to be present for other result codes than those
+ listed in RFC 2251.
+ - renamed the code "strongAuthRequired" to "strongerAuthRequired" to
+ clarify that this code may often be returned to indicate that a
+ stronger authentication is needed to perform a given operation.
+
+
+C.1.10. Section 4.1.11 (Referral)
+
+ - Defined referrals in terms of URIs rather than URLs.
+ - Removed the requirement that all referral URIs MUST be equally
+ capable of progressing the operation. The statement was ambiguous
+ and provided no instructions on how to carry it out.
+ - Added the requirement that clients MUST NOT loop between servers.
+ - Clarified the instructions for using LDAPURLs in referrals, and in
+ doing so added a recommendation that the scope part be present.
+ - Removed imperatives which required clients to use URLs in specific
+ ways to progress an operation. These did nothing for
+ interoperability.
+
+
+C.1.11. Section 4.1.12 (Controls)
+
+ - Specified how control values defined in terms of ASN.1 are to be
+ encoded.
+
+Sermersheim Internet-Draft - Expires April 2006 Page 58
+ Lightweight Directory Access Protocol Version 3
+
+ - Noted that the criticality field is only applied to request
+ messages (except UnbindRequest), and must be ignored when present
+ on response messages and UnbindRequest.
+ - Specified that non-critical controls may be ignored at the
+ server's discretion. There was confusion in the original wording
+ which led some to believe that recognized controls may not be
+ ignored as long as they were associated with a proper request.
+ - Added language regarding combinations of controls and the ordering
+ of controls on a message.
+ - Specified that when the semantics of the combination of controls
+ is undefined or unknown, it results in a protocolError.
+ - Changed "The server MUST be prepared" to "Implementations MUST be
+ prepared" in the eighth paragraph to reflect that both client and
+ server implementations must be able to handle this (as both parse
+ controls).
+
+
+C.1.12. Section 4.2 (Bind Operation)
+
+ - Mandated that servers return protocolError when the version is not
+ supported.
+ - Disambiguated behavior when the simple authentication is used, the
+ name is empty and the password is non-empty.
+ - Required servers to not dereference aliases for Bind. This was
+ added for consistency with other operations and to help ensure
+ data consistency.
+ - Required that textual passwords be transferred as UTF-8 encoded
+ Unicode, and added recommendations on string preparation. This was
+ to help ensure interoperability of passwords being sent from
+ different clients.
+
+
+C.1.13. Section 4.2.1 (Sequencing of the Bind Request)
+
+ - This section was largely reorganized for readability and language
+ was added to clarify the authentication state of failed and
+ abandoned Bind operations.
+ - Removed: "If a SASL transfer encryption or integrity mechanism has
+ been negotiated, that mechanism does not support the changing of
+ credentials from one identity to another, then the client MUST
+ instead establish a new connection."
+ If there are dependencies between multiple negotiations of a
+ particular SASL mechanism, the technical specification for that
+ SASL mechanism details how applications are to deal with them.
+ LDAP should not require any special handling.
+ - Dropped MUST imperative in paragraph 3 to align with [Keywords].
+ - Mandated that clients not send non-Bind operations while a Bind is
+ in progress, and suggested that servers not process them if they
+ are received. This is needed to ensure proper sequencing of the
+ Bind in relationship to other operations.
+
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 59
+ Lightweight Directory Access Protocol Version 3
+
+C.1.14. Section 4.2.3 (Bind Response)
+
+ - Moved most error-related text to Appendix A, and added text
+ regarding certain errors used in conjunction with the Bind
+ operation.
+ - Prohibited the server from specifying serverSaslCreds when not
+ appropriate.
+
+
+C.1.15. Section 4.3 (Unbind Operation)
+
+ - Specified that both peers are to cease transmission and terminate
+ the LDAP session for the Unbind operation.
+
+
+C.1.16. Section 4.4 (Unsolicited Notification)
+
+ - Added instructions for future specifications of Unsolicited
+ Notifications.
+
+
+C.1.17. Section 4.5.1 (Search Request)
+
+ - SearchRequest attributes is now defined as an AttributeSelection
+ type rather than AttributeDescriptionList, and an ABNF is
+ provided.
+ - SearchRequest attributes may contain duplicate attribute
+ descriptions. This was previously prohibited. Now servers are
+ instructed to ignore subsequent names when they are duplicated.
+ This was relaxed in order to allow different short names and also
+ OIDs to be requested for an attribute.
+ - The present search filter now evaluates to Undefined when the
+ specified attribute is not known to the server. It used to
+ evaluate to FALSE, which caused behavior inconsistent with what
+ most would expect, especially when the not operator was used.
+ - The Filter choice SubstringFilter substrings type is now defined
+ with a lower bound of 1.
+ - The SubstringFilter substrings 'initial, 'any', and 'final' types
+ are now AssertionValue rather than LDAPString. Also, added
+ imperatives stating that 'initial' (if present) must be listed
+ first, and 'final' (if present) must be listed last.
+ - Disambiguated the semantics of the derefAliases choices. There was
+ question as to whether derefInSearching applied to the base object
+ in a wholeSubtree Search.
+ - Added instructions for equalityMatch, substrings, greaterOrEqual,
+ lessOrEqual, and approxMatch.
+
+
+C.1.18. Section 4.5.2 (Search Result)
+
+ - Recommended that servers not use attribute short names when it
+ knows they are ambiguous or may cause interoperability problems.
+ - Removed all mention of ExtendedResponse due to lack of
+ implementation.
+
+Sermersheim Internet-Draft - Expires April 2006 Page 60
+ Lightweight Directory Access Protocol Version 3
+
+
+
+C.1.19. Section 4.5.3 (Continuation References in the Search Result)
+
+ - Made changes similar to those made to Section 4.1.11.
+
+
+C.1.20. Section 4.5.3.1 (Example)
+
+ - Fixed examples to adhere to changes made to Section 4.5.3.
+
+
+C.1.21. Section 4.6 (Modify Operation)
+
+ - Replaced AttributeTypeAndValues with Attribute as they are
+ equivalent.
+ - Specified the types of modification changes which might
+ temporarily violate schema. Some readers were under the impression
+ that any temporary schema violation was allowed.
+
+
+C.1.22. Section 4.7 (Add Operation)
+
+ - Aligned Add operation with X.511 in that the attributes of the RDN
+ are used in conjunction with the listed attributes to create the
+ entry. Previously, Add required that the distinguished values be
+ present in the listed attributes.
+ - Removed requirement that the objectClass attribute MUST be
+ specified as some DSE types do not require this attribute.
+ Instead, generic wording was added, requiring the added entry to
+ adhere to the data model.
+ - Removed recommendation regarding placement of objects. This is
+ covered in the data model document.
+
+
+C.1.23. Section 4.9 (Modify DN Operation)
+
+ - Required servers to not dereference aliases for Modify DN. This
+ was added for consistency with other operations and to help ensure
+ data consistency.
+ - Allow Modify DN to fail when moving between naming contexts.
+ - Specified what happens when the attributes of the newrdn are not
+ present on the entry.
+
+
+C.1.24. Section 4.10 (Compare Operation)
+
+ - Specified that compareFalse means that the Compare took place and
+ the result is false. There was confusion which lead people to
+ believe that an Undefined match resulted in compareFalse.
+ - Required servers to not dereference aliases for Compare. This was
+ added for consistency with other operations and to help ensure
+ data consistency.
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 61
+ Lightweight Directory Access Protocol Version 3
+
+
+C.1.25. Section 4.11 (Abandon Operation)
+
+ - Explained that since Abandon returns no response, clients should
+ not use it if they need to know the outcome.
+ - Specified that Abandon and Unbind cannot be abandoned.
+
+
+C.1.26. Section 4.12 (Extended Operation)
+
+ - Specified how values of Extended operations defined in terms of
+ ASN.1 are to be encoded.
+ - Added instructions on what Extended operation specifications
+ consist of.
+ - Added a recommendation that servers advertise supported Extended
+ operations.
+
+
+C.1.27. Section 5.2 (Transfer Protocols)
+
+ - Moved referral-specific instructions into referral-related
+ sections.
+
+
+C.1.28. Section 7 (Security Considerations)
+
+ - Reworded notes regarding SASL not protecting certain aspects of
+ the LDAP Bind messages.
+ - Noted that Servers are encouraged to prevent directory
+ modifications by clients that have authenticated anonymously
+ [AuthMeth].
+ - Added a note regarding the possibility of changes to security
+ factors (authentication, authorization, data confidentiality).
+ - Warned against following referrals that may have been injected in
+ the data stream.
+ - Noted that servers should protect information equally, whether in
+ an error condition or not, and mentioned specifically; matchedDN,
+ diagnosticMessage, and resultCodes.
+ - Added a note regarding malformed and long encodings.
+
+
+C.1.29. Appendix A (Complete ASN.1 Definition)
+
+ - Added "EXTENSIBILITY IMPLIED" to ASN.1 definition.
+ - Removed AttributeType. It is not used.
+
+
+C.2. Changes made to RFC 2830:
+
+ This section summarizes the substantive changes made to Sections of
+ RFC 2830. Readers should consult [AuthMeth] for summaries of changes
+ to other sections.
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 62
+ Lightweight Directory Access Protocol Version 3
+
+C.2.1. Section 2.3 (Response other than "success")
+
+ - Removed wording indicating that referrals can be returned from
+ StartTLS.
+ - Removed requirement that only a narrow set of result codes can be
+ returned. Some result codes are required in certain scenarios, but
+ any other may be returned if appropriate.
+ - Removed requirement that the ExtendedResponse.responseName MUST be
+ present. There are circumstances where this is impossible, and
+ requiring this is at odds with language in Section 4.12.
+
+
+C.2.1. Section 4 (Closing a TLS Connection)
+
+ - Reworded most of this section to align with definitions of the
+ LDAP protocol layers.
+ - Removed instructions on abrupt closure as this is covered in other
+ areas of the document (specifically, Section 5.3)
+
+
+C.3. Changes made to RFC 3771:
+
+ - Rewrote to fit into this document. In general, semantics were
+ preserved. Supporting and background language seen as redundant
+ due to its presence in this document was omitted.
+ - Specified that Intermediate responses to a request may be of
+ different types, and one of the response types may be specified to
+ have no response value.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 63
+ Lightweight Directory Access Protocol Version 3
+
+
+
+
+Intellectual Property Statement
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at ietf-
+ ipr@ietf.org.
+
+Disclaimer of Validity
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Copyright Statement
+
+ Copyright (C) The Internet Society (2005).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 64
diff --git a/doc/drafts/draft-zeilenga-ldap-dontusecopy-xx.txt b/doc/drafts/draft-zeilenga-ldap-dontusecopy-xx.txt
index 495ea5cc93..84065c8dfc 100644
--- a/doc/drafts/draft-zeilenga-ldap-dontusecopy-xx.txt
+++ b/doc/drafts/draft-zeilenga-ldap-dontusecopy-xx.txt
@@ -6,12 +6,12 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 17 July 2005
+Expires in six months 5 March 2006
The LDAP Don't Use Copy Control
- <draft-zeilenga-ldap-dontusecopy-01.txt>
+ <draft-zeilenga-ldap-dontusecopy-02.txt>
Status of this Memo
@@ -44,7 +44,7 @@ Status of this Memo
http://www.ietf.org/shadow.html
- Copyright (C) The Internet Society (2005). All Rights Reserved.
+ Copyright (C) The Internet Society (2006). All Rights Reserved.
Please see the Full Copyright section near the end of this document
for more information.
@@ -57,7 +57,7 @@ Status of this Memo
Zeilenga LDAP Don't Use Copy Control [Page 1]
-INTERNET-DRAFT draft-zeilenga-ldap-dontusecopy-01 17 July 2005
+INTERNET-DRAFT draft-zeilenga-ldap-dontusecopy-02 5 March 2006
Abstract
@@ -96,8 +96,7 @@ Abstract
The Don't Use Copy control is an LDAP Control [Protocol] whose
controlType is IANA-ASSIGNED-OID and controlValue is absent. The
- criticality may be TRUE or FALSE. There is no corresponding response
- control.
+ criticality MUST be TRUE. There is no corresponding response control.
The control is appropriate for both LDAP interrogation operations,
including Compare and Search operations [Protocol]. It is
@@ -108,15 +107,15 @@ Abstract
operation MUST NOT be performed on copied information. That is, the
requested operation MUST be performed on original information.
+ If original information for the target or base object of the operation
Zeilenga LDAP Don't Use Copy Control [Page 2]
-INTERNET-DRAFT draft-zeilenga-ldap-dontusecopy-01 17 July 2005
+INTERNET-DRAFT draft-zeilenga-ldap-dontusecopy-02 5 March 2006
- If original information for the target or base object of the operation
is not available (either locally or through chaining), the server MUST
either return a referral directing the client to a server believed to
be better able to service the request or return an appropriate result
@@ -164,15 +163,15 @@ INTERNET-DRAFT draft-zeilenga-ldap-dontusecopy-01 17 July 2005
Person & email address to contact for further information:
Kurt Zeilenga <kurt@openldap.org>
Usage: Control
+ Specification: RFC XXXX
Zeilenga LDAP Don't Use Copy Control [Page 3]
-INTERNET-DRAFT draft-zeilenga-ldap-dontusecopy-01 17 July 2005
+INTERNET-DRAFT draft-zeilenga-ldap-dontusecopy-02 5 March 2006
- Specification: RFC XXXX
Author/Change Controller: IESG
Comments: none
@@ -223,9 +222,10 @@ INTERNET-DRAFT draft-zeilenga-ldap-dontusecopy-01 17 July 2005
+
Zeilenga LDAP Don't Use Copy Control [Page 4]
-INTERNET-DRAFT draft-zeilenga-ldap-dontusecopy-01 17 July 2005
+INTERNET-DRAFT draft-zeilenga-ldap-dontusecopy-02 5 March 2006
Intellectual Property Rights
@@ -256,7 +256,7 @@ Intellectual Property Rights
Full Copyright
- Copyright (C) The Internet Society (2005).
+ Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
diff --git a/doc/drafts/draft-zeilenga-ldap-grouping-xx.txt b/doc/drafts/draft-zeilenga-ldap-grouping-xx.txt
deleted file mode 100644
index 76717f42c6..0000000000
--- a/doc/drafts/draft-zeilenga-ldap-grouping-xx.txt
+++ /dev/null
@@ -1,843 +0,0 @@
-
-
-
-
-
-
-INTERNET-DRAFT Kurt D. Zeilenga
-Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 3 May 2003
-
-
-
- LDAP: Grouping of Related Operations
- <draft-zeilenga-ldap-grouping-06.txt>
-
-
-Status of Memo
-
- This document is an Internet-Draft and is in full conformance with all
- provisions of Section 10 of RFC2026.
-
- This document is intended to be, after appropriate review and
- revision, submitted to the RFC Editor as a Standard Track document.
- Distribution of this memo is unlimited. Technical discussion of this
- document will take place on the IETF LDAP Extension Working Group
- mailing list <ldapext@ietf.org>. Please send editorial comments
- directly to the author <Kurt@OpenLDAP.org>.
-
- 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>.
-
- Copyright 2003, The Internet Society. All Rights Reserved.
-
- Please see the Copyright section near the end of this document for
- more information.
-
-
-Abstract
-
- This document provides a general mechanism for grouping related
- Lightweight Directory Access Protocol (LDAP) operations. Grouping of
- operations can be used to support replication, proxies, and
- transactions.
-
-
-
-
-Zeilenga LDAP Grouping [Page 1]
-
-INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
-
-
-Conventions
-
- Schema definitions are provided using LDAP description formats
- [RFC2252]. Definitions provided here are formatted (line wrapped) for
- readability.
-
- Protocol elements are described using ASN.1 [X.680]. The term
- "BER-encoded" means the element is to be encoded using the Basic
- Encoding Rules [X.690] under the restrictions detailed in Section 5.1
- of [RFC2251].
-
- 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 BCP 14 [RFC2119].
-
-
-1. Introduction
-
- This document provides a general mechanism for grouping related
- Lightweight Directory Access Protocol (LDAP) [RFC3377] operations.
- Grouping of operations can be used to support replication, proxies,
- and high level operations such as transactions [TXNGRP].
-
- This document describes a set of LDAP extended operations [RFC2251]
- and other protocol and schema elements to support grouping of related
- operations. Uses of this grouping mechanism will be detailed in
- separate documents.
-
- A group of operations is defined as a set of operations within a
- common session identified by a unique cookie. All requests which are
- initiated with the same cookie belong to the same grouping. The
- cookie is obtained using the create group operation and is normally
- valid until the end group operation is completed. A group can end
- prematurely as described below.
-
- Operations can be intermixed regardless of their grouping (or lack of
- grouping). Groups can be nested.
-
- Each group is of a particular type specified when the group is
- created. This type defines the semantics of the group.
-
-
-2. Protocol Elements
-
- This document describes three extended operations, two unsolicited
- notification, and one control. Extended operations and controls are
- described by LDAP [RFC2251] and provide here for convenience:
-
-
-
-
-Zeilenga LDAP Grouping [Page 2]
-
-INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
-
-
- ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
- requestName [0] LDAPOID,
- requestValue [1] OCTET STRING OPTIONAL
- }
-
- ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
- COMPONENTS of LDAPResult,
- responseName [10] LDAPOID OPTIONAL,
- response [11] OCTET STRING OPTIONAL
- }
-
- Control ::= SEQUENCE {
- controlType LDAPOID,
- criticality BOOLEAN DEFAULT FALSE,
- controlValue OCTET STRING OPTIONAL
- }
-
-
-2.1 Common Protocol Elements
-
- groupCookie ::= OCTET STRING
-
- A groupCookie is an octet string used to uniquely identify a grouping
- of related operations within the session. A groupCookie is a
- notational convenience.
-
-
-2.2 Create Grouping Operation
-
- The Create Grouping extended operation is used to create or start a
- grouping of related operations. The operation consists of the
- createGroupingRequest and the createGroupingResponse. The object
- identifier createGroupingOID identifies this operation and SHOULD be
- listed as a value of supportedExtension in the root DSE of servers
- which support this operation.
-
- createGroupingOID ::= "IANA-ASSIGNED-OID.1"
-
-
-2.2.1 createGroupingRequest
-
- The client initiates this operation by sending a
- createGroupingRequest. This request is an ExtendedRequest where the
- requestName is the object identifier createGroupOID and requestValue
- is BER-encoded createGroupingRequestValue:
-
- createGroupingRequestValue ::= SEQUENCE {
- createGroupType [0] LDAPOID,
-
-
-
-Zeilenga LDAP Grouping [Page 3]
-
-INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
-
-
- createGroupValue [1] OCTET STRING OPTIONAL
- }
-
- where createGroupType is an object identifier that describes the
- specific type of grouping and createGroupValue contains a type
- specific payload.
-
-
-2.2.2 createGroupingResponse
-
- The createGroupingResponse is sent in response to a
- createGroupingRequest. This response is an ExtendedResponse where the
- responseName MUST be the value of the requestName provided in the
- request and the response is a BER-encoded createGroupingResponseValue:
-
- createGroupingResponseValue ::= SEQUENCE {
- createGroupCookie [0] groupCookie OPTIONAL,
- createGroupValue [1] OCTET STRING OPTIONAL
- }
-
- where createGroupCookie, if present, is a cookie uniquely identifying
- the new grouping and createGroupValue is a type specific payload. The
- createGroupCookie only when the operation results in the creation of a
- group. Otherwise, it is absent.
-
-
-2.3 End Grouping Operation
-
- The End Grouping extended operation is used to end or stop a grouping
- of related operations. The operation consists of the
- endGroupingRequest and the endGroupingResponse. The object identifier
- endGroupingOID identifies this operation and SHOULD be listed as a
- value of supportedExtension in the root DSE of servers which support
- this operation.
-
- endGroupingOID ::= "IANA-ASSIGNED-OID.2"
-
-
-2.3.1 endGroupingRequest
-
- The client initiates this operation by sending an endGroupingRequest.
- This request is an ExtendedRequest where the requestName is the object
- identifier endGroupOID and requestValue is BER-encoded
- endGroupingRequestValue:
-
- endGroupingRequestValue ::= SEQUENCE {
- endGroupCookie [0] groupCookie,
- endGroupValue [1] OCTET STRING OPTIONAL
-
-
-
-Zeilenga LDAP Grouping [Page 4]
-
-INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
-
-
- }
-
- where endGroupCookie is a cookie identifying the grouping and
- endGroupValue contains a type specific payload.
-
-
-2.3.2 endGroupingResponse
-
- The endGroupingResponse is sent in response to a endGroupingRequest.
- This response is an ExtendedResponse where the responseName MUST be
- the value of the requestName provided in request and the response is a
- BER-encoded endGroupingResponseValue:
-
- endGroupingResponseValue ::= SEQUENCE {
- endGroupValue [1] OCTET STRING OPTIONAL
- }
-
- where endGroupValue is a type specific payload.
-
-
-2.4 endGroupingNotice
-
- The endGroupingNotice is an LDAP unsolicited notification. The
- notification may be sent to the client to end a grouping which the
- server is unable or unwilling to continue to process. The notice is
- an extendedResponse where the responseName is the object identifier
- endGroupingNoticeOID and the response is a BER-encoded
- endGroupingNoticeValue:
-
- endGroupingNoticeOID ::= "IANA-ASSIGNED-OID.3"
-
- endGroupingNoticeValue ::= SEQUENCE {
- endGroupingCookie [0] groupCookie,
- endGroupValue [1] OCTET STRING OPTIONAL
- }
-
- where endGroupingCookie is a cookie uniquely identifying the grouping
- and endGroupValue contains a type specific payload.
-
-
-2.5 Action Grouping Operation
-
- The Action Grouping extended operation is used to take an action
- affecting a grouping of related operations. The operation consists of
- the actionGroupingRequest and the actionGroupingResponse. The object
- identifier actionGroupingOID identifies this operation and SHOULD be
- listed as a value of supportedExtension in the root DSE of servers
- which support this operation.
-
-
-
-Zeilenga LDAP Grouping [Page 5]
-
-INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
-
-
- actionGroupingOID ::= "IANA-ASSIGNED-OID.4"
-
-
-2.5.1 actionGroupingRequest
-
- The client initiates this operation by sending an
- actionGroupingRequest. This request is an ExtendedRequest where the
- requestName is the object identifier actionGroupOID and requestValue
- is BER-encoded actionGroupingRequestValue:
-
- actionGroupingRequestValue ::= SEQUENCE {
- actionGroupCookie [0] groupCookie,
- actionGroupValue [1] OCTET STRING OPTIONAL
- }
-
- where actionGroupCookie is a cookie identifying the grouping and
- actionGroupValue contains a type specific payload.
-
-
-2.5.2 actionGroupingResponse
-
- The actionGroupingResponse is sent in response to a
- actionGroupingRequest. This response is an ExtendedResponse where the
- responseName MUST be the value of the requestName provided in request
- and the response is a BER-encoded actionGroupingResponseValue:
-
- actionGroupingResponseValue ::= SEQUENCE {
- actionGroupValue [1] OCTET STRING OPTIONAL
- }
-
- where actionGroupValue is a type specific payload.
-
-
-2.6 infoGroupingNotice
-
- The infoGroupingNotice is an LDAP unsolicited notification. The
- notice may be sent to the client to provide additional grouping type
- specific information. The notice is an extendedResponse where the
- responseName is the object identifier infoGroupingNoticeOID and the
- response is a BER-encoded infoGroupingNoticeValue:
-
- infoGroupingNoticeOID ::= "IANA-ASSIGNED-OID.5"
-
- infoGroupingNoticeValue ::= SEQUENCE {
- infoGroupingCookie [0] groupCookie,
- infoGroupValue [1] OCTET STRING OPTIONAL
- }
-
-
-
-
-Zeilenga LDAP Grouping [Page 6]
-
-INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
-
-
- where infoGroupingCookie is a cookie uniquely identifying the grouping
- and infoGroupValue contains a type specific payload.
-
-
-2.7 groupingControl
-
- The groupingControl is used to identify requests and responses as
- belonging to a grouping of operations. The groupingControl is a
- Control where the controlType is the object identifier
- groupingControlOID, the criticality is TRUE, and the controlValue is a
- BER-encoded groupingControlValue:
-
- groupingControlOID ::= "IANA-ASSIGNED-OID.6"
-
- groupingControlValue ::= SEQUENCE {
- groupingCookie [0] groupCookie,
- groupValue [1] OCTET STRING OPTIONAL
- }
-
- where groupingCookie is a cookie uniquely identifying the grouping and
- groupingValue contains a type specific payload.
-
- The value groupingControlOID SHOULD be listed as a value of
- supportedControl in the root DSE by servers which support this
- control.
-
- The control SHALL NOT appear multiple times in the same LDAP PDU. If
- multiple occurrences of the control are detected, the PDU SHALL be
- treated as a protocol error.
-
-
-3. Schema Elements
-
- The document describes one attribute type.
-
-
-3.1. supportedGroupingTypes
-
- Servers SHOULD publish grouping types they support listing group type
- object identifiers as values of the supportedGroupingTypes attribute
- type in the root DSE. The supportedGroupingTypes attribute type is
- defined as:
-
- ( IANA-ASSIGNED-OID.7 NAME 'supportedGroupingTypes'
- DESC 'supported types of groupings of operations'
- EQUALITY objectIdentifierMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation )
-
-
-
-
-Zeilenga LDAP Grouping [Page 7]
-
-INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
-
-
- The objectIdentifierMatch and OBJECT IDENTIFIER
- (1.3.6.1.4.1.1466.115.121.1.38) are defined in [RFC2252].
-
- Servers MUST be capable of recognizing this attribute type by the name
- 'supportedGroupingTypes'. Servers MAY recognize the attribute type by
- other names.
-
-
-4. Operational Semantics
-
- This section details the common semantics of groups of related
- operations. Additional semantics may be associated with each
- grouping type as described by other documents.
-
-
-4.1 Grouping Semantics
-
- This subsection details semantics of the protocol elements introduced
- in Section 2.
-
-
-4.1.1 Create Grouping
-
- To group related operations, the client MUST request a groupCookie
- from the server by sending a createGroupingRequest as described in
- Section 2.2.1. The client SHALL provide type specific payload in
- createGroupValue if so required by the grouping type.
-
- The server SHALL respond with a createGroupingResponse as described in
- Section 2.2.2. If the server is willing and able to create the
- grouping as requested (and per type requirements), it SHALL respond
- with success, provide a session-unique groupCookie and, if
- appropriate, a type specific payload. Otherwise the server SHALL
- respond with a non-successful response containing no groupCookie, but
- MAY, if appropriate, provide a type specific payload.
-
-
-4.1.2 End Grouping
-
- When the client wishes to end the grouping, the client SHALL send a
- endGroupingRequest as described in Section 2.3.1. The client SHALL
- provide the groupCookie of the grouping to end and MAY provided a type
- specific payload. If the grouping to end contains active nested
- groupings, these are implicitly ended as well without notice. The
- server SHALL respond with an endGroupingResponse as described in
- Section 2.3.2.
-
-
-
-
-
-Zeilenga LDAP Grouping [Page 8]
-
-INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
-
-
-4.1.3 End Group Notice
-
- The server MAY end a group without solicitation for any reason. The
- server SHALL notify the client of this action by sending a endGrouping
- Notice, as described in Section 2.4. The server SHALL provide the
- groupCookie of the group it terminated and MAY provide a type specific
- payload. The notice SHALL have a non-success resultCode.
-
- If the group contains nested groups, the nested groups are implicitly
- ended as well without additional notice.
-
-
-4.1.4 Action Grouping
-
- To perform an action within a group of related operations, the client
- sends to the server actionGroupingRequest as described in Section
- 2.5.1. The client SHALL provide the groupCookie of the group the
- operation is requested upon and, if required by the grouping type, a
- type specific payload.
-
- The server SHALL respond with a actionGroupingResponse as described in
- Section 2.5.2. The server SHALL, if required by the grouping type,
- provide type specific payload.
-
-
-4.1.5 Info Grouping Notice
-
- As allowed by the grouping type, the server MAY provide to the client
- a notice regarding the grouping of related operations in an
- infoGroupingNotice as described in Section 2.6. The server SHALL, if
- required by the grouping type, provide type specific payload.
-
-
-4.2 Nested groupings
-
- Groups of the same or different types MAY be nested. A nested group
- is instantiated by providing a groupingControl containing the parent
- group's cookie with the createGroupingRequest.
-
- Group type specifications MAY restrict the types of groupings which
- may be nested. Servers MAY also place additional restrictions upon
- nesting. Clients SHOULD NOT assume support for arbitrary nesting.
-
-
-4.3 Intermixing of unrelated operations
-
- LDAP is designed to allow clients to perform unrelated tasks
- concurrently. In keeping with this design, operations which unrelated
-
-
-
-Zeilenga LDAP Grouping [Page 9]
-
-INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
-
-
- to the grouping are generally allowed be intermixed with grouped
- operations. (See Section 4.5 for specific exceptions to this general
- rule.) It is noted that undue restrictions often unrelated operation
- cause unnecessary serialization of independent tasks, place
- unnecessary burden upon implementors, and can limit extensibility.
-
- Group type specifications SHOULD NOT disallow unrelated operations
- from being intermixed with grouped operations.
-
- Note: a grouping which disallows unrelated operatoins from being
- intermixed with grouped operations can be viewed as providing
- "framing" semantics.
-
-
-4.4 Grouped operations
-
- Interrogation (compare, search) and update (add, delete, modify,
- rename) MAY be grouped. Certain extended operations MAY also be
- grouped, but those which affect the session as a whole, such as Start
- TLS, MUST NOT be grouped.
-
- Requests and Responses associated with grouped operations contain a
- groupingControl control as described in Section 2.7.
-
- Group type specifications MAY restrict the kind and/or number of
- operations which may be related. Servers MAY place additional
- restrictions upon groupings. Clients SHOULD NOT assume support for
- arbitrary grouping.
-
-
-4.5 Other Operations
-
- Upon issuing any grouping operation, the semantics of following
- operations listed is modified as described below.
-
-
-4.5.1 abandon
-
- The abandon operation SHOULD NOT be used to cancel grouped operations.
- The Cancel operation is to be used instead (as discussed in 4.5.3).
-
-
-4.5.2 bind
-
- The client SHOULD end all outstanding groupings before issuing a bind
- request. The server SHALL, in addition to the behavior described in
- [RFC2251] and [RFC2829], abandon all outstanding groups. No
- endGroupingNotice notification is sent upon such abandonment.
-
-
-
-Zeilenga LDAP Grouping [Page 10]
-
-INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
-
-
- A Bind operation cannot be related to other operations using this
- grouping mechanism. The bind messages SHOULD NOT contain
- groupingControl controls and, if present, SHALL be treated as a a
- protocol error.
-
-
-4.5.3 cancel
-
- The cancel operation [CANCEL] MAY be used to cancel grouped operations
- but SHOULD NOT contain a groupingControl control unless the group type
- calls for a type specific payload to be provided. The groupingCookie
- in the provided groupingControl control MUST be the same associated
- with the operation to be canceled, otherwise the cancel request SHALL
- be treated as an error.
-
-
-4.5.4 Start TLS
-
- The client SHOULD end all outstanding groupings before issuing a Start
- TLS [RFC2930] request. If there are any outstanding groupings, the
- server MUST return operationsError in response to a StartTLS request.
- Start TLS operation cannot be related to other operations using this
- grouping mechanism and the Start TLS request and response PDUs SHALL
- NOT contain a groupingControl control.
-
-
-4.5.5 unbind
-
- The server SHALL, in addition to the behavior described in [RFC2251],
- abandon all outstanding groups. No endGroupingNotice is sent upon
- such abandonment. An unbind operation cannot be related to other
- operations using this grouping mechanism. The unbind request SHOULD
- NOT contain a groupingControl control and, if present, SHALL be
- ignored.
-
-
-5. Profiling Requirements
-
- Documents detailing extensions using the grouping mechanism MUST
- provide a profile of its use of the mechanism.
-
- The profile SHALL specify the object identifier to be used to uniquely
- identify each grouping type it defines. Object identifiers used to
- identity group types, like other protocol elements, SHALL be delegated
- in accordance with BCP 64 [RFC3383] and registered as LDAP Protocol
- Mechanisms [RFC3383] as detailed in Section 7.1 of this document.
-
- The profile SHALL state which protocol elements of the mechanism it
-
-
-
-Zeilenga LDAP Grouping [Page 11]
-
-INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
-
-
- uses.
-
- Each of the grouping protocol elements defined in this document allow
- transfer of type specific payloads. For each protocol element used,
- the profile SHALL state whether the element is to carry a type
- specific payload or not and SHALL fully describe the syntax and
- semantics associated with each type specific payload.
-
- The profile MAY define grouping type specific semantics which place
- further restrictions upon the grouping related operations.
-
-
-6. Security Considerations
-
- This mechanism can be used to support complex groupings of related
- operations. With such complexity comes inherit risk. Specifications
- of uses of this mechanism should take special care to address security
- issues. In particular, denial of service and authentication,
- authorization, and access-control issues should be addressed in
- documents detailing uses of this grouping mechanism.
-
-
-7. IANA Considerations
-
-7.1. Future Registration of Grouping Types
-
- Future specifications which detail LDAP grouping types are to register
- each grouping type as a LDAP Protocol Mechanism per guidance given in
- BCP 64 [RFC3383]. A usage of "Grouping Type" in a Protocol Mechanism
- registration template indicates that the value to be registered is
- associated with an LDAP Grouping Type.
-
-
-7.2. Object Identifier Registration
-
- It is requested that IANA register upon Standards Action an LDAP
- Object Identifier to identify protocol elements defined in this
- technical specification. The following registration template is
- suggested:
-
- Subject: Request for LDAP OID Registration
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@OpenLDAP.org>
- Specification: RFCXXXX
- Author/Change Controller: IESG
- Comments:
- Identifies elements of the LDAP Grouping Operation
-
-
-
-
-Zeilenga LDAP Grouping [Page 12]
-
-INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
-
-
-7.3. LDAP Protocol Mechanism
-
- It is requested that IANA register upon Standards Action the LDAP
- protocol mechanism described in this document. The following
- registration template is suggested:
-
- Subject: Request for LDAP Protocol Mechansism Registration
- Object Identifier: IANA-ASSIGNED-OID
- Description: See comments
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@openldap.org>
- Usage: Extended Operation
- Specification: RFCXXXX
- Author/Change Controller: IESG
- Comments: none
-
- Object Identifier Type Description
- ------------------- ---- -------------------------
- IANA-ASSIGNED-OID.1 E Create Grouping Operation
- IANA-ASSIGNED-OID.2 E End Grouping Operation
- IANA-ASSIGNED-OID.4 E Action Grouping Operation
-
- in 2
-
-
-7.4. supportedGroupingTypes Registration
-
- It is requested that IANA register upon Standards Action the LDAP
- 'supportedGroupingTypes' descriptor. The following registration
- template is suggested:
-
- Subject: Request for LDAP Descriptor Registration
- Descriptor (short name): supportedGroupingTypes
- Object Identifier: IANA-ASSIGNED-OID.7
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@OpenLDAP.org>
- Usage: Attribute Type
- Specification: RFCXXXX
- Author/Change Controller: IESG
-
-
-8. Acknowledgments
-
- The author gratefully acknowledges the contributions of the IETF
- LDAPext and LDUP working groups. In particular, Roger Harrison
- provided many useful suggestions. Also, the author notes that this
- document builds upon the early works "Extended Operations for Framing
- LDAP Operations" by Ellen Stokes, Roger Harrison, and Gordon Good and
-
-
-
-Zeilenga LDAP Grouping [Page 13]
-
-INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
-
-
- "Profile for Framing LDAPv3 Operations" by Roger Harrison.
-
-
-9. Author's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
- <Kurt@OpenLDAP.org>
-
-
-10. References
-
-10.1 Normative References
-
- [RFC2119] S. Bradner, "Key Words for use in RFCs to Indicate
- Requirement Levels", BCP 14 (also RFC 2119), March 1997.
-
- [RFC2251] M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access
- Protocol (v3)", RFC 2251, December 1997.
-
- [RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight
- Directory Access Protocol (v3): Attribute Syntax
- Definitions", RFC 2252, December 1997.
-
- [RFC2829] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan,
- "Authentication Methods for LDAP", RFC 2829, May 2000.
-
- [RFC2830] J. Hodges, R. Morgan, M. Wahl, "Lightweight Directory
- Access Protocol (v3): Extension for Transport Layer
- Security", RFC 2830, May 2000.
-
- [RFC3377] J. Hodges, R. Morgan, "Lightweight Directory Access
- Protocol (v3): Technical Specification", RFC 3377,
- September 2002.
-
- [RFC3383] K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also
- RFC 3383), September 2002.
-
- [X.680] ITU-T, "Abstract Syntax Notation One (ASN.1) -
- Specification of Basic Notation", X.680, 1994.
-
- [X.690] ITU-T, "Specification of ASN.1 encoding rules: Basic,
- Canonical, and Distinguished Encoding Rules", X.690, 1994.
-
-
-10.2. Informative References
-
- [TXNGRP] K. Zeilenga, "LDAP Transactions" (a work in progress),
-
-
-
-Zeilenga LDAP Grouping [Page 14]
-
-INTERNET-DRAFT draft-zeilenga-ldap-grouping-06 3 May 2003
-
-
- draft-zeilenga-ldap-txn-xx.txt.
-
-
-Copyright 2003, The Internet Society. 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 AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga LDAP Grouping [Page 15]
-
diff --git a/doc/drafts/draft-zeilenga-ldap-managedit-xx.txt b/doc/drafts/draft-zeilenga-ldap-managedit-xx.txt
new file mode 100644
index 0000000000..f73f2a3ff4
--- /dev/null
+++ b/doc/drafts/draft-zeilenga-ldap-managedit-xx.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+INTERNET-DRAFT Kurt D. Zeilenga
+Intended Category: Experimental OpenLDAP Foundation
+Expires in six months 27 February 2006
+
+
+
+ The LDAP Manage Directory Information Tree Control
+ <draft-zeilenga-ldap-managedit-00.txt>
+
+
+Status of this Memo
+
+ This document is intended to be, after appropriate review and
+ revision, submitted to the RFC Editor for publication as an
+ Experimental document. Distribution of this memo is unlimited.
+ Technical discussion of this document will take place on the IETF LDAP
+ Extensions mailing list <ldapext@ietf.org>. Please send editorial
+ comments directly to the author <Kurt@OpenLDAP.org>.
+
+ By submitting this Internet-Draft, each author represents that any
+ applicable patent or other IPR claims of which he or she is aware have
+ been or will be disclosed, and any of which he or she becomes aware
+ will be disclosed, in accordance with Section 6 of BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering Task
+ Force (IETF), its areas, and its working groups. Note that other
+ groups may also distribute working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference material
+ or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/1id-abstracts.html
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html
+
+
+ Copyright (C) The Internet Society (2006). All Rights Reserved.
+
+ Please see the Full Copyright section near the end of this document
+ for more information.
+
+
+
+
+
+
+
+Zeilenga LDAP Manage DIT Control [Page 1]
+
+INTERNET-DRAFT draft-zeilenga-ldap-managedit-00 27 February 2006
+
+
+Abstract
+
+ This document defines the Lightweight Directory Access Protocol (LDAP)
+ Manage Directory Information Tree (DIT) Control which allows a
+ directory user agent (a client) to request the directory service
+ temporarily relax enforcement of constraints of the X.500 models.
+
+
+1. Background and Intended Use
+
+ Directory servers accessible via Lightweight Directory Access Protocol
+ (LDAP) [Roadmap] are expected to act in accordance with the X.500
+ series of ITU-T Recommendations. In particular, servers are expected
+ to ensure the X.500 data and service models are not violated.
+
+ An LDAP server is expected to prevent modification of the structural
+ object class of an object [Models]. That is, the X.500 models do not
+ allow a 'person' object to be transformed into an
+ 'organizationalPerson' object through modification of the object.
+ Instead, the 'person' object must be deleted and then a new
+ 'organizationalPerson' object created in its place. This approach,
+ aside from being inconvient, is problematic for a number reasons.
+ First, as LDAP does not have a standardized method for performing the
+ two operations in a single transaction, the intermediate directory
+ state (after the delete, before the add) is visible to other clients,
+ which may lead to undesirable client behavior. Second, attributes
+ such as entryUUID [entryUUID] will reflect the object was replaced,
+ not transformed.
+
+ An LDAP server is expected to prevent clients from modifying values of
+ NO-USER-MODIFICATION attributes [Models]. For instance, an entry is
+ not allowed to assign or modify the value of the entryUUID attribute.
+ However, where an administrator is restoring a previously existing
+ object, for instance when repartitioning data between directory
+ servers or when migrating from one vendor server product to another,
+ it may be desirable to allow the client to assign or modify the value
+ of the entryUUID attribute.
+
+ This document specifies the Manage Directory Information Tree (DIT)
+ control. The Manage DIT control may be attached to LDAP requests to
+ update the DIT to request DIT restrictions be temporarily relaxed
+ during the performance of the requested DIT update. The server is
+ however to ensure the resulting directory state is valid.
+
+ Use of this control is expected that use of this extension will be
+ restricted by administrative and/or access controls. It is intended
+ to be used by directory administrators.
+
+
+
+
+Zeilenga LDAP Manage DIT Control [Page 2]
+
+INTERNET-DRAFT draft-zeilenga-ldap-managedit-00 27 February 2006
+
+
+ This extension is considered experimental as it is not yet clear
+ whether it adequately addresses directory administrators' needs for
+ flexible mechanisms for managing directory objects. It is hoped that
+ after suitable amount of time, either this extension or a suitable
+ replacement will be standardization.
+
+
+1.1. Terminology
+
+ Protocol elements are described using ASN.1 [X.680] with implicit
+ tags. The term "BER-encoded" means the element is to be encoded using
+ the Basic Encoding Rules [X.690] under the restrictions detailed in
+ Section 5.2 of [Protocol].
+
+ 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 BCP 14 [RFC2119].
+
+ DSA stands for Directory System Agent, a server. DSE stands for DSA-
+ specific Entry.
+
+
+2. The Manage DIT Control
+
+ The Manage DIT control is an LDAP Control [Protocol] whose controlType
+ is IANA-ASSIGNED-OID, controlValue is empty, and the criticality of
+ TRUE.
+
+ There is no corresponding response control.
+
+ The control is appropriate for all LDAP update requests, including
+ add, delete, modify, and modifyDN (rename) [Protocol].
+
+ The presence of the Manage DIT control in an LDAP update request
+ indicates the server temporarily relax X.500 model contraints during
+ performance of the directory update.
+
+ The server may restrict use of this control and/or limit the extent of
+ the relaxation provided based upon local policy or factors.
+
+ The server is obligated to ensure the resulting directory state is
+ consistent with the X.500 models. For instance, the server ensure
+ that values of attributes conform to the value syntax.
+
+ It is noted that while this extension may be used to add or modify
+ objects in a manner which violate the controlling subschema, the
+ presence of objects in the DIT is not inconsistent with the X.500
+ models. For instance, an object created prior to establshment of a
+
+
+
+Zeilenga LDAP Manage DIT Control [Page 3]
+
+INTERNET-DRAFT draft-zeilenga-ldap-managedit-00 27 February 2006
+
+
+ DIT content rule may contain an attribute now precluded by the current
+ controlling DIT Content Rule.
+
+ Servers implementing this technical specification SHOULD publish the
+ object identifier IANA-ASSIGNED-OID as a value of the
+ 'supportedControl' attribute [Models] in their root DSE. A server MAY
+ choose to advertise this extension only when the client is authorized
+ to use it.
+
+
+3. Use Cases
+
+3.1. Object metamorphism
+
+ In absence of this control, an attempt to modify an object's
+ 'objectClass' in a manner which cause a change in the structural
+ object class of the object would normally lead to an
+ objectClassModsProhibited error [Protocol]. The presence of the
+ Manage DIT control in the modify request requests the change be
+ allowed. If the server is willing and able to allow the change in the
+ structural object class of the object.
+
+ For instance, to change an 'organization' object into an
+ 'organizationalUnit' object, a client could issue the following LDAP
+ request:
+
+ dn: o=Unit,dc=example,dc=net
+ control: IANA-ASSIGNED-OID
+ changetype: modify
+ delete: objectClass
+ objectClass: organization
+ -
+ add: objectClass
+ objectClass: organizationalUnit
+ -
+
+ In this case, the server is expected to either effect the requested
+ change in the structural object class, including updating of the value
+ of the structural object class, or fail the operation.
+
+
+3.2. Inactive Attribute Types
+
+ In absence of the Manage DIT control, an attempt to add or modify
+ values to an attribute whose type has been marked inactive in the
+ controlling subschema (its attribute type description contains the
+ OBSOLETE field) [Models] normally results in a failure.
+
+
+
+
+Zeilenga LDAP Manage DIT Control [Page 4]
+
+INTERNET-DRAFT draft-zeilenga-ldap-managedit-00 27 February 2006
+
+
+ In the presence of the Manage DIT control, the server performs the
+ update operation as if the attribute's type is marked active in the
+ controlling subschema (its attribute type description does not contain
+ the OBSOLETE field).
+
+
+3.3. DIT Content Rules
+
+ In absence of the Manage DIT control, an attempt to include the name
+ (or OID) of an auxiliary class to an object's 'objectClass' which is
+ not allowed by the controlling DIT Content Rule would be disallowed
+ [Models]. Additionally, an attempt to add values of an attribute not
+ allowed (or explicitly precluded) by the DIT Content Rule would fail.
+
+ In presence of the Manage DIT control, the server performs the update
+ operation as if the controlling DIT Content Rule allowed any and all
+ known auxiliary classses to be present and allowed any and all known
+ attributes to be present (and precluded no attributes).
+
+
+3.4. DIT Structure Rules and Name Forms
+
+ In absence of the Manage DIT control, the service enforces DIT
+ structure rules and name form requirements of the controlling
+ subschema [Models].
+
+ In the presence of the Manage DIT control, the server performs the
+ update operation ignoring all DIT structure rules and name forms in
+ the controlling subschema.
+
+
+3.5. Modification of Nonconformant Objects
+
+ It is also noted that in absense of this control, modification of an
+ object which presently violates the controlling subschema will fail
+ unless the modification would result in the object conforming to the
+ controlling subschema. That is, modifications of an non-conformant
+ object should result in a conformant object.
+
+ In the presence of this control, modifications of a non-conformant
+ object need not result in a conformant object.
+
+
+3.6. NO-USER-MODIFICATION attribute modification
+
+ In absence of this control, an attempt to modify values of a
+ NO-USER-MODIFICATION attribute would normally lead to a
+ constraintViolation or other appropriate error [Protocol]. In the
+
+
+
+Zeilenga LDAP Manage DIT Control [Page 5]
+
+INTERNET-DRAFT draft-zeilenga-ldap-managedit-00 27 February 2006
+
+
+ presence of the Manage DIT control in the update request requests the
+ modification be allowed.
+
+ Relaxation of the NO-USER-MODIFICATION constraint is not appropriate
+ for some operational attribute types. For instance, as the value of
+ the 'structuralObjectClass' is derived by the values of the
+ 'objectClass' attribute, the 'structuralObjectClass' attribute type's
+ NO-USER-MODIFICATION contraint MUST NOT be relaxed. To effect a
+ change in the structuralObjectClass class, values of objectClass
+ should be changed as discussed in Section 3.1. Other attributes for
+ which the NO-USER-MODIFICATION constraint should not be relaxed
+ include 'entryDN' [EntryDN], 'subschemaSubentry' [Models], and
+ 'collectiveAttributeSubentries' [RFC3671].
+
+ The subsections of this section discuss modification of various
+ operational attributes where their NO-USER-MODIFICATION constraint may
+ be relaxed. Future documents may specify where NO-USER-MODIFICATION
+ constraints on other operational attribute may be relaxed. In absence
+ of a document detailing that the NO-USER-MODIFICATION constraint on a
+ particular operational attribute may be relaxed, implementors SHOULD
+ assume relaxation of the constraint is not appropriate for that
+ attribute.
+
+
+3.1.1. entryUUID
+
+ To provide a value for the 'entryUUID' attribute on entry creation,
+ the client should issue an LDAP Add request with a Manage DIT control
+ providing the desired value. For instance:
+
+ dn: ou=Unit,dc=example,dc=net
+ control: IANA-ASSIGNED-OID
+ changetype: add
+ objectClass: organizationalUnit
+ ou: Unit
+ entryUUID: 597ae2f6-16a6-1027-98f4-d28b5365dc14
+
+ In this case, the server is either to add the entry using the
+ provided 'entryUUID' value or fail the request.
+
+ To provide a replacement value for the 'entryUUID' after entry
+ creation, the client should issue an LDAP Modify request with a
+ Manage DIT control including an approrpiate change. For instance:
+
+ dn: ou=Unit,dc=example,dc=net
+ control: IANA-ASSIGNED-OID
+ changetype: modify
+ replace: entryUUID
+
+
+
+Zeilenga LDAP Manage DIT Control [Page 6]
+
+INTERNET-DRAFT draft-zeilenga-ldap-managedit-00 27 February 2006
+
+
+ entryUUID: 597ae2f6-16a6-1027-98f4-d28b5365dc14
+ -
+
+ In this case, the server is either to replace the 'entryUUID' value
+ as requested or fail the request.
+
+
+3.2.2. createTimestamp
+
+ To provide a value for the 'createTimestamp' attribute on entry
+ creation, the client should issue an LDAP Add request with a Manage
+ DIT control providing the desired 'createTimestamp' value. For
+ instance:
+
+ dn: ou=Unit,dc=example,dc=net
+ control: IANA-ASSIGNED-OID
+ changetype: add
+ objectClass: organizationalUnit
+ ou: Unit
+ createTimestamp: 20060101000000Z
+
+ In this case, the server is either to add the entry using the
+ provided 'createTimestamp' value or fail the request.
+
+ To provide a replacement value for the 'createTimestamp' after
+ entry creation, the client should issue an LDAP Modify request with
+ a Manage DIT control including an approrpiate change. For instance:
+
+ dn: ou=Unit,dc=example,dc=net
+ control: IANA-ASSIGNED-OID
+ changetype: modify
+ replace: createTimestamp
+ createTimestamp: 20060101000000Z
+ -
+
+ In this case, the server is either to replace the 'createTimestamp'
+ value as requested or fail the request.
+
+ The server should ensure the requested 'createTimestamp' value is
+ appropriate. In particular, it should fail the request if the
+ requested 'createTimestamp' value is in the future or is greater
+ than the value of the 'modifyTimestamp' attribute.
+
+
+3.2.3. modifyTimestamp
+
+ To provide a value for the 'modifyTimestamp' attribute on entry
+ creation, the client should issue an LDAP Add request with a Manage
+
+
+
+Zeilenga LDAP Manage DIT Control [Page 7]
+
+INTERNET-DRAFT draft-zeilenga-ldap-managedit-00 27 February 2006
+
+
+ DIT control providing the desired 'modifyTimestamp' value. For
+ instance:
+
+ dn: ou=Unit,dc=example,dc=net
+ control: IANA-ASSIGNED-OID
+ changetype: add
+ objectClass: organizationalUnit
+ ou: Unit
+ modifyTimestamp: 20060101000000Z
+
+ In this case, the server is either to add the entry using
+ the provided 'modifyTimestamp' value or fail the request.
+
+ To provide a replacement value for the 'modifyTimestamp' after
+ entry creation, the client should issue an LDAP Modify
+ request with a Manage DIT control including an approrpiate
+ change. For instance:
+
+ dn: ou=Unit,dc=example,dc=net
+ control: IANA-ASSIGNED-OID
+ changetype: modify
+ replace: modifyTimestamp
+ modifyTimestamp: 20060101000000Z
+ -
+
+ In this case, the server is either to replace the 'modifyTimestamp'
+ value as requested or fail the request.
+
+ The server should ensure the requested 'modifyTimestamp' value is
+ appropriate. In particular, it should fail the request if the
+ requested 'modifyTimestamp' value is in the future or is less than
+ the value of the 'createTimestamp' attribute.
+
+
+ 3.2.3. creatorsName and modifiersName
+
+ To provide a value for the 'creatorsName' and/or 'modifiersName'
+ attribute on entry creation, the client should issue an LDAP Add
+ request with a Manage DIT control providing the desired values.
+ For instance:
+
+ dn: ou=Unit,dc=example,dc=net
+ control: IANA-ASSIGNED-OID
+ changetype: add
+ objectClass: organizationalUnit
+ ou: Unit
+ creatorsName: cn=Jane Doe,dc=example,net
+ modifiersName: cn=Jane Doe,dc=example,net
+
+
+
+Zeilenga LDAP Manage DIT Control [Page 8]
+
+INTERNET-DRAFT draft-zeilenga-ldap-managedit-00 27 February 2006
+
+
+ In this case, the server is either to add the entry using
+ the provided values or fail the request.
+
+ To provide a replacement values after entry creation for either of
+ the 'creatorsName' or 'modifiersName' attributes or both, the
+ client should issue an LDAP Modify request with a Manage DIT control
+ including the approrpiate changes. For instance:
+
+ dn: ou=Unit,dc=example,dc=net
+ control: IANA-ASSIGNED-OID
+ changetype: modify
+ replace: creatorsName
+ creatorsName: cn=Jane Doe,dc=example,net
+ -
+ replace: modifiersName
+ modifiersName: cn=Jane Doe,dc=example,net
+ -
+
+ In this case, the server is either to replace the provided
+ values as requested or fail the request.
+
+
+4. Security Considerations
+
+ Use of this extension should be subject to appropriate administrative
+ and access controls. Use of this mechanism is intended to be
+ restricted to directory administrators.
+
+ Security considerations for the base operations [Protocol] extended
+ by this control, as well as general LDAP security considerations
+ [Roadmap], generally apply to implementation and use of this
+ extension.
+
+
+5. IANA Considerations
+
+5.1. Object Identifier
+
+ It is requested that IANA assign a LDAP Object Identifier [BCP64bis]
+ to identify the LDAP Assertion Control defined in this document.
+
+ Subject: Request for LDAP Object Identifier Registration
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@OpenLDAP.org>
+ Specification: RFC XXXX
+ Author/Change Controller: Kurt Zeilenga <kurt@openldap.org>
+ Comments: Identifies the LDAP Manage DIT Control
+
+
+
+
+Zeilenga LDAP Manage DIT Control [Page 9]
+
+INTERNET-DRAFT draft-zeilenga-ldap-managedit-00 27 February 2006
+
+
+5.2 LDAP Protocol Mechanism
+
+ Registration of this protocol mechanism [BCP64bis] is requested.
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: IANA-ASSIGNED-OID
+ Description: Manage DIT Control
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@openldap.org>
+ Usage: Control
+ Specification: RFC XXXX
+ Author/Change Controller: Kurt Zeilenga <kurt@openldap.org>
+ Comments: none
+
+
+6. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ Email: Kurt@OpenLDAP.org
+
+
+7. References
+
+ [[Note to the RFC Editor: please replace the citation tags used in
+ referencing Internet-Drafts with tags of the form RFCnnnn where
+ possible.]]
+
+
+7.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+
+ [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
+ Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
+ progress.
+
+ [Models] Zeilenga, K. (editor), "LDAP: Directory Information
+ Models", draft-ietf-ldapbis-models-xx.txt, a work in
+ progress.
+
+
+
+7.2. Informative References
+
+ [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
+
+
+
+Zeilenga LDAP Manage DIT Control [Page 10]
+
+INTERNET-DRAFT draft-zeilenga-ldap-managedit-00 27 February 2006
+
+
+ draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
+
+ [EntryUUID] Zeilenga, K., "The LDAP EntryUUID Operational
+ Attribute", draft-zeilenga-ldap-uuid-xx.txt, a work in
+ progress.
+
+ [RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) -
+ Technical Specification", RFC 2849, June 2000.
+
+
+
+Intellectual Property Rights
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be found
+ in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this specification
+ can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+
+
+Full Copyright
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+
+
+
+Zeilenga LDAP Manage DIT Control [Page 11]
+
+INTERNET-DRAFT draft-zeilenga-ldap-managedit-00 27 February 2006
+
+
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga LDAP Manage DIT Control [Page 12]
+
diff --git a/doc/drafts/draft-zeilenga-ldap-noop-xx.txt b/doc/drafts/draft-zeilenga-ldap-noop-xx.txt
index c0a30b58be..100a845bb6 100644
--- a/doc/drafts/draft-zeilenga-ldap-noop-xx.txt
+++ b/doc/drafts/draft-zeilenga-ldap-noop-xx.txt
@@ -6,12 +6,12 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 28 October 2005
+Expires in six months 5 March 2006
The LDAP No-Op Control
- <draft-zeilenga-ldap-noop-07.txt>
+ <draft-zeilenga-ldap-noop-08.txt>
Status of this Memo
@@ -44,7 +44,7 @@ Status of this Memo
http://www.ietf.org/shadow.html
- Copyright (C) The Internet Society (2005). All Rights Reserved.
+ Copyright (C) The Internet Society (2006). All Rights Reserved.
Please see the Full Copyright section near the end of this document
for more information.
@@ -57,7 +57,7 @@ Status of this Memo
Zeilenga LDAP No-Op Control [Page 1]
-INTERNET-DRAFT draft-zeilenga-ldap-noop-07 28 October 2005
+INTERNET-DRAFT draft-zeilenga-ldap-noop-08 5 March 2006
Abstract
@@ -113,7 +113,7 @@ Abstract
Zeilenga LDAP No-Op Control [Page 2]
-INTERNET-DRAFT draft-zeilenga-ldap-noop-07 28 October 2005
+INTERNET-DRAFT draft-zeilenga-ldap-noop-08 5 March 2006
2. No-Op Control
@@ -169,7 +169,7 @@ INTERNET-DRAFT draft-zeilenga-ldap-noop-07 28 October 2005
Zeilenga LDAP No-Op Control [Page 3]
-INTERNET-DRAFT draft-zeilenga-ldap-noop-07 28 October 2005
+INTERNET-DRAFT draft-zeilenga-ldap-noop-08 5 March 2006
4. IANA Considerations
@@ -225,7 +225,7 @@ INTERNET-DRAFT draft-zeilenga-ldap-noop-07 28 October 2005
Zeilenga LDAP No-Op Control [Page 4]
-INTERNET-DRAFT draft-zeilenga-ldap-noop-07 28 October 2005
+INTERNET-DRAFT draft-zeilenga-ldap-noop-08 5 March 2006
Email: Kurt@OpenLDAP.org
@@ -281,7 +281,7 @@ Intellectual Property Rights
Zeilenga LDAP No-Op Control [Page 5]
-INTERNET-DRAFT draft-zeilenga-ldap-noop-07 28 October 2005
+INTERNET-DRAFT draft-zeilenga-ldap-noop-08 5 March 2006
Intellectual Property Rights or other rights that might be claimed to
@@ -309,7 +309,7 @@ INTERNET-DRAFT draft-zeilenga-ldap-noop-07 28 October 2005
Full Copyright
- Copyright (C) The Internet Society (2005).
+ Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
diff --git a/doc/drafts/draft-zeilenga-ldap-txn-xx.txt b/doc/drafts/draft-zeilenga-ldap-txn-xx.txt
index a9683c5d29..639ce0208b 100644
--- a/doc/drafts/draft-zeilenga-ldap-txn-xx.txt
+++ b/doc/drafts/draft-zeilenga-ldap-txn-xx.txt
@@ -5,179 +5,258 @@
INTERNET-DRAFT Kurt D. Zeilenga
-Intended Category: Experimental OpenLDAP Foundation
-Expires in six months 3 May 2003
+Intended Category: Standard Track OpenLDAP Foundation
+Expires in six months 5 March 2006
LDAP Transactions
- <draft-zeilenga-ldap-txn-06.txt>
+ <draft-zeilenga-ldap-txn-07.txt>
Status of Memo
- This document is an Internet-Draft and is in full conformance with all
- provisions of Section 10 of RFC2026.
-
This document is intended to be, after appropriate review and
- revision, submitted to the RFC Editor as an Experimental document.
- Distribution of this memo is unlimited. Technical discussion of this
- document will take place on the IETF LDAP Extension Working Group
- mailing list <ldapext@ietf.org>. Please send editorial comments
- directly to the author <Kurt@OpenLDAP.org>.
+ revision, submitted to the IESG for consideration as a Proposed
+ Standard. Distribution of this memo is unlimited. Technical
+ discussion of this document will take place on the IETF LDAP
+ Extensions mailing list <ldapext@ietf.org>. Please send editorial
+ comments directly to the author <Kurt@OpenLDAP.org>.
+
+ By submitting this Internet-Draft, each author represents that any
+ applicable patent or other IPR claims of which he or she is aware have
+ been or will be disclosed, and any of which he or she becomes aware
+ will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task
- Force (IETF), its areas, and its working groups. Note that other
+ 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.''
+ 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>.
+ http://www.ietf.org/1id-abstracts.html
- Copyright 2003, The Internet Society. All Rights Reserved.
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html
- Please see the Copyright section near the end of this document for
- more information.
+
+ Copyright (C) The Internet Society (2006). All Rights Reserved.
+
+ Please see the Full Copyright section near the end of this document
+ for more information.
Abstract
- Lightweight Directory Access Protocol (LDAP) update operations acting
- upon entries have atomic, consistency, isolation, durability (ACID)
- properties. However, it is often desirable to update two or more
- entries as one unit of interaction, a transaction. Transactions are
- necessary to support a number of applications including resource
- provisioning and information replication. This document defines an
+ Lightweight Directory Access Protocol (LDAP) update operations, such
Zeilenga LDAP Transactions [Page 1]
-INTERNET-DRAFT draft-zeilenga-ldap-txn-06 3 May 2003
-
+INTERNET-DRAFT draft-zeilenga-ldap-txn-07 5 March 2006
- LDAP extension to support transactions.
-
-
-Conventions
-
- 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 BCP 14 [RFC2119].
- Protocol elements are described using ASN.1 [X.680]. The term
- "BER-encoded" means the element is to be encoded using the Basic
- Encoding Rules [X.690] under the restrictions detailed in Section 5.1
- of [RFC2251].
+ as Add, Delete, and Modify operations, have atomic, consistency,
+ isolation, durability (ACID) properties. Each of these update
+ operations act upon an entry. However, It is often desirable to
+ update two or more entries in a single unit of interaction, a
+ transaction. Transactions are necessary to support a number of
+ applications including resource provisioning and information
+ replication. This document defines an LDAP extension to support
+ transactions.
1. Overview
This document extends the Lightweight Directory Access Protocol (LDAP)
- [RFC3377] to allow clients to group a number of related update
- operations [RFC2251] and have them preformed as one unit of
+ [Roadmap] to allow clients to group a number of related update
+ operations [Protocol] and have them preformed as one unit of
interaction, a transaction. As with distinct update operations, each
transaction has atomic, consistency, isolation, and durability
([ACID]) properties.
- This extension uses the grouping mechanism provided by [GROUP] to
- relate operations of the transaction. The createGrouping operation is
- used to obtain a group cookie which is used to identify operations
- which are apart of the transaction. The group cookie can be viewed as
- a transaction identifier. The endGrouping operation is used to settle
- (commit or abort) the transaction.
+ This extension consists of two extended operations, one control, and
+ one unsolicited notification message. The Start Transaction operation
+ is used to obtain a transaction identifier. This identifier is then
+ attached to multiple update operations to indicate that they belong to
+ transaction using the Transaction Specification control. The End
+ Transaction is used to settle (commit or abort) the transaction. The
+ Aborted Tranaction Notice is used notify the client the server is no
+ longer willing or able to process an outstanding transaction.
-2. Specification of a Transaction
+1.1. Conventions and Terminology
+
+ 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 BCP 14 [RFC2119].
+
+ Protocol elements are described using ASN.1 [X.680] with implicit
+ tags. The term "BER-encoded" means the element is to be encoded using
+ the Basic Encoding Rules [X.690] under the restrictions detailed in
+ Section 5.2 of [Protocol].
+
+ DSA stands for "Directory System Agent" (a server). DSE stands for
+ "DSA-specific entry".
- Servers implementing this specification SHOULD publish the
- transactionGroupingType as a value of the 'supportedGroupingTypes'
- attribute contained within the Root DSE.
- transactionGroupingType ::= IANA-ASSIGNED-OID
+2. Elements of an LDAP Transaction
+
+2.1. Start Transaction Request and Response
- A client wishing to preform a transaction issues a
- createGroupingRequest with a createGroupType of
- transactionGroupingType and no createGroupValue. A server which is
- willing and able to support transactions returns a
- createGroupingResponse with a success result code, a
- createGroupCookie, and no createGroupValue. Otherwise the server
- returns a non-success result code, no createGroupCookie, and no
- createGroupValue.
Zeilenga LDAP Transactions [Page 2]
-INTERNET-DRAFT draft-zeilenga-ldap-txn-06 3 May 2003
+INTERNET-DRAFT draft-zeilenga-ldap-txn-07 5 March 2006
- The client then issues may issue one or more update (add, delete,
- modify, rename) requests, each with a GroupingControl indicating they
- are to processed as part of the transaction grouping. If the server
- is willing and able to attempt to process operation as part of the
- transaction, the server returns success. As further processing of the
- operation is be deferred until settlement, the operation is considered
- still outstanding and its messageID cannot to be reused until after
- settlement. If the server is unwilling or unable to attempt to
- process the operation as part of the transaction, the server returns a
- non-successful result code.
+ A Start Transaction Request is an LDAPMessage of CHOICE extendedReq
+ where the requestName is IANA-ASSIGNED-OID.1 and the requestValue is
+ absent.
- If the server becomes unwilling or unable to continue the
- specification of a transaction, the server return the canceled
- resultCode for each deferred operation and then issue a endGroupNotice
- with a non-success resultCode. Any future use of cookie by the client
- will result in a response containing a non-success result code. Upon
- receipt of a endGroupingNotice, the client is to discontinue all use
- of the grouping cookie as the transaction is null and void.
+ A Start Transaction Response is an LDAPMessage of CHOICE extendedRes
+ sent in response to a Start Transaction Request. Its responesName is
+ absent. When the resultCode is success, responseValue is present and
+ contains a transaction identifier. Otherwise, the responseValue is
+ absent.
- A client requests settling of transaction by issuing an
- endGroupingRequest where the groupingCookie is the group cookie
- identify the transaction. The absence of any endGroupingValue
- indicates a commit request. The presence of an empty endGroupValue
- indicates an abort request. The endGroupValue MUST be empty if
- provided.
- If the commit response indicates failure, the server may return an
- endGroupingValue with the endGroupingResponse. If so, it contains the
- BER-encoding of a MessageID [RFC2251] of the update operation
- associated with the failure.
+2.2. Transaction Specification Control
+ A Transaction Specification Control is an LDAPControl where the
+ controlType is IANA-ASSIGNED-OID.2, the criticality is TRUE, and the
+ controlValue is a transaction identifer. The control is appropriate
+ for update requests including Add, Delete, Modify, and ModifyDN
+ requests [Protocol].
-3. Settling of the Transaction
+2.3. End Transactions Request and Response
- Upon receipt of a request to abort the transaction, the server is to
- abort the transaction and then return an endGroupingResponse
- indicating success.
+ An End Transaction Request is an LDAPMessage of CHOICE extendedReq
+ where the requestName is IANA-ASSIGNED-OID.3 and the requestValue is
+ present and contains a BER-encoded settlementValue.
- Upon receipt of a request to commit the transaction, the server
- processes the group of update operations as one atomic, isolated
- action with each update request being processed in turn. Either all
- of the requested updates SHALL be successfully applied or none of the
- requested SHALL be applied. If all are applied, the server returns an
- endGroupingResponse indicating success. Otherwise, the server returns
- an endGroupingResponse indicating the nature of the failure. If the
- failure is associated with a particular update operation, the message
- ID is returned an attached endGroupingValue. If the failure was not
- associated with any particular update operation, no endGroupingValue
+ settlementValue ::= SEQUENCE {
+ commit BOOLEAN DEFAULT TRUE,
+ identifier OCTET STRING }
+
+ A commit value of TRUE indicates a request to commit the transaction
+ identified by the identifier. A commit value of FALSE indicates a
+ request to abort the identified transaction.
+
+ An End Transaction Response is an LDAPMessage sent in response to a
+ End Transaction Request. Its response name is absent. The
+ responseValue when present contains a BER-encoded MessageID.
+
+
+2.5. Aborted Transaction Notice
+
+ The Aborted Transaction Notice is an Unsolicited Notification message
+ where the responseName is IANA-ASSIGNED-OID.4 and responseValue is
+ present and contains a transaction identifier.
+
+
+3. An LDAP Transaction
+
+3.1. Extension Discovery
Zeilenga LDAP Transactions [Page 3]
-INTERNET-DRAFT draft-zeilenga-ldap-txn-06 3 May 2003
+INTERNET-DRAFT draft-zeilenga-ldap-txn-07 5 March 2006
+
+
+ To allow clients to discover support for this extension, servers
+ implementing this specification SHOULD publish IANA-ASSIGNED-OID.1 and
+ IANA-ASSIGNED-OID.3 as values of the 'supportedExtension' attribute
+ [Models] within the Root DSE, and publish the IANA-ASSIGNED-OID.2 as a
+ value of the 'supportedControl' attribute [Models] of the Root DSE.
+
+ A server MAY choose to advertise this extension only when the client
+ is authorized to use it.
+
+
+3.2. Starting an Transactions
+ A client wishing to preform a sequence of directory updates as an
+ transaction issues a Start Transaction Request. A server which is
+ willing and able to support transactions responds to this request with
+ a Start Transaction Response providing a transaction identifier and
+ with a resultCode of success. Otherwise, the server responds with a
+ Start Transaction Response wth a result code other than success
+ indicating the nature of the failure.
+
+ The transaction identifier provided upon successful start of a
+ transaction is used in subseqent protocol messages to identify this
+ transaction.
+
+
+3.3. Specification of a Transaction
+
+ The client then may issue may issue one or more update (add, delete,
+ modify, modifyDN) requests, each with a Transaction Specification
+ control containing the transaction identifier indicating the updates
+ are to processed as part of the transaction. Each of these update
+ request MUST have a different MessageId value. If the server is
+ unwilling or unable to attempt to process the requested update
+ operation as part of the transaction, the server immediately returns
+ the approrpiate response to the request with a resultCode indicating
+ the nature of the failure. Otherwise, the server immediately returns
+ success and the defers further processing of the operation is then
+ deferred until settlement.
+
+ If the server becomes unwilling or unable to continue the
+ specification of a transaction, the server issues an Aborted
+ Transaction Notice with a non-success resultCode indicating the nature
+ of the failure. All operations that were to be processed as part of
+ the transaction are implicitly abandoned. Upon receipt of an Aborted
+ Transaction Notice, the client is to discontinue all use of the
+ transaction identifier as the transaction is null and void. Any
+ future use of identifier by the client will result in a response
+ containing a non-success resultCode.
+
+
+
+Zeilenga LDAP Transactions [Page 4]
+
+INTERNET-DRAFT draft-zeilenga-ldap-txn-07 5 March 2006
- is to be provided.
- There is no requirement that a server serialize transactions. That
- is, a server MAY process multiple transactions commit requests (from
- one or more clients) acting upon different sets of entries
- concurrently. A server MUST avoid deadlock.
+3.4. Transaction Settlement
+
+ A client requests settlement of transaction by issuing an End
+ Transaction request for the transaction indicating whether it desires
+ the transaction to be committed or aborted.
+
+ Upon receipt of a request to abort the transaction, the server is to
+ abort the identified transaction (abandoning all operations which are
+ part of the transaction) and indicate that it has done so by returning
+ an End Transaction response with a resultCode of success.
+
+ Upon receipt of a request to commit the transaction, the server
+ processes all update operations of the transaction as one atomic,
+ isolated action with each requested update being processed in turn.
+ Either all of the requested updates are to be successfully applied or
+ none of the requested are to be applied. The server returns an End
+ Transaction Response with a resultCode of success and no responseValue
+ to indicate all the requested updates were applied. Otherwise, the
+ server returns an End Transaction with an non-success resultCode
+ indicating the nature of the failure. If the failure is associated
+ with a particular update request, a responseValue containing its
+ MessageID is returned. If the failure was not associated with any
+ particular update request, no responseValue is returned.
+
+ There is no requirement that a server serialize transactions, or
+ updates requested outside of a transaction. That is, a server MAY
+ process multiple commit requests (from one or more clients) acting
+ upon different sets of entries concurrently. A server MUST avoid
+ deadlock.
4. Distributed Directory Considerations
@@ -185,23 +264,30 @@ INTERNET-DRAFT draft-zeilenga-ldap-txn-06 3 May 2003
The LDAP/X.500 models provide for distributed directory operations
including server-side chaining and client-side chasing of operations.
- This document does not disallow servers from chaining operations which
+ This document does not preclude servers from chaining operations which
are part of a transaction. However, if a server does allow such
- chaining, it MUST ensure that transaction semantics detailed above are
- provided.
+ chaining, it MUST ensure that transaction semantics are provided.
This mechanism defined by this document does not support client-side
chasing. Grouping cookies used to identify the transaction are
specific to a particular client/server session.
- The LDAP/X.500 models provide for a single-master/multiple-slave
+ The LDAP/X.500 models provide for a single-master/multiple-shadow
replication architecture. This document states no requirement that
changes made to the directory based upon processing a transaction be
replicated as one atomic action. That is, the client SHOULD NOT
- assume tight data consistency nor fast data convergence at slave
- servers unless they have prior knowledge that such is provided.
- Though this mechanism could be used to support replication, such use
- is not described in this document.
+
+
+
+Zeilenga LDAP Transactions [Page 5]
+
+INTERNET-DRAFT draft-zeilenga-ldap-txn-07 5 March 2006
+
+
+ assume tight data consistency nor fast data convergence at shadow
+ servers unless they have prior knowledge that such service is
+ provided. Though this mechanism could be used to support replication,
+ use in replication is not described in this document.
The LDAP/X.500 models do not currently support a multi-master
replication architecture and, hence, not considered by this
@@ -210,159 +296,185 @@ INTERNET-DRAFT draft-zeilenga-ldap-txn-06 3 May 2003
5. Security Considerations
- Transactions mechanisms and related grouping operations may be the
- target of denial of service attacks. Implementors should provide
- safeguards to ensure these mechanisms are not abused.
+ Transactions mechanisms may be the target of denial of service
+ attacks. Implementors should provide safeguards to ensure these
+ mechanisms are not abused.
+
+ General security considerations [Roadmap], especially associated with
+ update operations [Protocol], apply to this extension.
6. IANA Considerations
- In accordance with [RFC3383], it is requested that Internet Assigned
+ In accordance with [BCP64bis], it is requested that Internet Assigned
Numbers Authority (IANA) make the following assignments.
-
-
-Zeilenga LDAP Transactions [Page 4]
-
-INTERNET-DRAFT draft-zeilenga-ldap-txn-06 3 May 2003
-
-
6.1. Object Identifier
- An LDAP Object Identifier to identify the grouping type defined in
- this document is requested.
-
- The following registration template is suggested:
+ Assignment of an LDAP Object Identifier to identify the protocol
+ elements specified in this document this document is requested.
Subject: Request for LDAP Object Identifier Registration
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
- Specification: RFCXXXX
+ Specification: RFC XXXX
Author/Change Controller: IESG
- Comments:
- Identifies the LDAP Transactions Grouping Type
+ Comments: Identifies protocol elements for LDAP Transactions
6.2. LDAP Protocol Mechanism
- Registration of the protocol mechanisms defined in this document is
+ Registration of the protocol mechanisms specified in this document is
requested.
- Subject: Request for LDAP Protocol Mechansism Registration
-
- Object Identifier: IANA-ASSIGNED-OID
- Description: LDAP Transaction Grouping Type
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: see table
+ Description: see table
Person & email address to contact for further information:
- Kurt Zeilenga <kurt@openldap.org>
- Usage: Grouping
- Specification: RFCxxxx
- Author/Change Controller: IESG
- Comments: none
-7. Acknowledgments
- The author gratefully acknowledges the contributions made by members
- of the Internet Engineering Task Force.
+Zeilenga LDAP Transactions [Page 6]
+
+INTERNET-DRAFT draft-zeilenga-ldap-txn-07 5 March 2006
-8. Author's Address
+ Kurt Zeilenga <kurt@openldap.org>
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+ Comments:
- Kurt D. Zeilenga
- OpenLDAP Foundation
- <Kurt@OpenLDAP.org>
+ Object Identifier Type Description
+ ------------------- ---- -----------------------------------------
+ IANA-ASSIGNED-OID.1 E Start Transaction Extended Request
+ IANA-ASSIGNED-OID.2 C Transaction Specification Control
+ IANA-ASSIGNED-OID.3 E End Transaction Extended Request
-9. Normative References
+7. Acknowledgments
+ The author gratefully acknowledges the contributions made by members
+ of the Internet Engineering Task Force.
+8. Author's Address
-Zeilenga LDAP Transactions [Page 5]
-
-INTERNET-DRAFT draft-zeilenga-ldap-txn-06 3 May 2003
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+ Email: Kurt@OpenLDAP.org
- [RFC2119] S. Bradner, "Key Words for use in RFCs to Indicate
- Requirement Levels", BCP 14 (also RFC 2119), March 1997.
- [RFC2251] M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access
- Protocol (v3)", RFC 2251, December 1997.
+9. References
- [RFC3377] J. Hodges, R. Morgan, "Lightweight Directory Access
- Protocol (v3): Technical Specification", RFC 3377, September 2002.
+ [[Note to the RFC Editor: please replace the citation tags used in
+ referencing Internet-Drafts with tags of the form RFCnnnn where
+ possible.]]
- [GROUP] K. Zeilenga, "LDAP: Grouping of Related Operations",
- draft-zeilenga-ldap-grouping-xx.txt, a work in progress.
- [X.680] ITU-T, "Abstract Syntax Notation One (ASN.1) - Specification
- of Basic Notation", X.680, 1994.
+9.1. Normative References
- [X.690] ITU-T, "Specification of ASN.1 encoding rules: Basic,
- Canonical, and Distinguished Encoding Rules", X.690, 1994.
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+ [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
+ Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
+ progress.
-10. Informative References
+ [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
+ draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
- [ACID] Section 4 of ISO/IEC 10026-1:1992.
+ [Models] Zeilenga, K. (editor), "LDAP: Directory Information
+ Models", draft-ietf-ldapbis-models-xx.txt, a work in
+ progress.
- [RFC3383] K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also
- RFC 3383), September 2002.
- [X.500] ITU-T, "The Directory: Overview of Concepts, Models, and
- Services", X.500, 1993.
- [X.501] ITU-T, "The Directory: Models", X.501, 1993.
+Zeilenga LDAP Transactions [Page 7]
+
+INTERNET-DRAFT draft-zeilenga-ldap-txn-07 5 March 2006
-Copyright 2003, The Internet Society. All Rights Reserved.
+ [X.680] International Telecommunication Union -
+ Telecommunication Standardization Sector, "Abstract
+ Syntax Notation One (ASN.1) - Specification of Basic
+ Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
- 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.
+ [X.690] International Telecommunication Union -
+ Telecommunication Standardization Sector, "Specification
+ of ASN.1 encoding rules: Basic Encoding Rules (BER),
+ Canonical Encoding Rules (CER), and Distinguished
+ Encoding Rules (DER)", X.690(2002) (also ISO/IEC
+ 8825-1:2002).
- The limited permissions granted above are perpetual and will not
+9.2. Informative References
+ [ACID] Section 4 of ISO/IEC 10026-1:1992.
-Zeilenga LDAP Transactions [Page 6]
-
-INTERNET-DRAFT draft-zeilenga-ldap-txn-06 3 May 2003
+ [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
+ draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
+ [X.500] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The Directory
+ -- Overview of concepts, models and services,"
+ X.500(1993) (also ISO/IEC 9594-1:1994).
- be revoked by the Internet Society or its successors or assigns.
+ [X.501] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The Directory
+ -- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
- This document and the information contained herein is provided on
- an "AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE
- INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS
- OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
- OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+Intellectual Property Rights
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be found
+ in BCP 78 and BCP 79.
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this specification
+ can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+Zeilenga LDAP Transactions [Page 8]
+
+INTERNET-DRAFT draft-zeilenga-ldap-txn-07 5 March 2006
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+Full Copyright
+ Copyright (C) The Internet Society (2006).
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
@@ -391,5 +503,5 @@ INTERNET-DRAFT draft-zeilenga-ldap-txn-06 3 May 2003
-Zeilenga LDAP Transactions [Page 7]
+Zeilenga LDAP Transactions [Page 9]
diff --git a/doc/rfc/INDEX b/doc/rfc/INDEX
index 4929ee1903..8c1aecd8d2 100644
--- a/doc/rfc/INDEX
+++ b/doc/rfc/INDEX
@@ -51,6 +51,7 @@ rfc3928.txt LDAP Client Update Protocol (PS)
rfc4013.txt SASLprep (PS)
rfc4370.txt LDAP Proxied Authorization Control (PS)
rfc4373.txt LBURP (I)
+rfc4404.txt LDAP Schema for UDDI (I)
Legend:
STD Standard
diff --git a/doc/rfc/rfc4403.txt b/doc/rfc/rfc4403.txt
new file mode 100644
index 0000000000..bcf5bfe58a
--- /dev/null
+++ b/doc/rfc/rfc4403.txt
@@ -0,0 +1,2355 @@
+
+
+
+
+
+
+Network Working Group B. Bergeson
+Request for Comments: 4403 K. Boogert
+Category: Informational Novell, Inc.
+ V. Nanjundaswamy
+ Oracle India Pvt. Ltd.
+ February 2006
+
+
+ Lightweight Directory Access Protocol (LDAP) Schema for
+ Universal Description, Discovery, and Integration version 3 (UDDIv3)
+
+Status of This Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ This document defines the Lightweight Directory Access Protocol
+ (LDAPv3) schema for representing Universal Description, Discovery,
+ and Integration (UDDI) data types in an LDAP directory. It defines
+ the LDAP object class and attribute definitions and containment rules
+ to model UDDI entities, defined in the UDDI version 3 information
+ model, in an LDAPv3-compliant directory.
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 2. Conventions Used in This Document ...............................2
+ 3. Representation of UDDI Data Structures ..........................2
+ 4. Attribute Type Definitions ......................................6
+ 5. Object Class Definitions .......................................28
+ 6. Name Forms .....................................................32
+ 7. DIT Structure Rules ............................................35
+ 8. Security Considerations ........................................37
+ 9. IANA Considerations ............................................37
+ 10. Normative References ..........................................40
+
+
+
+
+
+
+
+
+
+Bergeson, et al. Informational [Page 1]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+1. Introduction
+
+ This document defines the Lightweight Directory Access Protocol
+ [LDAPv3] schema elements to represent the core data structures
+ identified in the Universal Description, Discovery, and Integration
+ version 3 [UDDIv3] information model. This includes a
+ businessEntity, a businessService, a bindingTemplate, a tModel, a
+ publisherAssertion, and a Subscription. Portions of [UDDIv3] are
+ repeated here for clarity.
+
+2. Conventions Used in This Document
+
+ The keywords "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].
+
+ All schema definitions are provided using [RFC2252] descriptions, and
+ are line-wrapped for readability only.
+
+3. Representation of UDDI Data Structures
+
+ The information that makes up a registration in a UDDI registry
+ consists of these data structure types. This division by information
+ type provides simple partitions to assist in the rapid location and
+ understanding of the different information that makes up a
+ registration.
+
+ The individual instance data managed by a UDDI registry is sensitive
+ to the parent/child relationships found in the schema. A
+ businessEntity object contains one or more unique businessService
+ objects. Similarly, individual businessService objects contain
+ specific instances of bindingTemplate, which in turn contains
+ information that includes pointers to specific instances of tModel
+ objects.
+
+ It is important to note that no single instance of a core schema type
+ is ever "contained" by more than one parent instance. This means
+ that only one specific businessEntity object (identified by its
+ unique key value) will ever contain or be used to express information
+ about a specific instance of a businessService object (also
+ identified by its own unique key value).
+
+3.1. businessEntity
+
+ The businessEntity object represents all known information about a
+ business or entity that publishes descriptive information about the
+ entity as well as the services that it offers. The businessEntity is
+ the top-level container that accommodates holding descriptive
+
+
+
+Bergeson, et al. Informational [Page 2]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+ information about a business or entity. Service descriptions and
+ technical information are expressed within a businessEntity by a
+ containment relationship.
+
+3.1.1. Representation in the Directory
+
+ A businessEntity is represented in the directory by the attributes
+ uddiBusinessKey, uddiAuthorizedName, uddiOperator, uddiDiscoveryURLs,
+ uddiName, uddiDescription, uddiIdentifierBag, uddiCategoryBag, and
+ uddiv3DigitalSignature, along with corresponding v3 keys viz.
+ uddiv3BusinessKey, as defined in Section 4. A businessEntity may
+ contain zero or more instances of uddiContact and
+ uddiBusinessService.
+
+ A mandatory attribute, uddiBusinessKey, contains the unique
+ identifier for a given instance of a businessEntity.
+
+ businessEntity's definition is given in Section 5.
+
+3.2. businessService
+
+ The businessService instances represent a logical business service.
+ Each businessService object is the logical child of a single
+ businessEntity object. Each businessService element contains
+ descriptive information in business terms outlining the type of
+ technical services found within each businessService instance.
+
+ In some cases, businesses would like to share or reuse services,
+ e.g., when a large enterprise publishes separate businessEntity
+ structures. This can be established by using the businessService
+ instance as a projection to an already published businessService.
+
+3.2.1. Representation in the Directory
+
+ A businessService is represented in the directory by the attributes
+ uddiBusinessKey, uddiServiceKey, uddiName, uddiDescription,
+ uddiCategoryBag, uddiIsProjection, and uddiv3DigitalSignature, along
+ with corresponding v3 keys viz. uddiv3BusinessKey, and
+ uddiv3ServiceKey, as defined in Section 4. A businessService may
+ contain zero or more instances of uddiBindingTemplate.
+
+ The mandatory attribute, uddiServiceKey, contains the unique
+ identifier for a given instance of a businessService.
+
+ businessService's definition is given in Section 5.
+
+
+
+
+
+
+Bergeson, et al. Informational [Page 3]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+3.3. bindingTemplate
+
+ Technical descriptions of Web services are accommodated via
+ individual contained instances of bindingTemplate objects. These
+ instances provide support for determining a technical entry point or
+ optionally support remotely hosted services, as well as a lightweight
+ facility for describing unique technical characteristics of a given
+ implementation. Support for technology and application specific
+ parameters and settings files are also supported.
+
+ Since UDDI's main purpose is to enable description and discovery of
+ Web service information, it is the bindingTemplate that provides the
+ most interesting technical data. With UDDIv3, bindingTemplates also
+ can have categorization information.
+
+ Each bindingTemplate instance has a single logical businessService
+ parent, which in turn has a single logical businessEntity parent.
+
+3.3.1. Representation in the Directory
+
+ A bindingTemplate is represented in the directory by the attributes
+ uddiBindingKey, uddiServiceKey, uddiDescription, uddiAccessPoint,
+ uddiHostingRedirector, uddiCategoryBag, and uddiv3DigitalSignature,
+ along with corresponding v3 keys viz. uddiv3ServiceKey and
+ uddiv3BindingKey, as defined in Section 4. A bindingTemplate may
+ contain zero or more instances of uddiTModelInstanceDetails.
+
+ The mandatory attribute, uddiBindingKey, contains the unique
+ identifier for a given instance of a bindingTemplate.
+
+ BindingTemplate's definition is given in Section 5.
+
+3.4. tModel
+
+ The tModel object takes the form of keyed metadata (data about data).
+ In a general sense, the purpose of a tModel within the UDDI registry
+ is to provide a reference system based on abstraction. Thus, the
+ kind of data that a tModel represents is pretty nebulous. In other
+ words, a tModel registration can define just about anything, but in
+ the current revision, two conventions have been applied for using
+ tModels: as sources for determining compatibility and as keyed
+ namespace references.
+
+ The information that makes up a tModel is quite simple. There are a
+ key, a name, an optional description, and a Uniform Resource Locator
+ [URL] that points somewhere--presumably somewhere where the curious
+ can go to find out more about the actual concept represented by the
+ metadata in the tModel itself.
+
+
+
+Bergeson, et al. Informational [Page 4]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+3.4.1. Representation in the Directory
+
+ A tModel is represented in the directory by the attributes
+ uddiTModelKey, uddiAuthorizedName, uddiOperator, uddiName,
+ uddiDescription, uddiOverviewDescription, uddiOverviewURL,
+ uddiIdentifierBag, uddiCategoryBag, uddiIsHidden, and
+ uddiv3DigitalSignature, along with the corresponding v3 key viz.
+ uddiv3tModelKey, as defined in Section 4. A tModel may also contain
+ a uddiHidden to logically delete a tModel.
+
+ A mandatory attribute, uddiTModelKey, contains the unique identifier
+ for a given instance of a tModel.
+
+ tModel's definition is given in Section 5.
+
+3.5. publisherAssertion
+
+ Many businesses, such as large enterprises or marketplaces, are not
+ effectively represented by a single businessEntity, since their
+ description and discovery are likely to be diverse. As a
+ consequence, several businessEntity instances can be published,
+ representing individual subsidiaries of a large enterprise or
+ individual participants of a marketplace. Nevertheless, they still
+ represent a more or less coupled community and would like to make
+ some of their relationships visible in their UDDI registrations.
+
+3.5.1. Representation in the Directory
+
+ A publisherAssertion is represented in the directory by the
+ attributes uddiFromKey, uddiToKey, uddiKeyedReference, and uddiUUID,
+ and uddiv3DigitalSignature, as defined in Section 5.
+
+ A mandatory attribute, uddiUUID, contains the unique identifier for a
+ given instance of a publisherAssertion.
+
+ publisherAssertion's definition is given in Section 5.
+
+3.6. Operational Information:
+
+ With UDDIv3, the operational information associated with the core
+ UDDI data structures is maintained in a separate OperationalInfo
+ structure, so that the digital signature specified by the publisher
+ remains valid.
+
+ The operationalInfo structure is used to convey the operational
+ information for the UDDIv3 core data structures, that is, the
+ businessEntity, businessService, bindingTemplate, and tModel
+
+
+
+
+Bergeson, et al. Informational [Page 5]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+ structures. UDDIv3 OperationalInfo consists of 5 elements: created,
+ Modified, modifiedIncludingChildren, nodeId, and authorizedName.
+
+ Depending on the specific UDDIv3 core data structure, the
+ operationalInformation is represented in the directory as a
+ combination of implicit LDAP Standard Operational attributes:
+ createTimestamp and modifyTimestamp, and the following explicit
+ attributes: uddiAuthorizedName, uddiv3EntityCreationTime,
+ uddiv3EntityModificationTime, and uddiv3NodeId.
+
+4. Attribute Type Definitions
+
+ The OIDs for the attribute types in this document have been
+ registered by the IANA.
+
+4.1. uddiBusinessKey
+
+ This is used in uddiBusinessEntity and uddiBusinessService.
+
+ The uddiBusinessKey is the unique identifier for a given instance of
+ a uddiBusinessEntity. The attribute is optional for businessService
+ instances contained within a fully expressed parent that already
+ contains a businessKey value.
+
+ If the businessService instance is rendered into the Extensible
+ Markup Language [XML] and has no containing parent that has within
+ its data a businessKey, the value of the businessKey that is the
+ parent of the businessService is required to be provided. This
+ behavior supports the ability to browse through the parent-child
+ relationships given any of the core elements as a starting point.
+ The businessKey may differ from the publishing businessEntity's
+ businessKey to allow service projections.
+
+ ( 1.3.6.1.1.10.4.1 NAME 'uddiBusinessKey'
+ DESC 'businessEntity unique identifier'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+4.2. uddiAuthorizedName
+
+ The uddiAuthorizedName is the recorded name of the individual who
+ published the uddiBusinessEntity or uddiTModel data. This data is
+ generated by the controlling operator and should not be supplied
+ within save_business operations.
+
+ With UDDIv3, this attribute is part of the "operationalInformation"
+
+
+
+Bergeson, et al. Informational [Page 6]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+ metadata associated with core data structures.
+
+ ( 1.3.6.1.1.10.4.2 NAME 'uddiAuthorizedName'
+ DESC 'businessEntity publisher name'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ SINGLE-VALUE
+ )
+
+4.3. uddiOperator
+
+ The uddiOperator is the certified name of the UDDI registry site
+ operator that manages the master copy of the uddiBusinessEntity or
+ uddiTModel. The controlling operator records this data at the time
+ data is saved. This data is generated and should not be supplied
+ within save_business or save_tModel operations.
+
+ With UDDIv3, this field is no longer used -- it is replaced by the
+ nodeId (uddiv3NodeId) attribute that is part of the
+ "operationalInformation" metadata.
+
+ ( 1.3.6.1.1.10.4.3 NAME 'uddiOperator'
+ DESC 'registry site operator of businessEntitys master copy'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+4.4. uddiName
+
+ This is used in uddiBusinessEntity, uddiBusinessService, and
+ uddiTModel.
+
+ These are the human-readable names recorded for the
+ uddiBusinessEntity, uddiBusinessService, or uddiTModel, adorned with
+ a unique xml:lang value to signify the language that they are
+ expressed in. Name search is provided via find_business,
+ find_service, or find_tModel calls.
+
+ The publishing of several names, e.g., for romanization purposes, is
+ supported. In order to signify the language that the names are
+ expressed in, they carry unique xml:lang values. Not more than one
+ name element may omit specifying its language. Names passed in this
+ way will be assigned the default language code of the registering
+ party. This default language code is established at the time that
+ publishing credentials are established with an individual Operator
+
+
+
+
+
+Bergeson, et al. Informational [Page 7]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+ Site. If no default language is provisioned at the time a publisher
+ signs up, the operator can adopt an appropriate default language
+ code.
+
+ With UDDIv3, multiple values with the same language code are
+ permitted.
+
+ ( 1.3.6.1.1.10.4.4 NAME 'uddiName'
+ DESC 'human readable name'
+ EQUALITY caseIgnoreMatch
+ ORDERING caseIgnoreOrderingMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ )
+
+ The xml:lang value precedes the name value, with the "#" character
+ used as the separator.
+
+4.5. uddiDescription
+
+ The uddiDescription is an optional repeating element of one or more
+ descriptions. One description is allowed per national language code
+ supplied. With UDDIv3, there is no restriction on the number of
+ descriptions or on what xml:lang value that they may have.
+
+ ( 1.3.6.1.1.10.4.5 NAME 'uddiDescription'
+ DESC 'short description'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ )
+
+ The xml:lang value precedes the name value, with the "#" character
+ used as the separator.
+
+4.6. uddiDiscoveryURLs
+
+ This is a list of Uniform Resource Locators (URLs) that point to
+ alternate, file-based service discovery mechanisms. Each recorded
+ uddiBusinessEntity structure is automatically assigned a URL that
+ returns the individual uddiBusinessEntity structure. A URL search is
+ provided via find_business call.
+
+ The uddiDiscoveryURLs attribute is used to hold pointers to URL-
+ addressable discovery documents. The expected retrieval mechanism
+ for URLs referenced in the data within this structure is via the
+ Hypertext Transfer Protocol [HTTP] HTTP-GET operation. The expected
+ return document is not defined. Rather, a framework for establishing
+ conventions is provided, and two such conventions are defined within
+
+
+
+Bergeson, et al. Informational [Page 8]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+ UDDI behaviors. It is hoped that other conventions come about and
+ use this structure to accommodate alternate means of discovery. With
+ UDDIv3, a new convention is defined with useType as "homepage".
+ Further, a UDDIv3 server need not generate/add a discoveryURL itself,
+ since this can invalidate the digital signature of signed the
+ Business Entity saved by publishers.
+
+ ( 1.3.6.1.1.10.4.6 NAME 'uddiDiscoveryURLs'
+ DESC 'URL to retrieve a businessEntity instance'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ )
+
+ The useType value precedes the URL value, with the "#" character used
+ as the separator.
+
+4.7. uddiUseType
+
+ The uddiUseType is used to describe the type of contact or address in
+ freeform text. Suggested examples for contact include "technical
+ questions", "technical contact", "establish account", "sales
+ contact", etc. Suggested examples for address include
+ "headquarters", "sales office", "billing department", etc.
+
+ ( 1.3.6.1.1.10.4.7 NAME 'uddiUseType'
+ DESC 'name of convention the referenced document follows'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+4.8. uddiPersonName
+
+ The uddiPersonName should list the name of the person or name of the
+ job role that will be available behind the contact. Examples of
+ roles include "administrator" or "webmaster".
+
+ ( 1.3.6.1.1.10.4.8 NAME 'uddiPersonName'
+ DESC 'name of person or job role available for contact'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+ With UDDIv3, uddiPersonName becomes multi-valued and each name can
+ have an xml:lang attribute. The xml:lang value precedes the name
+ value with the "#" character used as the separator.
+
+
+
+
+Bergeson, et al. Informational [Page 9]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+4.9. uddiPhone
+
+ This is used to hold telephone numbers for the contact. This element
+ can be adorned with an optional uddiUseType attribute for descriptive
+ purposes. If more than one phone element is saved, uddiUseType
+ attributes are required on each.
+
+ ( 1.3.6.1.1.10.4.9 NAME 'uddiPhone'
+ DESC 'telephone number for contact'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ )
+
+ The useType precedes the telephone number by a separating '#' (e.g.,
+ "Work Number#123 456-7890") .
+
+4.10. uddiEMail
+
+ This is used to hold email addresses for the contact. This element
+ can be adorned with an optional uddiUseType attribute for descriptive
+ purposes. If more than one email element is saved, uddiUseType
+ attributes are required on each.
+
+ ( 1.3.6.1.1.10.4.10 NAME 'uddiEMail'
+ DESC 'e-mail address for contact'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ )
+
+ The useType precedes the email address by a separating '#' (e.g.,
+ "President of the United States #president@whitehouse.gov").
+
+4.11. uddiSortCode
+
+ The uddiSortCode is used to drive the behavior of external display
+ mechanisms that sort addresses. The suggested values for
+ uddiSortCode include numeric ordering values (e.g., 1, 2, 3),
+ alphabetic character ordering values (e.g., a, b, c), or the first n
+ positions of relevant data within the address.
+
+ ( 1.3.6.1.1.10.4.11 NAME 'uddiSortCode'
+ DESC 'specifies an external display mechanism'
+ EQUALITY caseIgnoreMatch
+ ORDERING caseIgnoreOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+
+
+
+Bergeson, et al. Informational [Page 10]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+ With UDDIv3, the sortCode attribute is deprecated because of the
+ guarantee of preserving the document Order.
+
+4.12. uddiTModelKey
+
+ The uddiTModelKey is the unique identifier for a given instance of an
+ uddiTModel.
+
+ It is also used in a KeyedReference and in Address structures. When
+ used with a keyed reference, this is the unique key to identify a
+ value set and implies that the keyName keyValue pair in a
+ uddiIdentifier or uddiCategory Bag are to be interpreted by the value
+ set referenced by the tModelKey.
+
+ When used with Addressline elements, it implies that the keyName
+ keyValue pair given by subsequent uddiAddressLine elements are to be
+ interpreted by the address structure associated with the tModel that
+ is referenced.
+
+ ( 1.3.6.1.1.10.4.12 NAME 'uddiTModelKey'
+ DESC 'tModel unique identifier'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+4.13. uddiAddressLine
+
+ The uddiAddressLine contains the actual address in freeform text. If
+ the address element contains a uddiTModelKey, these uddiAddressLine
+ elements are to be adorned, each with an optional keyName keyValue
+ attribute pair. Together with the uddiTModelKey, keyName and
+ keyValue qualify the uddiAddressLine in order to describe its
+ meaning.
+
+ The uddiAddressLine elements contain string data with a line length
+ limit of 80 character positions. Each uddiAddressLine element can be
+ adorned with two optional descriptive attributes, keyName and
+ keyValue. Both attributes must be present in each address line if a
+ uddiTModelKey is assigned to the address structure. By doing this,
+ the otherwise arbitrary use of address lines becomes structured.
+ Together with the address' uddiTModelKey, keyName and keyValue
+ virtually build a uddiKeyedReference that represents an address line
+ qualifier, given by the referenced uddiTModel.
+
+ When no uddiTModelKey is provided for the address structure, the
+ keyName and keyValue attributes can be used without restrictions, for
+ example, to provide descriptive information for each uddiAddressLine
+
+
+
+Bergeson, et al. Informational [Page 11]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+ by using the keyName attribute. Since both the keyName and the
+ keyValue attributes are optional, address line order is significant
+ and will always be returned by the UDDI-compliant registry in the
+ order originally provided during a call to save_business.
+
+ ( 1.3.6.1.1.10.4.13 NAME 'uddiAddressLine'
+ DESC 'address'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ )
+
+ The keyName, keyValue, and addressData of this attribute are
+ separated by "#" (e.g., "#"<keyName>"#"<keyValue>"#"<addressData>).
+ The addressData is the only required portion of the attribute.
+
+4.14. uddiIdentifierBag
+
+ The uddiIdentifierBag element allows uddiBusinessEntity or uddiTModel
+ structures to include information about common forms of
+ identification such as D-U-N-S_ numbers, tax identifiers, etc. This
+ data can be used to signify the identity of the uddiBusinessEntity or
+ can be used to signify the identity of the publishing party.
+ Including data of this sort is optional, but when used greatly
+ enhances the search behaviors exposed via the find_xx messages
+ defined in the UDDI Version 2.0 API Specification [UDDIapi]. For a
+ full description of the structures involved in establishing an
+ identity, see UDDI Version 2.0 Data Structure Specification -
+ Appendix A: Using Identifiers [UDDIdsr].
+
+ ( 1.3.6.1.1.10.4.14 NAME 'uddiIdentifierBag'
+ DESC 'identification information'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ )
+
+ The tModel, keyName, and keyValue of this attribute are separated by
+ "#" (e.g., <tModel>"#"<keyName>"#"<keyValue>). The keyValue is the
+ only required portion of the attribute.
+
+4.15. uddiCategoryBag
+
+ The uddiCategoryBag element allows uddiBusinessEntity,
+ uddiBusinessService, and uddiTModel structures to be categorized
+ according to any of several available taxonomy-based classification
+ schemes. Operator Sites automatically provide validated
+ categorization support for three taxonomies that cover industry codes
+ (via NAICS), product and service classifications (via UNSPC), and
+ geography (via ISO 3166). Including data of this sort is optional,
+
+
+
+Bergeson, et al. Informational [Page 12]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+ but when used, it greatly enhances the search behaviors exposed by
+ the find_xx messages defined in the UDDI Version 2.0 API
+ Specification [UDDIapi]. For a full description of structures
+ involved in establishing categorization information, see UDDI Version
+ 2.03 Data Structure Specification--Appendix B: Using Categorization
+ [UDDIdsr].
+
+ ( 1.3.6.1.1.10.4.15 NAME 'uddiCategoryBag'
+ DESC 'categorization information'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ )
+
+ The tModel, keyName, and keyValue of this attribute are separated by
+ "#" (e.g., <tModel>"#"<keyName>"#"<keyValue>). The keyValue is the
+ only required portion of the attribute.
+
+ With UDDIv3, uddiBindingTemplates also supports the uddiCategoryBag
+ element and they can also be categorized according to any of several
+ available taxonomy-based classification schemes.
+
+4.16. uddiKeyedReference
+
+ The uddiKeyedReference is a general-purpose attribute for a name-
+ value pair, with an additional reference to a tModel.
+
+ ( 1.3.6.1.1.10.4.16 NAME 'uddiKeyedReference'
+ DESC 'categorization information'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ )
+
+ The tModel, keyName, and keyValue of this attribute are separated by
+ "#" (e.g., <tModel>"#"<keyName>"#"<keyValue>). The keyValue is the
+ only required portion of the attribute. With UDDIv3, the tModelKey
+ also becomes a mandatory part of the attribute.
+
+ Also, UDDIv3 defines KeyedReferenceGroups for CategoryBags. A
+ keyedReferenceGroup contains a tModelKey and a simple list of
+ KeyedReference structures. The uddiKeyedReference attribute will
+ support KeyedReferenceGroups by suffixing the tModelKey for
+ KeyedReferenceGroup to each of the keyedReference values associated
+ with the group.
+
+ For example, to represent a keyedReference group containing a list of
+ 2 keyed references, the attribute will hold the following 2 strings
+ as its values:
+
+
+
+
+Bergeson, et al. Informational [Page 13]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+ tModelKey1#KeyName1#KeyValue1#KeyedReferenceGroup1_tModelKey
+ tModelKey2#KeyName2#KeyValue2#KeyedReferenceGroup1_tModelKey
+
+4.17. uddiServiceKey
+
+ This is the unique key for a given uddiBusinessService. When saving
+ a new uddiBusinessService structure, pass an empty uddiServiceKey
+ value. This signifies that a UUID value is to be generated. To
+ update an existing uddiBusinessService structure, pass the UUID value
+ that corresponds to the existing service. If a uddiServiceKey is
+ received via an inquiry operation, the key values may not be blank.
+ When saving a new or updated service projection, pass the
+ uddiServiceKey of the referenced uddiBusinessService structure.
+
+ This attribute is optional when the uddiBindingTemplate data is
+ contained within a fully expressed parent that already contains a
+ uddiServiceKey value. If the uddiBindingTemplate data is rendered
+ into XML and has no containing parent that has within its data a
+ uddiServiceKey, the value of the uddiServiceKey that is the ultimate
+ containing parent of the uddiBindingTemplate is required to be
+ provided. This behavior supports the ability to browse through the
+ parent-child relationships given any of the core elements as a
+ starting point.
+
+ ( 1.3.6.1.1.10.4.17 NAME 'uddiServiceKey'
+ DESC 'businessService unique identifier'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+4.18. uddiBindingKey
+
+ This is the unique key for a given uddiBindingTemplate. When saving
+ a new uddiBindingTemplate structure, pass an empty uddiBindingKey
+ value. This signifies that a UUID value is to be generated. To
+ update an existing uddiBindingTemplate, pass the UUID value that
+ corresponds to the existing uddiBindingTemplate instance. If a
+ uddiBindingKey is received via an inquiry operation, the key values
+ may not be blank.
+
+ ( 1.3.6.1.1.10.4.18 NAME 'uddiBindingKey'
+ DESC 'bindingTemplate unique identifier'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+
+
+
+Bergeson, et al. Informational [Page 14]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+4.19. uddiAccessPoint
+
+ The uddiAccessPoint element is an attribute-qualified pointer to a
+ service entry point. The notion of service at the metadata level
+ seen here is fairly abstract and many types of entry points are
+ accommodated. A single attribute is provided named URLType.
+
+ Required attribute-qualified element8: This element is a text field
+ that is used to convey the entry point address suitable for calling a
+ particular Web service. This may be a URL, an electronic mail
+ address, or even a telephone number. No assumptions about the type
+ of data in this field can be made without first understanding the
+ technical requirements associated with the Web service.
+
+ ( 1.3.6.1.1.10.4.19 NAME 'uddiAccessPoint'
+ DESC 'entry point address to call a web service'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+ The URLType value precedes the accessPoint value by a separating '#'.
+
+ With UDDIv3, the "URLType" attribute is replaced by a "UseType"
+ attribute. Using this UseType attribute, the accessPoint attribute
+ can model a hostingRedirector or support indirection to indicate that
+ the accesspoint is specified within a remotely hosted WSDL document.
+
+ For a UDDIv3 registry that needs to support UDDIv2 clients, the
+ attribute must allow the representation of URLType and UseType values
+ independently.
+
+ The UDDIv3 spec specifies the following logic for mapping values
+ between URLType and UseType: If an entity is saved with the v3
+ namespace and a v2 inquiry is made, the URLType will be returned as
+ "other". In the case when a v3 inquiry is made on an entity
+ published with the v2 namespace, the v3 useType attribute will be
+ returned as "endPoint".
+
+ For implementations that need to explicitly model both forms, the
+ recommended format is as follows: v2URLType#v3UseType#Address
+
+4.20. uddiHostingRedirector
+
+ The uddiHostingRedirector element is used to designate that a
+ uddiBindingTemplate entry is a pointer to a different
+ uddiBindingTemplate entry. The value in providing this facility is
+ seen when a business or entity wants to expose a service description
+
+
+
+Bergeson, et al. Informational [Page 15]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+ (e.g., advertise that it has a service available that suits a
+ specific purpose) that is actually a service described in a separate
+ uddiBindingTemplate record. This might occur when a service is
+ remotely hosted (hence the name of this element), or when many
+ service descriptions could benefit from a single service description.
+
+ The uddiHostingRedirector element has a single attribute and no
+ element content. The attribute is a uddiBindingKey value that is
+ suitable within the same UDDI registry instance for querying and
+ obtaining the uddiBindingDetail data that is to be used.
+
+ More on the uddiHostingRedirector can be found in the appendices for
+ the UDDI Version 2.0 API Specification [UDDIapi].
+
+ Required element if uddiAccessPoint is not provided: This element is
+ adorned with a uddiBindingKey attribute, giving the redirected
+ reference to a different uddiBindingTemplate. If you query a
+ uddiBindingTemplate and find a uddiHostingRedirector value, you
+ should retrieve that uddiBindingTemplate and use it in place of the
+ one containing the uddiHostingRedirector data.
+
+ ( 1.3.6.1.1.10.4.20 NAME 'uddiHostingRedirector'
+ DESC 'designates a pointer to another bindingTemplate'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+ With UDDIv3, the hostingRedirector is a deprecated element, since its
+ functionality is now covered by the accessPoint. For backward-
+ compatibility, it can still be used, but it is not recommended.
+
+4.21. uddiInstanceDescription
+
+ This is an optional repeating element. This is one or more
+ language-qualified text descriptions that designate what role a
+ uddiTModel reference plays in the overall service description.
+
+ ( 1.3.6.1.1.10.4.21 NAME 'uddiInstanceDescription'
+ DESC 'instance details description'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ )
+
+ The xml:lang value precedes the name value, with the "#" character
+ used as the separator.
+
+
+
+
+
+Bergeson, et al. Informational [Page 16]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+4.22. uddiInstanceParms
+
+ The uddiInstanceParms is an optional element of the uddiInstance. It
+ is used to contain settings parameters or a URL reference to a file
+ that contains settings or parameters required to use a specific facet
+ of a uddiBindingTemplate description. If used to house the
+ parameters themselves, the suggested content is a namespace-qualified
+ XML string using a namespace outside of the UDDI schema. If used to
+ house a URL pointer to a file, the suggested format is a URL that is
+ suitable for retrieving the settings or parameters via HTTP-GET.
+
+ ( 1.3.6.1.1.10.4.22 NAME 'uddiInstanceParms'
+ DESC 'URL reference to required settings'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+4.23. uddiOverviewDescription
+
+ This is an optional repeating element. This language-qualified
+ string is intended to hold a short descriptive overview of how a
+ particular uddiTModel is to be used.
+
+ ( 1.3.6.1.1.10.4.23 NAME 'uddiOverviewDescription'
+ DESC 'outlines tModel usage'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ )
+
+ The xml:lang value precedes the name value, with the "#" character
+ used as the separator.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bergeson, et al. Informational [Page 17]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+4.24. uddiOverviewURL
+
+ This is an optional element. This string data element is to be used
+ to hold a URL reference to a long form of an overview document that
+ covers the way a particular uddiTModel specific reference is used as
+ a component of an overall Web service description. The recommended
+ format for the overviewURL is a URI that is suitable for retrieving
+ the actual overview document with an HTTP-GET operation, for example,
+ via a Web browser.
+
+ ( 1.3.6.1.1.10.4.24 NAME 'uddiOverviewURL'
+ DESC 'URL reference to overview document'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+ With UDDIv3, uddiOverviewURL becomes multi-valued to allow the
+ representation of multiple OverviewDocs within a single
+ InstanceDetail element.
+
+ Modeling multiple OverviewDocs within an InstanceDetail element:
+
+ In UDDIv3, the InstanceDetails element in TmodelInstanceInfo can have
+ multiple OverviewDoc's. In UDDIv2, we could have only 1 OverviewDoc.
+ To retain the grouping between a set of overviewDescriptions and
+ overviewURL, we can make both OverviewDoc and OverviewURL multi-
+ valued, and have a "group ID" Prefix to each value (to group
+ OverviewDescriptions and OverviewURL).
+
+ An example is shown below:
+
+ Overview Description OverviewURL
+ 1#xml:lang#overviewDescription1 1#UseType#overviewURL
+ 1#xml:lang#overviewDescription2 2#UseType#overviewURL
+ 1#xml:lang#overviewDescription3 4#UseType#overviewURL
+ 3#xml:lang#overviewDescription1
+ 3#xml:lang#overviewDescription2
+ 4#xml:lang#overviewDescription1
+
+ This implies that OverviewDoc1 has 3 overview descriptions and an
+ overviewURL. OverviewDoc2 has only an overviewURL. OverviewDoc3 has
+ only 2 overviewDescriptions. OverviewDoc4 also has 1 overview
+ description and an overviewURL.
+
+
+
+
+
+
+
+Bergeson, et al. Informational [Page 18]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+4.25. uddiFromKey
+
+ The uddiFromKey is a required element. This is the unique key
+ reference to the first uddiBusinessEntity for which the assertion is
+ made.
+
+ ( 1.3.6.1.1.10.4.25 NAME 'uddiFromKey'
+ DESC 'unique businessEntity key reference'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+4.26. uddiToKey
+
+ The uddiToKey is a required element. This is the unique key
+ reference to the second uddiBusinessEntity for which the assertion is
+ made.
+
+ ( 1.3.6.1.1.10.4.26 NAME 'uddiToKey'
+ DESC 'unique businessEntity key reference'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+4.27. uddiUUID
+
+ The uddiUUID is a required element. This is to ensure unique
+ identification of uddiContact, uddiAddress, and
+ uddiPublisherAssertion objects.
+
+ ( 1.3.6.1.1.10.4.27 NAME 'uddiUUID'
+ DESC 'unique attribute'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+ With UDDIv3, this attribute will also be used for unique
+ identification of Subscription-feature-related entities.
+
+
+
+
+
+
+
+
+
+
+Bergeson, et al. Informational [Page 19]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+4.28. uddiIsHidden
+
+ This is used to provide functionality for the delete_tModel
+ operation. Logical deletion hides the deleted tModels from
+ find_tModel result sets but does not physically delete it.
+
+ ( 1.3.6.1.1.10.4.28 NAME 'uddiIsHidden'
+ DESC 'isHidden attribute'
+ EQUALITY booleanMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
+ SINGLE-VALUE
+ )
+
+ In case of UDDIv3, this attribute will represent the "deleted"
+ attribute value.
+
+4.29. uddiIsProjection
+
+ This is used to identify a Business Service that has a Service
+ Projection.
+
+ ( 1.3.6.1.1.10.4.29 NAME 'uddiIsProjection'
+ DESC 'isServiceProjection attribute'
+ EQUALITY booleanMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
+ SINGLE-VALUE
+ )
+
+4.30. uddiLang
+
+ This is used to model the xml:lang value for the Address structure in
+ UDDIv3.
+
+ ( 1.3.6.1.1.10.4.30 NAME 'uddiLang'
+ DESC 'xml:lang value in v3 Address structure'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+ The following are attribute definitions to model new elements/fields
+ in UDDIv3 information model. These attribute definitions have the
+ "uddiv3" prefix to indicate that these attributes represent UDDI
+ information model elements unique to UDDIv3.
+
+
+
+
+
+
+
+Bergeson, et al. Informational [Page 20]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+4.31. uddiv3BusinessKey
+
+ This is the unique UDDIv3 identifier for a given instance of
+ uddiBusinessEntity. It is used in uddiBusinessEntity and
+ uddiBusinessService.
+
+ A uddiBusinessEntity will include the uddiBusinessKey (the v2 form)
+ for unique identification by UDDIv2 clients. The uddiBusinessKey
+ (36-char) will also be the LDAP naming attribute for the
+ uddiBusinessEntity. The uddiBusinessEntity entry MAY also include
+ the uddiv3BusinessKey, the explicit v3 form key, which can be 255
+ characters long.
+
+ ( 1.3.6.1.1.10.4.31 NAME 'uddiv3BusinessKey'
+ DESC 'UDDIv3 businessEntity unique identifier'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+4.32. uddiv3ServiceKey
+
+ This is the unique UDDIv3 identifier for a given instance of
+ uddiBusinessService. It is used in uddiBusinessService and
+ uddiBindingTemplate.
+
+ A uddiBusinessService will include the uddiServiceKey (the v2 form)
+ for unique identification by UDDIv2 clients. The uddiServiceKey
+ (36-char) will also be the LDAP naming attribute for the
+ uddiBusinessService entry. The uddiBusinessService entry MAY also
+ include the uddiv3ServiceKey, the explicit v3 form key, which can be
+ 255 characters long.
+
+ ( 1.3.6.1.1.10.4.32 NAME 'uddiv3ServiceKey'
+ DESC 'UDDIv3 businessService unique identifier'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+4.33. uddiv3BindingKey
+
+ This is the unique UDDIv3 identifier for a given instance of
+ uddiBindingTemplate.
+
+ A uddiBindingTemplate will include the uddiBindingKey (the v2 form)
+ for unique identification by UDDIv2 clients. The uddiBindingKey
+ (36-char) will also be the LDAP naming attribute for the
+
+
+
+Bergeson, et al. Informational [Page 21]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+ uddiBindingTemplate entry. The uddiBindingTemplate entry MAY also
+ include the uddiv3BindingKey, the explicit v3 form key, which can be
+ 255 characters long.
+
+ ( 1.3.6.1.1.10.4.33 NAME 'uddiv3BindingKey'
+ DESC 'UDDIv3 BindingTemplate unique identifier'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+4.34. uddiv3TModelKey
+
+ This is the unique UDDIv3 identifier for a given instance of a
+ uddiTModel.
+
+ A uddiTModel will include the uddiTModelKey (the v2 form) for unique
+ identification by UDDIv2 clients. The uddiTModelKey (41-char) will
+ also be the LDAP naming attribute for the uddiTModel entry. The
+ uddiTModel entry MAY also include the uddiv3TModelKey, the explicit
+ v3 form key, which can be 255 characters long.
+
+ ( 1.3.6.1.1.10.4.34 NAME 'uddiv3TModelKey'
+ DESC 'UDDIv3 TModel unique identifier'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+ The tModelKey is also used in a KeyedReference and in Address
+ structures. In all instances where a tModelKey is used as a
+ reference to tModel, the v3 form of the tModel key (viz.
+ uddiv3TModelKey) will be the form used, since using the v2 form key
+ will require translating it to the v3 key by the UDDI Server, which
+ may invalidate the digital signature of the entity.
+
+4.35. uddiv3DigitalSignature
+
+ The UDDIv3 v3 schema supports the signing of the following UDDI
+ elements using "XML-Signature Syntax and Processing" (see
+ http://www.w3.org/TR/xmldsig-core/).
+
+ ..businessEntity
+ ..businessService
+ ..bindingTemplate
+ ..tModel
+ ..publisherAssertion
+
+
+
+
+Bergeson, et al. Informational [Page 22]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+ This uddiv3DigitalSignature attribute holds the digital signature for
+ the corresponding UDDI entity.
+
+ ( 1.3.6.1.1.10.4.35 NAME 'uddiv3DigitalSignature'
+ DESC 'UDDIv3 entity digital signature'
+ EQUALITY caseExactMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ )
+
+ A Signature element SHOULD be generated according to the required
+ steps of "Core Generation" in XML-Signature Syntax and Processing.
+ The signature should be calculated on the top-level element that will
+ be stored by the registry as a result of the Publication API call.
+ This element, referred to as the data object in the XML-Signature and
+ Syntax specification, is the businessEntity element for save_business
+ API calls, the businessService element for save_service API calls,
+ the bindingTemplate for save_binding API calls, the tModel for
+ save_tModel API calls, and the publisherAssertion for
+ set_publisherAssertions and add_publisherAssertion API calls.
+
+ The signature should be generated on the elements before they are
+ added to the body of an API call. Also, according to the signature
+ generation, all children of the element being signed are included in
+ the generation of the signature unless first excluded by application
+ of a transform. Due to the containment of service projections as
+ businessService elements within a businessEntity element, this also
+ means that changes to the projected service will render a signature
+ of the businessEntity containing the projection invalid, unless a
+ businessService element representing a service projection is excluded
+ using a transform.
+
+ Due to the location of the sequence of Signature elements within an
+ element that is to be signed, the signature is "enveloped". As a
+ result of the enveloping of the signature, it is necessary to apply
+ at least one transformation on the signed entity to exclude the
+ signature or signature(s). The transformation selected by a
+ publisher or the XML-Signature tool is specified in a Transform
+ element inside the Signature element.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bergeson, et al. Informational [Page 23]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+4.36. uddiv3NodeId
+
+ This attribute contains the Node Identity for a UDDIv3 node.
+
+ ( 1.3.6.1.1.10.4.36 NAME 'uddiv3NodeId'
+ DESC 'UDDIv3 Node Identifier'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+4.37. uddiv3EntityModificationTime
+
+ This attribute is used to maintain the last modification time for a
+ UDDI entity. It is needed in the context of maintaining the
+ modifiedIncludingChildren element. When a child entity (e.g.,
+ uddiBindingTemplate) is updated, the parent entity (e.g.,
+ uddiBusinessService) LDAP timestamp also gets updated. The
+ uddiv3EntityModificationTime attribute saves the last modification
+ time of the parent entity (uddiBusinessService in this case).
+
+ ( 1.3.6.1.1.10.4.37 NAME 'uddiv3EntityModificationTime'
+ DESC 'UDDIv3 Last Modified Time for Entity'
+ EQUALITY generalizedTimeMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+ SINGLE-VALUE
+ )
+
+ The following attribute definitions define attributes related to the
+ modeling of UDDIv3 subscription-related entities in the LDAP
+ directory.
+
+ Subscription provides clients, known as subscribers, with the ability
+ to register their interest in receiving information concerning
+ changes made in a UDDI registry. These changes can be scoped based
+ on preferences provided with the request. The uddiv3Subscription
+ object class is used to model registered UDDIv3 subscriptions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bergeson, et al. Informational [Page 24]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+4.38. uddiv3SubscriptionKey
+
+ This is the unique UDDIv3 identifier for a given instance of a
+ uddiv3Subscription entity.
+
+ ( 1.3.6.1.1.10.4.38 NAME 'uddiv3SubscriptionKey'
+ DESC 'UDDIv3 Subscription unique identifier'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+4.39. uddiv3SubscriptionFilter
+
+ This attribute contains the UDDIv3 Subscription Filter, specified as
+ part of the save_subscription API, i.e., the Inquiry API specified as
+ filtering criteria with a registered subscription. The filtering
+ criteria limits the scope of a subscription to a subset of registry
+ records. The get_xx and find_xx APIs are all valid choices for use
+ as a subscriptionFilter. Only one of these can be chosen for each
+ subscription.
+
+ ( 1.3.6.1.1.10.4.39 NAME 'uddiv3SubscriptionFilter'
+ DESC 'UDDIv3 Subscription Filter'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+4.40. uddiv3NotificationInterval
+
+ This attribute contains the Notification Interval string. It is of
+ the type xsd:duration and specifies how often Asynchronous change
+ notifications are to be provided to a subscriber.
+
+ ( 1.3.6.1.1.10.4.40 NAME 'uddiv3NotificationInterval'
+ DESC 'UDDIv3 Notification Interval'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+
+
+
+
+
+
+
+
+
+Bergeson, et al. Informational [Page 25]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+4.41. uddiv3MaxEntities
+
+ This attribute contains the maximum number of entities to be returned
+ as part of a subscription notification. It is an integer and
+ specifies the maximum number of entities in a notification returned
+ to a subscription listener.
+
+ ( 1.3.6.1.1.10.4.41 NAME 'uddiv3MaxEntities'
+ DESC 'UDDIv3 Subscription maxEntities field'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE
+ )
+
+4.42. uddiv3ExpiresAfter
+
+ This attribute specifies the Expiry Time associated with a
+ subscription. It is of the XML Schema type xsd:dateTime.
+
+ ( 1.3.6.1.1.10.4.42 NAME 'uddiv3ExpiresAfter'
+ DESC 'UDDIv3 Subscription ExpiresAfter field'
+ EQUALITY generalizedTimeMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+ SINGLE-VALUE
+ )
+
+4.43. uddiv3BriefResponse
+
+ This attribute is a Boolean flag for Brief Response associated with a
+ subscription entity. It controls the level of detail returned to a
+ subscription listener. The default is "false" when omitted. When
+ set to "true", it indicates that the subscription results are to be
+ returned to the subscriber in the form of a keyBag, listing all of
+ the entities that matched the subscriptionFilter.
+
+ ( 1.3.6.1.1.10.4.43 NAME 'uddiv3BriefResponse'
+ DESC 'UDDIv3 Subscription ExpiresAfter field'
+ EQUALITY booleanMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
+ SINGLE-VALUE
+ )
+
+
+
+
+
+
+
+
+
+
+Bergeson, et al. Informational [Page 26]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+4.44. uddiv3EntityKey
+
+ This is the unique UDDIv3 identifier for a given instance of a core
+ UDDI data structure that is to be logged as an Obituary entry
+ uddiv3EntityObituary. When a core UDDIv3 Entity is deleted and there
+ is an active subscription registered against this UDDI Entity, an
+ Obituary entry is created, in which the v3 key of the deleted entry
+ is logged as part of the uddiv3EntityKey attribute.
+
+ ( 1.3.6.1.1.10.4.44 NAME 'uddiv3EntityKey'
+ DESC 'UDDIv3 Entity unique identifier'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+4.45. uddiv3EntityCreationTime
+
+ This attribute is used to log the original Creation Time for a UDDI
+ Entity that is deleted in the uddiv3EntityObituary entry.
+
+ It is also used in uddiBusinessService and uddiBindingTemplate. A
+ Move BS operation needs to delete and recreate BT sub-tree due to
+ lack of support for moving a sub-tree in many LDAPv3 servers. This
+ attribute is used to save the original creation time of the BT during
+ a Move BS.
+
+ ( 1.3.6.1.1.10.4.45 NAME 'uddiv3EntityCreationTime'
+ DESC 'UDDIv3 Entity Creation Time'
+ EQUALITY generalizedTimeMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+ SINGLE-VALUE
+ )
+
+4.46. uddiv3EntityDeletionTime
+
+ This attribute is used to log the entity deletion time for a UDDI
+ Entity that is deleted in the uddiv3EntityObituary entry.
+
+ ( 1.3.6.1.1.10.4.46 NAME 'uddiv3EntityDeletionTime'
+ DESC 'UDDIv3 Entity Deletion Time'
+ EQUALITY generalizedTimeMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+ SINGLE-VALUE
+ )
+
+
+
+
+
+
+Bergeson, et al. Informational [Page 27]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+5. Object Class Definitions
+
+ The OIDs for the object classes in this document have been registered
+ by the IANA.
+
+5.1. uddiBusinessEntity
+
+ This structural object class represents a businessEntity.
+
+ ( 1.3.6.1.1.10.6.1 NAME 'uddiBusinessEntity'
+ SUP top
+ STRUCTURAL
+ MUST ( uddiBusinessKey $
+ uddiName)
+ MAY ( uddiAuthorizedName $
+ uddiOperator $
+ uddiDiscoveryURLs $
+ uddiDescription $
+ uddiIdentifierBag $
+ uddiCategoryBag $
+ uddiv3BusinessKey $
+ uddiv3DigitalSignature $
+ uddiv3EntityModificationTime $
+ uddiv3NodeId)
+ )
+
+5.2. uddiContact
+
+ This structural object class represents a contact. It is contained
+ by a uddiBusinessEntity.
+
+ ( 1.3.6.1.1.10.6.2 NAME 'uddiContact'
+ SUP top
+ STRUCTURAL
+ MUST ( uddiPersonName $
+ uddiUUID )
+ MAY ( uddiUseType $
+ uddiDescription $
+ uddiPhone $
+ uddiEMail )
+ )
+
+
+
+
+
+
+
+
+
+
+Bergeson, et al. Informational [Page 28]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+5.3. uddiAddress
+
+ This structural object class represents an address. It is contained
+ by a uddiContact.
+
+ ( 1.3.6.1.1.10.6.3 NAME 'uddiAddress'
+ SUP top
+ STRUCTURAL
+ MUST ( uddiUUID )
+ MAY ( uddiUseType $
+ uddiSortCode $
+ uddiTModelKey $
+ uddiv3TmodelKey $
+ uddiAddressLine $
+ uddiLang)
+ )
+
+5.4. uddiBusinessService
+
+ This structural object class represents a businessService.
+
+ ( 1.3.6.1.1.10.6.4 NAME 'uddiBusinessService'
+ SUP top
+ STRUCTURAL
+ MUST ( uddiServiceKey )
+ MAY ( uddiName $
+ uddiBusinessKey $
+ uddiDescription $
+ uddiCategoryBag $
+ uddiIsProjection $
+ uddiv3ServiceKey $
+ uddiv3BusinessKey $
+ uddiv3DigitalSignature $
+ uddiv3EntityCreationTime $
+ uddiv3EntityModificationTime $
+ uddiv3NodeId)
+ )
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bergeson, et al. Informational [Page 29]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+5.5. uddiBindingTemplate
+
+ This structural object class represents a bindingTemplate.
+
+ ( 1.3.6.1.1.10.6.5 NAME 'uddiBindingTemplate'
+ SUP top
+ STRUCTURAL
+ MUST ( uddiBindingKey )
+ MAY ( uddiServiceKey $
+ uddiDescription $
+ uddiAccessPoint $
+ uddiHostingRedirector
+ uddiCategoryBag $
+ uddiv3BindingKey $
+ uddiv3ServiceKey $
+ uddiv3DigitalSignature $
+ uddiv3EntityCreationTime $
+ uddiv3NodeId)
+ )
+
+5.6. uddiTModelInstanceInfo
+
+ This structural object class represents a tModelInstanceInfo. It is
+ contained by a uddiBindingTemplate.
+
+ ( 1.3.6.1.1.10.6.6 NAME 'uddiTModelInstanceInfo'
+ SUP top
+ STRUCTURAL
+ MUST ( uddiTModelKey )
+ MAY ( uddiDescription $
+ uddiInstanceDescription $
+ uddiInstanceParms $
+ uddiOverviewDescription $
+ uddiOverviewURL $
+ uddiv3TmodelKey)
+ )
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bergeson, et al. Informational [Page 30]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+5.7. uddiTModel
+
+ This structural object class represents a tModel.
+
+ ( 1.3.6.1.1.10.6.7 NAME 'uddiTModel'
+ SUP top
+ STRUCTURAL
+ MUST ( uddiTModelKey $
+ uddiName )
+ MAY ( uddiAuthorizedName $
+ uddiOperator $
+ uddiDescription $
+ uddiOverviewDescription $
+ uddiOverviewURL $
+ uddiIdentifierBag $
+ uddiCategoryBag $
+ uddiIsHidden
+ uddiv3TModelKey $
+ uddiv3DigitalSignature $
+ uddiv3NodeId)
+ )
+
+5.8. uddiPublisherAssertion
+
+ This structural object class represents a publisherAssertion.
+
+ ( 1.3.6.1.1.10.6.8 NAME 'uddiPublisherAssertion'
+ SUP top
+ STRUCTURAL
+ MUST ( uddiFromKey $
+ uddiToKey $
+ uddiKeyedReference $
+ uddiUUID )
+ MAY ( uddiv3DigitalSignature $
+ uddiv3NodeId)
+ )
+
+ The following are object class definitions to model new data
+ structures needed to implement the UDDIv3 information model. These
+ object class definitions have the "uddiv3" prefix to indicate that
+ these attributes represent UDDI information model elements unique to
+ UDDIv3.
+
+
+
+
+
+
+
+
+
+Bergeson, et al. Informational [Page 31]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+5.9. uddiv3Subscription
+
+ This structural object class represents a Subscription entity.
+
+ ( 1.3.6.1.1.10.6.9 NAME 'uddiv3Subscription'
+ SUP top
+ STRUCTURAL
+ MUST ( uddiv3SubscriptionFilter $
+ uddiUUID)
+ MAY ( uddiAuthorizedName $
+ uddiv3SubscriptionKey $
+ uddiv3BindingKey $
+ uddiv3NotificationInterval $
+ uddiv3MaxEntities $
+ uddiv3ExpiresAfter $
+ uddiv3BriefResponse $
+ uddiv3NodeId)
+ )
+
+5.10. uddiv3EntityObituary
+
+ This structural object class represents an Obituary entry for and
+ stores obituary information for deleted UDDIv3 entities needed for
+ handling subscriptions.
+
+ ( 1.3.6.1.1.10.6.10 NAME 'uddiv3EntityObituary'
+ SUP top
+ STRUCTURAL
+ MUST ( uddiv3EntityKey $
+ uddiUUID)
+ MAY ( uddiAuthorizedName $
+ uddiv3EntityCreationTime $
+ uddiv3EntityDeletionTime $
+ uddiv3NodeId)
+ )
+
+6. Name Forms
+
+ This section defines the required hierarchical structure rules and
+ naming attributes for the object classes defined in Section 6.
+
+ The OIDs for the structure rules in this document have been
+ registered by the IANA.
+
+
+
+
+
+
+
+
+Bergeson, et al. Informational [Page 32]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+6.1. uddiBusinessEntityNameForm
+
+ This name form defines the naming attribute for a businessEntity.
+
+ ( 1.3.6.1.1.10.15.1 NAME 'uddiBusinessEntityNameForm'
+ OC uddiBusinessEntity
+ MUST ( uddiBusinessKey )
+ )
+
+6.2. uddiContactNameForm
+
+ This name form defines the naming attribute for a contact.
+
+ ( 1.3.6.1.1.10.15.2 NAME 'uddiContactNameForm'
+ OC uddiContact
+ MUST ( uddiUUID )
+ )
+
+6.3. uddiAddressNameForm
+
+ This name form defines the naming attribute for an address.
+
+ ( 1.3.6.1.1.10.15.3 NAME 'uddiAddressNameForm'
+ OC uddiAddress
+ MUST ( uddiUUID )
+ )
+
+6.4. uddiBusinessServiceNameForm
+
+ This name form defines the naming attribute for a businessService.
+
+ ( 1.3.6.1.1.10.15.4 NAME 'uddiBusinessServiceNameForm'
+ OC uddiBusinessService
+ MUST ( uddiServiceKey )
+ )
+
+6.5. uddiBindingTemplateNameForm
+
+ This name form defines the naming attribute for a bindingTemplate.
+
+ ( 1.3.6.1.1.10.15.5 NAME 'uddiBindingTemplateNameForm'
+ OC uddiBindingTemplate
+ MUST ( uddiBindingKey )
+ )
+
+
+
+
+
+
+
+Bergeson, et al. Informational [Page 33]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+6.6. uddiTModelInstanceInfoNameForm
+
+ This name form defines the naming attribute for a tModelInstanceInfo.
+
+ ( 1.3.6.1.1.10.15.6 NAME 'uddiTModelInstanceInfoNameForm'
+ OC uddiTModelInstanceInfo
+ MUST ( uddiTModelKey )
+ )
+
+6.7. uddiTModelNameForm
+
+ This name form defines the naming attribute for a tModel.
+
+ ( 1.3.6.1.1.10.15.7 NAME 'uddiTModelNameForm'
+ OC uddiTModel
+ MUST ( uddiTModelKey )
+ )
+
+6.8. uddiPublisherAssertionNameForm
+
+ This name form defines the naming attribute for a publisherAssertion.
+
+ ( 1.3.6.1.1.10.15.8 NAME 'uddiPublisherAssertionNameForm'
+ OC uddiPublisherAssertion
+ MUST ( uddiUUID )
+ )
+
+6.9. uddiv3SubscriptionNameForm
+
+ This name form defines the naming attribute for a Subscription.
+
+ ( 1.3.6.1.1.10.15.9 NAME 'uddiv3SubscriptionNameForm'
+ OC uddiv3Subscription
+ MUST ( uddiUUID )
+ )
+
+6.10. uddiv3EntityObituaryNameForm
+
+ This name form defines the naming attribute for an Entity Obituary.
+
+ ( 1.3.6.1.1.10.15.10 NAME 'uddiv3EntityObituaryNameForm'
+ OC uddiv3EntityObituary
+ MUST ( uddiUUID )
+ )
+
+
+
+
+
+
+
+Bergeson, et al. Informational [Page 34]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+7. DIT Structure Rules
+
+ This section defines the required hierarchical structure rules for
+ the object classes defined in Section 6.
+
+ Note that rule identifiers defined here show the relationship between
+ structure rules. Implementations may use different identifiers but
+ must follow the same hierarchical model.
+
+7.1. uddiBusinessEntityStructureRule
+
+ ( 1
+ NAME 'uddiBusinessEntityStructureRule'
+ FORM uddiBusinessEntityNameForm
+ )
+
+7.2. uddiContactStructureRule
+
+ This structure rule defines the object class containment for a
+ contact.
+
+ ( 2
+ NAME 'uddiContactStructureRule'
+ FORM uddiContactNameForm
+ SUP ( 1 )
+ )
+
+7.3. uddiAddressStructureRule
+
+ This structure rule defines the object class containment for an
+ address.
+
+ ( 3
+ NAME 'uddiAddressStructureRule'
+ FORM uddiAddressNameForm
+ SUP ( 2 )
+ )
+
+7.4. uddiBusinessServiceStructureRule
+
+ This structure rule defines the object class containment for a
+ businessService.
+
+ ( 4
+ NAME 'uddiBusinessServiceStructureRule'
+ FORM uddiBusinessServiceNameForm
+ SUP ( 1 )
+ )
+
+
+
+Bergeson, et al. Informational [Page 35]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+
+7.5. uddiBindingTemplateStructureRule
+
+ This structure rule defines the object class containment for a
+ bindingTemplate.
+
+ ( 5
+ NAME 'uddiBindingTemplateStructureRule'
+ FORM uddiBindingTemplateNameForm
+ SUP ( 4 )
+ )
+
+7.6. uddiTModelInstanceInfoStructureRule
+
+ This structure rule defines the object class containment for a
+ tModelInstanceInfo.
+
+ ( 6
+ NAME 'uddiTModelInstanceInfoStructureRule'
+ FORM uddiTModelInstanceInfoNameForm
+ SUP ( 5 )
+ )
+
+7.7. uddiTModelStructureRule
+
+ ( 7
+ NAME 'uddiTModelStructureRule'
+ FORM uddiTModelNameForm
+ )
+
+7.8. uddiPublisherAssertion
+
+ ( 8
+ NAME 'uddiPublisherAssertionStructureRule'
+ FORM uddiPublisherAssertionNameForm
+ )
+
+7.9. uddiv3SubscriptionStructureRule
+
+ ( 9
+ NAME 'uddiv3SubscriptionStructureRule'
+ FORM uddiv3SubscriptionNameForm
+ )
+
+
+
+
+
+
+
+
+Bergeson, et al. Informational [Page 36]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+7.10. uddiv3EntityObituaryStructureRule
+
+ ( 10
+ NAME 'uddiv3EntityObituaryStructureRule'
+ FORM uddiv3EntityObituaryNameForm
+ )
+
+8. Security Considerations
+
+ Storing UDDI data into the directory enables the data to be examined
+ and used outside the environment in which it was originally created.
+ The directory entry containing the UDDI data could be read and
+ modified within the constraints imposed by the access control
+ mechanisms of the directory. With UDDIv3 [UDDIv3], publishers can
+ digitally sign UDDI Entities enabling registry clients to validate
+ the integrity of entries read from the UDDIv3 registry by verifying
+ the digital signature.
+
+ Each UDDI Entity has a uddiAuthorizedName attribute that contains an
+ LDAP DN identifying the publisher/owner. The referenced LDAP object
+ can provide the public key of the signer to a registry client for
+ integrity validation of the UDDI Entity.
+
+ Other general LDAP [LDAPv3] security considerations apply. Some of
+ the UDDI attributes such as AccessPoints for services may contain
+ sensitive information. Use of strong authentication mechanisms and
+ data integrity/confidentiality services [RFC2829][RFC2830] is
+ advised.
+
+9. IANA Considerations
+
+ Refer to RFC 3383, "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access Protocol (LDAP)"
+ [RFC3383].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bergeson, et al. Informational [Page 37]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+9.1. Object Identifier Registration
+
+ The IANA has registered an LDAP Object Identifier for use in this
+ technical specification, according to the following template:
+
+ Subject: Request for LDAP OID Registration
+ Person & email address to contact for further information:
+ Bruce Bergeson (bruce.bergeson@novell.com)
+ Specification: RFC 4403
+ Author/Change Controller: IESG
+ Comments:
+ The assigned OID (10) will be used as a base for identifying
+ a number of UDDI schema elements defined in this document.
+
+9.2. Object Identifier Descriptors
+
+ The IANA has registered the LDAP Descriptors used in this technical
+ specification as detailed in the following template:
+
+ Subject: Request for LDAP Descriptor Registration Update
+ Descriptor (short name): see table
+ Object Identifier: see table
+ Person & email address to contact for further information:
+ Bruce Bergeson (bruce.bergeson@novell.com)
+ Usage: see table
+ Specification: RFC 4403
+ Author/Change Controller: IESG
+ Table:
+
+ The following descriptors have been added:
+
+ NAME Type OID
+ -------------- ---- ------------
+ uddiBusinessKey A 1.3.6.1.1.10.4.1
+ uddiAuthorizedName A 1.3.6.1.1.10.4.2
+ uddiOperator A 1.3.6.1.1.10.4.3
+ uddiName A 1.3.6.1.1.10.4.4
+ uddiDescription A 1.3.6.1.1.10.4.5
+ uddiDiscoveryURLs A 1.3.6.1.1.10.4.6
+ uddiUseType A 1.3.6.1.1.10.4.7
+ uddiPersonName A 1.3.6.1.1.10.4.8
+ uddiPhone A 1.3.6.1.1.10.4.9
+ uddiEMail A 1.3.6.1.1.10.4.10
+ uddiSortCode A 1.3.6.1.1.10.4.11
+ uddiTModelKey A 1.3.6.1.1.10.4.12
+ uddiAddressLine A 1.3.6.1.1.10.4.13
+
+
+
+
+
+Bergeson, et al. Informational [Page 38]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+ NAME Type OID
+ -------------- ---- ------------
+ uddiIdentifierBag A 1.3.6.1.1.10.4.14
+ uddiCategoryBag A 1.3.6.1.1.10.4.15
+ uddiKeyedReference A 1.3.6.1.1.10.4.16
+ uddiServiceKey A 1.3.6.1.1.10.4.17
+ uddiBindingKey A 1.3.6.1.1.10.4.18
+ uddiAccessPoint A 1.3.6.1.1.10.4.19
+ uddiHostingRedirector A 1.3.6.1.1.10.4.20
+ uddiInstanceDescription A 1.3.6.1.1.10.4.21
+ uddiInstanceParms A 1.3.6.1.1.10.4.22
+ uddiOverviewDescription A 1.3.6.1.1.10.4.23
+ uddiOverviewURL A 1.3.6.1.1.10.4.24
+ uddiFromKey A 1.3.6.1.1.10.4.25
+ uddiToKey A 1.3.6.1.1.10.4.26
+ uddiUUID A 1.3.6.1.1.10.4.27
+ uddiIsHidden A 1.3.6.1.1.10.4.28
+ uddiIsProjection A 1.3.6.1.1.10.4.29
+ uddiLang A 1.3.6.1.1.10.4.30
+ uddiv3BusinessKey A 1.3.6.1.1.10.4.31
+ uddiv3ServiceKey A 1.3.6.1.1.10.4.32
+ uddiv3BindingKey A 1.3.6.1.1.10.4.33
+ uddiv3TmodelKey A 1.3.6.1.1.10.4.34
+ uddiv3DigitalSignature A 1.3.6.1.1.10.4.35
+ uddiv3NodeId A 1.3.6.1.1.10.4.36
+ uddiv3EntityModificationTime A 1.3.6.1.1.10.4.37
+ uddiv3SubscriptionKey A 1.3.6.1.1.10.4.38
+ uddiv3SubscriptionFilter A 1.3.6.1.1.10.4.39
+ uddiv3NotificationInterval A 1.3.6.1.1.10.4.40
+ uddiv3MaxEntities A 1.3.6.1.1.10.4.41
+ uddiv3ExpiresAfter A 1.3.6.1.1.10.4.42
+ uddiv3BriefResponse A 1.3.6.1.1.10.4.43
+ uddiv3EntityKey A 1.3.6.1.1.10.4.44
+ uddiv3EntityCreationTime A 1.3.6.1.1.10.4.45
+ uddiv3EntityDeletionTime A 1.3.6.1.1.10.4.46
+ uddiBusinessEntity O 1.3.6.1.1.10.6.1
+ uddiContact O 1.3.6.1.1.10.6.2
+ uddiAddress O 1.3.6.1.1.10.6.3
+ uddiBusinessService O 1.3.6.1.1.10.6.4
+ uddiBindingTemplate O 1.3.6.1.1.10.6.5
+ uddiTModelInstanceInfo O 1.3.6.1.1.10.6.6
+ uddiTModel O 1.3.6.1.1.10.6.7
+ uddiPublisherAssertion O 1.3.6.1.1.10.6.8
+ uddiv3Subscription O 1.3.6.1.1.10.6.9
+ uddiv3EntityObituary O 1.3.6.1.1.10.6.10
+ uddiBusinessEntityNameForm N 1.3.6.1.1.10.15.1
+ uddiContactNameForm N 1.3.6.1.1.10.15.2
+ uddiAddressNameForm N 1.3.6.1.1.10.15.3
+
+
+
+Bergeson, et al. Informational [Page 39]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+ NAME Type OID
+ -------------- ---- ------------
+ uddiBusinessServiceNameForm N 1.3.6.1.1.10.15.4
+ uddiBindingTemplateNameForm N 1.3.6.1.1.10.15.5
+ uddiTModelInstanceInfoNameForm N 1.3.6.1.1.10.15.6
+ uddiTModelNameForm N 1.3.6.1.1.10.15.7
+ uddiPublisherAssertionNameForm N 1.3.6.1.1.10.15.8
+ uddiv3SubscriptionNameForm N 1.3.6.1.1.10.15.9
+ uddiv3EntityObituaryNameForm N 1.3.6.1.1.10.15.10
+
+ where Type A is Attribute, Type O is ObjectClass, Type N is NameForm
+
+ These assignments have been recorded in the following registry:
+
+ http://www.iana.org/assignments/ldap-parameters
+
+10. Normative References
+
+ [LDAPv3] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
+
+ [RFC2252] Wahl, M., Coulbeck, A., Howes, T., and S. Kille,
+ "Lightweight Directory Access Protocol (v3): Attribute
+ Syntax Definitions", RFC 2252, December 1997.
+
+ [UDDIdsr] UDDI.ORG, "UDDI version 2.03 Data Structure Reference,"
+ http://uddi.org/pubs/DataStructure-V2.03-Published-
+ 20020719.htm
+
+ [UDDIapi] "UDDI Version 2.04 API Specification",
+ http://uddi.org/pubs/ProgrammersAPI-V2.04-Published-
+ 20020719.htm
+
+ [UDDIv3] UDDI Version 3.0, Published Specification, 19 July 2002
+ http://uddi.org/pubs/uddi-v3.00-published-20020719.htm
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2829] Wahl, M., Alvestrand, H., Hodges, J., and R. Morgan,
+ "Authentication Methods for LDAP", RFC 2829, May 2000.
+
+ [RFC2830] Hodges, J., Morgan, R., and M. Wahl, "Lightweight Directory
+ Access Protocol (v3): Extension for Transport Layer
+ Security", RFC 2830, May 2000.
+
+
+
+
+
+Bergeson, et al. Informational [Page 40]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+ [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access
+ Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
+
+ [XML] Extensible Markup Language (XML) 1.0 (Second Edition) W3C
+ Recommendation 6 October 2000 http://www.w3.org/TR/REC-xml
+
+ [URL] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+ Resource Identifier (URI): Generic Syntax", STD 66, RFC
+ 3986, January 2005.
+
+ [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
+ Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
+ Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
+
+Authors' Addresses
+
+ Bruce Bergeson
+ Novell, Inc.
+ 1800 S Novell Place
+ Provo, UT 84606
+
+ Phone: +1 801 861 3854
+ EMail: bruce.bergeson@novell.com
+
+
+ Kent Boogert
+ Novell, Inc.
+ 1800 S Novell Place
+ Provo, UT 84606
+
+ Phone: +1 801 861 3212
+ EMail: kent.boogert@novell.com
+
+
+ Vijay Nanjundaswamy
+ Oracle India Pvt. Ltd.
+ Lexington Towers, Prestige St. John's Woods
+ #18, 2nd Cross Road,
+ Chikka Audugodi,
+ Bangalore 560029
+ India
+
+ Phone: +11 9180 4108 5000
+ EMail: vijay.nanjundaswamy@oracle.com
+
+
+
+
+
+
+Bergeson, et al. Informational [Page 41]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Bergeson, et al. Informational [Page 42]
+
--
GitLab