--- /dev/null
+
+
+Internet-Draft Editor: R. Harrison
+Intended Category: Draft Standard Novell, Inc.
+Document: draft-ietf-ldapbis-authmeth-05.txt March 2003
+Obsoletes: RFC 2829, RFC 2830
+
+
+ LDAP: Authentication Methods
+ and
+ Connection Level Security Mechanisms
+
+Status of this 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 <ietf-ldapbis@OpenLDAP.org>. Please send
+ editorial comments directly to the author
+ <roger_harrison@novell.com>.
+
+ 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.
+
+Abstract
+
+ This document describes LDAPv3 (Lightweight Directory Access
+ Protocol v3) authentication methods and connection level security
+ mechanisms that are required of all conforming LDAPv3 server
+ implementations and makes recommendations for combinations of these
+ mechanisms to be used in various deployment circumstances.
+
+ Among the mechanisms described are
+
+ - various forms of authentication including anonymous
+ authentication, password-based authentication, and certificate
+ based authentication
+ - the use of SASL mechanisms with LDAPv3
+ - the use of TLS (Transport Layer Security) with LDAPv3
+
+
+Harrison Expires September 2003 [Page 1]
+\f
+ Authentication Methods for LDAPv3
+
+ - the various authentication and authorization states through
+ which a connection to an LDAP server may pass and the actions
+ that trigger these state changes.
+
+
+1. Conventions Used in this Document
+
+1.1. Glossary of Terms
+
+ The following terms are used in this document. To aid the reader,
+ these terms are defined here.
+
+ - "user" represents any application which is an LDAP client using
+ the directory to retrieve or store information.
+
+ - "LDAP association" is used to distinguish the LDAP-level
+ connection from any underlying TLS-level connection that may or
+ may not exist.
+
+1.2. Security Terms and Concepts
+
+ In general, security terms in this document are used consistently
+ with the definitions provided in [RFC2828]. In addition, several
+ terms and concepts relating to security, authentication, and
+ authorization are presented in Appendix B of this document. While
+ the formal definition of these terms and concepts is outside the
+ scope of this document, an understanding of them is prerequisite to
+ understanding much of the material in this document. Readers who are
+ unfamiliar with security-related concepts are encouraged to review
+ Appendix B before reading the remainder of this document.
+
+1.3. Keywords
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [RFC2119].
+
+2. Introduction
+
+ This document is an integral part of the LDAP Technical
+ Specification [ROADMAP]. This document replaces RFC 2829 and
+ portions of RFC 2830. Changes to RFC 2829 are summarized in Appendix
+ C and changes to RFC 2830 are summarized in Appendix D.
+
+ LDAPv3 is a powerful access protocol for directories. It offers
+ means of searching, retrieving and manipulating directory content,
+ and ways to access a rich set of security functions.
+
+ It is vital that these security functions be interoperable among all
+ LDAP clients and servers on the Internet; therefore there has to be
+ a minimum subset of security functions that is common to all
+ implementations that claim LDAPv3 conformance.
+
+ Basic threats to an LDAP directory service include:
+
+Harrison Expires September 2003 [Page 2]
+\f
+ Authentication Methods for LDAPv3
+
+
+ (1) Unauthorized access to directory data via data-retrieval
+ operations,
+
+ (2) Unauthorized access to reusable client authentication
+ information by monitoring others' access,
+
+ (3) Unauthorized access to directory data by monitoring others'
+ access,
+
+ (4) Unauthorized modification of directory data,
+
+ (5) Unauthorized modification of configuration information,
+
+ (6) Unauthorized or excessive use of resources (denial of service),
+ and
+
+ (7) Spoofing of directory: Tricking a client into believing that
+ information came from the directory when in fact it did not,
+ either by modifying data in transit or misdirecting the client's
+ connection.
+
+ Threats (1), (4), (5) and (6) are due to hostile clients. Threats
+ (2), (3) and (7) are due to hostile agents on the path between
+ client and server or hostile agents posing as a server.
+
+ The LDAP protocol suite can be protected with the following security
+ mechanisms:
+
+ (1) Client authentication by means of the SASL [RFC2222] mechanism
+ set, possibly backed by the TLS [RFC2246] credentials exchange
+ mechanism,
+
+ (2) Client authorization by means of access control based on the
+ requestor's authenticated identity,
+
+ (3) Data integrity protection by means of the TLS protocol or SASL
+ mechanisms that provide data integrity services,
+
+ (4) Data confidentiality protection against snooping by means of the
+ TLS protocol or SASL mechanisms that provide data
+ confidentiality services,
+
+ (5) Server resource usage limitation by means of administrative
+ service limits configured on the server, and
+
+ (6) Server authentication by means of the TLS protocol or SASL
+ mechanism.
+
+ At the moment, imposition of access controls is done by means
+ outside the scope of the LDAPv3 protocol.
+
+3. Rationale for LDAPv3 Security Mechanisms
+
+
+
+Harrison Expires September 2003 [Page 3]
+\f
+ Authentication Methods for LDAPv3
+
+ It seems clear that allowing any implementation, faced with the
+ above requirements, to simply pick and choose among the possible
+ alternatives is not a strategy that is likely to lead to
+ interoperability. In the absence of mandates, clients will be
+ written that do not support any security function supported by the
+ server, or worse, they will support only mechanisms like the LDAPv3
+ simple bind using clear text passwords that provide inadequate
+ security for most circumstances.
+
+ Given the presence of the Directory, there is a strong desire to see
+ mechanisms where identities take the form of an LDAP distinguished
+ name [LDAPDN] and authentication data can be stored in the
+ directory. This means that this data must be updated outside the
+ protocol or only updated in sessions well protected against
+ snooping. It is also desirable to allow authentication methods to
+ carry authorization identities based on existing--non-LDAP DN--forms
+ of user identities for backwards compatibility with non-LDAP-based
+ authentication services.
+
+ The set of security mechanisms provided in LDAPv3 and described in
+ this document is intended to meet the security needs for a wide
+ range of deployment scenarios and still provide a high degree of
+ interoperability among various LDAPv3 implementations and
+ deployments. Appendix A contains example deployment scenarios that
+ list the mechanisms that might be used to achieve a reasonable level
+ of security in various circumstances.
+
+4. Bind Operation
+
+ The Bind operation defined in section 4.2 of [Protocol] allows
+ authentication information to be exchanged between the client and
+ server.
+
+4.1. Unbound Connection Treated as Anonymous ("Implied Anonymous Bind")
+
+ Unlike LDAP version 2, the client need not send a Bind Request in
+ the first PDU of the connection. The client may send any operation
+ request prior to binding, and the server MUST treat it as if it had
+ been performed after an anonymous bind operation. If the server
+ requires that the client bind before browsing or modifying the
+ directory, the server MAY reject a request other than binding,
+ unbinding or an extended request with the "operationsError" result.
+
+
+4.2. Simple Authentication
+
+ The simple authentication option provides minimal authentication
+ facilities, with the contents of the authentication field consisting
+ only of a cleartext password. Note that the use of cleartext
+ passwords is strongly discouraged over open networks when the
+ underlying transport service cannot guarantee confidentiality (see
+ section 8).
+
+4.3. SASL Authentication
+
+Harrison Expires September 2003 [Page 4]
+\f
+ Authentication Methods for LDAPv3
+
+
+ The sasl authentication option allows for any mechanism defined for
+ use with SASL [RFC2222] not specifically prohibited by this document
+ (see section 4.3.1).
+
+ Clients sending a bind request with the sasl choice selected SHOULD
+ NOT send a value in the name field. Servers receiving a bind request
+ with the sasl choice selected SHALL ignore any value in the name
+ field.
+
+ The mechanism field in SaslCredentials contains the name of the
+ mechanism. The credentials field contains the arbitrary data used
+ for authentication, inside an OCTET STRING wrapper. Note that unlike
+ some Internet application protocols where SASL is used, LDAP is not
+ text-based, thus no Base64 transformations are performed on the
+ credentials.
+
+ If any SASL-based integrity or confidentiality services are enabled,
+ they take effect following the transmission by the server and
+ reception by the client of the final BindResponse with a resultCode
+ of success.
+
+ If a SASL security layer is negotiated, the client MUST discard all
+ information about the server fetched prior to the initiation of the
+ SASL negotiation. If the client is configured to support multiple
+ SASL mechanisms, it SHOULD fetch the supportedSASLmechanisms list
+ both before and after the SASL security layer is negotiated. This
+ allows the client to detect active attacks that remove supported
+ SASL mechanisms from the supportedSASLMechanisms list and allows the
+ client to ensure that it is using the best mechanism supported by
+ both client and server. (This requirement is a SHOULD to allow for
+ environments where the supportedSASLMechanisms list is provided to
+ the client through a different trusted source, e.g. as part of a
+ digitally signed object.)
+
+ The client can request that the server use authentication
+ information from a lower layer protocol by using the SASL EXTERNAL
+ mechanism (see section 5.2.2.).
+
+4.3.1. Use of ANONYMOUS and PLAIN SASL Mechanisms
+
+ As LDAP includes native anonymous and plaintext authentication
+ methods, the "ANONYMOUS" and "PLAIN" SASL mechanisms are not used
+ with LDAP. If an authorization identity of a form different from a
+ DN is requested by the client, a data confidentiality mechanism that
+ protects the password in transit should be used.
+
+4.3.2. Use of EXTERNAL SASL Mechanism
+
+ The "EXTERNAL" SASL mechanism can be used to request the LDAP server
+ make use of security credentials exchanged by a lower layer. If a
+ TLS session has not been established between the client and server
+ prior to making the SASL EXTERNAL Bind request and there is no other
+ external source of authentication credentials (e.g. IP-level
+
+Harrison Expires September 2003 [Page 5]
+\f
+ Authentication Methods for LDAPv3
+
+ security [RFC2401]), or if during the process of establishing the
+ TLS session, the server did not request the client's authentication
+ credentials, the SASL EXTERNAL bind MUST fail with a resultCode of
+ inappropriateAuthentication. Any client authentication and
+ authorization state of the LDAP association is lost, so the LDAP
+ association is in an anonymous state after the failure (see
+ [Protocol] section 4.2.1).
+
+4.3.3. Other SASL Mechanisms
+
+ Other SASL mechanisms may be used with LDAP, but their usage is not
+ considered in this document.
+
+4.4. SASL Authorization Identity
+
+ The authorization identity is carried as part of the SaslCredentials
+ credentials field in the Bind request and response.
+
+ When the "EXTERNAL" SASL mechanism is being negotiated, if the
+ credentials field is present, it contains an authorization identity
+ of the authzId form described below.
+
+ Other mechanisms define the location of the authorization identity
+ in the credentials field.
+
+4.4.1. Authorization Identity Syntax
+
+ The authorization identity is a string in the UTF-8 character set,
+ corresponding to the following ABNF grammar [RFC2234]:
+
+ ; Specific predefined authorization (authz) id schemes are
+ ; defined below -- new schemes may be defined in the future.
+
+ authzId = dnAuthzId / uAuthzId
+
+ DNCOLON = %x64 %x6e %x3a ; "dn:"
+ UCOLON = %x75 %x3a ; "u:"
+
+ ; distinguished-name-based authz id.
+ dnAuthzId = DNCOLON dn
+ dn = utf8string ; with syntax defined in [LDAPDN] section 3.
+
+
+ ; unspecified authorization id, UTF-8 encoded.
+ uAuthzId = UCOLON userid
+ userid = utf8string ; syntax unspecified
+
+ The dnAuthzId choice allows client applications to assert
+ authorization identities in the form of a distinguished name. The
+ decision to allow or disallow an authentication identity to have
+ access to the requested authorization identity is a matter of local
+ policy ([SASL] section 4.2). For this reason there is no requirement
+ that the asserted dn be that of an entry in directory.
+
+
+Harrison Expires September 2003 [Page 6]
+\f
+ Authentication Methods for LDAPv3
+
+ The uAuthzId choice allows for compatibility with client
+ applications that wish to assert an authorization identity to a
+ local directory but do not have that identity in distinguished name
+ form. The format of utf8string is defined as only a sequence of UTF-
+ 8 encoded ISO 10646 characters, and further interpretation is
+ subject to prior agreement between the client and server.
+
+ For example, the userid could identify a user of a specific
+ directory service, or be a login name or the local-part of an RFC
+ 822 email address. In general, a uAuthzId MUST NOT be assumed to be
+ globally unique.
+
+ Additional authorization identity schemes MAY be defined in future
+ versions of this document.
+
+4.5. SASL Service Name for LDAP
+
+ For use with SASL [RFC2222], a protocol must specify a service name
+ to be used with various SASL mechanisms, such as GSSAPI. For LDAP,
+ the service name is "ldap", which has been registered with the IANA
+ as a GSSAPI service name.
+
+4.6. SASL Integrity and Privacy Protections
+
+ Any negotiated SASL integrity and privacy protections SHALL start on
+ the first octet of the first LDAP PDU following successful
+ completion of the SASL bind operation. If lower level security layer
+ is negotiated, such as TLS, any SASL security services SHALL be
+ layered on top of such security layers regardless of the order of
+ their negotiation.
+
+5. Start TLS Operation
+
+ The Start Transport Layer Security (StartTLS) operation defined in
+ section 4.13 of [Protocol] provides the ability to establish
+ Transport Layer Security [RFC2246] on an LDAP association.
+
+5.1. Sequencing of the Start TLS Operation
+
+ This section describes the overall procedures clients and servers
+ must follow for TLS establishment. These procedures take into
+ consideration various aspects of the overall security of the LDAP
+ association including discovery of resultant security level and
+ assertion of the client's authorization identity.
+
+ Note that the precise effects, on a client's authorization identity,
+ of establishing TLS on an LDAP association are described in detail
+ in section 5.5.
+
+5.1.1. Requesting to Start TLS on an LDAP Association
+
+ The client MAY send the Start TLS extended request at any time after
+ establishing an LDAP association, except that in the following cases
+ the client MUST NOT send a Start TLS extended request:
+
+Harrison Expires September 2003 [Page 7]
+\f
+ Authentication Methods for LDAPv3
+
+
+ - if TLS is currently established on the connection, or
+ - during a multi-stage SASL negotiation, or
+ - if there are any LDAP operations outstanding on the
+ connection.
+
+ The result of violating any of these requirements is a resultCode of
+ operationsError, as described above in [Protocol] section 14.3.2.2.
+
+ In particular, there is no requirement that the client have or have
+ not already performed a Bind operation before sending a Start TLS
+ operation request. The client may have already performed a Bind
+ operation when it sends a Start TLS request, or the client might
+ have not yet bound.
+
+ If the client did not establish a TLS connection before sending any
+ other requests, and the server requires the client to establish a
+ TLS connection before performing a particular request, the server
+ MUST reject that request by sending a resultCode of
+ confidentialityRequired or strongAuthRequired. In response, the
+ client MAY send a Start TLS extended request, or it MAY choose to
+ close the connection.
+
+5.1.2. Starting TLS
+
+ The server will return an extended response with the resultCode of
+ success if it is willing and able to negotiate TLS. It will return
+ other resultCodes (documented in [Protocol] section 4.13.2.2) if it
+ is unable to do so.
+
+ In the successful case, the client (which has ceased to transfer
+ LDAP requests on the connection) MUST either begin a TLS negotiation
+ or close the connection. The client will send PDUs in the TLS Record
+ Protocol directly over the underlying transport connection to the
+ server to initiate TLS negotiation [RFC2246].
+
+5.1.3. TLS Version Negotiation
+
+ Negotiating the version of TLS or SSL to be used is a part of the
+ TLS Handshake Protocol, as documented in [RFC2246]. Please refer to
+ that document for details.
+
+5.1.4. Discovery of Resultant Security Level
+
+ After a TLS connection is established on an LDAP association, both
+ parties MUST individually decide whether or not to continue based on
+ the privacy level achieved. Ascertaining the TLS connection's
+ privacy level is implementation dependent, and accomplished by
+ communicating with one's respective local TLS implementation.
+
+ If the client or server decides that the level of authentication or
+ privacy is not high enough for it to continue, it SHOULD gracefully
+ close the TLS connection immediately after the TLS negotiation has
+ completed (see [Protocol] section 4.13.3.1 and section 5.2.3 below).
+
+Harrison Expires September 2003 [Page 8]
+\f
+ Authentication Methods for LDAPv3
+
+ If the client decides to continue, it MAY attempt to Start TLS
+ again, it MAY send an unbind request, or it MAY send any other LDAP
+ request.
+
+5.1.5. Assertion of Client's Authorization Identity
+
+ The client MAY, upon receipt of a Start TLS response indicating
+ success, assert that a specific authorization identity be utilized
+ in determining the client's authorization status. The client
+ accomplishes this via an LDAP Bind request specifying a SASL
+ mechanism of "EXTERNAL" [RFC2222] (see section 5.5.1.2 below).
+
+5.1.6. Server Identity Check
+
+ The client MUST check its understanding of the server's hostname
+ against the server's identity as presented in the server's
+ Certificate message, in order to prevent man-in-the-middle attacks.
+
+ Matching is performed according to these rules:
+
+ - The client MUST use the server hostname it used to open the LDAP
+ connection as the value to compare against the server name as
+ expressed in the server's certificate. The client MUST NOT use
+ the any other derived form of name including the server's
+ canonical DNS name.
+
+ - If a subjectAltName extension of type dNSName is present in the
+ certificate, it SHOULD be used as the source of the server's
+ identity.
+
+ - Matching is case-insensitive.
+
+ - The "*" wildcard character is allowed. If present, it applies
+ only to the left-most name component.
+
+ For example, *.bar.com would match a.bar.com and b.bar.com, but it
+ would not match a.x.bar.com nor would it match bar.com. If more
+ than one identity of a given type is present in the certificate
+ (e.g. more than one dNSName name), a match in any one of the set is
+ considered acceptable.
+
+ If the hostname does not match the dNSName-based identity in the
+ certificate per the above check, user-oriented clients SHOULD either
+ notify the user (clients MAY give the user the opportunity to
+ continue with the connection in any case) or terminate the
+ connection and indicate that the server's identity is suspect.
+ Automated clients SHOULD close the connection, returning and/or
+ logging an error indicating that the server's identity is suspect.
+
+ Beyond the server identity checks described in this section, clients
+ SHOULD be prepared to do further checking to ensure that the server
+ is authorized to provide the service it is observed to provide. The
+ client MAY need to make use of local policy information.
+
+
+Harrison Expires September 2003 [Page 9]
+\f
+ Authentication Methods for LDAPv3
+
+5.1.7. Refresh of Server Capabilities Information
+
+ Upon TLS session establishment, the client MUST discard all
+ information about the server fetched prior to the initiation of the
+ TLS negotiation and MUST refresh any cached server capabilities
+ information (e.g. from the server's root DSE; see section 3.4 of
+ [Protocol]). This is necessary to protect against active-
+ intermediary attacks that may have altered any server capabilities
+ information retrieved prior to TLS establishment.
+
+ The server MAY advertise different capabilities after TLS
+ establishment. In particular, the value of supportedSASLMechanisms
+ MAY be different after TLS has been negotiated (specifically, the
+ EXTERNAL mechanism or the proposed PLAIN mechanism are likely to
+ only be listed after a TLS negotiation has been performed).
+
+5.2. Effects of TLS on a Client's Authorization Identity
+
+ This section describes the effects on a client's authorization
+ identity brought about by establishing TLS on an LDAP association.
+ The default effects are described first, and next the facilities for
+ client assertion of authorization identity are discussed including
+ error conditions. Finally, the effects of closing the TLS connection
+ are described.
+
+ Authorization identities and related concepts are described in
+ Appendix B.
+
+5.2.1. Default Effects
+
+ Upon establishment of the TLS session onto the LDAP association, any
+ previously established authentication and authorization identities
+ MUST remain in force, including anonymous state. This holds even in
+ the case where the server requests client authentication via TLS --
+ e.g. requests the client to supply its certificate during TLS
+ negotiation (see [RFC2246]).
+
+5.2.2. Client Assertion of Authorization Identity
+
+ A client MAY either implicitly request that its LDAP authorization
+ identity be derived from its authenticated TLS credentials or it MAY
+ explicitly provide an authorization identity and assert that it be
+ used in combination with its authenticated TLS credentials. The
+ former is known as an implicit assertion, and the latter as an
+ explicit assertion.
+
+5.2.2.1. Implicit Assertion
+
+ An implicit authorization identity assertion is accomplished after
+ TLS establishment by invoking a Bind request of the SASL form using
+ the "EXTERNAL" mechanism name [RFC2222] [Protocol] that SHALL NOT
+ include the optional credentials octet string (found within the
+ SaslCredentials sequence in the Bind Request). The server will
+ derive the client's authorization identity from the authentication
+
+Harrison Expires September 2003 [Page 10]
+\f
+ Authentication Methods for LDAPv3
+
+ identity supplied in the client's TLS credentials (typically a
+ public key certificate) according to local policy. The underlying
+ mechanics of how this is accomplished are implementation specific.
+
+5.2.2.2. Explicit Assertion
+
+ An explicit authorization identity assertion is accomplished after
+ TLS establishment by invoking a Bind request of the SASL form using
+ the "EXTERNAL" mechanism name [RFC2222] [Protocol] that SHALL
+ include the credentials octet string. This string MUST be
+ constructed as documented in section 4.4.1.
+
+5.2.2.3. Error Conditions
+
+ For either form of assertion, the server MUST verify that the
+ client's authentication identity as supplied in its TLS credentials
+ is permitted to be mapped to the asserted authorization identity.
+ The server MUST reject the Bind operation with an invalidCredentials
+ resultCode in the Bind response if the client is not so authorized.
+
+ Additionally, with either form of assertion, if a TLS session has
+ not been established between the client and server prior to making
+ the SASL EXTERNAL Bind request and there is no other external source
+ of authentication credentials (e.g. IP-level security [RFC2401]), or
+ if during the process of establishing the TLS session, the server
+ did not request the client's authentication credentials, the SASL
+ EXTERNAL bind MUST fail with a result code of
+ inappropriateAuthentication.
+
+ After the above Bind operation failures, any client authentication
+ and authorization state of the LDAP association is lost (see
+ [Protocol] section 4.2.1), so the LDAP association is in an
+ anonymous state after the failure. The TLS session state is
+ unaffected, though a server MAY end the TLS session, via a TLS
+ close_notify message, based on the Bind failure (as it MAY at any
+ time).
+
+5.2.3. TLS Connection Closure Effects
+
+ Closure of the TLS session MUST cause the LDAP association to move
+ to an anonymous authentication and authorization state regardless of
+ the state established over TLS and regardless of the authentication
+ and authorization state prior to TLS session establishment.
+
+6. LDAP Association State Transition Tables
+
+ To comprehensively diagram the various authentication and TLS states
+ through which an LDAP association may pass, this section provides a
+ state transition table to represent a state diagram for the various
+ states through which an LDAP association may pass during the course
+ of its existence and the actions that cause these changes in state.
+
+6.1. LDAP Association States
+
+
+Harrison Expires September 2003 [Page 11]
+\f
+ Authentication Methods for LDAPv3
+
+ The following table lists the valid LDAP association states and
+ provides a description of each state. The ID for each state is used
+ in the state transition table in section 6.4.
+
+ ID State Description
+ -- --------------------------------------------------------------
+ S1 no Auth ID
+ no AuthZ ID
+ [TLS: no Creds, OFF]
+ S2 no Auth ID
+ no AuthZ ID
+ [TLS: no Creds, ON]
+ S3 no Auth ID
+ no AuthZ ID
+ [TLS: Creds Auth ID "I", ON]
+ S4 Auth ID = Xn
+ AuthZ ID= Y
+ [TLS: no Creds, OFF]
+ S5 Auth ID = Xn
+ AuthZ ID= Yn
+ [TLS: no Creds, ON]
+ S6 Auth ID = Xn
+ AuthZ ID= Yn
+ [TLS: Creds Auth ID "I", ON]
+ S7 Auth ID = I
+ AuthZ ID= J
+ [TLS: Creds Auth ID "I", ON]
+ S8 Auth ID = I
+ AuthZ ID= K
+ [TLS: Creds Auth ID "I", ON]
+
+6.2. Actions that Affect LDAP Association State
+
+ The following table lists the actions that can affect the state of
+ an LDAP association. The ID for each action is used in the state
+ transition table in section 6.4.
+
+ ID Action
+ -- ------------------------------------------------
+ A1 Client binds anonymously
+ A2 Inappropriate authentication: client attempts an anonymous
+ bind or a bind without supplying credentials to a server that
+ requires the client to provide some form of credentials.
+ A3 Client Start TLS request
+ Server: client auth NOT required
+ A4 Client: Start TLS request
+ Server: client creds requested
+ Client: [TLS creds: Auth ID "I"]
+ A5 Client or Server: send TLS closure alert ([Protocol] section
+ X)
+ A6 Client: Bind w/simple password or SASL mechanism (e.g. DIGEST-
+ MD5 password, Kerberos, etc. -û except EXTERNAL [Auth ID "X"
+
+Harrison Expires September 2003 [Page 12]
+\f
+ Authentication Methods for LDAPv3
+
+ maps to AuthZ ID "Y"]
+ A7 Client Binds SASL EXTERNAL with credentials: AuthZ ID "J"
+ [Explicit Assertion (section 5.2.1.2.2)]
+ A8 Client Bind SASL EXTERNAL without credentials [Implicit
+ Assertion (section 5.2 .1.2.1)]
+
+6.3. Decisions Used in Making LDAP Association State Changes
+
+ Certain changes in the state of an LDAP association are only allowed
+ if the server can affirmatively answer a question. These questions
+ are applied as part of the criteria for allowing or disallowing a
+ state change in the state transition table in section 6.4.
+
+ ID Decision Question
+ -- --------------------------------------------------------------
+ D1 Can TLS Credentials Auth ID "I" be mapped to AuthZ ID "J"?
+ D2 Can a valid AuthZ ID "K" be derived from TLS Credentials Auth
+ ID "I"?
+
+6.4. LDAP Association State Transition Table
+
+ The LDAP Association table below lists the valid states for an LDAP
+ association and the actions that could affect them. For any given
+ row in the table, the Current State column gives the state of an
+ LDAP association, the Action column gives an action that could
+ affect the state of an LDAP assocation, and the Next State column
+ gives the resulting state of an LDAP association after the action
+ occurs.
+
+ The initial state for the state machine described in this table is
+ S1.
+
+ Current Next
+ State Action State Comment
+ ------- ------------- ----- -----------------------------------
+ S1 A1 S1
+ S1 A2 S1 Error: Inappropriate authentication
+ S1 A3 S2
+ S1 A4 S3
+ S1 A6 S4
+ S1 A7 ? identity could be provided by
+ another underlying mechanism such
+ as IPSec.
+ S1 A8 ? identity could be provided by
+ another underlying mechanism such
+ as IPSec.
+ S2 A1 S2
+ S2 A2 S2 Error: Inappropriate authentication
+ S2 A5 S1
+ S2 A6 S5
+ S2 A7 ? identity could be provided by
+ another underlying mechanism such
+ as IPSec.
+
+Harrison Expires September 2003 [Page 13]
+\f
+ Authentication Methods for LDAPv3
+
+ S2 A8 ? identity could be provided by
+ another underlying mechanism such
+ as IPSec.
+ S3 A1 S3
+ S3 A2 S3 Error: Inappropriate authentication
+ S3 A5 S1
+ S3 A6 S6
+ S3 A7 and D1=NO S3 Error: InvalidCredentials
+ S3 A7 and D1=YES S7
+ S3 A8 and D2=NO S3 Error: InvalidCredentials
+ S3 A8 and D2=YES S8
+ S4 A1 S1
+ S4 A2 S4 Error: Inappropriate Authentication
+ S4 A3 S5
+ S4 A4 S6
+ S4 A5 S1
+ S4 A6 S4
+ S4 A7 ? identity could be provided by
+ another underlying mechanism such
+ as IPSec.
+ S4 A8 ? identity could be provided by
+ another underlying mechanism such
+ as IPSec.
+ S5 A1 S2
+ S5 A2 S5 Error: Inappropriate Authentication
+ S5 A5 S1
+ S5 A6 S5
+ S5 A7 ? identity could be provided by
+ another underlying mechanism such
+ as IPSec.
+ S5 A8 ? identity could be provided by
+ another underlying mechanism such
+ as IPSec.
+ S6 A1 S3
+ S6 A2 S6 Error: Inappropriate Authentication
+ S6 A5 S1
+ S6 A6 S6
+ S6 A7 and D1=NO S6 Error: InvalidCredentials
+ S6 A7 and D1=YES S7
+ S6 A8 and D2=NO S6 Error: InvalidCredentials
+ S6 A8 and D2=YES S8
+ S7 A1 S3
+ S7 A2 S7 Error: Inappropriate Authentication
+ S7 A5 S1
+ S7 A6 S6
+ S7 A7 S7
+ S7 A8 and D2=NO S3 Error: InvalidCredentials
+ S7 A8 and D2=YES S8
+ S8 A1 S3
+ S8 A2 S8 Error: Inappropriate Authentication
+ S8 A5 S1
+ S8 A6 S6
+
+Harrison Expires September 2003 [Page 14]
+\f
+ Authentication Methods for LDAPv3
+
+ S8 A7 and D1=NO S6 Error: InvalidCredentials
+ S8 A7 and D1=YES S7
+ S8 A8 S8
+
+
+7. Anonymous Authentication
+
+ Directory operations that modify entries or access protected
+ attributes or entries generally require client authentication.
+ Clients that do not intend to perform any of these operations
+ typically use anonymous authentication. Servers SHOULD NOT allow
+ clients with anonymous authentication to modify directory entries or
+ access sensitive information in directory entries.
+
+ LDAP implementations MUST support anonymous authentication, as
+ defined in section 7.1.
+
+ LDAP implementations MAY support anonymous authentication with TLS,
+ as defined in section 7.2.
+
+ While there MAY be access control restrictions to prevent access to
+ directory entries, an LDAP server SHOULD allow an anonymously-bound
+ client to retrieve the supportedSASLMechanisms attribute of the root
+ DSE.
+
+ An LDAP server MAY use other information about the client provided
+ by the lower layers or external means to grant or deny access even
+ to anonymously authenticated clients.
+
+7.1. Anonymous Authentication Procedure
+
+ An LDAPv3 client that has not successfully completed a bind
+ operation on a connection is anonymously authenticated. See section
+ 4.3.3.
+
+ An LDAP client MAY also choose to explicitly bind anonymously. A
+ client that wishes to do so MUST choose the simple authentication
+ option in the Bind Request (see section 4.1) and set the password to
+ be of zero length. (This is often done by LDAPv2 clients.) Typically
+ the name is also of zero length.
+
+7.2. Anonymous Authentication and TLS
+
+ An LDAP client MAY use the Start TLS operation (section 5) to
+ negotiate the use of TLS security [RFC2246]. If the client has not
+ bound beforehand, then until the client uses the EXTERNAL SASL
+ mechanism to negotiate the recognition of the client's certificate,
+ the client is anonymously authenticated.
+
+ Recommendations on TLS ciphersuites are given in section 10.
+
+ An LDAP server which requests that clients provide their certificate
+ during TLS negotiation MAY use a local security policy to determine
+
+
+Harrison Expires September 2003 [Page 15]
+\f
+ Authentication Methods for LDAPv3
+
+ whether to successfully complete TLS negotiation if the client did
+ not present a certificate which could be validated.
+
+8. Password-based Authentication
+
+ This section discusses various options for performing password-based
+ authentication to LDAPv3 compliant servers and the environments
+ suitable for their use.
+
+8.1. Simple Authentication
+
+ The LDAP "simple" authentication choice is not suitable for
+ authentication in environments where there is no network or
+ transport layer confidentiality. LDAP implementations SHOULD support
+ authentication with the "simple" authentication choice when the
+ connection is protected against eavesdropping using TLS, as defined
+ in section 5. LDAP implementations SHOULD NOT support authentication
+ with the "simple" authentication choice unless the data on the
+ connection is protected using TLS or other data confidentiality and
+ data integrity protection.
+
+8.2. Digest Authentication
+
+ LDAP servers that implement any password-based authentication method
+ MUST support authentication with a password using the DIGEST-MD5
+ SASL mechanism for password protection.
+
+ An LDAP client MAY determine whether the server supports this
+ mechanism by performing a search request on the root DSE, requesting
+ the supportedSASLMechanisms attribute, and checking whether the
+ string "DIGEST-MD5" is present as a value of this attribute.
+
+ In the first stage of authentication, when the client is performing
+ an "initial authentication" as defined in section 2.1 of [RFC2831],
+ the client sends a bind request in which the version number is 3,
+ the authentication choice is sasl, the sasl mechanism name is
+ "DIGEST-MD5", and the credentials are absent. The client then waits
+ for a response from the server to this request.
+
+ The server will respond with a bind response in which the resultCode
+ is saslBindInProgress, and the serverSaslCreds field is present. The
+ contents of this field is a string defined by "digest-challenge" in
+ section 2.1.1 of [RFC2831]. The server SHOULD include a realm
+ indication and MUST indicate support for UTF-8.
+
+ The client will send a bind request with a distinct message id, in
+ which the version number is 3, the authentication choice is sasl,
+ the sasl mechanism name is "DIGEST-MD5", and the credentials contain
+ the string defined by "digest-response" in section 2.1.2 of
+ [RFC2831]. The serv-type is "ldap".
+
+ The server will respond with a bind response in which the resultCode
+ is either success, or an error indication. If the authentication is
+ successful and the server does not support subsequent
+
+Harrison Expires September 2003 [Page 16]
+\f
+ Authentication Methods for LDAPv3
+
+ authentication, then the credentials field is absent. If the
+ authentication is successful and the server supports subsequent
+ authentication, then the credentials field contains the string
+ defined by "response-auth" in section 2.1.3 of [RFC2831]. Support
+ for subsequent authentication is OPTIONAL in clients and servers.
+
+8.3. "simple" authentication choice under TLS encryption
+
+ Following the negotiation of an appropriate TLS ciphersuite
+ providing connection confidentiality [RFC2246], a client MAY
+ authenticate to a directory that supports the simple authentication
+ choice by performing a simple bind operation.
+
+ The client will use the Start TLS operation [Protocol] to negotiate
+ the use of TLS security [RFC2246] on the connection to the LDAP
+ server. The client need not have bound to the directory beforehand.
+
+ For this authentication procedure to be successful, the client and
+ server MUST negotiate a ciphersuite which contains a bulk encryption
+ algorithm of appropriate strength. Recommendations on cipher suites
+ are given in section 10.
+
+ Following the successful completion of TLS negotiation, the client
+ MUST send an LDAP bind request with the version number of 3, the
+ name field containing a DN, and the "simple" authentication choice,
+ containing a password.
+
+8.3.1. "simple" Authentication Choice
+
+ DSAs that map the DN sent in the bind request to a directory entry
+ with an associated set of one or more passwords will compare the
+ presented password to the set of passwords associated with that
+ entry. If there is a match, then the server will respond with
+ resultCode success, otherwise the server will respond with
+ resultCode invalidCredentials.
+
+8.4. Other authentication choices with TLS
+
+ It is also possible, following the negotiation of TLS, to perform a
+ SASL authentication that does not involve the exchange of plaintext
+ reusable passwords. In this case the client and server need not
+ negotiate a ciphersuite that provides confidentiality if the only
+ service required is data integrity.
+
+9. Certificate-based authentication
+
+ LDAP server implementations SHOULD support authentication via a
+ client certificate in TLS, as defined in section 5.2.2.
+
+9.1. Certificate-based authentication with TLS
+
+ A user who has a public/private key pair in which the public key has
+ been signed by a Certification Authority may use this key pair to
+ authenticate to the directory server if the user's certificate is
+
+Harrison Expires September 2003 [Page 17]
+\f
+ Authentication Methods for LDAPv3
+
+ requested by the server. The user's certificate subject field SHOULD
+ be the name of the user's directory entry, and the Certification
+ Authority that issued the user's certificate must be sufficiently
+ trusted by the directory server in order for the server to process
+ the certificate. The means by which servers validate certificate
+ paths is outside the scope of this document.
+
+ A server MAY support mappings for certificates in which the subject
+ field name is different from the name of the user's directory entry.
+ A server which supports mappings of names MUST be capable of being
+ configured to support certificates for which no mapping is required.
+
+ The client will use the Start TLS operation [Protocol] to negotiate
+ the use of TLS security [RFC2246] on the connection to the LDAP
+ server. The client need not have bound to the directory beforehand.
+
+ In the TLS negotiation, the server MUST request a certificate. The
+ client will provide its certificate to the server, and the server
+ MUST perform a private key-based encryption, proving it has the
+ private key associated with the certificate.
+
+ In deployments that require protection of sensitive data in transit,
+ the client and server MUST negotiate a ciphersuite that contains a
+ bulk encryption algorithm of appropriate strength. Recommendations
+ of cipher suites are given in section 10.
+
+ The server MUST verify that the client's certificate is valid. The
+ server will normally check that the certificate is issued by a known
+ certification authority (CA), and that none of the certificates on
+ the client's certificate chain are invalid or revoked. There are
+ several procedures by which the server can perform these checks.
+
+ Following the successful completion of TLS negotiation, the client
+ will send an LDAP bind request with the SASL "EXTERNAL" mechanism.
+
+10. TLS Ciphersuites
+
+ The following ciphersuites defined in [RFC2246] MUST NOT be used for
+ confidentiality protection of passwords or data:
+
+ TLS_NULL_WITH_NULL_NULL
+ TLS_RSA_WITH_NULL_MD5
+ TLS_RSA_WITH_NULL_SHA
+
+ The following ciphersuites defined in [RFC2246] can be cracked
+ easily (less than a day of CPU time on a standard CPU in 2000).
+ These ciphersuites are NOT RECOMMENDED for use in confidentiality
+ protection of passwords or data. Client and server implementers
+ SHOULD carefully consider the value of the password or data being
+ protected before using these ciphersuites:
+
+ TLS_RSA_EXPORT_WITH_RC4_40_MD5
+ TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
+ TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
+
+Harrison Expires September 2003 [Page 18]
+\f
+ Authentication Methods for LDAPv3
+
+ TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA
+ TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA
+ TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
+ TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
+ TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
+ TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
+
+ The following ciphersuites are vulnerable to man-in-the-middle
+ attacks, and SHOULD NOT be used to protect passwords or sensitive
+ data, unless the network configuration is such that the danger of a
+ man-in-the-middle attack is tolerable:
+
+ TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
+ TLS_DH_anon_WITH_RC4_128_MD5
+ TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
+ TLS_DH_anon_WITH_DES_CBC_SHA
+ TLS_DH_anon_WITH_3DES_EDE_CBC_SHA
+
+ A client or server that supports TLS MUST support
+ TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA and MAY support other ciphersuites
+ offering equivalent or better protection.
+
+11. Security Considerations
+
+ Security issues are discussed throughout this memo; the
+ (unsurprising) conclusion is that mandatory security is important
+ and that session confidentiality protection is required when
+ snooping is a problem.
+
+ Servers are encouraged to prevent modifications by anonymous users.
+ Servers may also wish to minimize denial of service attacks by
+ timing out idle connections, and returning the unwillingToPerform
+ result code rather than performing computationally expensive
+ operations requested by unauthorized clients.
+
+ Operational experience shows that clients can misuse unauthenticated
+ access (simple bind with name but no password). For this reason,
+ servers SHOULD by default reject authentication requests that have a
+ DN with an empty password with an error of invalidCredentials.
+
+ Access control SHOULD be applied when reading sensitive information
+ or updating directory information.
+
+ A connection on which the client has not performed the Start TLS
+ operation or negotiated a suitable SASL mechanism for connection
+ integrity and encryption services is subject to man-in-the-middle
+ attacks to view and modify information in transit.
+
+11.1. Start TLS Security Considerations
+
+ The goals of using the TLS protocol with LDAP are to ensure
+ connection confidentiality and integrity, and to optionally provide
+ for authentication. TLS expressly provides these capabilities, as
+ described in [RFC2246].
+
+Harrison Expires September 2003 [Page 19]
+\f
+ Authentication Methods for LDAPv3
+
+
+ All security gained via use of the Start TLS operation is gained by
+ the use of TLS itself. The Start TLS operation, on its own, does not
+ provide any additional security.
+
+ Once established, TLS only provides for and ensures confidentiality
+ and integrity of the operations and data in transit over the LDAP
+ association--and only if the implementations on the client and
+ server support and negotiate it. The use of TLS does not provide or
+ ensure for confidentiality and/or non-repudiation of the data housed
+ by an LDAP-based directory server. Nor does it secure the data from
+ inspection by the server administrators.
+
+ The level of security provided though the use of TLS depends
+ directly on both the quality of the TLS implementation used and the
+ style of usage of that implementation. Additionally, an active-
+ intermediary attacker can remove the Start TLS extended operation
+ from the supportedExtension attribute of the root DSE. Therefore,
+ both parties SHOULD independently ascertain and consent to the
+ security level achieved once TLS is established and before beginning
+ use of the TLS connection. For example, the security level of the
+ TLS connection might have been negotiated down to plaintext.
+
+ Clients SHOULD either warn the user when the security level achieved
+ does not provide confidentiality and/or integrity protection, or be
+ configurable to refuse to proceed without an acceptable level of
+ security.
+
+ Client and server implementors SHOULD take measures to ensure proper
+ protection of credentials and other confidential data where such
+ measures are not otherwise provided by the TLS implementation.
+
+ Server implementors SHOULD allow for server administrators to elect
+ whether and when connection confidentiality and/or integrity is
+ required, as well as elect whether and when client authentication
+ via TLS is required.
+
+ Additional security considerations relating to the EXTERNAL
+ mechanism to negotiate TLS can be found in [RFC2222] and [RFC2246].
+
+
+12. Acknowledgements
+
+ This document combines information originally contained in RFC 2829
+ and RFC 2830. The author acknowledges the work of Harald Tveit
+ Alvestrand, Jeff Hodges, Tim Howes, Steve Kille, RL "Bob" Morgan ,
+ and Mark Wahl, each of whom authored one or more of these documents.
+ RFC 2829 and RFC 2830 were products of the IETF LDAPEXT Working
+ Group. RFC 2251 was a product of the ASID Working Group.
+
+ This document is based upon input of the IETF LDAP Revision working
+ group. The contributions of its members is greatly appreciated.
+
+13. Normative References
+
+Harrison Expires September 2003 [Page 20]
+\f
+ Authentication Methods for LDAPv3
+
+
+ [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2222] Myers, J., "Simple Authentication and Security Layer
+ (SASL)", draft-myers-saslrev-xx.txt, a work in progress.
+
+ [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [RFC2246] Dierks, T. and C. Allen. "The TLS Protocol Version 1.0",
+ RFC 2246, January 1999.
+
+ [RFC2831] Leach, P. and C. Newman, "Using Digest Authentication as
+ a SASL Mechanism", RFC 2831, May 2000.
+
+ [LDAPDN] Zeilenga, Kurt D. (editor), "LDAP: String Representation of
+ Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work in
+ progress.
+
+ [Protocol] Sermersheim, J., "LDAP: The Protocol", draft-ietf-
+ ldapbis-protocol-xx.txt, a work in progress.
+
+ [ROADMAP] K. Zeilenga, "LDAP: Technical Specification Road Map",
+ draft-ietf-ldapbis-roadmap-xx.txt, a work in progress.
+
+14. Informative References
+
+ [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, May
+ 2000.
+
+ [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
+ Internet Protocol", RFC 2401, November 1998.
+
+
+15. Author's Address
+
+ Roger Harrison
+ Novell, Inc.
+ 1800 S. Novell Place
+ Provo, UT 84606
+ +1 801 861 2642
+ roger_harrison@novell.com
+
+16. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2000). 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
+
+Harrison Expires September 2003 [Page 21]
+\f
+ Authentication Methods for LDAPv3
+
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 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.
+
+Appendix A. Example Deployment Scenarios
+
+ The following scenarios are typical for LDAP directories on the
+ Internet, and have different security requirements. (In the
+ following discussion, "sensitive data" refers to information whose
+ disclosure, alteration, destruction, or loss would adversely affect
+ the interests or business of its owner or user. Also note that there
+ may be data that is protected but not sensitive.) This is not
+ intended to be a comprehensive list; other scenarios are possible,
+ especially on physically protected networks.
+
+ (1) A read-only directory, containing no sensitive data, accessible
+ to "anyone", and TCP connection hijacking or IP spoofing is not
+ a problem. Anonymous authentication, described in section 7, is
+ suitable for this type of deployment, and requires no additional
+ security functions except administrative service limits.
+
+ (2) A read-only directory containing no sensitive data; read access
+ is granted based on identity. TCP connection hijacking is not
+ currently a problem. This scenario requires data confidentiality
+ for sensitive authentication information AND data integrity for
+ all authentication information.
+
+ (3) A read-only directory containing no sensitive data; and the
+ client needs to ensure the identity of the directory server and
+ that the directory data is not modified while being returned
+ from the server. A data origin authentication service AND data
+ integrity service are required.
+
+ (4) A read-write directory, containing no sensitive data; read
+ access is available to "anyone", update access to properly
+ authorized persons. TCP connection hijacking is not currently a
+ problem. This scenario requires data confidentiality for
+ sensitive authentication information AND data integrity for all
+ authentication information.
+
+
+Harrison Expires September 2003 [Page 22]
+\f
+ Authentication Methods for LDAPv3
+
+ (5) A directory containing sensitive data. This scenario requires
+ data confidentiality protection AND secure authentication.
+
+Appendix B. Authentication and Authorization: Definitions and Concepts
+
+ This appendix defines basic terms, concepts, and interrelationships
+ regarding authentication, authorization, credentials, and identity.
+ These concepts are used in describing how various security
+ approaches are utilized in client authentication and authorization.
+
+B.1. Access Control Policy
+
+ An access control policy is a set of rules defining the protection
+ of resources, generally in terms of the capabilities of persons or
+ other entities accessing those resources. A common expression of an
+ access control policy is an access control list. Security objects
+ and mechanisms, such as those described here, enable the expression
+ of access control policies and their enforcement. Access control
+ policies are typically expressed in terms of access control
+ attributes as described below.
+
+B.2. Access Control Factors
+
+ A request, when it is being processed by a server, may be associated
+ with a wide variety of security-related factors (section 4.2 of
+ [Protocol]). The server uses these factors to determine whether and
+ how to process the request. These are called access control factors
+ (ACFs). They might include source IP address, encryption strength,
+ the type of operation being requested, time of day, etc. Some
+ factors may be specific to the request itself, others may be
+ associated with the connection via which the request is transmitted,
+ others (e.g. time of day) may be "environmental".
+
+ Access control policies are expressed in terms of access control
+ factors. E.g., a request having ACFs i,j,k can perform operation Y
+ on resource Z. The set of ACFs that a server makes available for
+ such expressions is implementation-specific.
+
+B.3. Authentication, Credentials, Identity
+
+ Authentication credentials are the evidence supplied by one party to
+ another, asserting the identity of the supplying party (e.g. a user)
+ who is attempting to establish an association with the other party
+ (typically a server). Authentication is the process of generating,
+ transmitting, and verifying these credentials and thus the identity
+ they assert. An authentication identity is the name presented in a
+ credential.
+
+ There are many forms of authentication credentials -- the form used
+ depends upon the particular authentication mechanism negotiated by
+ the parties. For example: X.509 certificates, Kerberos tickets,
+ simple identity and password pairs. Note that an authentication
+ mechanism may constrain the form of authentication identities used
+ with it.
+
+Harrison Expires September 2003 [Page 23]
+\f
+ Authentication Methods for LDAPv3
+
+
+B.4. Authorization Identity
+
+ An authorization identity is one kind of access control factor. It
+ is the name of the user or other entity that requests that
+ operations be performed. Access control policies are often expressed
+ in terms of authorization identities; e.g., entity X can perform
+ operation Y on resource Z.
+
+ The authorization identity bound to an association is often exactly
+ the same as the authentication identity presented by the client, but
+ it may be different. SASL allows clients to specify an authorization
+ identity distinct from the authentication identity asserted by the
+ client's credentials. This permits agents such as proxy servers to
+ authenticate using their own credentials, yet request the access
+ privileges of the identity for which they are proxying [RFC2222].
+ Also, the form of authentication identity supplied by a service like
+ TLS may not correspond to the authorization identities used to
+ express a server's access control policy, requiring a server-
+ specific mapping to be done. The method by which a server composes
+ and validates an authorization identity from the authentication
+ credentials supplied by a client is implementation-specific.
+
+Appendix C. RFC 2829 Change History
+
+ This appendix lists the changes made to the text of RFC 2829 in
+ preparing this document.
+
+C.0. General Editorial Changes
+ Version -00
+
+ - Changed other instances of the term LDAP to LDAPv3 where v3 of
+ the protocol is implied. Also made all references to LDAPv3 use
+ the same wording.
+
+ - Miscellaneous grammatical changes to improve readability.
+
+ - Made capitalization in section headings consistent.
+
+ Version -01
+
+ - Changed title to reflect inclusion of material from RFC 2830 and
+ 2251.
+
+C.1. Changes to Section 1
+
+ Version -01
+
+ - Moved conventions used in document to a separate section.
+
+C.2. Changes to Section 2
+
+ Version -01
+
+
+Harrison Expires September 2003 [Page 24]
+\f
+ Authentication Methods for LDAPv3
+
+ - Moved section to an appendix.
+
+C.3. Changes to Section 3
+
+ Version -01
+
+ - Moved section to an appendix.
+
+C.4 Changes to Section 4
+
+ Version -00
+
+ - Changed "Distinguished Name" to "LDAP distinguished name".
+
+C.5. Changes to Section 5
+
+ Version -00
+
+ - Added the following sentence: "Servers SHOULD NOT allow clients
+ with anonymous authentication to modify directory entries or
+ access sensitive information in directory entries."
+
+C.5.1. Changes to Section 5.1
+
+ Version -00
+
+ - Replaced the text describing the procedure for performing an
+ anonymous bind (protocol) with a reference to section 4.2 of RFC
+ 2251 (the protocol spec).
+
+ Version -01
+
+ - Brought text describing procedure for performing an anonymous
+ bind from section 4.2 of RFC 2251 bis. This text will be
+ removed from the draft standard version of that document.
+
+C.6. Changes to Section 6.
+
+ Version -00
+
+ Reorganized text in section 6.1 as follows:
+
+ 1. Added a new section (6.1) titled "Simple Authentication" and
+ moved one of two introductory paragraphs for section 6 into
+ section 6.1. Added sentences to the paragraph indicating:
+
+ a. simple authentication is not suitable for environments where
+ confidentiality is not available.
+
+ b. LDAP implementations SHOULD NOT support simple
+ authentication unless confidentiality and data integrity
+ mechanisms are in force.
+
+
+
+Harrison Expires September 2003 [Page 25]
+\f
+ Authentication Methods for LDAPv3
+
+ 2. Moved first paragraph of section 6 (beginning with "LDAP
+ implementations MUST support authentication with a passwordà")
+ to section on Digest Authentication (Now section 6.2).
+
+C.6.1. Changes to Section 6.1.
+
+ Version -00 Renamed section to 6.2
+
+ - Added sentence from original section 6 indicating that the
+ DIGEST-MD5 SASL mechanism is required for all conforming LDAPv3
+ implementations
+
+C.6.2. Changes to Section 6.2
+
+ Version -00
+
+ - Renamed section to 6.3
+
+ - Reworded first paragraph to remove reference to user and the
+ userPassword password attribute Made the first paragraph more
+ general by simply saying that if a directory supports simple
+ authentication that the simple bind operation MAY performed
+ following negotiation of a TLS ciphersuite that supports
+ confidentiality.
+
+ - Replaced "the name of the user's entry" with "a DN" since not
+ all bind operations are performed on behalf of a "user."
+
+ - Added Section 6.3.1 heading just prior to paragraph 5.
+
+ - Paragraph 5: replaced "The server" with "DSAs that map the DN
+ sent in the bind request to a directory entry with a
+ userPassword attribute."
+
+C.6.3. Changes to section 6.3.
+
+ Version -00
+
+ - Renamed to section 6.4.
+
+C.7. Changes to section 7.
+
+ none
+
+C.7.1. Changes to section 7.1.
+
+ Version -00
+
+ - Clarified the entity issuing a certificate by moving the phrase
+ "to have issued the certificate" immediately after
+ "Certification Authority."
+
+C.8. Changes to section 8.
+
+
+Harrison Expires September 2003 [Page 26]
+\f
+ Authentication Methods for LDAPv3
+
+ Version -00
+
+ - Removed the first paragraph because simple authentication is
+ covered explicitly in section 6.
+
+ - Added section 8.1. heading just prior to second paragraph.
+
+ - Added section 8.2. heading just prior to third paragraph.
+
+ - Added section 8.3. heading just prior to fourth paragraph.
+
+ Version -01
+
+ - Moved entire section 8 of RFC 2829 into section 3.4 (Using SASL
+ for Other Security Services) to bring material on SASL
+ mechanisms together into one location.
+
+C.9. Changes to section 9.
+
+ Version -00
+
+ - Paragraph 2: changed "EXTERNAL mechanism" to "EXTERNAL SASL
+ mechanism."
+
+ - Added section 9.1. heading.
+
+ - Modified a comment in the ABNF from "unspecified userid" to
+ "unspecified authz id".
+
+ - Deleted sentence, "A utf8string is defined to be the UTF-8
+ encoding of one or more ISO 10646 characters," because it is
+ redundant.
+
+ - Added section 9.1.1. heading.
+
+ - Added section 9.1.2. heading.
+
+ Version -01
+
+ - Moved entire section 9 to become section 3.5 so that it would be
+ with other SASL material.
+
+C.10. Changes to Section 10.
+
+ Version -00
+
+ - Updated reference to cracking from a week of CPU time in 1997 to
+ be a day of CPU time in 2000.
+
+ - Added text: "These ciphersuites are NOT RECOMMENDED for use...
+ and server implementers SHOULD" to sentence just prior the
+ second list of ciphersuites.
+
+
+
+Harrison Expires September 2003 [Page 27]
+\f
+ Authentication Methods for LDAPv3
+
+ - Added text: "and MAY support other ciphersuites offering
+ equivalent or better protection," to the last paragraph of the
+ section.
+
+C.11. Changes to Section 11.
+
+ Version -01
+
+ - Moved to section 3.6 to be with other SASL material.
+
+C.12. Changes to Section 12.
+
+ Version -00
+
+ - Inserted new section 12 that specifies when SASL protections
+ begin following SASL negotiation, etc. The original section 12
+ is renumbered to become section 13.
+
+ Version -01
+
+ - Moved to section 3.7 to be with other SASL material.
+
+C.13. Changes to Section 13 (original section 12).
+
+ None
+
+Appendix D. RFC 2830 Change History
+
+ This appendix lists the changes made to the text of RFC 2830 in
+ preparing this document.
+
+D.0. General Editorial Changes
+
+ - Material showing the PDUs for the Start TLS response was broken
+ out into a new section.
+
+ - The wording of the definition of the Start TLS request and Start
+ TLS response was changed to make them parallel. NO changes were
+ made to the ASN.1 definition or the associated values of the
+ parameters.
+
+ - A separate section heading for graceful TLS closure was added
+ for parallelism with section on abrupt TLS closure.
+
+Appendix E. RFC 2251 Change History
+
+ This appendix lists the changes made to the text of RFC 2251 in
+ preparing this document.
+
+E.0. General Editorial Changes
+
+ - All material from section 4.2 of RFC 2251 was moved into this
+ document.
+
+
+Harrison Expires September 2003 [Page 28]
+\f
+ Authentication Methods for LDAPv3
+
+ - A new section was created for the Bind Request
+
+ - Section 4.2.1 of RFC 2251 (Sequencing Bind Request) was moved
+ after the section on the Bind Response for parallelism with the
+ presentation of the Start TLS operations. The section was also
+ subdivided to explicitly call out the various effects being
+ described within it.
+
+ - All SASL profile information from RFC 2829 was brought within
+ the discussion of the Bind operation (primarily sections 4.4 -
+ 4.7).
+
+Appendix F. Change History to Combined Document
+
+F.1. Changes for draft-ldap-bis-authmeth-02
+
+ General
+
+ - Added references to other LDAP standard documents, to sections
+ within the document, and fixed broken references.
+
+ - General editorial changesùpunctuation, spelling, formatting,
+ etc.
+
+ Section 1.
+
+ - Added glossary of terms and added sub-section headings
+
+ Section 2.
+
+ - Clarified security mechanisms 3, 4, & 5 and brought language in
+ line with IETF security glossary.
+
+ Section 3.
+
+ - Brought language in requirement (3) in line with security
+ glossary.
+
+ - Clarified that information fetched prior to initiation of TLS
+ negotiation must be discarded
+
+ -Clarified that information fetched prior to initiation of SASL
+ negotiation must be discarded
+
+ - Rewrote paragraph on SASL negotiation requirements to clarify
+ intent
+
+ Section 4.4.
+
+ - Added stipulation that sasl choice allows for any SASL mechanism
+ not prohibited by this document. (Resolved conflict between this
+ statement and one that prohibited use of ANONYMOUS and PLAIN
+ SASL mechanisms.)
+
+
+Harrison Expires September 2003 [Page 29]
+\f
+ Authentication Methods for LDAPv3
+
+ Section 5.3.6
+
+ - Added a.x.bar.com to wildcard matching example on hostname
+ check.
+
+ Section 6
+
+ - Added LDAP Association State Transition Tables to show the
+ various states through which an LDAP association may pass along
+ with the actions and decisions required to traverse from state
+ to state.
+
+ Appendix A
+
+ - Brought security terminology in line with IETF security glossary
+ throughout the appendix.
+
+F.2. Changes for draft-ldap-bis-authmeth-03
+
+ General
+
+ - Added introductory notes and changed title of document and
+ references to conform to WG chair suggestions for the overall
+ technical specification.
+
+ - Several issues--G.13, G.14, G.16, G.17--were resolved without
+ requiring changes to the document.
+
+ Section 3
+
+ - Removed reference to /etc/passwd file and associated text.
+
+ Section 4
+
+ - Removed sections 4.1, 4.2 and parts of section 4.3. This
+ information was being duplicated in the protocol specification
+ and will now reside there permanently.
+ Section 4.2
+
+ - changed words, "not recommended" to "strongly discouraged"
+
+ Section 4.3
+
+ - Based on ldapbis WG discussion at IETF52 two sentences were
+ added indicating that clients SHOULD NOT send a DN value when
+ binding with the sasl choice and servers SHALL ignore any value
+ received in this circumstance.
+ -
+
+ Section 8.3.1
+
+ - Generalized the language of this section to not refer to any
+ specific password attribute or to refer to the directory entry
+ as a "user" entry.
+
+Harrison Expires September 2003 [Page 30]
+\f
+ Authentication Methods for LDAPv3
+
+
+ Section 11
+
+ - Added security consideration regarding misuse of unauthenticated
+ access.
+
+ - Added security consideration requiring access control to be
+ applied only to authenticated users and recommending it be
+ applied when reading sensitive information or updating directory
+ information.
+
+
+F.3. Changes for draft-ldap-bis-authmeth-04
+
+ General
+
+ - Changed references to use [RFCnnnn] format wherever possible.
+ (References to works in progress still use [name] format.)
+ - Various edits to correct typos and bring field names, etc. in
+ line with specification in [Protocol] draft.
+
+ - Several issues--G.13, G.14, G.16, G.17--were resolved without
+ requiring changes to the document.
+
+ Section 4.4.1.
+
+ - Changed ABNF grammar to use productions that are like those in
+ the model draft.
+
+ Section 5
+
+ - Removed sections 5.1, 5.2, and 5.4 that will be added to
+ [Protocol]. Renumbered sections to accommodate this change.
+ -
+
+ Section 6
+
+ - Reviewed LDAP Association State table for completeness and
+ accuracy. Renumbered actions A3, A4, and A5 to be A5, A3, and A4
+ respectively. Re-ordered several lines in the table to ensure
+ that actions are in ascending order (makes analyzing the table
+ much more logical). Added action A2 to several states where it
+ was missing and valid. Added actions A7 and A8 placeholders to
+ states S1, S2, S4 and S5 pending resolution of issue G.28.
+
+ Section 11
+
+ - Modified security consideration (originally added in -03)
+ requiring access control to be applied only to authenticated
+ users. This seems nonsensical because anonymous users may have
+ access control applied to limit permissible actions.
+ -
+ Section 13
+
+
+Harrison Expires September 2003 [Page 31]
+\f
+ Authentication Methods for LDAPv3
+
+ - Verified all normative references and moved informative
+ references to a new section 14.
+
+F.4. Changes for draft-ldap-bis-authmeth-05
+
+ General
+
+ - General editory changes to fix punctuation, spelling, line
+ length issues, etc.
+ - Verified and updated intra- and inter-document references
+ throughout.
+ - Document-wide review for proper usage of RFC 2119 keywords with
+ several changes to correct improper usage.
+
+ Abstract
+ - Updated to match current contents of documents. This was needed
+ due to movement of material on Bind and Start TLS operations to
+ [Protocol] in this revision.
+
+ Section 3.
+
+ - Renamed section to "Rationale for LDAPv3 Security Mechanisms"
+ and removed text that did not support this theme. Part of the
+ motivation for this change was to remove the implication of the
+ previous section title, "Required Security Mechanisms", and
+ other text found in the section that everything in the section
+ was a requirement
+
+ - Information from several removed paragraphs that describe
+ deployment scenarios will be added Appendix A in the next
+ revision of the draft.
+
+
+ - Paragraph beginning, " If TLS is negotiated, the client MUST
+ discard all information..." was moved to section 5.1.7 and
+ integrated with related material there.
+
+ - Paragraph beginning, "If a SASL security layer is negotiated..."
+ was moved to section 4.2
+
+ Section 4.l.
+
+ - Changed wording of first paragraph to clarify meaning.
+
+ Section 4.2.
+ - Added paragraph from section 3 of -04 beginning, "If a SASL
+ security layer is negotiated..."
+
+ Section 4.3.3.
+ - Renamed to "Other SASL Mechanisms" and completely rewrote the
+ section (one sentence) to generalize the treatment of SASL
+ mechanisms not explicitly mentioned in this document.
+
+ Section 4.4.1.
+
+Harrison Expires September 2003 [Page 32]
+\f
+ Authentication Methods for LDAPv3
+
+
+ - Added paragraph beginning, "The dnAuthzID choice allows client
+ applications..." to clarify whether DN form authorization
+ identities have to also have a corresponding directory entry.
+ This change was based on editor's perception of WG consensus.
+
+ - Made minor clarifying edits in the paragraph beginning, "The
+ uAuthzID choice allows for compatibility..."
+
+ Section 5.1.1.
+
+ - Made minor clarifying edits in the last paragraph of the
+ section.
+
+ Section 5.1.7.
+
+ - Wording from section 3 paragraph beginning " If TLS is
+ negotiated, the client MUST discard all information..." was
+ moved to this section and integrated with existing text.
+
+ Section 5.2.
+
+ - Changed usage of "TLS connection" to "TLS session" throughout.
+
+ - Removed empty section 5.2.1 and renumbered sections it had
+ previously contained.
+
+ Section 8.
+
+ - Added introductory paragraph at beginning of section.
+
+ Section 8.1.
+
+ - Changed term "data privacy" to "data confidentiality" to be
+ consistent with usage in rest of document.
+
+ Section 8.2.
+
+ - Changed first paragraph to require implementations that
+ implement *password-based* authentication to implement and
+ support DIGEST-MD5 SASL authentication.
+
+ Section 11.
+
+ - First paragraph: changed "session encryption" to "session
+ confidentiality protection" to be consistent with usage in rest
+ of document.
+
+ Appendix A.
+
+ - Began changes to incorporate information on deployment scenarios
+ removed from section 3.
+
+
+
+Harrison Expires September 2003 [Page 33]
+\f
+ Authentication Methods for LDAPv3
+
+Appendix G. Issues to be Resolved
+
+ This appendix lists open questions and issues that need to be
+ resolved before work on this document is deemed complete.
+
+G.1.
+
+ Section 1 lists 6 security mechanisms that can be used by LDAP
+ servers. I'm not sure what mechanism 5, "Resource limitation by
+ means of administrative limits on service controls" means.
+
+ Status: resolved. Changed wording to "administrative service limits"
+ to clarify meaning.
+
+G.2.
+
+ Section 2 paragraph 1 defines the term, "sensitive." Do we want to
+ bring this term and other security-related terms in alignment with
+ usage with the IETF security glossary (RFC 2828)?
+
+ Status: resolved. WG input at IETF 51 was that we should do this, so
+ the appropriate changes have been made.
+
+G.3.
+
+ Section 2, deployment scenario 2: What is meant by the term "secure
+ authentication function?"
+
+ Status: resolved. Based on the idea that a "secure authentication
+ function" could be provided by TLS, I changed the wording to require
+ data confidentiality for sensitive authentication information and
+ data integrity for all authentication information.
+
+G.4.
+
+ Section 3, deployment scenario 3: What is meant by the phrase,
+ "directory data is authenticated by the server?"
+
+ Status: resolved. I interpreted this to mean the ability to ensure
+ the identity of the directory server and the integrity of the data
+ sent from that server to the client, and explictly stated such.
+
+G.5.
+
+ Section 4 paragraph 3: What is meant by the phrase, "this means that
+ either this data is useless for faking authentication (like the Unix
+ "/etc/passwd" file format used to be)?"
+
+ Status: resolved. Discussion at IETF 52 along with discussions with
+ the original authors of this material have convinced us that this
+ reference is simply too arcane to be left in place. In -03 the text
+ has been modified to focus on the need to either update password
+ information in a protected fashion outside of the protocol or to
+
+
+Harrison Expires September 2003 [Page 34]
+\f
+ Authentication Methods for LDAPv3
+
+ update it in session well protected against snooping, and the
+ reference to /etc/passwd has been removed.
+
+G.6.
+
+ Section 4 paragraph 7 begins: "For a directory needing session
+ protection..." Is this referring to data confidentiality or data
+ integrity or both?
+
+ Status: resolved. Changed wording to say, "For a directory needing
+ data security (both data integrity and data confidentiality)..."
+
+G.7.
+
+ Section 4 paragraph 8 indicates that "information about the server
+ fetched fetched prior to the TLS negotiation" must be discarded. Do
+ we want to explicitly state that this applies to information fetched
+ prior to the *completion* of the TLS negotiation or is this going
+ too far?
+
+ Status: resolved. Based on comments in the IETF 51 LDAPBIS WG
+ meeting, this has been changed to explicitly state, "fetched prior
+ to the initiation of the TLS negotiation..."
+
+G.8.
+
+ Section 4 paragraph 9 indicates that clients SHOULD check the
+ supportedSASLMechanisms list both before and after a SASL security
+ layer is negotiated to ensure that they are using the best available
+ security mechanism supported mutually by the client and server. A
+ note at the end of the paragraph indicates that this is a SHOULD
+ since there are environments where the client might get a list of
+ supported SASL mechanisms from a different trusted source.
+
+ I wonder if the intent of this could be restated more plainly using
+ one of these two approaches (I've paraphrased for the sake of
+ brevity):
+
+ Approach 1: Clients SHOULD check the supportedSASLMechanisms
+ list both before and after SASL negotiation or clients SHOULD
+ use a different trusted source to determine available supported
+ SASL mechanisms.
+
+ Approach 2: Clients MUST check the supportedSASLMechanisms list
+ both before and after SASL negotiation UNLESS they use a
+ different trusted source to determine available supported SASL
+ mechanisms.
+
+ Status: resolved. WG input at IETF 51 was that Approach 1 was
+ probably best. I ended up keeping the basic structure similar to the
+ original to meet this intent.
+
+G.9.
+
+
+Harrison Expires September 2003 [Page 35]
+\f
+ Authentication Methods for LDAPv3
+
+ Section 6.3.1 states: "DSAs that map the DN sent in the bind request
+ to a directory entry with a userPassword attribute will... compare
+ [each value in the named user's entry]... with the presented
+ password." This implies that this applies only to user entries with
+ userPassword attributes. What about other types of entries that
+ might allow passwords and might store in the password information in
+ other attributes? Do we want to make this text more general?
+
+ Status: resolved in -03 draft by generalizing section 8.3.1 to not
+ refer to any specific password attribute and by removing the term
+ "user" in referring to the directory entry specified by the DN in
+ the bind request.
+
+G.10 userPassword and simple bind
+
+ We need to be sure that we don't require userPassword to be the only
+ attribute used for authenticating via simple bind. (See 2251 sec 4.2
+ and authmeth 6.3.1. Work with Jim Sermersheim on resolution to this.
+ On publication state something like: "This is the specific
+ implementation of what we discussed in our general reorg
+ conversation on the list." (Source: Kurt Zeilenga)
+
+ Status: resolved in -03 draft by generalizing section 8.3.1 to not
+ refer to any specific password attribute and by removing the term
+ "user" in referring to the directory entry specified by the DN in
+ the bind request.
+
+G.11. Meaning of LDAP Association
+
+ The original RFC 2830 uses the term "LDAP association" in describing
+ a connection between an LDAP client and server regardless of the
+ state of TLS on that connection. This term needs to be defined or
+ possibly changed.
+
+ Status: resolved. at IETF 51 Bob Morgan indicated that the term
+ "LDAP association" was intended to distinguish the LDAP-level
+ connection from the TLS-level connection. This still needs to be
+ clarified somewhere in the draft. Added "LDAP association" to a
+ glossary in section 1.
+
+G.12. Is DIGEST-MD5 mandatory for all implementations?
+
+ Reading 2829bis I think DIGEST-MD5 is mandatory ONLY IF your server
+ supports password based authentication...but the following makes it
+ sound mandatory to provide BOTH password authentication AND DIGEST-
+ MD5:
+
+ "6.2. Digest authentication
+
+ LDAP implementations MUST support authentication with a password
+ using the DIGEST-MD5 SASL mechanism for password protection, as
+ defined in section 6.1."
+
+ The thing is for acl it would be nice (though not critical) to be
+
+Harrison Expires September 2003 [Page 36]
+\f
+ Authentication Methods for LDAPv3
+
+ able to default the required authentication level for a subject to a
+ single "fairly secure" mechanism--if there is no such mandatory
+ authentication scheme then you cannot do that. (Source: Rob Byrne)
+
+ Status: resolved. -00 version of the draft added a sentence at the
+ beginning of section 8.2 stating that LDAP server implementations
+ must support this method.
+
+G.13. Ordering of authentication levels requested
+
+ Again on the subject of authentication level, is it possible to
+ define an ordering on authentication levels which defines their
+ relative "strengths" ? This would be useful in acl as you could say
+ things like"a given aci grants access to a given subject at this
+ authentication level AND ABOVE". David Chadwick raised this before
+ in the context of denying access to a subject at a given
+ authentication level, in which case he wanted to express "deny
+ access to this subject at this authentication level AND TO ALL
+ IDENTITIES AUTHENTICATED BELOW THAT LEVEL". (Source: Rob Byrne)
+
+ Status: out of scope. This is outside the scope of this document and
+ will not be addressed.
+
+G.14. Document vulnerabilities of various mechanisms
+
+ While I'm here...in 2829, I think it would be good to have some
+ comments or explicit reference to a place where the security
+ properties of the particular mandatory authentication schemes are
+ outlined. When I say "security properties" I mean stuff like "This
+ scheme is vulnerable to such and such attacks, is only safe if the
+ key size is > 50, this hash is widely considered the best, etc...".
+ I think an LDAP implementor is likely to be interested in that
+ information, without having to wade through the security RFCs.
+ (Source: Rob Byrne)
+
+ Status: out of scope. This is outside the scope of this document and
+ will not be addressed.
+
+G.15. Include a StartTLS state transition table
+
+ The pictoral representation it is nominally based on is here (URL
+ possibly folded):
+
+ http://www.stanford.edu/~hodges/doc/LDAPAssociationStateDiagram-
+ 1999-12-14.html
+
+ (Source: Jeff Hodges)
+
+ Status: In Process. Table provided in -03. Review of content for
+ accuracy in -04. Additional review is needed, plus comments from WG
+ members indicate that additional description of each state's meaning
+ would be helpful.
+
+
+
+Harrison Expires September 2003 [Page 37]
+\f
+ Authentication Methods for LDAPv3
+
+G.16. Empty sasl credentials question
+
+ I spent some more time looking microscopically at ldap-auth-methods
+ and ldap-ext-tls drafts. The drafts say that the credential must
+ have the form dn:xxx or u:xxx or be absent, and although they don't
+ say what to do in the case of an empty octet string I would say that
+ we could send protocolError (claim it is a bad PDU).
+
+ There is still the question of what to do if the credential is 'dn:'
+ (or 'u:') followed by the empty string. (Source: ariel@columbia.edu
+ via Jeff Hodges)
+
+ Status: resolved. Kurt Zeilenga indicated during ldapbis WG
+ discussion at IETF 52 that SASL AuthzID credentials empty and absent
+ are equivalent in the latest SASL ID. This resolves the issue.
+
+G.17. Hostname check from MUST to SHOULD?
+
+ I am uneasy about the hostname check. My experience from PKI with
+ HTTP probably is a contributing factor; we have people using the
+ short hostname to get to a server which naturally has the FQDN in
+ the certificate, no end of problems. I have a certificate on my
+ laptop which has the FQDN for the casse when the system is on our
+ Columbia network with a fixed IP; when I dial in however, I have
+ some horrible dialup name, and using the local https server becomes
+ annoying. Issuing a certificate in the name 'localhost' is not a
+ solution! Wildcard match does not solve this problem. For these
+ reasons I am inclined to argue for 'SHOULD' instead of
+ 'MUST' in paragraph...
+
+ Also, The hostname check against the name in the certificate is a
+ very weak means of preventing man-in-the-middle attacks; the proper
+ solution is not here yet (SecureDNS or some equivalent). Faking out
+ DNS is not so hard, and we see this sort of thing in the press on a
+ pretty regular basis, where site A hijacks the DNS server for site B
+ and gets all their requests. Some mention of this should be made in
+ the draft. (Source: ariel@columbia.edu via Jeff Hodges)
+
+ Status: resolved. Based on discussion at IETF 52 ldapbis WG meeting,
+ this text will stand as it is. The check is a MUST, but the behavior
+ afterward is a SHOULD. This gives server implementations the room to
+ maneuver as needed.
+
+ G.18. Must SASL DN exist in the directory?
+
+ If the 'dn:' form of sasl creds is used, is it the intention of the
+ draft(ers) that this DN must exist in the directory and the client
+ will have the privileges associated with that entry, or can the
+ server map the sasl DN to perhaps some other DN in the directory,
+ in an implementation-dependent fashion?
+
+ We already know that if *no* sasl credentials are presented, the DN
+ or altname in the client certificate may be mapped to a DN in an
+ implementation-dependent fashion, or indeed to something not in the
+
+Harrison Expires September 2003 [Page 38]
+\f
+ Authentication Methods for LDAPv3
+
+ directory at all. (Right?) (Source: ariel@columbia.edu via Jeff
+ Hodges)
+
+ Status: resolved. (11/12/02)Based on my research I propose that the
+ DN MUST exist in the directory when the DN form of sasl creds is
+ used. I have made this proposal to the ldapbis mailing list.
+
+ (11/21/02) Feedback from mailing list has proposed removing this
+ paragraph entirely because (1) explicit assertion of authorization
+ identity should only be done when proxying (2) mapping of the
+ asserted authorization identity is implementation specific and
+ policy driven [SASL] section 4.2, and (3) keeping this paragraph is
+ not required for interoperability.
+
+G.19. DN used in conjunction with SASL mechanism
+
+ We need to specify whether the DN field in Bind operation can/cannot
+ be used when SASL mechanism is specified. (source: RL Bob)
+
+ Status: resolved. (-03) Based on ldapbis WG discussion at IETF52 two
+ sentences were added to section 4.3 indicating that clients SHOULD
+ NOT send a DN value when binding with the sasl choice and servers
+ SHALL ignore any value received in this circumstance. During edits
+ for -04 version of draft it was noted that [Protocol] section 4.2
+ conflicts with this draft. The editor of [Protocol] has been
+ notified of the discrepancy, and they have been handled.
+
+G.20. Bind states
+
+ Differences between unauthenticated and anonymous. There are four
+ states you can get into. One is completely undefined (this is now
+ explicitly called out in [Protocol]). This text needs to be moved
+ from [Protocol] to this draft. (source: Jim Sermersheim)
+
+ Status: Resolved. There are four states: (1) no name, no password
+ (anon); (2) name, no password (anon); (3) no name, password
+ (invalid); (4) name, password (simple bind). States 1, 2, and 4 are
+ called out in [AuthMeth]. State 3 is called out in [Protocol]; this
+ seems appropriate based on review of alternatives.
+
+G.21. Misuse of unauthenticated access
+
+ Add a security consideration that operational experience shows that
+ clients can misuse unauthenticated access (simple bind with name but
+ no password). Servers SHOULD by default reject authentication
+ requests that have a DN with an empty password with an error of
+ invalidCredentials. (Source: Kurt Zeilenga and Chris Newman (Sun))
+
+ Status: Resolved. Added to security considerations in û03.
+
+G.22. Need to move StartTLS protocol information to [Protocol]
+
+ Status: Resolved. Removed Sections 5.1, 5.2, and 5.4 for -04 and
+ they are [Protocol] -11.
+
+Harrison Expires September 2003 [Page 39]
+\f
+ Authentication Methods for LDAPv3
+
+
+G.23. Split Normative and Non-normative references into separate
+sections.
+
+ Status: Resolved. Changes made in -04
+
+G.24. What is the authentication state if a Bind operation is
+abandoned?
+
+ Status: In process. (11/12/02) This text was suggested to be added
+ to [Protocol] -11 to cover what happens if a bind operation is
+ abandoned:
+
+ "If a server receives an Abandon request for a Bind operation, the
+ server SHOULD leave the connection in the anonymous state. Clients
+ that abandon a Bind operation MUST rebind after abandoning the Bind
+ request in order to have a known authentication state on the
+ connection."
+
+ (11/21/02) Jim Sermersheim prposed the following wording on the
+ ldapbis mail list: "Authentication from earlier binds are
+ subsequently ignored. A failed or abandoned Bind Operation has the
+ effect of leaving the connection in an anonymous state. Clients MUST
+ rebind after abandoning a bind operation in order to determine a
+ known authentication state."
+
+ Once this is resolved in [Protocol] the state table in section 6 of
+ [AuthMeth] will need to be updated to reflect the consensus wording.
+
+G.25. Difference between checking server hostname and server's
+canonical DNS name in Server Identity Check?
+
+ Section 5.1.6: I now understand the intent of the check (prevent
+ man-in-the-middle attacks). But what is the subtle difference
+ between the "server hostname" and the "server's canonical DNS name"?
+ (Source: Tim Hahn)
+
+ Status: In Process. (11/12/02) Sent suggested wording change to this
+ paragraph to the ldapbis mail list and also asked for opinion as to
+ whether we should discuss the distinction between server DNS
+ hostname and server canonical DNS hostname in [AuthMeth].
+
+ (11/21/02): RL Bob Morgan will provide wording that allows
+ derivations of the name that are provided securely.
+
+6.26. Server Identity Check using servers located via SRV records
+
+ Section 5.1.6: What should be done if the server was found using SRV
+ records based on the "locate" draft/RFC? (Source: Tim Hahn).
+
+ Status: Resolved. Section 5 of draft-ietf-ldapext-locate-08
+ specifically calls out how the server identity should be performed
+ if the server is located using the method defined in that draft.
+
+
+Harrison Expires September 2003 [Page 40]
+\f
+ Authentication Methods for LDAPv3
+
+ This is the right location for this information, and the coverage
+ appears to be adequate.
+
+G.27 Inconsistency in effect of TLS closure on LDAP association.
+
+ Section 5.4.1 of authmeth -03 (section 4.1 of RFC2830) states that
+ TLS closure alert will leave the LDAP association intact. Contrast
+ this with Section 5.5.2 (section 5.2 of RFC2830) that says that the
+ closure of the TLS connection MUST cause the LDAP association to
+ move to an anonymous authentication.
+
+ Status: in process. (11/12/02) This is actually a [Protocol] issue
+ because these sections have now been moved to [Protocol] -11. I have
+ proposed the following text for Section 5.4.1 of [AuthMeth] -03
+ (section 4.13.3.1 of [Protocol]) to resolve this apparent
+ discrepancy:
+
+ "Either the client or server MAY terminate the TLS connection on an
+ LDAP association by sending a TLS closure alert. The LDAP
+ connection remains open for further communication after TLS closure
+ occurs although the authentication state of the LDAP connection is
+ affected (see [AuthMeth] section 5.2.2).
+
+ (11/21/02): resolution to this is expected in [Protocol] -12
+
+G.28 Ordering of external sources of authorization identities
+
+ Section 4.3.2 implies that external sources of authorization
+ identities other than TLS are permitted. What is the behavior when
+ two external sources of authentication credentials are available
+ (e.g. TLS and IPsec are both present (is this possible?)) and a SASL
+ EXTERNAL Bind operation is performed?
+
+ Status: resolved. 11/20/02: Resolved by Section 4.2 of [SASL] which
+ states that the decision to allow or disallow the asserted identity
+ is based on an implementation defined policy.
+
+G.29 Rewrite of Section 10, TLS Ciphersuites
+
+ This section contains anachronistic references and needs to be
+ updated/rewritten in a way that provides useful guidance for future
+ readers in a way that will transcend the passage of time.
+
+G.30 Update to Appendix A, Example Deployment Scenarios
+
+ This section needs to be updated to indicate which security
+ mechanisms and/or combinations of security mechanisms described
+ elsewhere in the document can provide the types of protections
+ suggested in this appendix.
+
+
+
+
+
+Harrison Expires September 2003 [Page 41]
+\f
--- /dev/null
+
+
+
+
+
+
+INTERNET-DRAFT Editor: Kurt D. Zeilenga
+Intended Category: Standard Track OpenLDAP Foundation
+Expires in six months 4 May 2003
+Obsoletes: 2253
+
+
+ LDAP: String Representation of Distinguished Names
+ <draft-ietf-ldapbis-dn-10.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
+ replacing RFC 2253. Distribution of this memo is unlimited.
+ Technical discussion of this document will take place on the IETF LDAP
+ Revision (LDAPbis) Working Group mailing list
+ <ietf-ldapbis@openldap.org>. Please send editorial comments directly
+ to the document editor <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
+
+ The X.500 Directory uses distinguished names (DNs) as primary keys to
+ entries in the directory. This document defines the string
+ representation used in the Lightweight Directory Access Protocol
+ (LDAP) to transfer distinguished names. The string representation is
+
+
+
+Zeilenga LDAP: Distinguished Names [Page 1]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
+
+
+ designed to give a clean representation of commonly used distinguished
+ names, while being able to represent any distinguished name.
+
+
+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].
+
+
+1. Background and Intended Usage
+
+ In X.500-based directory systems [X.500], including those accessed
+ using the Lightweight Directory Access Protocol (LDAP) [Roadmap],
+ distinguished names (DNs) are used to unambiguously refer to a
+ directory entry [X.501][Models].
+
+ The structure of a DN [X.501] is described in terms of ASN.1 [X.680].
+ In the X.500 Directory Access Protocol [X.511] (and other ITU-defined
+ directory protocols), DNs are encoded using the Basic Encoding Rules
+ (BER) [X.690]. In LDAP, DNs are represented in string form.
+
+ It is important to have a common format to be able to unambiguously
+ represent a distinguished name. The primary goal of this
+ specification is ease of encoding and decoding. A secondary goal is
+ to have names that are human readable. It is not expected that LDAP
+ implementations with a human user interface would display these
+ strings directly to the user, but would most likely be performing
+ translations (such as expressing attribute type names in one of the
+ local national languages).
+
+ This document defines the string representation of Distinguished Names
+ used in LDAP [Protocol][Syntaxes]. Section 2 details the RECOMMENDED
+ algorithm for converting a DN from its ASN.1 structured representation
+ to a string. Section 3 details how to convert a DN from a string to a
+ ASN.1 structured representation.
+
+ While other documents may define other algorithms for converting a DN
+ from its ASN.1 structured representation to a string, all algorithms
+ MUST produce strings which adhere to the requirements of Section 3.
+
+ This document does not define a canonical string representation for
+ DNs. Comparison of DNs for equality is to be performed in accordance
+ with the distinguishedNameMatch matching rule [Syntaxes].
+
+ This document is an integral part of the LDAP Technical Specification
+ [Roadmap].
+
+
+
+Zeilenga LDAP: Distinguished Names [Page 2]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
+
+
+ This document obsoletes RFC 2253. Changes since RFC 2253 are
+ summarized in Appendix B.
+
+ This specification assumes familiarity with X.500 [X.500], and the
+ concept of Distinguished Name [X.501][Models].
+
+
+2. Converting DistinguishedName from ASN.1 to a String
+
+ X.501 [X.501] defines the ASN.1 [X.680] structure of distinguished
+ name. The following is a variant provided for discussion purposes.
+
+ DistinguishedName ::= RDNSequence
+
+ RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
+
+ RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
+ AttributeTypeAndValue
+
+ AttributeTypeAndValue ::= SEQUENCE {
+ type AttributeType,
+ value AttributeValue }
+
+ This section defines the RECOMMENDED algorithm for converting a
+ distinguished name from an ASN.1 structured representation to an UTF-8
+ [RFC2279] encoded Universal Character Set (UCS) [ISO10646] character
+ string representation. Other documents may describe other algorithms
+ for converting a distinguished name to a string, but only strings
+ which conform to the grammar defined in Section 3 MUST be produced by
+ LDAP implementations.
+
+
+2.1. Converting the RDNSequence
+
+ If the RDNSequence is an empty sequence, the result is the empty or
+ zero length string.
+
+ Otherwise, the output consists of the string encodings of each
+ RelativeDistinguishedName in the RDNSequence (according to Section
+ 2.2), starting with the last element of the sequence and moving
+ backwards toward the first.
+
+ The encodings of adjoining RelativeDistinguishedNames are separated by
+ a comma ("," U+002C) character.
+
+
+2.2. Converting RelativeDistinguishedName
+
+
+
+
+Zeilenga LDAP: Distinguished Names [Page 3]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
+
+
+ When converting from an ASN.1 RelativeDistinguishedName to a string,
+ the output consists of the string encodings of each
+ AttributeTypeAndValue (according to Section 2.3), in any order.
+
+ Where there is a multi-valued RDN, the outputs from adjoining
+ AttributeTypeAndValues are separated by a plus sign ("+" U+002B)
+ character.
+
+
+2.3. Converting AttributeTypeAndValue
+
+ The AttributeTypeAndValue is encoded as the string representation of
+ the AttributeType, followed by an equals ("=" U+003D) character,
+ followed by the string representation of the AttributeValue. The
+ encoding of the AttributeValue is given in Section 2.4.
+
+ If the AttributeType is defined to have a short name and that short
+ name is known to be registered [REGISTRY] as identifying the
+ AttributeType, that short name, a <descr>, is used. Otherwise the
+ AttributeType is encoded as the dotted-decimal encoding, a
+ <numericoid>, of its OBJECT IDENTIFIER. The <descr> and <numericoid>
+ is defined in [Models].
+
+ Implementations are not expected dynamically update their knowledge of
+ registered short names. However, implementations SHOULD provide a
+ mechanism to allow its knowledge of registered short names to be
+ updated.
+
+
+2.4. Converting an AttributeValue from ASN.1 to a String
+
+ If the AttributeType is of the dotted-decimal form, the AttributeValue
+ is represented by an number sign ("#" U+0023) character followed by
+ the hexadecimal encoding of each of the octets of the BER encoding of
+ the X.500 AttributeValue. This form is also used when the syntax of
+ the AttributeValue does not have a native string encoding defined for
+ it or the native string encoding is not restricted to UTF-8 encoded
+ UCS (or a subset of UCS) characters. This form may also be used in
+ other cases, such as when a reversible string representation is
+ desired (see Section 5.2).
+
+ Otherwise, if the AttributeValue is of a syntax which has a native
+ string encoding, the value is converted first to a UTF-8 encoded UCS
+ string according to its syntax specification (see for example Section
+ 6 of [Syntaxes]). If that UTF-8 encoded UCS string does not have any
+ of the following characters which need escaping, then that string can
+ be used as the string representation of the value.
+
+
+
+
+Zeilenga LDAP: Distinguished Names [Page 4]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
+
+
+ - a space (" " U+0020) or number sign ("#" U+0023) occurring at
+ the beginning of the string;
+
+ - a space (" " U+0020) character occurring at the end of the
+ string;
+
+ - one of the characters """, "+", ",", ";", "<", ">", or "\"
+ (U+0022, U+002B, U+002C, U+003B, U+003C, U+003E, or U+005C
+ respectively);
+
+ - the null (U+0000) character.
+
+ Other characters may be escaped.
+
+ Each octet of the character to be escaped is replaced by a backslash
+ and two hex digits, which form a single octet in the code of the
+ character. Alternatively, if and only if the character to be escaped
+ is one of
+
+ " ", """, "#", "+", ",", ";", "<", "=", ">", or "\"
+ (U+0020, U+0022, U+0023, U+002B, U+002C, U+003B,
+ U+003C, U+003D, U+003E, U+005C respectively)
+
+ it can be prefixed by a backslash ("\" U+0005C).
+
+ Examples of the escaping mechanism are shown in Section 4.
+
+
+3. Parsing a String back to a Distinguished Name
+
+ The string representation of Distinguished Names is restricted to
+ UTF-8 [RFC2279] encoded characters from the Universal Character Set
+ (UCS) [ISO10646]. The structure of this string representation is
+ specified using the following Augmented BNF [RFC2234] grammar:
+
+ distinguishedName = [ relativeDistinguishedName
+ *( COMMA relativeDistinguishedName ) ]
+
+ relativeDistinguishedName = attributeTypeAndValue
+ *( PLUS attributeTypeAndValue )
+
+ attributeTypeAndValue = attributeType EQUALS attributeValue
+
+ attributeType = descr / numericoid
+
+ attributeValue = string / hexstring
+
+ ; The UTF-8 string shall not contain NULL, ESC, or
+
+
+
+Zeilenga LDAP: Distinguished Names [Page 5]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
+
+
+ ; one of escaped, shall not start with SHARP or SPACE,
+ ; and shall must not end with SPACE.
+ string = [ (leadchar / pair)
+ [ *( stringchar / pair ) ( trailchar / pair ) ] ]
+
+ leadchar = LUTF1 / UTFMB
+ LUTF1 = %x01-1F / %x21 / %x24-2A / %x2D-3A /
+ %x3D / %x3F-5B / %x5D-7F
+
+ trailchar = TUTF1 / UTFMB
+ TUTF1 = %x01-1F / %x21 / %x23-2A / %x2D-3A /
+ %x3D / %x3F-5B / %x5D-7F
+
+ stringchar = SUTF1 / UTFMB
+ SUTF1 = %x01-21 / %x23-2A / %x2D-3A /
+ %x3D / %x3F-5B / %x5D-7F
+
+ pair = ESC ( ESC / special / hexpair )
+
+ special = escaped / SPACE / SHARP / EQUALS
+
+ escaped = DQUOTE / PLUS / COMMA / SEMI / LANGLE / RANGLE
+
+ hexstring = SHARP 1*hexpair
+
+ hexpair = HEX HEX
+
+ where the productions <descr>, <numericoid>, <COMMA>, <DQUOTE>,
+ <EQUALS>, <ESC>, <HEX>, <LANGLE>, <NULL>, <PLUS>, <RANGLE>, <SEMI>,
+ <SPACE>, <SHARP>, <UTFMB> are defined in [Models].
+
+ Each <attributeType>, either a <descr> or a <numericoid>, refers to an
+ attribute type of an attribute value assertion (AVA). The
+ <attributeType> is followed by a <EQUALS> and an <attributeValue>.
+ The <attributeValue> is either in <string> or <hexstring> form.
+
+ If in <string> form, a LDAP string representation asserted value can
+ be obtained by replacing (left-to-right, non-recursively) each <pair>
+ appearing in the <string> as follows:
+ replace <ESC><ESC> with <ESC>;
+ replace <ESC><special> with <special>;
+ replace <ESC><hexpair> with the octet indicated by the <hexpair>.
+
+ If in <hexstring> form, a BER representation can be obtained from
+ converting each <hexpair> of the <hexstring> to the octet indicated by
+ the <hexpair>.
+
+ One or more attribute values assertions, separated by <PLUS>, for a
+
+
+
+Zeilenga LDAP: Distinguished Names [Page 6]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
+
+
+ relative distinguished name.
+
+ Zero or more relative distinguished names, separated by <COMMA>, for a
+ distinguished name.
+
+ Implementations MUST recognize AttributeType name strings
+ (descriptors) listed in the following table, but MAY recognize other
+ name strings.
+
+ String X.500 AttributeType
+ ------ --------------------------------------------
+ CN commonName (2.5.4.3)
+ L localityName (2.5.4.7)
+ ST stateOrProvinceName (2.5.4.8)
+ O organizationName (2.5.4.10)
+ OU organizationalUnitName (2.5.4.11)
+ C countryName (2.5.4.6)
+ STREET streetAddress (2.5.4.9)
+ DC domainComponent (0.9.2342.19200300.100.1.25)
+ UID userId (0.9.2342.19200300.100.1.1)
+
+ Implementations MAY recognize other DN string representations
+ (such as that described in RFC 1779). However, as there is no
+ requirement that alternative DN string representations to be
+ recognized (and, if so, how), implementations SHOULD only generate
+ DN strings in accordance with Section 2 of this document.
+
+
+4. Examples
+
+ This notation is designed to be convenient for common forms of
+ name. This section gives a few examples of distinguished names
+ written using this notation. First is a name containing three
+ relative distinguished names (RDNs):
+
+ UID=jsmith,DC=example,DC=net
+
+ Here is an example name containing three RDNs, in which the first
+ RDN is multi-valued:
+
+ OU=Sales+CN=J. Smith,DC=example,DC=net
+
+ This example shows the method of escaping of a comma in a common
+ name:
+
+ CN=John Smith\, III,DC=example,DC=net
+
+ An example name in which a value contains a carriage return
+
+
+
+Zeilenga LDAP: Distinguished Names [Page 7]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
+
+
+ character:
+
+ CN=Before\0dAfter,DC=example,DC=net
+
+ An example name in which an RDN was of an unrecognized type. The
+ value is the BER encoding of an OCTET STRING containing two octets
+ 0x48 and 0x69.
+
+ 1.3.6.1.4.1.1466.0=#04024869,DC=example,DC=com
+
+ Finally, an example of an RDN commonName value consisting of 5
+ letters:
+
+ Unicode Letter Description UCS code UTF-8 Escaped
+ ------------------------------- -------- ------ --------
+ LATIN CAPITAL LETTER L U+004C 0x4C L
+ LATIN SMALL LETTER U U+0075 0x75 u
+ LATIN SMALL LETTER C WITH CARON U+010D 0xC48D \C4\8D
+ LATIN SMALL LETTER I U+0069 0x69 i
+ LATIN SMALL LETTER C WITH ACUTE U+0107 0xC487 \C4\87
+
+ could be written in printable ASCII (useful for debugging purposes):
+
+ CN=Lu\C4\8Di\C4\87
+
+
+5. Security Considerations
+
+ The following security considerations are specific to the handling of
+ distinguished names. LDAP security considerations are discussed in
+ [Protocol] and other documents comprising the LDAP Technical
+ Specification [Roadmap].
+
+
+5.1. Disclosure
+
+ Distinguished Names typically consist of descriptive information about
+ the entries they name, which can be people, organizations, devices or
+ other real-world objects. This frequently includes some of the
+ following kinds of information:
+
+ - the common name of the object (i.e. a person's full name)
+ - an email or TCP/IP address
+ - its physical location (country, locality, city, street address)
+ - organizational attributes (such as department name or affiliation)
+
+ Most countries have privacy laws regarding the publication of
+ information about people.
+
+
+
+Zeilenga LDAP: Distinguished Names [Page 8]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
+
+
+5.2. Use of Distinguished Names in Security Applications
+
+ The transformations of an AttributeValue value from its X.501 form to
+ an LDAP string representation are not always reversible back to the
+ same BER (Basic Encoding Rules) or DER (Distinguished Encoding rules)
+ form. An example of a situation which requires the DER form of a
+ distinguished name is the verification of an X.509 certificate.
+
+ For example, a distinguished name consisting of one RDN with one AVA,
+ in which the type is commonName and the value is of the TeletexString
+ choice with the letters 'Sam' would be represented in LDAP as the
+ string CN=Sam. Another distinguished name in which the value is still
+ 'Sam' but of the PrintableString choice would have the same
+ representation CN=Sam.
+
+ Applications which require the reconstruction of the DER form of the
+ value SHOULD NOT use the string representation of attribute syntaxes
+ when converting a distinguished name to the LDAP format. Instead,
+ they SHOULD use the hexadecimal form prefixed by the number sign ('#')
+ as described in the first paragraph of Section 2.3.
+
+
+6. Acknowledgment
+
+ This document is an update to RFC 2253, by Mark Wahl, Tim Howes, and
+ Steve Kille. RFC 2253 was a product of the IETF ASID Working Group.
+
+ This document is a product of the IETF LDAPBIS Working Group.
+
+
+7. Document Editor's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+ <Kurt@OpenLDAP.org>
+
+
+8. Normative References
+
+ [X.501] "The Directory -- Models," ITU-T Rec. X.501(1993).
+
+ [X.680] ITU-T, "Abstract Syntax Notation One (ASN.1) -
+ Specification of Basic Notation", X.680, 1994.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14 (also RFC 2119).
+
+ [RFC2234] Crocker, D., and P. Overell, "Augmented BNF for Syntax
+
+
+
+Zeilenga LDAP: Distinguished Names [Page 9]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
+
+
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 2279, January 1998.
+
+ [Models] K. Zeilenga (editor), "LDAP: Directory Information
+ Models", draft-ietf-ldapbis-models-xx.txt, a work in
+ progress.
+
+ [Roadmap] K. Zeilenga, "LDAP: Technical Specification Road Map",
+ draft-ietf-ldapbis-roadmap-xx.txt, a work in progress.
+
+ [Protocol] J. Sermersheim (editor), "LDAP: The Protocol",
+ draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
+
+ [Syntaxes] S. Legg (editor), "LDAP: Syntaxes",
+ draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
+
+ [Schema] K. Dally (editor), "LDAP: User Schema",
+ draft-ietf-ldapbis-user-schema-xx.txt, a work in
+ progress.
+
+ [ISO10646] Universal Multiple-Octet Coded Character Set (UCS) -
+ Architecture and Basic Multilingual Plane, ISO/IEC
+ 10646-1 : 1993.
+
+
+9. Informative References
+
+ [X.500] "The Directory -- overview of concepts, models and
+ services," ITU-T Rec. X.500(1993).
+
+ [X.690] ITU-T, "Specification of ASN.1 encoding rules: Basic,
+ Canonical, and Distinguished Encoding Rules", X.690,
+ 1994.
+
+ [RFC3383] K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also
+ RFC 3383), September 2002.
+
+ [RFC2849] G. Good, "The LDAP Data Interchange Format (LDIF) -
+ Technical Specification", RFC 2849, June 2000.
+
+
+Appendix A. Presentation Issues
+
+ This appendix is provided for informational purposes only, it is not a
+ normative part of this specification.
+
+
+
+
+Zeilenga LDAP: Distinguished Names [Page 10]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
+
+
+ The string representation described in this document is not intended
+ to be presented to humans without translation. However, at times it
+ may be desirable to present non-translated DN strings to users. This
+ section discusses presentation issues associated with non-translated
+ DN strings. Presentation of translated DN strings issues are not
+ discussed in this appendix. Transcoding issues are also not discussed
+ in this appendix.
+
+ This appendix provides guidance for applications presenting DN strings
+ to users. This section is not comprehensive, it does not discuss all
+ presentation issues which implementors may face.
+
+ Not all user interfaces are capable of displaying the full set of UCS
+ characters. Some UCS characters are not displayable.
+
+ It is recommended that human interfaces use the optional hex pair
+ escaping mechanism (Section 2.3) to produce a string representation
+ suitable for display to the user. For example, an application can
+ generate a DN string for display which escapes all non-printable
+ characters appearing in the AttributeValue's string representation (as
+ demonstrated in the final example of Section 4).
+
+ When a DN string is displayed in free form text, it is often necessary
+ to distinguish the DN string from surrounding text. While this is
+ often done with white space (as demonstrated in Section 4), it is
+ noted that DN strings may end with white space. Careful readers of
+ Section 3 will note that characters "<" (U+003C) and ">" (U+003E) may
+ only appear in the DN string if escaped. These characters are
+ intended to be used in free form text to distinguish a DN string from
+ surrounding text. For example, <CN=Sam\ > distinguished the string
+ representation of the DN comprised of one RDN consisting of the AVA:
+ the commonName (CN) value "Sam " from the surrounding text. It should
+ be noted to the user that the wrapping "<" and ">" characters are not
+ part of the DN string.
+
+ DN strings can be quite long. It is often desirable to line-wrap
+ overly long DN strings in presentations. Line wrapping should be done
+ by inserting white space after the RDN separator character or, if
+ necessary, after the AVA separator character. It should be noted to
+ the user that the inserted white space is not part of the DN string
+ and is to be removed before use in LDAP. For example,
+
+ The following DN string is long:
+ CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores,
+ O=OpenLDAP Foundation,ST=California,C=US
+ so it has been line-wrapped for readability. The extra white
+ space is to be removed before the DN string is used in LDAP.
+
+
+
+
+Zeilenga LDAP: Distinguished Names [Page 11]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
+
+
+ It is not advised to insert white space otherwise as it may not be
+ obvious to the user which white space is part of the DN string and
+ which white space was added for readability.
+
+ Another alternative is to use the LDAP Data Interchange Format (LDIF)
+ [RFC2849]. For example,
+
+ # This entry has a long DN...
+ dn: CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores,
+ O=OpenLDAP Foundation,ST=California,C=US
+ CN: Kurt D. Zeilenga
+ SN: Zeilenga
+ objectClass: person
+
+
+Appendix B. Changes made since RFC 2253
+
+ This appendix is provided for informational purposes only, it is not a
+ normative part of this specification.
+
+ The following substantive changes were made to RFC 2253:
+ - Removed IESG Note. The IESG Note has been addressed.
+ - Clarified (in Section 1), that this document does not define a
+ canonical string representation.
+ - Replaced specification of additional requirements for LDAPv2
+ implementations which also support LDAPv3 (RFC 2253, Section 4)
+ with a statement (in Section 3) allowing recognition of
+ alternative string representations.
+ - Clarified (in Section 2.3) that the "published" table of names
+ which may be appear in DNs is the table which Section 2.3
+ provides. Remove "as an example" language. Noted this table is
+ not extensible. Added statement (in Section 3) allowing
+ recognition of additional names. Added security considerations
+ (Section 5.3) regarding the use of other names.
+ - Updated Section 2.3 to indicate attribute type name strings are
+ case insensitive.
+ - Updated Section 2.4 to allow hex pair escaping of all characters
+ and clarified escaping for when multiple octet UTF-8 characters
+ are present.
+ - Rewrote Section 3 to use ABNF as defined in RFC 2234.
+ - Rewrote Section 3 ABNF to be consistent with 2.4.
+ - Updated Section 3 to describe how to parse elements of the
+ grammar.
+ - Rewrote examples.
+ - Added reference to documentations containing general LDAP security
+ considerations.
+ - Added discussion of presentation issues (Appendix A).
+ - Added this appendix.
+
+
+
+Zeilenga LDAP: Distinguished Names [Page 12]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
+
+
+ In addition, numerous editorial changes were made.
+
+
+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: Distinguished Names [Page 13]
+\f
--- /dev/null
+
+
+
+
+
+
+Network Working Group M. Smith, Editor
+Request for Comments: DRAFT Netscape Communications Corp.
+Obsoletes: RFC 2254 T. Howes
+Expires: 28 August 2003 Opsware, Inc.
+ 28 February 2003
+
+
+ LDAP: String Representation of Search Filters
+ <draft-ietf-ldapbis-filter-04.txt>
+
+
+
+1. Status of this Memo
+
+ This document is an Internet-Draft and is subject to all provisions
+ of Section 10 of RFC2026.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet- Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/1id-abstracts.html
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html
+
+ Discussion of this document should take place on the LDAP (v3)
+ Revision (ldapbis) Working Group mailing list <ietf-
+ ldapbis@openldap.org>.
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+2. Abstract
+
+ LDAP search filters are transmitted in the LDAP protocol using a
+ binary representation that is appropriate for use on the network.
+ This document defines a human-readable string representation of LDAP
+ search filters that is appropriate for use in LDAP URLs and in other
+ applications.
+
+
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 1]
+\f
+INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
+
+
+3. Table of Contents
+
+1. Status of this Memo............................................1
+2. Abstract.......................................................1
+3. Table of Contents..............................................2
+4. Introduction...................................................2
+5. LDAP Search Filter Definition..................................2
+6. String Search Filter Definition................................4
+7. Examples.......................................................5
+8. Security Considerations........................................7
+9. Normative References...........................................7
+10. Informative References.........................................8
+11. Acknowledgments................................................8
+12. Authors' Address...............................................8
+13. Full Copyright Statement.......................................9
+14. Appendix A: Changes Since RFC 2254.............................9
+14.1. Technical Changes...........................................9
+14.2. Editorial Changes...........................................10
+15. Appendix B: Changes Since Previous Document Revision...........11
+15.1. Technical Changes...........................................11
+15.2. Editorial Changes...........................................11
+
+4. Introduction
+
+ The Lightweight Directory Access Protocol (LDAP) [Protocol] defines a
+ network representation of a search filter transmitted to an LDAP
+ server. Some applications may find it useful to have a common way of
+ representing these search filters in a human-readable form; LDAP URLs
+ are an example of one such application. This document defines a
+ human-readable string format for representing the full range of
+ possible LDAP version 3 search filters, including extended match
+ filters.
+
+ This document is an integral part of the LDAP Technical
+ Specification [Roadmap].
+
+ This document replaces RFC 2254. Changes to RFC 2254 are summarized
+ in Appendix A.
+
+ 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].
+
+5. LDAP Search Filter Definition
+
+ An LDAPv3 search filter is defined in Section 4.5.1 of [Protocol] as
+ follows:
+
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 2]
+\f
+INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
+
+
+ Filter ::= CHOICE {
+ and [0] SET SIZE (1..MAX) OF Filter,
+ or [1] SET SIZE (1..MAX) OF 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,
+ -- at least one must be present,
+ -- initial and final can occur at most once
+ substrings SEQUENCE OF CHOICE {
+ initial [0] AssertionValue,
+ any [1] AssertionValue,
+ final [2] AssertionValue } }
+
+ AttributeValueAssertion ::= SEQUENCE {
+ attributeDesc AttributeDescription,
+ assertionValue AssertionValue }
+
+ MatchingRuleAssertion ::= SEQUENCE {
+ matchingRule [1] MatchingRuleId OPTIONAL,
+ type [2] AttributeDescription OPTIONAL,
+ matchValue [3] AssertionValue,
+ dnAttributes [4] BOOLEAN DEFAULT FALSE }
+
+ AttributeDescription ::= LDAPString
+ -- Constrained to attributedescription
+ -- [Models]
+
+ AttributeValue ::= OCTET STRING
+
+ MatchingRuleId ::= LDAPString
+
+ AssertionValue ::= OCTET STRING
+
+ LDAPString ::= OCTET STRING -- UTF-8 encoded,
+ -- ISO 10646 characters
+
+ where the LDAPString above is limited to the UTF-8 encoding [RFC2279]
+ of the ISO 10646 character set [ISO10646]. The AttributeDescription
+ is a string representation of the attribute description and is
+ defined in [Protocol]. The AttributeValue and AssertionValue OCTET
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 3]
+\f
+INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
+
+
+ STRING have the form defined in [Syntaxes]. The Filter is encoded
+ for transmission over a network using the Basic Encoding Rules
+ defined in [ASN.1], with simplifications described in [Protocol].
+
+6. String Search Filter Definition
+
+ The string representation of an LDAP search filter is a string of
+ UTF-8 encoded ISO 10646-1 characters that is defined by the following
+ grammar, following the ABNF notation defined in [RFC2234]. The
+ productions used that are not defined here are defined in section 1.3
+ (Common ABNF Productions) of [Models] unless otherwise noted. The
+ filter format uses a prefix notation.
+
+ filter = LPAREN filtercomp RPAREN
+ filtercomp = and / or / not / item
+ and = AMPERSAND filterlist
+ or = VERTBAR filterlist
+ not = EXCLAMATION filter
+ filterlist = 1*filter
+ item = simple / present / substring / extensible
+ simple = attr filtertype assertionvalue
+ filtertype = equal / approx / greater / less
+ equal = EQUALS
+ approx = TILDE EQUALS
+ greater = RANGLE EQUALS
+ less = LANGLE EQUALS
+ extensible = attr [dnattrs] [matchingrule] COLON EQUALS assertionvalue
+ / [dnattrs] matchingrule COLON EQUALS assertionvalue
+ / COLON EQUALS assertionvalue
+ present = attr EQUALS ASTERIX
+ substring = attr EQUALS [initial] any [final]
+ initial = assertionvalue
+ any = ASTERIX *(assertionvalue ASTERIX)
+ final = assertionvalue
+ attr = attributedescription
+ ; The attributedescription rule is defined in
+ ; Section 2.5 of [Models].
+ dnattrs = COLON "dn"
+ matchingrule = COLON oid
+ assertionvalue = valueencoding
+ ; The <valueencoding> rule is used to encode an
+ ; <AssertionValue> from Section 4.1.6 of [Protocol].
+ valueencoding = 0*(normal / escaped)
+ normal = UTF1SUBSET / UTFMB
+ escaped = ESC HEX HEX
+ UTF1SUBSET = %x01-27 / %x2B-5B / %x5D-7F
+ ; UTF1SUBSET excludes 0x00 (NUL), LPAREN,
+ ; RPAREN, ASTERIX, and ESC.
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 4]
+\f
+INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
+
+
+ EXCLAMATION = %x21 ; exclamation mark ("!")
+ AMPERSAND = %x26 ; ampersand (or AND symbol) ("&")
+ ASTERIX = %x2A ; asterix ("*")
+ COLON = %x3A ; colon (":")
+ VERTBAR = %x7C ; vertical bar (or pipe) ("|")
+ TILDE = %x7E ; tilde ("~")
+
+
+ Note that although both the <substring> and <present> productions in
+ the grammar above can produce the "attr=*" construct, this construct
+ is used only to denote a presence filter.
+
+ The <valueencoding> rule ensures that the entire filter string is a
+ valid UTF-8 string and provides that the octets that represent the
+ ASCII characters "*" (ASCII 0x2a), "(" (ASCII 0x28), ")" (ASCII
+ 0x29), "\" (ASCII 0x5c), and NUL (ASCII 0x00) are represented as a
+ backslash "\" (ASCII 0x5c) followed by the two hexadecimal digits
+ representing the value of the encoded octet.
+
+ This simple escaping mechanism eliminates filter-parsing ambiguities
+ and allows any filter that can be represented in LDAP to be
+ represented as a NUL-terminated string. Other octets that are part of
+ the <normal> set may be escaped using this mechanism, for example,
+ non-printing ASCII characters.
+
+ For AssertionValues that contain UTF-8 character data, each octet of
+ the character to be escaped is replaced by a backslash and two hex
+ digits, which form a single octet in the code of the character.
+
+ For example, the filter checking whether the "cn" attribute contained
+ a value with the character "*" anywhere in it would be represented as
+ "(cn=*\2a*)".
+
+ As indicated by the valueencoding rule, implementations MUST escape
+ all octets greater than 0x7F that are not part of a valid UTF-8
+ encoding sequence when they generate a string representation of a
+ search filter. Since RFC 2254 does not clearly define the term
+ "string representation" (and in particular does mention that the
+ string representation of an LDAP search filter is a string of UTF-8
+ encoded ISO 10646-1 characters) implementations SHOULD accept as
+ input strings that include invalid UTF-8 octet sequences.
+
+7. Examples
+
+ This section gives a few examples of search filters written using
+ this notation.
+
+ (cn=Babs Jensen)
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 5]
+\f
+INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
+
+
+ (!(cn=Tim Howes))
+ (&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*)))
+ (o=univ*of*mich*)
+ (seeAlso=)
+
+ The following examples illustrate the use of extensible matching.
+
+ (cn:1.2.3.4.5:=Fred Flintstone)
+ (cn:=Betty Rubble)
+ (sn:dn:2.4.6.8.10:=Barney Rubble)
+ (o:dn:=Ace Industry)
+ (:1.2.3:=Wilma Flintstone)
+ (:dn:2.4.6.8.10:=Dino)
+ (:=Fred Flintstone)
+
+ The first example shows use of the matching rule "1.2.3.4.5".
+
+ The second example demonstrates use of a MatchingRuleAssertion form
+ without a matchingRule.
+
+ The third example illustrates the use of the ":dn" notation to
+ indicate that matching rule "2.4.6.8.10" should be used when making
+ comparisons, and that the attributes of an entry's distinguished name
+ should be considered part of the entry when evaluating the match.
+
+ The fourth example denotes an equality match, except that DN
+ components should be considered part of the entry when doing the
+ match.
+
+ The fifth example is a filter that should be applied to any attribute
+ supporting the matching rule given (since the attr has been omitted).
+
+ The sixth example is also a filter that should be applied to any
+ attribute supporting the matching rule given. Attributes supporting
+ the matching rule contained in the DN should also be considered.
+
+ The seventh and final example is a filter that should be applied to
+ any attribute (since both the attr and matching rule have been
+ omitted).
+
+ The following examples illustrate the use of the escaping mechanism.
+
+ (o=Parens R Us \28for all your parenthetical needs\29)
+ (cn=*\2A*)
+ (filename=C:\5cMyFile)
+ (bin=\00\00\00\04)
+ (sn=Lu\c4\8di\c4\87)
+ (1.3.6.1.4.1.1466.0=\04\02\48\69)
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 6]
+\f
+INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
+
+
+ The first example shows the use of the escaping mechanism to
+ represent parenthesis characters. The second shows how to represent a
+ "*" in an assertion value, preventing it from being interpreted as a
+ substring indicator. The third illustrates the escaping of the
+ backslash character.
+
+ The fourth example shows a filter searching for the four-byte value
+ 0x00000004, illustrating the use of the escaping mechanism to
+ represent arbitrary data, including NUL characters.
+
+ The fifth example illustrates the use of the escaping mechanism to
+ represent various non-ASCII UTF-8 characters.
+
+ The sixth and final example demonstrates assertion of a BER encoded
+ value.
+
+8. Security Considerations
+
+ This memo describes a string representation of LDAP search filters.
+ While the representation itself has no known security implications,
+ LDAP search filters do. They are interpreted by LDAP servers to
+ select entries from which data is retrieved. LDAP servers should
+ take care to protect the data they maintain from unauthorized access.
+
+ Please refer to the Security Considerations sections of [Protocol]
+ and [AuthMeth] for more information.
+
+9. Normative References
+
+ [ASN.1] Specification of ASN.1 encoding rules: Basic, Canonical, and
+ Distinguished Encoding Rules, ITU-T Recommendation X.690, 1994.
+
+ [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and
+ Connection Level Security Mechanisms", draft-ietf-ldapbis-authmeth-
+ xx.txt, a work in progress.
+
+ [ISO10646] Universal Multiple-Octet Coded Character Set (UCS) -
+ Architecture and Basic Multilingual Plane, ISO/IEC 10646-1, 1993.
+
+ [Models] Zeilenga, K. (editor), "LDAP: Directory Information Models",
+ draft-ietf-ldapbis-models-xx.txt, a work in progress.
+
+ [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol", draft-
+ ietf-ldapbis-protocol-xx.txt, a work in progress.
+
+ [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 7]
+\f
+INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
+
+
+ [RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
+ RFC 2279, January 1998.
+
+ [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification Road
+ Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in progress.
+
+ [Syntaxes] Dally, K. (editor), "LDAP: Syntaxes", draft-ietf-ldapbis-
+ syntaxes-xx.txt, a work in progress.
+
+
+10. Informative References
+
+ None.
+
+
+11. Acknowledgments
+
+ This document replaces RFC 2254 by Tim Howes. Changes included in
+ this revised specification are based upon discussions among the
+ authors, discussions within the LDAP (v3) Revision Working Group
+ (ldapbis), and discussions within other IETF Working Groups. The
+ contributions of individuals in these working groups is gratefully
+ acknowledged.
+
+
+12. Authors' Address
+
+ Mark Smith, Editor
+ Netscape Communications Corp.
+ 360 W. Caribbean Drive
+ Sunnyvale, CA 94089
+ USA
+ +1 650 937-3477
+ mcs@netscape.com
+
+ Tim Howes
+ Opsware, Inc.
+ 599 N. Mathilda Ave.
+ Sunnyvale, CA 94085
+ USA
+ +1 408 744-7509
+ howes@opsware.com
+
+
+
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 8]
+\f
+INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
+
+
+13. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 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.
+
+
+14. Appendix A: Changes Since RFC 2254
+
+14.1. Technical Changes
+
+ The following technical changes were made to the contents of the
+ "String Search Filter Definition" section:
+
+ Added statement that the string representation is a string of UTF-8
+ encoded ISO 10646-1 characters.
+
+ Revised all of the ABNF to use common productions from [Models].
+
+ Replaced the "value" rule with a new "assertionvalue" rule within the
+ "simple", "extensible", and "substring" ("initial", "any", and
+ "final") rules. This matches a change made in [Syntaxes].
+
+ Revised the "attr", "matchingrule", and "assertionvalue" ABNF to more
+ precisely reference productions from the [Models] and [Protocol]
+ documents.
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 9]
+\f
+INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
+
+
+ Introduced the "valueencoding" and associated "normal" and "escaped"
+ rules to reduce the dependence on descriptive text. The "normal"
+ production restricts filter strings to valid UTF-8 sequences.
+
+ Added a third option to the "extensible" production to allow creation
+ of a MatchingRuleAssertion that only has a matchValue.
+
+ Added a statement about expected behavior in light of RFC 2254's lack
+ of a clear definition of "string representation."
+
+
+14.2. Editorial Changes
+
+ Changed document title to include "LDAP:" prefix.
+
+ IESG Note: removed note about lack of satisfactory mandatory
+ authentication mechanisms.
+
+ Header and "Authors' Addresses" sections: added Mark Smith as the
+ document editor and updated affiliation and contact information.
+
+ "Table of Contents" section: added.
+
+ Copyright: updated the year.
+
+ "Abstract" section: separated from introductory material.
+
+ "Introduction" section: new section; separated from the Abstract.
+ Updated second paragraph to indicate that RFC 2254 is replaced by
+ this document (instead of RFC 1960). Added reference to the [Roadmap]
+ document.
+
+ "LDAP Search Filter Definition" section: made corrections to the
+ LDAPv3 search filter ABNF so it matches that used in [Protocol].
+
+ Clarified the definition of 'value' (now 'assertionvalue') to take
+ into account the fact that it is not precisely an AttributeAssertion
+ from [Protocol] section 4.1.6 (special handling is required for some
+ characters). Added a note that each octet of a character to be
+ escaped is replaced by a backslash and two hex digits, which
+ represent a single octet.
+
+ "Examples" section: added five additional examples: (seeAlso=),
+ (cn:=Betty Rubble), (:1.2.3:=Wilma Flintstone), (:=Fred Flintstone),
+ and (1.3.6.1.4.1.1466.0=\04\02\48\69). Replaced one occurrence of "a
+ value" with "an assertion value".
+
+ "Security Considerations" section: added references to [Protocol] and
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 10]
+\f
+INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
+
+
+ [AuthMeth].
+
+ "Normative References" section: renamed from "References" per new RFC
+ guidelines. Changed from [1] style to [Protocol] style throughout the
+ document. Added entries for [ISO10646], [RFC2119], [AuthMeth],
+ [Models], and [Roadmap] and updated UTF-8 reference to RFC 2279.
+ Replaced RFC 822 reference with a reference to RFC 2234.
+
+ "Informative References" section: added for clarity.
+
+ "Acknowledgments" section: added.
+
+ "Appendix A: Changes Since RFC 2254" section: added.
+
+ "Appendix B: Changes Since Previous Document Revision" section:
+ added.
+
+
+15. Appendix B: Changes Since Previous Document Revision
+
+ This appendix lists all changes relative to the last published
+ revision, draft-ietf-ldapbis-filter-03.txt. Note that when
+ appropriate these changes are also included in Appendix A, but are
+ also included here for the benefit of the people who have already
+ reviewed draft-ietf-ldapbis-filter-03.txt. This section will be
+ removed before this document is published as an RFC.
+
+
+15.1. Technical Changes
+
+ "String Search Filter Definition" section: Added statement that the
+ string representation is a string of UTF-8 encoded ISO 10646-1
+ characters and statement about expected behavior in light of RFC
+ 2254's lack of a clear definition of "string representation."
+
+ "String Search Filter Definition" section: Revised all of the ABNF to
+ use common productions from [Models]. Revised the "normal"
+ production to restrict filter strings to valid UTF-8 sequences.
+
+
+15.2. Editorial Changes
+
+ "Status of this Memo" section: updated boilerplate to match current
+ I-D guidelines.
+
+ "Examples" section: removed ;binary from an example.
+
+ "LDAP Search Filter Definition " section: updated section references
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 11]
+\f
+INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
+
+
+ to match current LDAPBis drafts. Made minor changes to the ASN.1 so
+ it exactly matches that used in the Protocol document (added
+ comments).
+
+ "Normative References" section: added references to [ISO10646],
+ [RFC2119] and [Models].
+
+ "Informative References" section: added for clarity.
+
+ Updated copyright year to 2003.
+
+
+This Internet Draft expires on 28 August 2003.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 12]
+\f
--- /dev/null
+
+
+
+
+
+
+INTERNET-DRAFT Editor: Kurt D. Zeilenga
+Intended Category: Standard Track OpenLDAP Foundation
+Expires in six months 1 March 2003
+Obsoletes: RFC 2251, RFC 2252, RFC 2256
+
+
+
+ LDAP: Directory Information Models
+ <draft-ietf-ldapbis-models-07.txt>
+
+
+
+Status of this 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 published as a Standard Track RFC.
+ Distribution of this memo is unlimited. Technical discussion of this
+ document will take place on the IETF LDAP Revision Working Group
+ mailing list <ietf-ldapbis@openldap.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
+
+ The Lightweight Directory Access Protocol (LDAP) is an Internet
+ protocol for accessing distributed directory services which act in
+ accordance with X.500 data and service models. This document
+ describes the X.500 Directory Information Models, as used in LDAP.
+
+
+
+
+Zeilenga LDAP Models [Page 1]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+
+
+Table of Contents
+
+ Status of this Memo 1
+ Abstract
+ Table of Contents 2
+ 1. Introduction 3
+ 1.1. Relationship to Other LDAP Specifications
+ 1.2. Relationship to ITU Specifications
+ 1.3. Conventions 4
+ 1.4. Common ABNF Productions
+ 2. Model of Directory User Information 6
+ 2.1. The Directory Information Tree
+ 2.2. Naming of Entries 7
+ 2.3. Structure of an Entry 8
+ 2.4. Object Classes
+ 2.5. Attribute Descriptions 11
+ 2.6. Alias Entries 15
+ 3. Directory Administrative and Operational Information 16
+ 3.1. Subtrees
+ 3.2. Subentries 17
+ 3.3. The 'objectClass' attribute
+ 3.4. Operational attributes 18
+ 4. Directory Schema 20
+ 4.1. Schema Definitions 21
+ 4.2. Subschema Subentries 30
+ 4.3. 'extensibleObject' 34
+ 4.4. Subschema Discovery
+ 5. DSA (Server) Informational Model
+ 5.1. Server-specific Data Requirements 35
+ 6. Other Considerations 38
+ 6.1. Preservation of User Information
+ 6.2. Short Names
+ 6.3. Cache and Shadowing 39
+ 7. Implementation Guidelines 40
+ 7.1. Server Guidelines
+ 7.2. Client Guidelines
+ 8. Security Considerations 41
+ 9. IANA Considerations
+ 10. Acknowledgments 42
+ 11. Author's Address
+ 12. References
+ 12.1. Normative References
+ 12.2. Informative References 43
+ Appendix A. Changes
+ A.1 Changes to RFC 2251 44
+ A.2 Changes to RFC 2252 46
+ A.3 Changes to RFC 2256 47
+ Copyright
+
+
+
+Zeilenga LDAP Models [Page 2]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+
+
+1. Introduction
+
+ This document discusses the X.500 Directory Information Models
+ [X.501], as used by the Lightweight Directory Access Protocol (LDAP)
+ [Roadmap].
+
+ The Directory is "a collection of open systems cooperating to provide
+ directory services" [X.500]. The information held in the Directory is
+ collectively known as the Directory Information Base (DIB). 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)). A server holds a fragment
+ of the DIB.
+
+ The DIB contains two classes of information:
+
+ 1) user information (e.g., information provided and administrated
+ by users). Section 2 describes the Model of User Information.
+
+ 2) administrative and operational information (e.g., information
+ used to administer and/or operate the directory). Section 3
+ describes the model of Directory Administrative and Operational
+ Information.
+
+ These two models, referred to as the generic Directory Information
+ Models, describe how information is represented in the Directory.
+ These generic models provide a framework for other information models.
+ Section 4 discusses the subschema information model and subschema
+ discovery. Section 5 discusses the DSA (Server) Informational Model.
+
+ Other X.500 information models, such as access control, collective
+ attribute, distribution knowledge, and replication knowledge
+ information models, may be adapted for use in LDAP. Specification of
+ how these models apply to LDAP is left to future documents.
+
+
+1.1. Relationship to Other LDAP Specifications
+
+ This document is a integral part of the LDAP technical specification
+ [Roadmap] which obsoletes the previously defined LDAP technical
+ specification, RFC 3377, in its entirety.
+
+ This document obsoletes RFC 2251 sections 3.2 and 3.4, as well as
+ portions of sections 4 and 6. Appendix A.1 summaries changes to these
+ sections. The remainder of RFC 2251 is obsoleted by the [Protocol],
+ [AuthMeth], and [Roadmap] documents.
+
+
+
+
+Zeilenga LDAP Models [Page 3]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+
+
+ This document obsoletes RFC 2252 sections 4, 5 and 7. Appendix A.2
+ summaries changes to these sections. The remainder of RFC 2252 is
+ obsoleted by [Syntaxes] and [Schema].
+
+ This document obsoletes RFC 2256 sections 5.1, 5.2, 7.1 and 7.2.
+ Appendix A.3 summarizes changes to these sections. The remainder of
+ RFC 2256 is obsoleted by [Schema] and [Syntaxes].
+
+
+1.2. Relationship to X.501
+
+ This document includes material, with and without adaptation, from the
+ [X.501]. Due to the adaptation, the material included in this
+ document takes precedence.
+
+
+1.3. 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].
+
+ Schema definitions are provided using LDAP description formats (as
+ defined in Section 4.1). Definitions provided here are formatted
+ (line wrapped) for readability. Matching rules and LDAP syntaxes
+ referenced in these definitions are specified in [Syntaxes].
+
+
+1.4. Common ABNF Productions
+
+ A number of syntaxes in this document are described using Augmented
+ Backus-Naur Form (ABNF) [RFC2234]. These syntaxes (as well as a
+ number of syntaxes defined in other documents) rely on the following
+ common productions:
+
+ keystring = leadkeychar *keychar
+ leadkeychar = ALPHA
+ keychar = ALPHA / DIGIT / HYPHEN
+
+ number = DIGIT / ( LDIGIT 1*DIGIT )
+
+ ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z"
+ DIGIT = %x30 / LDIGIT ; "0"-"9"
+ LDIGIT = %x31-39 ; "1"-"9"
+
+ HEX = DIGIT / %x41-46 / %x61-66 ; 0-9 / A-F / a-f
+
+ SP = 1*SPACE ; one or more " "
+
+
+
+Zeilenga LDAP Models [Page 4]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+
+
+ WSP = 0*SPACE ; zero or more " "
+
+ NULL = %x00 ; null (0)
+ SPACE = %x20 ; space (" ")
+ DQUOTE = %x22 ; quote (""")
+ SHARP = %x23 ; octothorpe (or sharp sign) ("#")
+ DOLLAR = %x24 ; dollar sign ("$")
+ SQUOTE = %x27 ; single quote ("'")
+ LPAREN = %x28 ; left paren ("(")
+ RPAREN = %x29 ; right paren (")")
+ PLUS = %x2B ; plus sign ("+")
+ COMMA = %x2C ; comma (",")
+ HYPHEN = %x2D ; hyphen ("-")
+ DOT = %x2E ; period (".")
+ SEMI = %x3B ; semicolon (";")
+ LANGLE = %x3C ; left angle bracket ("<")
+ EQUALS = %x3D ; equals sign ("=")
+ RANGLE = %x3E ; right angle bracket (">")
+ X = %x58 ; uppercase x ("X")
+ ESC = %x5C ; backslash ("\")
+ USCORE = %x5F ; underscore ("_")
+ LCURLY = %x7B ; left curly brace "{"
+ RCURLY = %x7D ; right curly brace "}"
+
+ ; Any UTF-8 character
+ UTF8 = UTF1 / UTFMB
+ UTFMB = UTF2 / UTF3 / UTF4 / UTF5 / UTF6
+ UTF0 = %x80-BF
+ UTF1 = %x00-7F
+ UTF2 = %xC0-DF 1(UTF0)
+ UTF3 = %xE0-EF 2(UTF0)
+ UTF4 = %xF0-F7 3(UTF0)
+ UTF5 = %xF8-FB 4(UTF0)
+ UTF6 = %xFC-FD 5(UTF0)
+
+ ; Any octet
+ OCTET = %x00-FF
+
+ Object identifiers are represented in LDAP using a dot-decimal format
+ conforming to the ABNF:
+
+ numericoid = number *( DOT number )
+
+ Short names, also known as descriptors, are used as more readable
+ aliases for object identifiers. Short names are case insensitive and
+ conform to the ABNF:
+
+ descr = keystring
+
+
+
+Zeilenga LDAP Models [Page 5]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+
+
+ Where either an object identifier or a short name may be specified,
+ the following production is used:
+
+ oid = descr / numericoid
+
+ While the <descr> form is generally preferred when the usage is
+ restricted to short names referring to object identifiers which
+ identify like kinds of objects (e.g., attribute type descriptions,
+ matching rule descriptions, object class descriptions), the
+ <numericoid> form should be used when the object identifiers may
+ identify multiple kinds of objects or when an unambiguous short name
+ (descriptor) is not available.
+
+ When the <descr> form is used, the representation SHALL be considered
+ invalid if the usage is not restricted as discussed above or the
+ implementation cannot determine unambiguously which object identifier
+ the <descr> refers to.
+
+ Short Names (descriptors) are discussed further in Section 6.2.
+
+
+2. Model of Directory User Information
+
+ As [X.501] states:
+
+ The purpose of the Directory is to hold, and provide access to,
+ information about objects of interest (objects) in some 'world'.
+ An object can be anything which is identifiable (can be named).
+
+ An object class is an identified family of objects, or conceivable
+ objects, which share certain characteristics. Every object belongs
+ to at least one class. An object class may be a subclass of other
+ object classes, in which case the members of the former class, the
+ subclass, are also considered to be members of the latter classes,
+ the superclasses. There may be subclasses of subclasses, etc., to
+ an arbitrary depth.
+
+ A directory entry, a named collection of information, is the basic
+ unit of information held in the Directory. There are multiple kinds
+ of directory entries.
+
+ An object entry represents a particular object. An alias entry
+ provides alternative naming. A subentry holds administrative and/or
+ operational information.
+
+ The set of entries representing the DIB are organized hierarchically
+ in a tree structure known as the Directory Information Tree (DIT).
+
+
+
+
+Zeilenga LDAP Models [Page 6]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+
+
+ Section 2.1 describes the Directory Information Tree
+ Section 2.2 discusses naming of entries.
+ Section 2.3 discusses the structure of entries.
+ Section 2.4 discusses object classes.
+ Section 2.5 discusses attribute descriptions.
+ Section 2.6 discusses alias entries.
+
+
+2.1. The Directory Information Tree
+
+ As noted above, the DIB is composed of a set of entries organized
+ hierarchically in a tree structure known as the Directory Information
+ Tree (DIT). Specifically, a tree where vertices are the entries.
+
+ The arcs between vertices define relations between entries. If an arc
+ exists from X to Y, then the entry at X is the immediate superior of Y
+ and Y is the immediate subordinate of X. An entry's superiors are the
+ entry's immediate superior and its superiors. An entry's subordinates
+ are all of its immediate subordinates and their subordinates.
+
+ Similarly, the superior/subordinate relationship between object
+ entries can be used to derive a relation between the objects they
+ represent. DIT structure rules can be used to govern relationships
+ between objects.
+
+ Note: An entry's immediate superior is also known as the entry's
+ parent and an entry's immediate subordinate is also known as the
+ entry's child. Entries which have the same parent are known as
+ siblings.
+
+
+2.2. Naming of Entries
+
+2.2.1. Relative Distinguished Names
+
+ Each entry is named relative to its immediate superior. This relative
+ name, known as its Relative Distinguished Name (RDN) [X.501], is
+ composed of an unordered set of one or more attribute value assertions
+ (AVA) consisting of an attribute description with zero options and an
+ attribute value. These AVAs are chosen from the attributes of the
+ entry.
+
+ An entry's relative distinguished name must be unique among all
+ immediate subordinates of the entry's immediate superior (i.e., all
+ siblings).
+
+ The following are example string representations of RDNs [LDAPDN]:
+
+
+
+
+Zeilenga LDAP Models [Page 7]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+
+
+ UID=12345
+ OU=Engineering
+ CN=Kurt Zeilenga+L=Redwood Shores
+
+ The last is an example of a multi-valued RDN. That is, an RDN
+ composed of multiple AVAs.
+
+
+2.2.2. Distinguished Names
+
+ An entry's fully qualified name, known as its Distinguished Name (DN)
+ [X.501], is the concatenation of its RDN and its immediate superior's
+ DN. A Distinguished Name unambiguously refers to an entry in the
+ tree. The following are example string representations of DNs
+ [LDAPDN]:
+
+ UID=nobody@example.com,DC=example,DC=com
+ CN=John Smith,OU=Sales,O=ACME Limited,L=Moab,ST=Utah,C=US
+
+
+2.2.3. Alias Names
+
+ An alias, or alias name, is "an name for an object, provided by the
+ use of alias entries" [X.501]. Alias entries are described in Section
+ 2.6.
+
+
+2.3. Structure of an Entry
+
+ An entry consists of a set of attributes which hold information about
+ the object which entry represents. Some attributes represent user
+ information and are called user attributes. Other attributes
+ represent operational and/or administrative information and are called
+ operational attributes.
+
+ An attribute is an attribute description (a type and zero or more
+ options) with one or more associated values. An attribute is often
+ referred to by its attribute description. For example, the
+ 'givenName' attribute is the attribute which consists of the attribute
+ description 'givenName' (the 'givenName' attribute type [Schema] and
+ zero options) and one or more associated values.
+
+ The attribute type governs whether the attribute can have multiple
+ values, the syntax and matching rules used to construct and compare
+ values of that attribute, and other functions. Options indicate
+ subtypes and other functions. No two values of an attribute may be
+ equivalent.
+
+
+
+
+Zeilenga LDAP Models [Page 8]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+
+
+ Two values are considered equivalent if they would match according to
+ the equality matching rule of the attribute type. If the attribute
+ type is defined with no equality matching rule, two values are
+ equivalent if and only if they are identical.
+
+ For example, the 'givenName' attribute can have can have more than one
+ value, they must be Directory Strings, and they are case insensitive.
+ The 'givenName' attribute cannot hold both "John" and "JOHN" as these
+ are equivalent values per the equality matching rule of the attribute
+ type.
+
+
+2.4. Object Classes
+
+ An object class is "an identified family of objects (or conceivable
+ objects) which share certain characteristics" [X.501].
+
+ As defined in [X.501]:
+
+ Object classes are used in the Directory for a number of purposes:
+
+ - describing and categorising objects and the entries that
+ correspond to these objects;
+
+ - where appropriate, controlling the operation of the Directory;
+
+ - regulating, in conjunction with DIT structure rule
+ specifications, the position of entries in the DIT;
+
+ - regulating, in conjunction with DIT content rule
+ specifications, the attributes that are contained in entries;
+
+ - identifying classes of entry that are to be associated with a
+ particular policy by the appropriate administrative authority.
+
+ An object class (a subclass) may be derived from an object class
+ (its direct superclass) which is itself derived from an even more
+ generic object class. For structural object classes, this process
+ stops at the most generic object class, 'top' (defined in Section
+ 2.4.1). An ordered set of superclasses up to the most superior
+ object class of an object class is its superclass chain.
+
+ An object class may be derived from two or more direct
+ superclasses (superclasses not part of the same superclass chain).
+ This feature of subclassing is termed multiple inheritance.
+
+ Each object class identifies the set of attributes required to be
+ present in entries belonging to the class and the set of attributes
+
+
+
+Zeilenga LDAP Models [Page 9]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+
+
+ allowed to be present in entries belonging to the class. As an entry
+ of a class must meet the requirements of each class it belongs to, it
+ can be said that an object class inherits the sets of allowed and
+ required attributes from its superclasses. A subclass can identify an
+ attribute allowed by its superclass as being required. If an
+ attribute is a member of both sets, it is required to be present.
+
+ Each object class is defined to be one of three kinds of object
+ classes: Abstract, Structural, or Auxiliary.
+
+ Each object class is identified by an object identifier (OID) and,
+ optionally, one or more short names (descriptors).
+
+
+2.4.1. Abstract Object Classes
+
+ An abstract object class, as the name implies, provides a base of
+ characteristics from which other object classes can be defined to
+ inherit from. An entry cannot belong to an abstract object class
+ unless it belongs to a structural or auxiliary class which inherits
+ from that abstract class.
+
+ Abstract object classes can not derive from structural nor auxiliary
+ object classes.
+
+ All structural object classes derive (directly or indirectly) from the
+ 'top' abstract object class. Auxiliary object classes do not
+ necessarily derive from 'top'.
+
+ ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass )
+
+ All entries belong to the 'top' abstract object class.
+
+
+2.4.2. Structural Object Classes
+
+ As stated in [X.501]:
+
+ An object class defined for use in the structural specification of
+ the DIT is termed a structural object class. Structural object
+ classes are used in the definition of the structure of the names
+ of the objects for compliant entries.
+
+ An object or alias entry is characterised by precisely one
+ structural object class superclass chain which has a single
+ structural object class as the most subordinate object class.
+ This structural object class is referred to as the structural
+ object class of the entry.
+
+
+
+Zeilenga LDAP Models [Page 10]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+
+
+ Structural object classes are related to associated entries:
+
+ - an entry conforming to a structural object class shall
+ represent the real-world object constrained by the object
+ class;
+
+ - DIT structure rules only refer to structural object classes;
+ the structural object class of an entry is used to specify the
+ position of the entry in the DIT;
+
+ - the structural object class of an entry is used, along with an
+ associated DIT content rule, to control the content of an
+ entry.
+
+ The structural object class of an entry shall not be changed.
+
+ Each structural object class is a (direct or indirect) subclass of the
+ 'top' abstract object class.
+
+ Structural object classes cannot subclass auxiliary object classes.
+
+ Each entry is said to belong to its structural object class as well as
+ all classes in its structural object class's superclass chain, which
+ always includes 'top'.
+
+
+2.4.3. Auxiliary Object Classes
+
+ Auxiliary object classes are used augment the characteristics of
+ entries. They are commonly used to augment the sets of attributes
+ required and allowed attributes to be present in an entry. They can
+ be used to describe entries or classes of entries.
+
+ Auxiliary object classes cannot subclass structural object classes.
+
+ An entry can belong to any subset of the set of auxiliary object
+ classes allowed by the DIT content rule associated with structural
+ object class of the entry. If no DIT content rule is associated with
+ the structural object class of the entry, the entry cannot belong to
+ any auxiliary object class.
+
+ The set of auxiliary object classes which an entry belongs to can
+ change over time.
+
+
+2.5. Attribute Descriptions
+
+ An attribute description is composed of an attribute type (see Section
+
+
+
+Zeilenga LDAP Models [Page 11]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+
+
+ 2.5.1) and a set of zero or more attribute options (see Section
+ 2.5.2).
+
+ An attribute description is represented by the ABNF:
+
+ attributedescription = attributetype options
+
+ attributetype = oid
+
+ options = *( SEMI option )
+
+ option = 1*keychar
+
+ where <attributetype> identifies the attribute type and each <option>
+ identifies an attribute option. Both <attributetype> and <option>
+ productions are case insensitive. The order in which <option>s appear
+ is irrelevant. That is, any two <attributedescription>s which consist
+ of the same <attributetype> and same set of <option>s are equivalent.
+
+ Examples of valid attribute descriptions:
+
+ 2.5.4.0
+ cn;lang-de;lang-en
+ owner
+
+ An attribute description which consisting of an unrecognized attribute
+ type is to be treated as unrecognized. Servers SHALL treat an
+ attribute description with an unrecognized attribute option as
+ unrecognized. Clients MAY treat an unrecognized attribute option as a
+ tagging option (see Section 2.5.2.1).
+
+ All attributes of an entry must have distinct attribute descriptions.
+
+
+2.5.1. Attribute Types
+
+ An attribute type governs whether the attribute can have multiple
+ values, the syntax and matching rules used to construct and compare
+ values of that attribute, and other functions.
+
+ The attribute type indicates whether the attribute is a user attribute
+ or an operational attribute. If operational, the attribute type
+ indicates the operational usage and whether the attribute can
+ modifiable by users or not. Operational attributes discussed in
+ Section 3.4.
+
+ An attribute type (a subtype) may derive from another attribute type
+ (a direct supertype). The subtype inherits the matching rules and
+
+
+
+Zeilenga LDAP Models [Page 12]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+
+
+ syntax of its supertype. An attribute type cannot be a subtype of an
+ attribute of different usage.
+
+ An attribute description consisting of a subtype and no options is
+ said to the direct description subtype of the attribute description
+ consisting of the subtype's direct supertype and no options.
+
+ Each attribute type is identified by an object identifier (OID) and,
+ optionally, one or more short names (descriptors).
+
+
+2.5.2. Attribute Options
+
+ There are multiple kinds of attribute description options. The LDAP
+ technical specification details one kind: tagging options.
+
+ Not all options can be associated with attributes held in the
+ directory. Tagging options can be.
+
+ Not all options can be use in conjunction with all attribute types.
+ In such cases, the attribute description is to be treated as
+ unrecognized.
+
+ An attribute description that contains mutually exclusive options
+ shall be treated as unrecognized. That is, "cn;x-bar;x-foo", where
+ "x-foo" and "x-bar" are mutually exclusive, is to be treated as
+ unrecognized.
+
+ Other kinds of options may be specified in future documents. These
+ documents must detail how new kinds of options they define relate to
+ tagging options. In particular, these documents must detail whether
+ or not new kinds of options can be associated with attributes held in
+ the directory, how new kinds of options affect transfer of attribute
+ values, and how new kinds of options are treated in attribute
+ description hierarchies.
+
+ Options are represented as short case insensitive textual strings
+ conforming to the <option> production defined in Section 2.5 of this
+ document.
+
+ Procedures for registering options are detailed in BCP 64 [RFC3383].
+
+
+2.5.2.1. Tagging Options
+
+ Attributes held in the directory can have attribute descriptions with
+ any number of tagging options. Tagging options are never mutually
+ exclusive.
+
+
+
+Zeilenga LDAP Models [Page 13]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+
+
+ An attribute description with N tagging options is considered a direct
+ (description) subtype of all attribute descriptions of the same
+ attribute type and all but one of the N options. If the attribute
+ type has a supertype, then the attribute description is also
+ considered a direct (description) subtype of the attribute description
+ of the supertype and the N tagging options. That is,
+ 'cn;lang-de;lang-en' is considered a direct subtype of 'cn;lang-de',
+ 'cn;lang-en', and 'name;lang-de;lang-en' ('cn' is a subtype of 'name',
+ both are defined in [Schema]).
+
+
+2.5.3. Attribute Description Hierarchies
+
+ An attribute description can be the direct subtype of zero or more
+ other attribute descriptions as indicated by attribute type subtyping
+ (as described in Section 2.5.1) or attribute tagging option subtyping
+ (as described in Section 2.5.2.1). These subtyping relationships are
+ used to form hierarchies of attribute descriptions and attributes.
+
+ As adapted from [X.501]:
+
+ Attribute hierarchies allow access to the DIB with varying degrees
+ of granularity. This is achieved by allowing the value components
+ of attributes to be accessed by using either their specific
+ attribute description (a direct reference to the attribute) or by
+ a more generic attribute description (an indirect reference).
+
+ Semantically related attributes may be placed in a hierarchical
+ relationship, the more specialized being placed subordinate to the
+ more generalized. Searching for, or retrieving attributes and
+ their values is made easier by quoting the more generalized
+ attribute description; a filter item so specified is evaluated for
+ the more specialized descriptions as well as for the quoted
+ description.
+
+ Where subordinate specialized descriptions are selected to be
+ returned as part of a search result these descriptions shall be
+ returned if available. Where the more general descriptions are
+ selected to be returned as part of a search result both the
+ general and the specialized descriptions shall be returned, if
+ available. An attribute value shall always be returned as a value
+ of its own attribute description.
+
+ All of the attribute descriptions in an attribute hierarchy are
+ treated as distinct and unrelated descriptions for user
+ modification of entry content.
+
+ An attribute value stored in a object or alias entry is of
+
+
+
+Zeilenga LDAP Models [Page 14]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+
+
+ precisely one attribute description. The description is indicated
+ when the value is originally added to the entry.
+
+ For the purpose of subschema administration of the entry, a required
+ attribute specification is fulfilled if the entry contains a value of
+ an attribute description belonging to an attribute hierarchy if the
+ attribute type of that description is the same as the required
+ attribute's type. That is, a "MUST name" specification is fulfilled
+ by 'name' or 'name;x-tag-option', but is not fulfilled by 'CN' nor by
+ 'CN;x-tag-option'. Likewise, an entry may contain a value of an
+ attribute description belonging to an attribute hierarchy if the
+ attribute type of that description is either explicitly included in
+ the definition of an object class to which the entry belongs or
+ allowed by the DIT content rule applicable to that entry. That is,
+ 'name' and 'name;x-tag-option' are allowed by "MAY name" (or by "MUST
+ name"), but 'CN' and 'CN;x-tag-option' are not allowed by "MAY name"
+ (nor by "MUST name").
+
+ For the purposes of other policy administration, unless stated
+ otherwise in the specification of the particular administrative model,
+ all of the attribute descriptions in an attribute hierarchy are
+ treated as distinct and unrelated descriptions.
+
+
+2.5.4. Attribute Values
+
+ Attribute values conform to the defined syntax of the attribute.
+
+ When an attribute is used for naming of the entry, one and only one
+ value of the attribute is selected to appear in the Relative
+ Distinguished Name. This value is known as a distinguished value.
+
+ Only attributes whose descriptions have no options can be used for
+ naming.
+
+
+2.6. Alias Entries
+
+ As adapted from [X.501]:
+
+ An alias, or an alias name, for an object is a an alternative name
+ for an object or object entry which is provided by the use of
+ alias entries.
+
+ Each alias entry contains, within the 'aliasedObjectName'
+ attribute (known as the 'aliasedEntryName' attribute in X.500]), a
+ name of some object. The distinguished name of the alias entry is
+ thus also a name for this object.
+
+
+
+Zeilenga LDAP Models [Page 15]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+
+
+ NOTE - The name within the 'aliasedObjectName' is said to be
+ pointed to by the alias. It does not have to be the
+ distinguished name of any entry.
+
+ The conversion of an alias name to an object name is termed
+ (alias) dereferencing and comprises the systematic replacement of
+ alias names, where found within a purported name, by the value of
+ the corresponding 'aliasedObjectName' attribute. The process may
+ require the examination of more than one alias entry.
+
+ Any particular entry in the DIT may have zero or more alias names.
+ It therefore follows that several alias entries may point to the
+ same entry. An alias entry may point to an entry that is not a
+ leaf entry and may point to another alias entry.
+
+ An alias entry shall have no subordinates, so that an alias entry
+ is always a leaf entry.
+
+ Every alias entry shall belong to the 'alias' object class.
+
+ An entry with the 'alias' object class must also belong to an object
+ class (or classes), or be governed by a DIT content rule, which allows
+ suitable naming attributes to be present.
+
+ Example:
+ dn: cn=bar,dc=example,dc=com
+ objectClass: top
+ objectClass: alias
+ objectClass: extensibleObject
+ cn: bar
+ aliasedObjectName: cn=foo,dc=example,dc=com
+
+
+2.6.1. 'alias' object class
+
+ Alias entries belong to the 'alias' object class.
+
+ ( 2.5.6.1 NAME 'alias'
+ SUP top STRUCTURAL
+ MUST aliasedObjectName )
+
+
+2.6.2. 'aliasedObjectName' attribute type
+
+ The 'aliasedObjectName' attribute holds the name of the entry an alias
+ points to. The 'aliasedObjectName' attribute is known as the
+ 'aliasedEntryName' attribute in X.500.
+
+
+
+
+Zeilenga LDAP Models [Page 16]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+
+
+ ( 2.5.4.1 NAME 'aliasedObjectName'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ SINGLE-VALUE )
+
+ The 'distinguishedNameMatch' matching rule and the DistinguishedName
+ (1.3.6.1.4.1.1466.115.121.1.12) syntax is defined in [Syntaxes].
+
+
+3. Directory Administrative and Operational Information
+
+ This section discusses select aspects of the X.500 Directory
+ Administrative and Operational Information model [X.501]. LDAP
+ implementations MAY support other aspects of this model.
+
+
+3.1. Subtrees
+
+ As defined in [X.501]:
+
+ A subtree is a collection of object and alias entries situated at
+ the vertices of a tree. Subtrees do not contain subentries. The
+ prefix sub, in subtree, emphasizes that the base (or root) vertex
+ of this tree is usually subordinate to the root of the DIT.
+
+ A subtree begins at some vertex and extends to some identifiable
+ lower boundary, possibly extending to leaves. A subtree is always
+ defined within a context which implicitly bounds the subtree. For
+ example, the vertex and lower boundaries of a subtree defining a
+ replicated area are bounded by a naming context. Similarly, the
+ scope of a subtree defining a specific administrative area is
+ limited to the context of an enclosing autonomous administrative
+ area.
+
+
+3.2. Subentries
+
+ A subentry is a "special sort of entry, known by the Directory, used
+ to hold information associated with a subtree or subtree refinement"
+ [X.501]. Subentries are used in Directory to hold for administrative
+ and operational purposes as defined in [X.501]. Their use in LDAP is
+ not detailed in this technical specification, but may be detailed in
+ future documents.
+
+ The term "(sub)entry" in this specification indicates that servers
+ implementing X.500(93) models are, in accordance with X.500(93), to
+ use a subentry and that other servers are to use an object entry
+ belonging to the appropriate auxiliary class normally used with the
+
+
+
+Zeilenga LDAP Models [Page 17]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+
+
+ subentry (e.g., 'subschema' for subschema subentries) to mimic the
+ subentry. This object entry's RDN SHALL be formed from a value of the
+ 'cn' (commonName) attribute [Schema].
+
+
+3.3. The 'objectClass' attribute
+
+ Each entry in the DIT has an 'objectClass' attribute.
+
+ ( 2.5.4.0 NAME 'objectClass'
+ EQUALITY objectIdentifierMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
+
+ The 'objectIdentifierMatch' matching rule and OBJECT IDENTIFIER
+ (1.3.6.1.4.1.1466.115.121.1.38) syntax is defined in [Syntaxes].
+
+ The 'objectClass' attribute specifies the object classes of an entry,
+ which (among other things) is used in conjunction with user and system
+ schema to determine the permitted attributes of an entry. Values of
+ this attribute can be modified by clients, but the 'objectClass'
+ attribute cannot be removed.
+
+ Servers which follow X.500(93) models SHALL restrict modifications of
+ this attribute to prevent the basic structural class of the entry from
+ being changed. That is, one cannot change a 'person' into a
+ 'country'.
+
+ When creating an entry or adding an 'objectClass' value to an entry,
+ all superclasses of the named classes SHALL be implicitly added as
+ well if not already present. That is, if the auxiliary class 'x-a' is
+ a subclass of the class 'x-b', adding 'x-a' to 'objectClass' causes
+ 'x-b' to added (if is not already present).
+
+ Servers SHALL restrict modifications of this attribute to prevent a
+ superclasses of remaining 'objectClass' values from being deleted.
+ That is, if the auxiliary class 'x-a' is a subclass of the auxiliary
+ class 'x-b' and the 'objectClass' attribute contains 'x-a' and 'x-b',
+ an attempt to delete only 'x-b' from the 'objectClass' attribute is an
+ error.
+
+
+3.4. Operational attributes
+
+ Some attributes, termed operational attributes, are used or maintained
+ by servers for administrative and operational purposes. As stated in
+ [X.501]: "There are three varieties of operational attributes:
+ Directory operational attributes, DSA-shared operational attributes,
+ and DSA-specific operational attributes."
+
+
+
+Zeilenga LDAP Models [Page 18]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+
+
+ A directory operational attribute is used to represent operational
+ and/or administrative information in the Directory Information Model.
+ This includes operational attributes maintained by the server (e.g.
+ 'createTimeStamp') as well as operational attributes which hold values
+ administrated by the user (e.g. 'ditContentRules').
+
+ A DSA-shared operational attribute is used to represent information of
+ the DSA Information Model. Its values, if shared between DSAs
+ (servers) are identical (except during periods of transient
+ inconsistency).
+
+ A DSA-specific operational attribute is used to represent information
+ of the DSA Information Model. Its values, if shared between DSAs
+ (servers), need not be identical.
+
+ The DSA Information Model operational attributes are detailed in
+ [X.501].
+
+ Operational attributes are not normally visible. They are not
+ returned in search results unless explicitly requested by name.
+
+ Not all operational attributes are user modifiable.
+
+ Entries may contain, among others, the following operational
+ attributes.
+
+ - creatorsName: the Distinguished Name of the user who added this
+ entry to the directory.
+
+ - createTimestamp: the time this entry was added to the directory.
+
+ - modifiersName: the Distinguished Name of the user who last
+ modified this entry.
+
+ - modifyTimestamp: the time this entry was last modified.
+
+ Servers SHOULD maintain the 'creatorsName', 'createTimestamp',
+ 'modifiersName', and 'modifyTimestamp' for all entries of the DIT.
+
+
+3.4.1. 'creatorsName'
+
+ This attribute appears in entries which were added using the protocol
+ (e.g., using the Add operation). The value is the distinguished name
+ of the creator.
+
+ ( 2.5.18.3 NAME 'creatorsName'
+ EQUALITY distinguishedNameMatch
+
+
+
+Zeilenga LDAP Models [Page 19]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+
+
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ SINGLE-VALUE NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+ The 'distinguishedNameMatch' matching rule and the DistinguishedName
+ (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes].
+
+
+3.4.2. 'createTimestamp'
+
+ This attribute appears in entries which were added using the protocol
+ (e.g., using the Add operation). The value is the time the entry was
+ added.
+
+ ( 2.5.18.1 NAME 'createTimestamp'
+ EQUALITY generalizedTimeMatch
+ ORDERING generalizedTimeOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+ SINGLE-VALUE NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+ The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch' matching
+ rules and the GeneralizedTime (1.3.6.1.4.1.1466.115.121.1.24) syntax
+ are defined in [Syntaxes].
+
+
+3.4.3. 'modifiersName'
+
+ This attribute appears in entries which have been modified using the
+ protocol (e.g., using Modify operation). The value is the
+ distinguished name of the last modifier.
+
+ ( 2.5.18.4 NAME 'modifiersName'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ SINGLE-VALUE NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+ The 'distinguishedNameMatch' matching rule and the DistinguishedName
+ (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes].
+
+
+3.4.4. 'modifyTimestamp'
+
+ This attribute appears in entries which have been modified using the
+ protocol (e.g., using the Modify operation). The value is the time
+ the entry was last modified.
+
+
+
+
+Zeilenga LDAP Models [Page 20]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+
+
+ ( 2.5.18.2 NAME 'modifyTimestamp'
+ EQUALITY generalizedTimeMatch
+ ORDERING generalizedTimeOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+ SINGLE-VALUE NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+ The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch' matching
+ rules and the GeneralizedTime (1.3.6.1.4.1.1466.115.121.1.24) syntax
+ are defined in [Syntaxes].
+
+
+4. Directory Schema
+
+ As defined in [X.501]:
+
+ The Directory Schema is a set of definitions and constraints
+ concerning the structure of the DIT, the possible ways entries are
+ named, the information that can be held in an entry, the
+ attributes used to represent that information and their
+ organization into hierarchies to facilitate search and retrieval
+ of the information and the ways in which values of attributes may
+ be matched in attribute value and matching rule assertions.
+
+ NOTE 1 - The schema enables the Directory system to, for example:
+
+ - prevent the creation of subordinate entries of the wrong
+ object-class (e.g. a country as a subordinate of a person);
+
+ - prevent the addition of attribute-types to an entry
+ inappropriate to the object-class (e.g. a serial number to a
+ person's entry);
+
+ - prevent the addition of an attribute value of a syntax not
+ matching that defined for the attribute-type (e.g. a printable
+ string to a bit string).
+
+ Formally, the Directory Schema comprises a set of:
+
+ a) Name Form definitions that define primitive naming relations
+ for structural object classes;
+
+ b) DIT Structure Rule definitions that define the names that
+ entries may have and the ways in which the entries may be
+ related to one another in the DIT;
+
+ c) DIT Content Rule definitions that extend the specification of
+ allowable attributes for entries beyond those indicated by the
+
+
+
+Zeilenga LDAP Models [Page 21]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+
+
+ structural object classes of the entries;
+
+ d) Object Class definitions that define the basic set of mandatory
+ and optional attributes that shall be present, and may be
+ present, respectively, in an entry of a given class, and which
+ indicate the kind of object class that is being defined;
+
+ e) Attribute Type definitions that identify the object identifier
+ by which an attribute is known, its syntax, associated matching
+ rules, whether it is an operational attribute and if so its
+ type, whether it is a collective attribute, whether it is
+ permitted to have multiple values and whether or not it is
+ derived from another attribute type;
+
+ f) Matching Rule definitions that define matching rules.
+
+ And in LDAP:
+
+ g) LDAP Syntaxes definitions that define encodings used in LDAP.
+
+
+4.1. Schema Definitions
+
+ Schema definitions in this section are described using ABNF and rely
+ on the common productions specified in Section 1.2 as well as these:
+
+ noidlen = numericoid [ LCURLY len RCURLY ]
+
+ len = number
+
+ oids = oid / ( LPAREN WSP oidlist WSP RPAREN )
+
+ oidlist = oid *( WSP DOLLAR WSP oid )
+
+ extensions = *( SP xstring SP qdstrings )
+
+ xstring = X HYPHEN 1*( ALPHA / HYPHEN / USCORE )
+
+ qdescrs = qdescr / ( LPAREN WSP qdescrlist WSP RPAREN )
+
+ qdescrlist = [ qdescr *( SP qdescr ) ]
+
+ qdescr = SQUOTE descr SQUOTE
+
+ qdstrings = qdstring / ( LPAREN WSP qdstringlist WSP RPAREN )
+
+ qdstringlist = [ qdstring *( SP qdstring ) ]
+
+
+
+
+Zeilenga LDAP Models [Page 22]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+
+
+ qdstring = SQUOTE dstring SQUOTE
+
+ dstring = 1*( QS / QQ / QUTF8 ) ; escaped UTF8 string
+
+ QQ = ESC %x32 %x37 ; "\27"
+
+ QS = ESC %x35 ( %x43 / %x63 ) ; "\5C" / "\5c"
+
+ ; Any UTF-8 encoded UCS character
+ ; except %x27 ("'") and %x5C ("\")
+ QUTF8 = QUTF1 / UTFMB
+
+ ; Any ASCII character except %x27 ("'") and %x5C ("\")
+ QUTF1 = %x00-26 / %x28-5B / %x5D-7F
+
+ Schema definitions in this section also share a number of common
+ terms.
+
+ The NAME field provides a set of short names (descriptors) which are
+ be used as aliases for the OID.
+
+ The DESC field optionally allows a descriptive string to be provided
+ by the directory administrator and/or implementor. While
+ specifications may suggest a descriptive string, there is no
+ requirement that the suggested (or any) descriptive string be used.
+
+ The OBSOLETE field, if present, indicates the element is not active.
+
+ Implementors should note that future versions of this document may
+ expand these definitions to include additional terms. Terms whose
+ identifier begins with "X-" are reserved for private experiments, and
+ are followed by <SP> and <qdstrings> tokens.
+
+
+4.1.1. Object Class Definitions
+
+ Object Class definitions are written according to the ABNF:
+
+ ObjectClassDescription = LPAREN WSP
+ numericoid ; object identifier
+ [ SP "NAME" SP qdescrs ] ; short names (descriptors)
+ [ SP "DESC" SP qdstring ] ; description
+ [ SP "OBSOLETE" ] ; not active
+ [ SP "SUP" SP oids ] ; superior object classes
+ [ SP kind ] ; kind of class
+ [ SP "MUST" SP oids ] ; attribute types
+ [ SP "MAY" SP oids ] ; attribute types
+ extensions WSP RPAREN
+
+
+
+Zeilenga LDAP Models [Page 23]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+
+
+ kind = "ABSTRACT" / "STRUCTURAL" / "AUXILIARY"
+
+ where:
+ <numericoid> is object identifier assigned to this object class;
+ NAME <qdescrs> are short names (descriptors) identifying this object
+ class;
+ DESC <qdstring> is a short descriptive string;
+ OBSOLETE indicates this object class is not active;
+ SUP <oids> specifies the direct superclasses of this object class;
+ the kind of object class is indicated by one of ABSTRACT,
+ STRUCTURAL, or AUXILIARY, default is STRUCTURAL;
+ MUST and MAY specify the sets of required and allowed attribute
+ types, respectively; and
+ <extensions> describe extensions.
+
+
+4.1.2. Attribute Types
+
+ Attribute Type definitions are written according to the ABNF:
+
+ AttributeTypeDescription = LPAREN WSP
+ numericoid ; object identifier
+ [ SP "NAME" SP qdescrs ] ; short names (descriptors)
+ [ SP "DESC" SP qdstring ] ; description
+ [ SP "OBSOLETE" ] ; not active
+ [ SP "SUP" SP oid ] ; subtype
+ [ SP "EQUALITY" SP oid ] ; equality matching rule
+ [ SP "ORDERING" SP oid ] ; ordering matching rule
+ [ SP "SUBSTR" SP oid ] ; substrings matching rule
+ [ SP "SYNTAX" SP noidlen ] ; value syntax
+ [ SP "SINGLE-VALUE" ] ; single-value
+ [ SP "COLLECTIVE" ] ; collective
+ [ SP "NO-USER-MODIFICATION" ] ; not user modifiable
+ [ SP "USAGE" SP usage ] ; usage
+ extensions WSP RPAREN ; extensions
+
+ usage = "userApplications" / ; user
+ "directoryOperation" / ; directory operational
+ "distributedOperation" / ; DSA-shared operational
+ "dSAOperation" ; DSA-specific operational
+
+ where:
+ <numericoid> is object identifier assigned to this attribute type;
+ NAME <qdescrs> are short names (descriptors) identifying this
+ attribute type;
+ DESC <qdstring> is a short descriptive string;
+ OBSOLETE indicates this attribute type is not active;
+ SUP oid specifies the direct supertype of this type;
+
+
+
+Zeilenga LDAP Models [Page 24]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+
+
+ EQUALITY, ORDERING, SUBSTRING provide the oid of the equality,
+ ordering, and substrings matching rules, respectively;
+ SYNTAX identifies value syntax by object identifier and may suggest
+ a minimum upper bound;
+ COLLECTIVE indicates this attribute type is collective [X.501];
+ NO-USER-MODIFICATION indicates this attribute type is not user
+ modifiable;
+ USAGE indicates the application of this attribute type; and
+ <extensions> describe extensions.
+
+ Each attribute type description must contain at least one of the SUP
+ or SYNTAX fields.
+
+ Usage of userApplications, the default, indicates that attributes of
+ this type represent user information. That is, they are user
+ attributes.
+
+ COLLECTIVE requires usage userApplications. Use of collective
+ attribute types in LDAP is not discussed in this technical
+ specification.
+
+ A usage of directoryOperation, distributedOperation, or dSAOperation
+ indicates that attributes of this type represent operational and/or
+ administrative information. That is, they are operational attributes.
+
+ directoryOperation usage indicates that the attribute of this type is
+ a directory operational attribute. distributedOperation usage
+ indicates that the attribute of this DSA-shared usage operational
+ attribute. dSAOperation usage indicates that the attribute of this
+ type is a DSA-specific operational attribute.
+
+ NO-USER-MODIFICATION requires an operational usage.
+
+ Note that the <AttributeTypeDescription> does not list the matching
+ rules which can be used with that attribute type in an extensibleMatch
+ search filter. This is done using the 'matchingRuleUse' attribute
+ described in Section 4.1.4.
+
+ This document refines the schema description of X.501 by requiring
+ that the SYNTAX field in an <AttributeTypeDescription> be a string
+ representation of an object identifier for the LDAP string syntax
+ definition with an optional indication of the suggested minimum bound
+ of a value of this attribute.
+
+ A suggested minimum upper bound on the number of characters in a value
+ with a string-based syntax, or the number of bytes in a value for all
+ other syntaxes, may be indicated by appending this bound count inside
+ of curly braces following the syntax's OBJECT IDENTIFIER in an
+
+
+
+Zeilenga LDAP Models [Page 25]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+
+
+ Attribute Type Description. This bound is not part of the syntax name
+ itself. For instance, "1.3.6.4.1.1466.0{64}" suggests that server
+ implementations should allow a string to be 64 characters long,
+ although they may allow longer strings. Note that a single character
+ of the Directory String syntax may be encoded in more than one octet
+ since UTF-8 is a variable-length encoding.
+
+
+4.1.3. Matching Rules
+
+ Matching rules are used by servers to compare attribute values against
+ assertion values when performing Search and Compare operations. They
+ are also used to identify the value to be added or deleted when
+ modifying entries, and are used when comparing a purported
+ distinguished name with the name of an entry.
+
+ A matching rule specifies the syntax of the assertion value.
+
+ Each matching rule is identified by an object identifier (OID) and,
+ optionally, one or more short names (descriptors).
+
+ Matching rule definitions are written according to the ABNF:
+
+ MatchingRuleDescription = LPAREN WSP
+ numericoid ; object identifier
+ [ SP "NAME" SP qdescrs ] ; short names (descriptors)
+ [ SP "DESC" SP qdstring ] ; description
+ [ SP "OBSOLETE" ] ; not active
+ SP "SYNTAX" SP numericoid ; assertion syntax
+ extensions WSP RPAREN ; extensions
+
+ where:
+ <numericoid> is object identifier assigned to this matching rule;
+ NAME <qdescrs> are short names (descriptors) identifying this
+ matching rule;
+ DESC <qdstring> is a short descriptive string;
+ OBSOLETE indicates this matching rule is not active;
+ SYNTAX identifies the assertion syntax by object identifier; and
+ <extensions> describe extensions.
+
+
+4.1.4. Matching Rule Uses
+
+ A matching rule use lists the attributes which are suitable for use
+ with an extensibleMatch search filter.
+
+ Matching rule use descriptions are written according to the following
+ ABNF:
+
+
+
+Zeilenga LDAP Models [Page 26]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+
+
+ MatchingRuleUseDescription = LPAREN WSP
+ numericoid ; object identifier
+ [ SP "NAME" SP qdescrs ] ; short names (descriptors)
+ [ SP "DESC" SP qdstring ] ; description
+ [ SP "OBSOLETE" ] ; not active
+ SP "APPLIES" SP oids ; attribute types
+ extensions WSP RPAREN ; extensions
+
+ where:
+ <numericoid> is the object identifier of the matching rule
+ associated with this matching rule use description;
+ NAME <qdescrs> are short names (descriptors) identifying this
+ matching rule use;
+ DESC <qdstring> is a short descriptive string;
+ OBSOLETE indicates this matching rule use is not active;
+ APPLIES provides a list of attribute types the matching rule applies
+ to; and
+ <extensions> describe extensions.
+
+
+4.1.5. LDAP Syntaxes
+
+ LDAP Syntaxes of (attribute and assertion) values are described in
+ terms of ASN.1 [X.680] and, optionally, have an octet string encoding
+ known as the LDAP-specific encoding. Commonly, the LDAP-specific
+ encoding is constrained to string of Universal Character Set (UCS)
+ [ISO10646] characters in UTF-8 [RFC2279] form.
+
+ Each LDAP syntax is identified by an object identifier (OID).
+
+ LDAP syntax definitions are written according to the ABNF:
+
+ SyntaxDescription = LPAREN WSP
+ numericoid ; object identifier
+ [ SP "DESC" SP qdstring ] ; description
+ extensions WSP RPAREN ; extensions
+
+ where:
+ <numericoid> is object identifier assigned to this LDAP syntax;
+ DESC <qdstring> is a short descriptive string; and
+ <extensions> describe extensions.
+
+
+4.1.6. DIT Content Rules
+
+ A DIT content rule is a "rule governing the content of entries of a
+ particular structural object class" [X.501].
+
+
+
+
+Zeilenga LDAP Models [Page 27]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+
+
+ For DIT entries of a particular structural object class, a DIT content
+ rule specifies which auxiliary object classes the entries are allowed
+ to belong to and which additional attributes (by type) are required,
+ allowed or not allowed to appear in the entries.
+
+ The list of precluded attributes cannot include any attribute listed
+ as mandatory in rule, the structural object class, or any of the
+ allowed auxiliary object classes.
+
+ Each content rule is identified by the object identifier, as well as
+ any short names (descriptors), of the structural object class it
+ applies to.
+
+ An entry may only belong to auxiliary object classes listed in the
+ governing content rule.
+
+ An entry must contain all attributes required by the object classes
+ the entry belongs to as well as all attributed required by the
+ governing content rule.
+
+ An entry may contain any non-precluded attributes allowed by the
+ object classes the entry belongs to as well as all attributes allowed
+ by the governing content rule.
+
+ An entry cannot include any attribute precluded by the governing
+ content rule.
+
+ An entry is governed by (if present and active in the subschema) the
+ DIT content rule which applies to the structural object class of the
+ entry (see Section 2.4.2). If no active rule is present for the
+ entry's structural object class, the entry's content is governed by
+ the structural object class (and possibly other aspects of user and
+ system schema).
+
+ DIT content rule descriptions are written according to the ABNF:
+
+ DITContentRuleDescription = LPAREN WSP
+ numericoid ; object identifier
+ [ SP "NAME" SP qdescrs ] ; short names (descriptors)
+ [ SP "DESC" SP qdstring ] ; description
+ [ SP "OBSOLETE" ] ; not active
+ [ SP "AUX" SP oids ] ; auxiliary object classes
+ [ SP "MUST" SP oids ] ; attribute types
+ [ SP "MAY" SP oids ] ; attribute types
+ [ SP "NOT" SP oids ] ; attribute types
+ extensions WSP RPAREN ; extensions
+
+ where:
+
+
+
+Zeilenga LDAP Models [Page 28]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+
+
+ <numericoid> is the object identifier of the structural object class
+ associated with this DIT content rule;
+ NAME <qdescrs> are short names (descriptors) identifying this DIT
+ content rule;
+ DESC <qdstring> is a short descriptive string;
+ OBSOLETE indicates this DIT content rule use is not active;
+ AUX specifies a list of auxiliary object classes which entries
+ subject to this DIT content rule may belong to;
+ MUST, MAY, and NOT specify lists of attribute types which are
+ required, allowed, or precluded, respectively, from appearing in
+ entries subject to this DIT content rule; and
+ <extensions> describe extensions.
+
+
+4.1.7. DIT Structure Rules and Name Forms
+
+ It is sometimes desirable to regulate where object entries can be
+ placed in the DIT and how they can be named based upon their
+ structural object class.
+
+
+4.1.7.1. DIT Structure Rules
+
+ A DIT structure rule is a "rule governing the structure of the DIT by
+ specifying a permitted superior to subordinate entry relationship. A
+ structure rule relates a name form, and therefore a structural object
+ class, to superior structure rules. This permits entries of the
+ structural object class identified by the name form to exist in the
+ DIT as subordinates to entries governed by the indicated superior
+ structure rules" [X.501].
+
+ DIT structure rule descriptions are written according to the ABNF:
+
+ DITStructureRuleDescription = LPAREN WSP
+ ruleid ; rule identifier
+ [ SP "NAME" SP qdescrs ] ; short names (descriptors)
+ [ SP "DESC" SP qdstring ] ; description
+ [ SP "OBSOLETE" ] ; not active
+ SP "FORM" SP oid ; NameForm
+ [ SP "SUP" ruleids ] ; superior rules
+ extensions WSP RPAREN ; extensions
+
+ ruleids = ruleid / ( LPAREN WSP ruleidlist WSP RPAREN )
+
+ ruleidlist = ruleid *( SP ruleid )
+
+ ruleid = number
+
+
+
+
+Zeilenga LDAP Models [Page 29]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+
+
+ where:
+ <ruleid> is the rule identifier of this DIT structure rule;
+ NAME <qdescrs> are short names (descriptors) identifying this DIT
+ structure rule;
+ DESC <qdstring> is a short descriptive string;
+ OBSOLETE indicates this DIT structure rule use is not active;
+ FORM is specifies the name form associated with this DIT structure
+ rule;
+ SUP identifies superior rules (by rule id); and
+ <extensions> describe extensions.
+
+ If no superior rules are identified, the DIT structure rule applies
+ to an autonomous administrative point (e.g. the root vertex of the
+ subtree controlled by the subschema) [X.501].
+
+
+4.1.7.2. Name Forms
+
+ A name form "specifies a permissible RDN for entries of a particular
+ structural object class. A name form identifies a named object
+ class and one or more attribute types to be used for naming (i.e.
+ for the RDN). Name forms are primitive pieces of specification
+ used in the definition of DIT structure rules" [X.501].
+
+ Each name form indicates the structural object class to be named,
+ a set of required attribute types, and a set of allowed attributes
+ types. A particular attribute type cannot be listed in both sets.
+
+ Entries governed by the form must be named using a value from each
+ required attribute type and zero or more values from the allowed
+ attribute types.
+
+ Each name form is identified by an object identifier (OID) and,
+ optionally, one or more short names (descriptors).
+
+ Name form descriptions are written according to the ABNF:
+
+ NameFormDescription = LPAREN WSP
+ numericoid ; object identifier
+ [ SP "NAME" SP qdescrs ] ; short names (descriptors)
+ [ SP "DESC" SP qdstring ] ; description
+ [ SP "OBSOLETE" ] ; not active
+ SP "OC" SP oid ; structural object class
+ SP "MUST" SP oids ; attribute types
+ [ SP "MAY" SP oids ] ; attribute types
+ extensions WSP RPAREN ; extensions
+
+ where:
+
+
+
+Zeilenga LDAP Models [Page 30]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+
+
+ <numericoid> is object identifier which identifies this name form;
+ NAME <qdescrs> are short names (descriptors) identifying this name
+ form;
+ DESC <qdstring> is a short descriptive string;
+ OBSOLETE indicates this name form is not active;
+ OC identifies the structural object class this rule applies to,
+ MUST and MAY specify the sets of required and allowed, respectively,
+ naming attributes for this name form; and
+ <extensions> describe extensions.
+
+ All attribute types in the required ("MUST") and allowed ("MAY") lists
+ shall be different.
+
+
+4.2. Subschema Subentries
+
+ Subschema (sub)entries are used for administering information about
+ the directory schema. A single subschema (sub)entry contains all
+ schema definitions (see Section 4.1) used by entries in a particular
+ part of the directory tree.
+
+ Servers which follow X.500(93) models SHOULD implement subschema using
+ the X.500 subschema mechanisms (as detailed in Section 12 of [X.501]),
+ and so these are not ordinary object entries but subentries (see
+ Section 3.2). LDAP clients SHOULD NOT assume that servers implement
+ any of the other aspects of X.500 subschema.
+
+ Servers MAY allow subschema modification. Procedures for subschema
+ modification are discussed in Section 14.5 of [X.501].
+
+ A server which masters entries and permits clients to modify these
+ entries SHALL implement and provide access to these subschema
+ (sub)entries including providing a 'subschemaSubentry' attribute in
+ each modifiable entry. This so clients may discover the attributes
+ and object classes which are permitted to be present. It is strongly
+ RECOMMENDED that all other servers implement this as well.
+
+ The value of the 'subschemaSubentry' attribute is the name of the
+ subschema (sub)entry holding the subschema controlling the entry.
+
+ ( 2.5.18.10 NAME 'subschemaSubentry'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ NO-USER-MODIFICATION SINGLE-VALUE
+ USAGE directoryOperation )
+
+ The 'distinguishedNameMatch' matching rule and the DistinguishedName
+ (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes].
+
+
+
+Zeilenga LDAP Models [Page 31]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+
+
+ Subschema is held in (sub)entries belonging to the subschema auxiliary
+ object class.
+
+ ( 2.5.20.1 NAME 'subschema' AUXILIARY
+ MAY ( dITStructureRules $ nameForms $ ditContentRules $
+ objectClasses $ attributeTypes $ matchingRules $
+ matchingRuleUse ) )
+
+ The 'ldapSyntaxes' operational attribute may also be present in
+ subschema entries.
+
+ Servers MAY provide additional attributes (described in other
+ documents) in subschema (sub)entries.
+
+ Servers SHOULD provide the attributes 'createTimestamp' and
+ 'modifyTimestamp' in subschema (sub)entries, in order to allow clients
+ to maintain their caches of schema information.
+
+ The following subsections provide attribute type definitions for each
+ of schema definition attribute types.
+
+
+4.2.1. 'objectClasses'
+
+ This attribute holds definitions of object classes.
+
+ ( 2.5.21.6 NAME 'objectClasses'
+ EQUALITY objectIdentifierFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.37
+ USAGE directoryOperation )
+
+ The 'objectIdentifierFirstComponentMatch' matching rule and the
+ ObjectClassDescription (1.3.6.1.4.1.1466.115.121.1.37) syntax are
+ defined in [Syntaxes].
+
+
+4.2.2. 'attributeTypes'
+
+ This attribute holds definitions of attribute types.
+
+ ( 2.5.21.5 NAME 'attributeTypes'
+ EQUALITY objectIdentifierFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.3
+ USAGE directoryOperation )
+
+ The 'objectIdentifierFirstComponentMatch' matching rule and the
+ AttributeTypeDescription (1.3.6.1.4.1.1466.115.121.1.3) syntax are
+ defined in [Syntaxes].
+
+
+
+Zeilenga LDAP Models [Page 32]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+
+
+4.2.3. 'matchingRules'
+
+ This attribute holds definitions of matching rules.
+
+ ( 2.5.21.4 NAME 'matchingRules'
+ EQUALITY objectIdentifierFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.30
+ USAGE directoryOperation )
+
+ The 'objectIdentifierFirstComponentMatch' matching rule and the
+ MatchingRuleDescription (1.3.6.1.4.1.1466.115.121.1.30) syntax are
+ defined in [Syntaxes].
+
+
+4.2.4 'matchingRuleUse'
+
+ This attribute holds definitions of matching rule uses.
+
+ ( 2.5.21.8 NAME 'matchingRuleUse'
+ EQUALITY objectIdentifierFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.31
+ USAGE directoryOperation )
+
+ The 'objectIdentifierFirstComponentMatch' matching rule and the
+ MatchingRuleUseDescription (1.3.6.1.4.1.1466.115.121.1.31) syntax are
+ defined in [Syntaxes].
+
+
+4.2.5. 'ldapSyntaxes'
+
+ This attribute holds definitions of LDAP syntaxes.
+
+ ( 1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes'
+ EQUALITY objectIdentifierFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.54
+ USAGE directoryOperation )
+
+ The 'objectIdentifierFirstComponentMatch' matching rule and the
+ SyntaxDescription (1.3.6.1.4.1.1466.115.121.1.54) syntax are defined
+ in [Syntaxes].
+
+
+4.2.6. 'dITContentRules'
+
+ This attribute lists DIT Content Rules which are in force.
+
+ ( 2.5.21.2 NAME 'dITContentRules'
+ EQUALITY objectIdentifierFirstComponentMatch
+
+
+
+Zeilenga LDAP Models [Page 33]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+
+
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.16
+ USAGE directoryOperation )
+
+ The 'objectIdentifierFirstComponentMatch' matching rule and the
+ DITContentRuleDescription (1.3.6.1.4.1.1466.115.121.1.16) syntax are
+ defined in [Syntaxes].
+
+
+4.2.7. 'dITStructureRules'
+
+ This attribute lists DIT Structure Rules which are in force.
+
+ ( 2.5.21.1 NAME 'dITStructureRules'
+ EQUALITY integerFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.17
+ USAGE directoryOperation )
+
+ The 'integerFirstComponentMatch' matching rule and the
+ DITStructureRuleDescription (1.3.6.1.4.1.1466.115.121.1.17) syntax are
+ defined in [Syntaxes].
+
+
+4.2.8 'nameForms'
+
+ This attribute lists Name Forms which are in force.
+
+ ( 2.5.21.7 NAME 'nameForms'
+ EQUALITY objectIdentifierFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.35
+ USAGE directoryOperation )
+
+ The 'objectIdentifierFirstComponentMatch' matching rule and the
+ NameFormDescription (1.3.6.1.4.1.1466.115.121.1.35) syntax are defined
+ in [Syntaxes].
+
+
+4.3. 'extensibleObject' object class
+
+ The 'extensibleObject auxiliary object class allows entries belong to
+ it to hold any attribute type. The set of allowed attributes of this
+ class is implicitly the set of all user attributes.
+
+ ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject'
+ SUP top AUXILIARY )
+
+ The mandatory attributes of the other object classes of this entry are
+ still required to be present and any precluded attributes are still
+ not allowed to be present.
+
+
+
+Zeilenga LDAP Models [Page 34]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+
+
+ Note that not all servers will implement this object class, and those
+ which do not will reject requests to add entries which contain this
+ object class, or modify an entry to add this object class.
+
+
+4.4. Subschema Discovery
+
+ To discover the DN of the subschema (sub)entry holding the subschema
+ controlling a particular entry, a client reads that entry's
+ 'subschemaSubentry' operational attribute. To read schema attributes
+ from the subschema (sub)entry, clients MUST issue a base object search
+ where the filter is "(objectClass=subschema)" [Filters] and the list
+ of attributes includes the names of the desired schema attributes (as
+ they are operational). This filter allows LDAP servers which gateway
+ to X.500 to detect that subentry information is being requested.
+
+ Clients SHOULD NOT assume a published subschema is complete nor assume
+ the server supports all of the schema elements it publishes nor assume
+ the server does not support an unpublished element.
+
+
+5. DSA (Server) Informational Model
+
+ The LDAP protocol assumes there are one or more servers which jointly
+ provide access to a Directory Information Tree (DIT).
+
+ As defined in [X.501]:
+
+ context prefix: The sequence of RDNs leading from the Root of the
+ DIT to the initial vertex of a naming context; corresponds to
+ the distinguished name of that vertex.
+
+ DIB fragment: The portion of the DIB that is held by one master
+ DSA, comprising one or more naming contexts.
+
+ naming context: A subtree of entries held in a single master DSA.
+
+ That is, a naming context is the largest collection of entries,
+ starting at an entry that is mastered by a particular server, and
+ including all its subordinates and their subordinates, down to the
+ entries which are mastered by different servers. The context prefix
+ is the name of the initial entry.
+
+ The root of the DIT is a DSA-specific Entry (DSE) and not part of any
+ naming context (or any subtree); each server has different attribute
+ values in the root DSE.
+
+
+
+
+
+Zeilenga LDAP Models [Page 35]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+
+
+5.1. Server-specific Data Requirements
+
+ An LDAP server SHALL provide information about itself and other
+ information that is specific to each server. This is represented as a
+ group of attributes located in the root DSE (DSA-Specific Entry),
+ which is named with the zero-length LDAPDN. These attributes are
+ retrievable, subject to access control and other restrictions, if a
+ client performs a base object search of the root with the filter
+ "(objectClass=*)" [Filters] requesting the desired attributes. It is
+ noted that root DSE attributes are operational, and like other
+ operational attributes, are not returned in search requests unless
+ requested by name.
+
+ The root DSE SHALL NOT be included if the client performs a subtree
+ search starting from the root.
+
+ Servers may allow clients to modify attributes of the root DSE where
+ appropriate.
+
+ The following attributes of the root DSE are defined in [Syntaxes].
+ Additional attributes may be defined in other documents.
+
+ - altServer: alternative servers;
+
+ - namingContexts: naming contexts;
+
+ - supportedControl: recognized LDAP controls;
+
+ - supportedExtension: recognized LDAP extended operations;
+
+ - supportedLDAPVersion: LDAP versions supported; and
+
+ - supportedSASLMechanisms: recognized SASL mechnanisms.
+
+ The values of these attributes provided may depend on session specific
+ and other factors. For example, a server supporting the SASL EXTERNAL
+ mechanism might only list "EXTERNAL" when the client's identity has
+ been established by a lower level. See [AuthMeth].
+
+ The root DSE may also include a 'subschemaSubentry' attribute. If so,
+ it refers to the subschema (sub)entry holding schema controlling
+ attributes of the root DSE. Client SHOULD NOT assume that the
+ subschema (sub)entry controlling the root DSE controls any entry held
+ by the server. General subschema discovery procedures are provided in
+ Section 4.4.
+
+
+5.1.1. 'altServer'
+
+
+
+Zeilenga LDAP Models [Page 36]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+
+
+ The 'altServer' attribute lists URLs referring to alternative servers
+ which may be contacted when this server becomes unavailable. If the
+ server does not know of any other servers which could be used this
+ attribute will be absent. Clients may cache this information in case
+ their preferred server later becomes unavailable.
+
+ ( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
+ USAGE dSAOperation )
+
+ The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax is defined in
+ [Syntaxes].
+
+
+5.1.2. 'namingContexts'
+
+ The 'namingContexts' attribute lists the context prefixes of the
+ naming contexts the server masters or shadows (in part or in whole).
+ If the server is a first-level DSA [X.501], it should list (in
+ addition) an empty string (indicating the root of the DIT). If the
+ server does not master or shadow any information (e.g. it is an LDAP
+ gateway to a public X.500 directory) this attribute will be absent.
+ If the server believes it masters or shadows the entire directory, the
+ attribute will have a single value, and that value will be the empty
+ string (indicating the root of the DIT). This attribute allows a
+ client to choose suitable base objects for searching when it has
+ contacted a server.
+
+ ( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ USAGE dSAOperation )
+
+ The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax is
+ defined in [Syntaxes].
+
+
+5.1.3. 'supportedControl'
+
+ The 'supportedControl' attribute lists object identifiers identifying
+ the request controls the server supports. If the server does not
+ support any request controls, this attribute will be absent.
+
+ Object identifiers identifying response controls need not be listed.
+
+ Procedures for registering object identifiers used to discovery of
+ protocol mechanisms are detailed in BCP 64 [RFC3383].
+
+ ( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl'
+
+
+
+Zeilenga LDAP Models [Page 37]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+
+
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
+ USAGE dSAOperation )
+
+ The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is
+ defined in [Syntaxes].
+
+
+5.1.4. 'supportedExtension'
+
+ The 'supportedExtension' attribute lists object identifiers
+ identifying the extended operations which the server supports. If the
+ server does not support any extended operations, this attribute will
+ be absent.
+
+ An extended operation comprises a ExtendedRequest, possibly other PDUs
+ defined by extension, and an ExtendedResponse [Protocol]. The object
+ identifier assigned to the ExtendedRequest is used to identify the
+ extended operation. Other object identifiers associated with the
+ extended operation need not be listed.
+
+ Procedures for registering object identifiers used to discovery of
+ protocol mechanisms are detailed in BCP 64 [RFC3383].
+
+ ( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
+ USAGE dSAOperation )
+
+ The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is
+ defined in [Syntaxes].
+
+
+5.1.5. 'supportedLDAPVersion'
+
+ The 'supportedLDAPVersion' attribute lists the versions of LDAP which
+ the server supports.
+
+ ( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ USAGE dSAOperation )
+
+ The INTEGER (1.3.6.1.4.1.1466.115.121.1.27) syntax are defined in
+ [Syntaxes].
+
+
+5.1.6. 'supportedSASLMechanisms'
+
+ The 'supportedSASLMechanisms' attribute lists the SASL mechanisms
+ [RFC2222] which the server recognizes. The contents of this attribute
+
+
+
+Zeilenga LDAP Models [Page 38]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+
+
+ may depend on the current session state. If the server does not
+ support any SASL mechanisms this attribute will not be present.
+
+ ( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ USAGE dSAOperation )
+
+ The Directory String (1.3.6.1.4.1.1466.115.121.1.15) syntax is defined
+ in [Syntaxes].
+
+
+6. Other Considerations
+
+6.1. Preservation of User Information
+
+ Syntaxes may be defined which have specific value and/or value form
+ (representation) preservation requirements. For example, a syntax
+ containing digitally signed data can mandate the server preserve both
+ the value and form of value presented to ensure signature is not
+ invalidated.
+
+ Where such requirements have not be explicitly stated, servers SHOULD
+ preserve the value of user information but MAY return the value in a
+ different form. And where a server is unable (or unwilling) to
+ preserve the value of user information, the server SHALL ensure that
+ an equivalent value (per Section 2.3) is returned.
+
+
+6.2. Short Names
+
+ Short names, also known as descriptors, are used as more readable
+ aliases for object identifiers and are used to identify various schema
+ elements. However, it is not expected that LDAP implementations with
+ human user interface would display these short names (nor the object
+ identifiers they refer to) to the user, but would most likely be
+ performing translations (such as expressing the short name in one of
+ the local national languages). For example, the short name "st"
+ (stateOrProvinceName) might be displayed to a German-speaking user as
+ "Land".
+
+ The same short name might have different meaning in different
+ subschemas and, within a particular subschema, the same short name
+ might refer to different object identifiers each identifying a
+ different kind of schema element.
+
+ Implementations MUST be prepared that the same short name might be
+ used in a subschema to refer to the different kinds of schema
+ elements. That is, there might be an object class 'x-fubar' and an
+
+
+
+Zeilenga LDAP Models [Page 39]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+
+
+ attribute type 'x-fubar' in a subschema.
+
+ Implementations MUST be prepared that the same short name might be
+ used in the different subschemas to refer to the different schema
+ elements. That is, there might be two matching rules 'x-fubar', each
+ in different subschemas.
+
+ Procedures for registering short names (descriptors) are detailed in
+ BCP 64 [RFC3383bis].
+
+ [[The remainder of this subsection will be included a subsequent
+ revision of RFC 3383.]]
+
+ To avoid interoperability problems, the following additional
+ considerations are stated:
+
+ Descriptors used to identify various schema elements SHOULD be
+ registered unless in private-use name space (e.g., they begin with
+ "x-"). Descriptors defined in RFCs MUST be registered.
+
+ While the protocol allows the same descriptor to refer to
+ different object identifiers in certain cases and the registry
+ supports multiple registrations of the same descriptor (each
+ indicating a different kind of schema element and different object
+ identifier), multiple registrations of the same descriptor are to
+ be avoided. All such registration requests require Expert Review.
+
+
+6.3. Cache and Shadowing
+
+ Some servers may hold cache or shadow copies of entries, which can be
+ used to answer search and comparison queries, but will return
+ referrals or contact other servers if modification operations are
+ requested. Servers that perform shadowing or caching MUST ensure that
+ they do not violate any access control constraints placed on the data
+ by the originating server.
+
+
+7. Implementation Guidelines
+
+7.1 Server Guidelines
+
+ Servers MUST recognize all attribute types and object classes names
+ defined in this document but, unless stated otherwise, need not
+ support the associated functionality. Servers SHOULD recognize all
+ the names of attribute types and object classes defined in Section 3
+ and 4, respectively, of [Schema].
+
+
+
+
+Zeilenga LDAP Models [Page 40]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+
+
+ Servers MUST ensure that entries conform to user and system schema
+ rules or other data model constraints.
+
+ Servers MAY support the 'extensibleObject' object class.
+
+ Servers MAY support DIT Content Rules. Servers MAY support DIT
+ Structure Rules and Name Forms.
+
+ Servers MAY support alias entries.
+
+ Servers MAY support subentries. If so, they MUST do so in accordance
+ with [X.501]. Servers which do not support subentries SHOULD use
+ object entries to mimic subentries as detailed in Section 3.2.
+
+ Servers MAY implement additional schema elements. Servers SHOULD
+ provide definitions of all schema elements they support in subschema
+ (sub)entries.
+
+
+7.2 Client Guidelines
+
+ Clients MUST NOT display nor attempt to decode as ASN.1, a value if
+ its syntax is not known. The implementation may attempt to discover
+ the subschema of the source entry, and retrieve the values of
+ 'attributeTypes' from the subschema (sub)entry.
+
+ Clients MUST NOT assume the LDAP-specific string encoding is
+ restricted to a UTF-8 encoded string of UCS characters or any
+ particular subset of particular subset of UCS (such as a printable
+ subset) unless such restriction is explicitly stated.
+
+ Clients MUST NOT send attribute values in a request that are not valid
+ according to the syntax defined for the attributes.
+
+
+8. Security Considerations
+
+ Attributes of directory entries are used to provide descriptive
+ information about the real-world objects they represent, which can be
+ people, organizations or devices. Most countries have privacy laws
+ regarding the publication of information about people.
+
+ General security considerations for accessing directory information
+ with LDAP are discussed in [Protocol] and [AuthMeth].
+
+
+9. IANA Considerations
+
+
+
+
+Zeilenga LDAP Models [Page 41]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+
+
+ It is requested that the Internet Assigned Numbers Authority (IANA)
+ update the LDAP descriptors registry as indicated the following
+ template:
+
+ Subject: Request for LDAP Descriptor Registration Update
+ Descriptor (short name): see comment
+ Object Identifier: see comment
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@OpenLDAP.org>
+ Usage: see comment
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+ Comments:
+
+ The following descriptors (short names) should be updated to refer
+ to RFC XXXX.
+
+ NAME Type OID
+ ------------------------ ---- -----------------
+ alias O 2.5.6.1
+ aliasedEntryName A 2.5.4.1
+ aliasedObjectName A 2.5.4.1
+ altServer A 1.3.6.1.4.1.1466.101.120.6
+ attributeTypes A 2.5.21.5
+ createTimestamp A 2.5.18.1
+ creatorsName A 2.5.18.3
+ dITContentRules A 2.5.21.2
+ dITStructureRules A 2.5.21.1
+ extensibleObject O 1.3.6.1.4.1.1466.101.120.111
+ ldapSyntaxes A 1.3.6.1.4.1.1466.101.120.16
+ matchingRuleUse A 2.5.21.8
+ matchingRules A 2.5.21.4
+ modifiersName A 2.5.18.4
+ modifyTimestamp A 2.5.18.2
+ nameForms A 2.5.21.7
+ namingContexts A 1.3.6.1.4.1.1466.101.120.5
+ objectClass A 2.5.4.0
+ objectClasses A 2.5.21.6
+ subschema O 2.5.20.1
+ subschemaSubentry A 2.5.18.10
+ supportedControl A 1.3.6.1.4.1.1466.101.120.13
+ supportedExtension A 1.3.6.1.4.1.1466.101.120.7
+ supportedLDAPVersion A 1.3.6.1.4.1.1466.101.120.15
+ supportedSASLMechanisms A 1.3.6.1.4.1.1466.101.120.14
+ top O 2.5.6.0
+
+
+10. Acknowledgments
+
+
+
+Zeilenga LDAP Models [Page 42]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+
+
+ This document is based in part on RFC 2251 by M. Wahl, T. Howes, and
+ S. Kille; RFC 2252 by M. Wahl, A. Coulbeck, T. Howes, S. Kille; and
+ RFC 2556 by M. Wahl, all products of the IETF Access, Searching and
+ Indexing of Directories (ASID) Working Group. This document is also
+ based in part on "The Directory: Models" [X.501], a product of the
+ International Telephone Union (ITU). Additional text was borrowed
+ from RFC 2253 by Mark Wahl, Tim Howes, and Steve Kille.
+
+ This document is a product of the IETF LDAPBIS Working Group.
+
+
+11. Author's Address
+
+ Kurt Zeilenga
+ E-mail: <kurt@openldap.org>
+
+
+12. References
+
+12.1. Normative References
+
+ [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
+ RFC 2279, January 1998.
+
+ [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+
+ [RFC2234] Crocker, D., and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [RFC3383] K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also
+ RFC 3383), September 2002.
+
+ [Roadmap] K. Zeilenga (editor), "LDAP: Technical Specification Road
+ Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
+ progress.
+
+ [Protocol] J. Sermersheim (editor), "LDAP: The Protocol",
+ draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
+
+ [AuthMeth] R. Harrison (editor), "LDAP: Authentication Methods and
+ Connection Level Security Mechanisms",
+ draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
+
+ [LDAPDN] K. Zeilenga (editor), "LDAP: String Representation of
+ Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work
+ in progress.
+
+
+
+
+Zeilenga LDAP Models [Page 43]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+
+
+ [Filters] M. Smith (editor), LDAPbis WG, "LDAP: String Representation
+ of Search Filters", draft-ietf-ldapbis-filter-xx.txt, a
+ work in progress.
+
+ [LDAPURL] M. Smith (editor), "LDAP: Uniform Resource Locator",
+ draft-ietf-ldapbis-url-xx.txt, a work in progress.
+
+ [Syntaxes] S. Legg (editor), "LDAP: Syntaxes",
+ draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
+
+ [Schema] K. Dally (editor), "LDAP: User Schema",
+ draft-ietf-ldapbis-user-schema-xx.txt, a work in progress.
+
+ [ISO10646] Universal Multiple-Octet Coded Character Set (UCS) -
+ Architecture and Basic Multilingual Plane, ISO/IEC 10646-1
+ : 1993.
+
+ [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.680] ITU-T Rec. X.680, "Abstract Syntax Notation One (ASN.1) -
+ Specification of Basic Notation", 1994.
+
+
+12.2. Informative References
+
+ None.
+
+
+Appendix A. Changes
+
+ This appendix is non-normative.
+
+ This document amounts to nearly a complete rewrite of portions of RFC
+ 2251, RFC 2252, and RFC 2256. This rewrite was undertaken to improve
+ overall clarity of technical specification. This appendix provides a
+ summary of substantive changes made to the portions of these documents
+ incorporated into this document. Readers should consult [Roadmap],
+ [Protocol], [Syntaxes], and [Schema] for summaries of remaining
+ portions of these documents.
+
+
+A.1 Changes to RFC 2251
+
+ This document incorporates from RFC 2251 sections 3.2 and 3.4,
+ portions of Section 4 and 6 as summarized below.
+
+
+
+Zeilenga LDAP Models [Page 44]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+
+
+A.1.1 Section 3.2 of RFC 2251
+
+ Section 3.2 of RFC 2251 provided a brief introduction to the X.500
+ data model, as used by LDAP. The previous specification relied on
+ [X.501] but lacked clarity in how X.500 models are adapted for use by
+ LDAP. This document describes the X.500 data models, as used by LDAP
+ in greater detail, especially in areas where the models require
+ adaptation is needed.
+
+ Section 3.2.1 of RFC 2251 described an attribute as "a type with one
+ or more associated values." In LDAP, an attribute is better described
+ as an attribute description, a type with zero or more options, and one
+ or more associated values.
+
+ Section 3.2.2 of RFC 2251 mandated that subschema subentries contain
+ objectClasses and attributeTypes attributes, yet X.500(93) treats
+ these attributes as optional. While generally all implementations
+ that support X.500(93) subschema mechanisms will provide both of these
+ attributes, it is not absolutely required for interoperability that
+ all servers do. The mandate was removed for consistency with
+ X.500(93). The subschema discovery mechanism was also clarified to
+ indicate that subschema controlling an entry is obtained by reading
+ the (sub)entry referred to by that entry's 'subschemaSubentry'
+ attribute.
+
+
+A.1.2 Section 3.4 of RFC 2251
+
+ Section 3.4 of RFC 2251 provided "Server-specific Data Requirements".
+ This material, with changes, was incorporated in Section 5.1 of this
+ document.
+
+ Changes:
+
+ - Clarify that attributes of the root DSE are subject to "other
+ restrictions" in addition to acccess controls.
+
+ - Clarify that only recognized extended requests need to be enumerated
+ 'supportedExtension'.
+
+ - Clarify that only recognized request controls need to be enumerated
+ 'supportedControl'.
+
+ - Clarify that root DSE attributes are operational and, like other
+ operational attributes, will not be returned in search requests
+ unless requested by name.
+
+ - Clarify that not all root DSE attributes are user modifiable.
+
+
+
+Zeilenga LDAP Models [Page 45]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+
+
+ - Remove inconsistent text regarding handling of the
+ 'subschemaSubentry' attribute within the root DSE. The previous
+ specification stated that the 'subschemaSubentry' attribute held in
+ the root DSE referred to "subschema entries (or subentries) known by
+ this server." This is inconsistent with the attribute intended use
+ as well as its formal definition as a single valued attribute
+ [X.501]. It is also noted that a simple (possibly incomplete) list
+ of subschema (sub)entries is not terrible useful. This document (in
+ section 5.1) specifies that the 'subschemaSubentry' attribute of the
+ root DSE refers to the subschema controlling the root DSE. It is
+ noted that the general subschema discovery mechanism remains
+ available (see Section 4.4 of this document).
+
+
+A.1.2 Section 4 of RFC 2251
+
+ Portions of Section 4 of RFC 2251 detailing aspects of the information
+ model used by LDAP were incorporated in this document, including:
+
+ - Restriction of distinguished values to attributes whose descriptions
+ have no options (from Section 4.1.3).
+
+ - Data model aspects of Attribute Types (from Section 4.1.4),
+ Attribute Descriptions (from 4.1.4), Attribute (from 4.1.8),
+ Matching Rule Identifier (from 4.1.9).
+
+ - User schema requirements (from Section 4.1.6, 4.5.1, and 4.7).
+
+
+A.1.3 Section 6 of RFC 2251
+
+ The Section 6.1 and the second paragraph of Section 6.2 of RFC 2251
+ where incorporated into this document.
+
+
+A.2 Changes to RFC 2252
+
+ This document incorporates Sections 4, 5 and 7 from RFC 2252.
+
+
+A.2.1 Section 4 of RFC 2252
+
+ The specification was updated to use Augmented BNF [RFC2234]. The
+ string representation of an OBJECT IDENTIFIER was tighten to
+ disallow leading zeros as described in RFC 2252 text.
+
+ The <descr> syntax was changed to disallow semicolon (U+003B)
+ characters to appear to be consistent its natural language
+
+
+
+Zeilenga LDAP Models [Page 46]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+
+
+ specification "descr is the syntactic representation of an object
+ descriptor, which consists of letters and digits, starting with a
+ letter." In a related change, the statement "an
+ AttributeDescription can be used as the value in a NAME part of an
+ AttributeTypeDescription" was deleted. RFC 2252 provided no
+ specification as to the semantics of attribute options appearing in
+ NAME fields.
+
+ RFC 2252 stated that the <descr> form of <oid> SHOULD be preferred
+ over the <numericoid> form. However, <descr> form can be ambiguous.
+ To address this issue, the imperative was replaced with a statement
+ (in Section 1.4) that while the <descr> form is generally preferred,
+ <numericoid> should be used where an unambiguous <descr> is not
+ available. Additionally, an expanded discussion of descriptor
+ issues is discussed in Section 6.2 (Short Names).
+
+ The ABNF for a quoted string (qdstring) was updated to reflect
+ support for the escaping mechanism described in 4.3 of RFC 2252.
+
+
+A.2.2 Section 5 of RFC 2252
+
+ Definitions of operational attributes provided in Section 5 of RFC
+ 2252 where incorporated into this document.
+
+ The 'namingContexts' description was clarified. A first-level DSA
+ should publish, in addition to other values, "" indicating the root
+ of the DIT.
+
+ The 'supportedExtension' description was clarified. A server need
+ only list the OBJECT IDENTIFIERs associated with the extended
+ requests of the extended operations it recognizes.
+
+ The 'supportedControl' description was clarified. A server need
+ only list the OBJECT IDENTIFIERs associated with the request
+ controls it recognizes.
+
+
+A.2.3 Section 7 of RFC 2252
+
+ Section 7 of RFC 2252 provides definitions of the 'subschema' and
+ 'extensibleObject' object classes. These definitions where
+ integrated into Section 4.2 and Section 4.3 of this document,
+ respectively. Section 7 of RFC 2252 also contained the object class
+ implementation requirement. This was incorporated into Section 7 of
+ this document.
+
+ The specification of 'extensibleObject' was clarified of how it
+
+
+
+Zeilenga LDAP Models [Page 47]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+
+
+ interacts with precluded attributes.
+
+
+A.3 Changes to RFC 2256
+
+ This document incorporates Sections 5.1, 5.2, 7.1, and 7.2 of RFC
+ 2256.
+
+ Section 5.1 of RFC 2256 provided the definition of the 'objectClass'
+ attribute type. This was integrated into Section 2.4.1 of this
+ document. The statement "One of the values is either 'top' or
+ 'alias'" was replaced with statement that one of the values is 'top'
+ as entries belonging to 'alias' also belong to 'top'.
+
+ Section 5.2 of RFC 2256 provided the definition of the
+ 'aliasedObjectName' attribute type. This was integrated into
+ Section 2.6.2 of this document.
+
+ Section 7.1 of RFC 2256 provided the definition of the 'top' object
+ class. This was integrated into Section 2.4.1 of this document.
+
+ Section 7.2 of RFC 2256 provided the definition of the 'alias'
+ object class. This was integrated into Section 2.6.1 of this
+ document.
+
+
+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
+
+
+
+Zeilenga LDAP Models [Page 48]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
+
+
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga LDAP Models [Page 49]
+\f
--- /dev/null
+
+
+Internet-Draft Editor: J. Sermersheim
+Intended Category: Standard Track Novell, Inc
+Document: draft-ietf-ldapbis-protocol-13.txt Mar 2003
+Obsoletes: RFC 2251
+
+
+ LDAP: The Protocol
+
+
+Status of this Memo
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC2026.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that other
+ groups may also distribute working documents as Internet-Drafts.
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ Distribution of this memo is unlimited. 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, for 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
+
+ 1. Introduction.....................................................2
+ 2. Conventions......................................................3
+ 3. Protocol Model...................................................3
+ 4. Elements of Protocol.............................................3
+ 4.1. Common Elements................................................4
+ 4.1.1. Message Envelope.............................................4
+ 4.1.2. String Types.................................................6
+ 4.1.3. Distinguished Name and Relative Distinguished Name...........6
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 1 \f
+ Lightweight Directory Access Protocol Version 3
+
+ 4.1.4. Attribute Descriptions.......................................6
+ 4.1.5. Attribute Value..............................................7
+ 4.1.6. Attribute Value Assertion....................................7
+ 4.1.7. Attribute....................................................7
+ 4.1.8. Matching Rule Identifier.....................................8
+ 4.1.9. Result Message...............................................8
+ 4.1.10. Referral...................................................10
+ 4.1.11. Controls...................................................11
+ 4.2. Bind Operation................................................12
+ 4.3. Unbind Operation..............................................14
+ 4.4. Unsolicited Notification......................................15
+ 4.5. Search Operation..............................................16
+ 4.6. Modify Operation..............................................23
+ 4.7. Add Operation.................................................24
+ 4.8. Delete Operation..............................................25
+ 4.9. Modify DN Operation...........................................26
+ 4.10. Compare Operation............................................27
+ 4.11. Abandon Operation............................................28
+ 4.12. Extended Operation...........................................28
+ 4.13. Start TLS Operation..........................................29
+ 5. Protocol Element Encodings and Transfer.........................31
+ 5.1. Protocol Encoding.............................................31
+ 5.2. Transfer Protocols............................................31
+ 6. Implementation Guidelines.......................................32
+ 6.1. Server Implementations........................................32
+ 6.2. Client Implementations........................................32
+ 7. Security Considerations.........................................32
+ 8. Acknowledgements................................................33
+ 9. Normative References............................................33
+ 10. Editor's Address...............................................34
+ Appendix A - LDAP Result Codes.....................................35
+ A.1 Non-Error Result Codes.........................................35
+ A.2 Error Result Codes.............................................35
+ A.3 Classes and Precedence of Error Result Codes...................35
+ Appendix C - Change History........................................46
+ C.1 Changes made to RFC 2251:......................................46
+ C.2 Changes made to draft-ietf-ldapbis-protocol-00.txt:............46
+ C.3 Changes made to draft-ietf-ldapbis-protocol-01.txt:............47
+ C.4 Changes made to draft-ietf-ldapbis-protocol-02.txt:............47
+ C.5 Changes made to draft-ietf-ldapbis-protocol-03.txt:............49
+ C.6 Changes made to draft-ietf-ldapbis-protocol-04.txt:............51
+ C.7 Changes made to draft-ietf-ldapbis-protocol-05.txt:............51
+ C.8 Changes made to draft-ietf-ldapbis-protocol-06.txt:............52
+ C.9 Changes made to draft-ietf-ldapbis-protocol-07.txt:............55
+ C.10 Changes made to draft-ietf-ldapbis-protocol-08.txt:...........55
+ C.11 Changes made to draft-ietf-ldapbis-protocol-09.txt:...........55
+ C.12 Changes made to draft-ietf-ldapbis-protocol-10.txt:...........55
+ C.13 Changes made to draft-ietf-ldapbis-protocol-11.txt:...........56
+ C.14 Changes made to draft-ietf-ldapbis-protocol-12.txt:...........56
+ Appendix D - Outstanding Work Items................................56
+
+
+1. Introduction
+
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 2 \f
+ Lightweight Directory Access Protocol Version 3
+
+ 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 Lightweight Directory
+ Access Protocol, along with their semantics. Following the
+ description of protocol elements, it describes the way in which the
+ protocol is encoded and transferred.
+
+ This document is an integral part of the LDAP Technical Specification
+ [Roadmap].
+
+ This document replaces RFC 2251. Appendix C holds a detailed log of
+ changes to RFC 2251. Prior to Working Group Last Call, this appendix
+ will be distilled to a summary of changes to RFC 2251.
+
+
+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 [RFC2119].
+
+
+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 the
+ operation(s), the server returns a response containing any results or
+ errors to the requesting client.
+
+ Note that 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 may be exchanged
+ between a client and server in any order, provided the client
+ eventually receives a response for every request that requires one.
+
+ Note that the core protocol operations defined in this document can
+ be mapped to a subset of the X.500(1997) directory abstract service.
+ However there is not a one-to-one mapping between LDAP protocol
+ operations and DAP operations. Server implementations acting as a
+ gateway to X.500 directories may need to make multiple DAP requests.
+
+
+4. Elements of Protocol
+
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 3 \f
+ Lightweight Directory Access Protocol Version 3
+
+ The LDAP protocol is described using Abstract Syntax Notation 1
+ (ASN.1) [X.680], and is transferred using a subset of ASN.1 Basic
+ Encoding Rules [X.690]. Section 5.1 specifies how the protocol is
+ encoded and transferred.
+
+ In order to support future Standards Track extensions to this
+ protocol, extensibility is implied where it is allowed (per ASN.1).
+ 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 ignore trailing
+ SEQUENCE elements whose tags they do not recognize.
+
+ Changes to the LDAP 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 bind request,
+ 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 determine the protocol versions a server supports by
+ reading the supportedLDAPVersion attribute from the root DSE
+ [Models]. Servers which implement version 3 or later MUST provide
+ this attribute.
+
+
+4.1. Common Elements
+
+ This section describes the LDAPMessage envelope PDU (Protocol Data
+ Unit) 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:
+
+ 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,
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 4 \f
+ Lightweight Directory Access Protocol Version 3
+
+ modDNResponse ModifyDNResponse,
+ compareRequest CompareRequest,
+ compareResponse CompareResponse,
+ abandonRequest AbandonRequest,
+ extendedReq ExtendedRequest,
+ extendedResp ExtendedResponse,
+ ... },
+ controls [0] Controls OPTIONAL }
+
+ MessageID ::= INTEGER (0 .. maxInt)
+
+ maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
+
+ 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 message ID and the controls.
+
+ If the server receives a PDU 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 MAY return the Notice of Disconnection
+ described in section 4.4.1, with resultCode protocolError, and MUST
+ immediately close the connection.
+
+ In other cases where the client or server cannot parse a PDU, it
+ SHOULD abruptly close the connection 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.
+
+ The ASN.1 type Controls is defined in section 4.1.11.
+
+
+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 values of any other requests outstanding in the LDAP session of
+ which this message is a part. 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 on the same connection unless it can be determined
+ that the server is no longer servicing the earlier request. Otherwise
+ the behavior is undefined. For operations that do not return
+ responses (unbind, abandon, and abandoned operations), the client
+ SHOULD assume the operation is in progress until a subsequent bind
+ request completes.
+
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 5 \f
+ Lightweight Directory Access Protocol Version 3
+
+
+4.1.2. String Types
+
+ The LDAPString is a notational convenience to indicate that, although
+ strings of LDAPString type encode as OCTET STRING types, the
+ [ISO10646] character set (a superset of Unicode) is used, encoded
+ following the UTF-8 algorithm [RFC2279]. Note that in the UTF-8
+ algorithm characters which are the same as ASCII (0x0000 through
+ 0x007F) are represented as that same ASCII character in a single
+ byte. The other byte values are used to form a variable-length
+ encoding of an arbitrary character.
+
+ LDAPString ::= OCTET STRING -- UTF-8 encoded,
+ -- ISO 10646 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.3 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 and a RelativeLDAPDN are respectively defined to be the
+ representation of a distinguished-name and a relative-distinguished-
+ name after encoding according to the specification in [LDAPDN].
+
+ LDAPDN ::= LDAPString
+ -- Constrained to distinguishedName [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]
+
+ An AttributeDescriptionList describes a list of 0 or more attribute
+ descriptions. (A list of zero elements has special significance in
+ the Search request.)
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 6 \f
+ Lightweight Directory Access Protocol Version 3
+
+
+ AttributeDescriptionList ::= SEQUENCE OF
+ AttributeDescription
+
+
+4.1.5. Attribute Value
+
+ A field of type AttributeValue is an OCTET STRING containing an
+ encoded attribute value data type. The value is encoded according to
+ its LDAP-specific encoding definition. 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 attributes (e.g.
+ photographs).
+
+ Attributes may be defined which have arbitrary and non-printable
+ syntax. Implementations MUST NOT display nor attempt to decode as
+ ASN.1, a value if its syntax is not known. The implementation may
+ attempt to discover the subschema of the source entry, and retrieve
+ the values of attributeTypes from it.
+
+ Clients MUST NOT send attribute values in a request that are not
+ valid according to the syntax defined for the attributes.
+
+
+4.1.6. Attribute Value Assertion
+
+ The AttributeValueAssertion type definition is similar to the one in
+ the X.500 directory standards. It contains an attribute description
+ and a matching rule assertion value suitable for that type.
+
+ 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
+
+ An attribute consists of an attribute description and one or more
+ values of that attribute description. (Though attributes MUST have at
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 7 \f
+ Lightweight Directory Access Protocol Version 3
+
+ least one value when stored, due to access control restrictions the
+ set may be empty when transferred from the server to the client. This
+ is described in section 4.5.2, concerning the PartialAttributeList
+ type.)
+
+ Attribute ::= SEQUENCE {
+ type AttributeDescription,
+ vals SET OF AttributeValue }
+
+ Each attribute value is distinct in the set (no duplicates). The set
+ of attribute values is unordered. Implementations MUST NOT reply upon
+ any apparent ordering being repeatable.
+
+
+4.1.8. Matching Rule Identifier
+
+ Matching rules are defined in 4.1.3 of [Models]. A matching rule is
+ identified in the LDAP protocol by the printable representation of
+ either its numericoid, or one of its short name descriptors, e.g.
+ "caseIgnoreIA5Match" or "1.3.6.1.4.1.453.33.33".
+
+ MatchingRuleId ::= LDAPString
+
+ Servers which support matching rules for use in the extensibleMatch
+ search filter MUST list the matching rules they implement in
+ subschema entries, using the matchingRules attributes. The server
+ SHOULD also list there, using the matchingRuleUse attribute, the
+ attribute types with which each matching rule can be used. More
+ information is given in section 4.5 of [Syntaxes].
+
+
+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 of LDAPResult or responses
+ containing the components of LDAPResult to indicate the final status
+ of a protocol operation request.
+
+ LDAPResult ::= SEQUENCE {
+ resultCode ENUMERATED {
+ success (0),
+ operationsError (1),
+ protocolError (2),
+ timeLimitExceeded (3),
+ sizeLimitExceeded (4),
+ compareFalse (5),
+ compareTrue (6),
+ authMethodNotSupported (7),
+ strongAuthRequired (8),
+ -- 9 reserved --
+ referral (10),
+ adminLimitExceeded (11),
+ unavailableCriticalExtension (12),
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 8 \f
+ Lightweight Directory Access Protocol Version 3
+
+ 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),
+ ... },
+ -- 81-90 reserved for APIs --
+ matchedDN LDAPDN,
+ diagnosticMessage LDAPString,
+ referral [3] Referral OPTIONAL }
+
+ The result codes enumeration is extensible as defined in Section 3.5
+ of [LDAPIANA]. The meanings of the result codes are given in Appendix
+ A.
+
+ 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.
+ If the server chooses not to return a textual diagnostic, the
+ diagnosticMessage field of the LDAPResult type MUST contain a zero
+ length string.
+
+ For certain result codes (typically, but not restricted to
+ noSuchObject, aliasProblem, invalidDNSyntax and
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 9 \f
+ Lightweight Directory Access Protocol Version 3
+
+ aliasDereferencingProblem), the matchedDN field is set to the name of
+ the lowest entry (object or alias) in the directory that was matched.
+ If no aliases were dereferenced while attempting to locate the entry,
+ this will be a truncated form of the name provided, or if aliases
+ were dereferenced, of the resulting name, as defined in section 12.5
+ of [X.511]. The matchedDN field contains a zero length string with
+ all other result codes.
+
+
+4.1.10. Referral
+
+ The referral result code indicates that the contacted server does not
+ hold the target entry of the request. The referral field is present
+ in an LDAPResult if the LDAPResult.resultCode field value is
+ 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 URL 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 the search scope spans multiple naming contexts, and several
+ different servers would need to be contacted to complete the
+ operation.
+
+ Referral ::= SEQUENCE OF LDAPURL -- one or more
+
+ LDAPURL ::= LDAPString -- limited to characters permitted in
+ -- URLs
+
+ If the client wishes to progress the operation, it MUST follow the
+ referral by contacting one of the servers. If multiple URLs are
+ present, the client assumes that any URL may be used to progress the
+ operation.
+
+ URLs for servers implementing the LDAP protocol are written according
+ to [LDAPURL]. If an alias was dereferenced, the <dn> part of the URL
+ MUST be present, with the new target object name. If the <dn> part is
+ present, the client MUST use this name in its next request to
+ progress the operation, and if it is not present the client will use
+ the same name as in the original request. Some servers (e.g.
+ participating in distributed indexing) may provide a different filter
+ in a referral for a search operation. If the filter part of the URL
+ is present in an LDAPURL, the client MUST use this filter in its next
+ request to progress this search, and if it is not present the client
+ MUST use the same filter as it used for that search. Other aspects of
+ the new request may be the same or different as the request which
+ generated the referral.
+
+
+
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 10 \f
+ Lightweight Directory Access Protocol Version 3
+
+ Note that UTF-8 characters appearing in a DN or search filter may not
+ be legal for URLs (e.g. spaces) and MUST be escaped using the %
+ method in [RFC2396].
+
+ Other kinds of URLs may be returned, so long as the operation could
+ be performed using that protocol.
+
+
+4.1.11. Controls
+
+ A control is a way to specify extension information for an LDAP
+ message. A control only alters the semantics of the message it is
+ attached to.
+
+ Controls ::= SEQUENCE OF Control
+
+ Control ::= SEQUENCE {
+ controlType LDAPOID,
+ criticality BOOLEAN DEFAULT FALSE,
+ controlValue OCTET STRING OPTIONAL }
+
+ The controlType field MUST be a UTF-8 encoded dotted-decimal
+ representation of an OBJECT IDENTIFIER which uniquely identifies the
+ control. This prevents conflicts between control names.
+
+ The criticality field is either TRUE or FALSE and only applies to
+ request messages that have a corresponding response message. For all
+ other messages (such as abandonRequest, unbindRequest and all
+ response messages), the criticality field is treated as FALSE.
+
+ If the server recognizes the control type and it is appropriate for
+ the operation, the server will make use of the control when
+ performing the operation.
+
+ If the server does not recognize the control type or it is not
+ appropriate for the operation, and the criticality field is TRUE, the
+ server MUST NOT perform the operation, and MUST instead return the
+ resultCode unavailableCriticalExtension.
+
+ If the control is unrecognized or inappropriate but the criticality
+ field is FALSE, the server MUST ignore the control.
+
+ The controlValue contains any information associated with the
+ control, and its format is defined for 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.
+
+ This document does not specify any controls. Controls may be
+ specified in other documents. The specification of a control consists
+ of:
+
+ - the OBJECT IDENTIFIER assigned to the control,
+
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 11 \f
+ Lightweight Directory Access Protocol Version 3
+
+ - whether the control is always noncritical, always critical, or
+ critical at the client's option,
+
+ - the format of the controlValue contents of the control,
+
+ - the semantics of the control,
+
+ - and optionally, semantics regarding the combination of the control
+ with other controls.
+
+ Servers list the controlType of all request controls they recognize
+ in the supportedControl attribute [Models] in the root DSE.
+
+ 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. In the absence of combination
+ semantics, the behavior of the operation is undefined.
+ Additionally, the order of a combination of controls in the SEQUENCE
+ is ignored unless the control specification(s) describe(s)
+ combination semantics.
+
+
+4.2. Bind Operation
+
+ The function of the Bind Operation is to allow authentication
+ information to be exchanged between the client and server. Prior to
+ the first BindRequest, the implied identity is anonymous. Refer to
+ [AuthMeth] for the authentication-related semantics of this
+ operation.
+
+ 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 }
+
+ Parameters of the Bind Request are:
+
+ - version: A version number indicating the version of the protocol
+ to be used in this protocol session. This document describes
+ version 3 of the LDAP protocol. Note that there is no version
+ negotiation, and the client just sets this parameter to the
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 12 \f
+ Lightweight Directory Access Protocol Version 3
+
+ version it desires. If the server does not support the specified
+ version, it responds with protocolError in the resultCode field of
+ the BindResponse.
+
+ - name: 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 7)
+ or when using SASL authentication ([AuthMeth] section 4.3). Server
+ behavior is undefined when the name is a null value, simple
+ authentication is used, and a password is specified. The server
+ SHOULD NOT perform any alias dereferencing in determining the
+ object to bind as.
+
+ - authentication: information used to authenticate the name, if any,
+ provided in the Bind Request. This type is extensible as defined
+ in Section 3.6 of [LDAPIANA]. Servers that do not support a choice
+ supplied by a client will return authMethodNotSupported in the
+ result code of the BindResponse.
+
+ Authorization is the use of this authentication information when
+ performing operations. Authorization MAY be affected by factors
+ outside of the LDAP Bind Request, such as lower layer security
+ services.
+
+
+4.2.1. Processing of the Bind Request
+
+ Upon receipt of a BindRequest, the server MUST ensure there are no
+ outstanding operations in progress on the connection (This simplifies
+ server implementation). 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.
+
+ If the client did not bind before sending a request and receives an
+ operationsError, it may then send a Bind Request. If this also fails
+ or the client chooses not to bind on the existing connection, it may
+ close the connection, reopen it and begin again by first sending a
+ PDU with a Bind Request. This will aid in interoperating with servers
+ implementing other versions of LDAP.
+
+ Clients MAY send multiple Bind Requests on a connection to change
+ their credentials. Authentication from earlier binds is subsequently
+ ignored. A failed or abandoned Bind Operation has the effect of
+ leaving the connection in an anonymous state. To arrive at a known
+ authentication state after abandoning a bind operation, clients may
+ unbind, rebind, or make use of the BindResponse. If a SASL transfer
+ encryption or integrity mechanism has been negotiated, and that
+ mechanism does not support the changing of credentials from one
+ identity to another, then the client MUST instead establish a new
+ connection.
+
+ For some SASL authentication mechanisms, it may be necessary for the
+ client to invoke the BindRequest multiple times. This is indicated by
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 13 \f
+ Lightweight Directory Access Protocol Version 3
+
+ the server sending a BindResponse with the resultCode set to
+ saslBindInProgress. This indicates that the server requires the
+ client to send a new bind request, with the same sasl mechanism, to
+ continue the authentication process. If at any stage the client
+ wishes to abort the bind process it MAY unbind and then drop the
+ underlying connection. 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
+ authMethodNotSupported as the resultCode. 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.
+
+ A successful bind operation is indicated by a BindResponse with a
+ resultCode set to success (0). Otherwise, an appropriate resultCode
+ is set in the BindResponse. For bind, the protocolError (2)
+ resultCode may be used to indicate that the version number supplied
+ by the client is unsupported.
+
+ If the server does not support the client's requested protocol
+ version, it MUST set the resultCode to protocolError.
+
+ If the client receives a BindResponse response where the resultCode
+ was protocolError, it MUST close the connection as the server will be
+ unwilling to accept further operations. (This is for compatibility
+ with earlier versions of LDAP, in which the bind was always the first
+ operation, and there was no negotiation.)
+
+ The serverSaslCreds are 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 is not to be included in the result.
+
+
+4.3. Unbind Operation
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 14 \f
+ Lightweight Directory Access Protocol Version 3
+
+
+ The function of the Unbind Operation is to terminate a protocol
+ session. The Unbind Operation is defined as follows:
+
+ UnbindRequest ::= [APPLICATION 2] NULL
+
+ The Unbind Operation has no response defined. Upon transmission of an
+ UnbindRequest, a protocol client MUST assume that the protocol
+ session is terminated. Upon receipt of an UnbindRequest, a protocol
+ server MUST assume that the requesting client has terminated the
+ session and that all outstanding requests may be discarded, and MUST
+ close the connection.
+
+
+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 connection between the client and the server. The
+ notification is of an advisory nature, and the server will not expect
+ any response to be returned from the client.
+
+ The unsolicited notification is structured as an LDAPMessage in which
+ the messageID is 0 and protocolOp is of the extendedResp form. The
+ responseName field of the ExtendedResponse is present. The LDAPOID
+ value MUST be unique for this notification, and not be used in any
+ other situation.
+
+ One unsolicited notification (Notice of Disconnection) is defined in
+ this document.
+
+
+4.4.1. Notice of Disconnection
+
+ This notification may be used by the server to advise the client that
+ the server is about to close the connection due to an error
+ condition. Note that this notification is NOT a response to an unbind
+ requested by the client: the server MUST follow the procedures of
+ section 4.3. This notification is intended to assist clients in
+ distinguishing between an error condition and a transient network
+ failure. As with a connection close due to network failure, the
+ client MUST NOT assume that any outstanding requests which modified
+ the directory have succeeded or failed.
+
+ The responseName is 1.3.6.1.4.1.1466.20036, the response field is
+ absent, and the resultCode is used to indicate the reason for the
+ disconnection.
+
+ The following resultCode values are to be used in this notification:
+
+ - protocolError: The server has received data from the client in
+ which the LDAPMessage structure could not be parsed.
+
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 15 \f
+ Lightweight Directory Access Protocol Version 3
+
+ - strongAuthRequired: The server has detected that an established
+ underlying security association protecting communication between
+ the client and server has unexpectedly failed or been compromised.
+
+ - unavailable: This server will stop accepting new connections and
+ operations on all existing connections, and be unavailable for an
+ extended period of time. The client may make use of an alternative
+ server.
+
+ After sending this notice, the server MUST close the connection.
+ After receiving this notice, the client MUST NOT transmit any further
+ on the connection, and may abruptly close the connection.
+
+
+4.5. Search Operation
+
+ The Search Operation allows a client to request that a search be
+ performed on its behalf by a server. This can be used to read
+ attributes from a single entry, from entries immediately below a
+ particular entry, or a whole subtree of entries.
+
+
+4.5.1. Search Request
+
+ The Search Request is defined as follows:
+
+ 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 AttributeDescriptionList }
+
+ Filter ::= CHOICE {
+ and [0] SET SIZE (1..MAX) OF Filter,
+ or [1] SET SIZE (1..MAX) OF 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 }
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 16 \f
+ Lightweight Directory Access Protocol Version 3
+
+
+ SubstringFilter ::= SEQUENCE {
+ type AttributeDescription,
+ -- at least one must be present,
+ -- initial and final can occur at most once
+ substrings SEQUENCE OF CHOICE {
+ initial [0] AssertionValue,
+ any [1] AssertionValue,
+ final [2] AssertionValue } }
+
+ MatchingRuleAssertion ::= SEQUENCE {
+ matchingRule [1] MatchingRuleId OPTIONAL,
+ type [2] AttributeDescription OPTIONAL,
+ matchValue [3] AssertionValue,
+ dnAttributes [4] BOOLEAN DEFAULT FALSE }
+
+ Parameters of the Search Request are:
+
+ - baseObject: An LDAPDN that is the base object entry relative to
+ which the search is to be performed.
+
+ - scope: An indicator of the scope of the search to be performed.
+ The semantics of the possible values of this field are identical
+ to the semantics of the scope field in the X.511 Search Operation.
+
+ - derefAliases: An indicator as to how alias objects (as defined in
+ X.501) are to be handled in searching. The semantics of the
+ possible values of this field are:
+
+ neverDerefAliases: do not dereference aliases in searching
+ or in locating the base object of the search;
+
+ derefInSearching: dereference aliases in subordinates of
+ the base object in searching, but not in locating the base
+ object of the search;
+
+ 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.
+
+ - sizeLimit: A size limit that restricts the maximum number of
+ entries to be returned as a result of the search. A value of 0 in
+ this field indicates that no client-requested size limit
+ restrictions are in effect for the search. Servers may enforce a
+ maximum number of entries to return.
+
+ - timeLimit: A time limit that restricts the maximum time (in
+ seconds) allowed for a search. A value of 0 in this field
+ indicates that no client-requested time limit restrictions are in
+ effect for the search.
+
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 17 \f
+ Lightweight Directory Access Protocol Version 3
+
+ - typesOnly: An indicator as to whether search results will 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.
+
+ - 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) section 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.
+
+ The present match evaluates to TRUE where there is an attribute or
+ subtype of the specified attribute description present in an
+ entry, and FALSE otherwise (including a presence test with an
+ unrecognized attribute description.)
+
+ The matching rule for equalityMatch filter items is defined by the
+ EQUALITY matching rule for the attribute type.
+
+ The matching rule and assertion syntax for AssertionValues in a
+ substrings filter item is defined by the SUBSTR matching rule for
+ the attribute type.
+
+ The matching rule for greaterOrEqual and lessOrEqual filter items
+ is defined by the ORDERING matching rule for the attribute type.
+
+ The matching rule for approxMatch filter items is implementation-
+ defined. If approximate matching is not supported by the server,
+ the filter item should be treated as an equalityMatch.
+
+ The extensibleMatch is new in this version of LDAP. If the
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 18 \f
+ Lightweight Directory Access Protocol Version 3
+
+ matchingRule field is absent, the type field MUST be present, and
+ the equality match is performed for that type. If the type field
+ is absent and matchingRule is present, the matchValue is compared
+ against all attributes in an entry which support that
+ matchingRule, and the matchingRule determines the syntax for the
+ assertion value (the filter item evaluates to TRUE if it matches
+ with at least one attribute in the entry, FALSE if it does not
+ match any attribute in the entry, and Undefined if the
+ matchingRule is not recognized or the assertionValue cannot be
+ parsed.) If the type field is present and matchingRule is present,
+ the matchingRule MUST be one permitted for use with that type,
+ otherwise the filter item is undefined. If the dnAttributes field
+ is set to TRUE, the match is applied against all the
+ AttributeValueAssertions in an entry's distinguished name as well,
+ and also evaluates to TRUE if there is at least one attribute in
+ the distinguished name for which the filter item evaluates to
+ TRUE. (Editors note: The dnAttributes field is present so that
+ there does not need to be multiple versions of generic matching
+ rules such as for word matching, one to apply to entries and
+ another to apply to entries and dn attributes as well).
+
+ A filter item evaluates to Undefined when the server would not be
+ able to determine whether the assertion value matches an entry. If
+ an attribute description in an equalityMatch, substrings,
+ greaterOrEqual, lessOrEqual, approxMatch or extensibleMatch filter
+ is not recognized by the server, a matching rule id in the
+ extensibleMatch is not recognized by the server, the assertion
+ value cannot be parsed, or the type of filtering requested is not
+ implemented, then the filter is Undefined. Thus for example if a
+ server did not recognize the attribute type shoeSize, a filter of
+ (shoeSize=*) would evaluate to FALSE, and the filters
+ (shoeSize=12), (shoeSize>=12) and (shoeSize<=12) would evaluate to
+ Undefined.
+
+ Servers MUST NOT return errors if attribute descriptions or
+ matching rule ids are not recognized, or assertion values cannot
+ be parsed. More details of filter processing are given in section
+ 7.8 of [X.511].
+
+ - attributes: A list of the attributes to be returned from each
+ entry which matches the search filter. There are two special
+ values which may be used: an empty list with no attributes, and
+ the attribute description string "*". Both of these signify that
+ all user attributes are to be returned. (The "*" allows the client
+ to request all user attributes in addition to any specified
+ operational attributes).
+
+ Attributes MUST be named at most once in the list, and are
+ returned at most once in an entry. If there are attribute
+ descriptions in the list which are not recognized, they are
+ ignored by the server.
+
+ If the client does not want any attributes returned, it can
+ specify a list containing only the attribute with OID "1.1". This
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 19 \f
+ Lightweight Directory Access Protocol Version 3
+
+ OID was chosen arbitrarily and does not correspond to any
+ attribute in use.
+
+ Client implementors should note that even if all user attributes
+ are requested, some attributes 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, since there may be extremely large number of values for
+ certain operational attributes. (A list of operational attributes
+ for use in LDAP is given in [Syntaxes].)
+
+ Note that an X.500 "list"-like operation can be emulated by the
+ client requesting a one-level LDAP 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 base object LDAP
+ 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.2. Search Result
+
+ The results of the search attempted by the server upon receipt of a
+ Search Request are returned in Search Responses, which are LDAP
+ messages containing either SearchResultEntry, SearchResultReference,
+ or SearchResultDone data types.
+
+ SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
+ objectName LDAPDN,
+ attributes PartialAttributeList }
+
+ PartialAttributeList ::= SEQUENCE OF SEQUENCE {
+ type AttributeDescription,
+ vals SET OF AttributeValue }
+ -- implementors should note that the PartialAttributeList may
+ -- have zero elements (if none of the attributes of that entry
+ -- were requested, or could be returned), and that the vals set
+ -- may also have zero elements (if types only was requested, or
+ -- all values were excluded from the result.)
+
+ SearchResultReference ::= [APPLICATION 19] SEQUENCE OF LDAPURL
+ -- at least one LDAPURL element must be present
+
+ SearchResultDone ::= [APPLICATION 5] LDAPResult
+
+ Upon receipt of a Search Request, a server will perform the necessary
+ search of the DIT.
+
+ If the LDAP session is operating over a connection-oriented transport
+ such as TCP, the server will return to the client a sequence of
+ responses in separate LDAP messages. There may be zero or more
+ responses containing SearchResultEntry, one for each entry found
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 20 \f
+ Lightweight Directory Access Protocol Version 3
+
+ during the search. There may also be zero or more responses
+ containing SearchResultReference, one for each area not explored by
+ this server during the search. The SearchResultEntry and
+ SearchResultReference PDUs may come in any order. Following all the
+ SearchResultReference responses and all SearchResultEntry responses
+ to be returned by the server, the server will return a response
+ containing the SearchResultDone, 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. Return of attributes is subject to access control and
+ other administrative policy.
+
+ 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 a textual name for an attribute type,
+ it MUST use a textual name for attributes of that attribute type by
+ specifying one of the textual names as the value of the attribute
+ type. Otherwise, the server uses the object identifier for the
+ attribute type by specifying the object identifier, in ldapOID form,
+ as the value of attribute type.
+
+
+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 to search all the entries in the scope at
+ and under the baseObject, the server may return one or more
+ SearchResultReference entries, each containing a reference to another
+ set of servers for continuing the operation. A server MUST NOT return
+ any SearchResultReference if it has not located the baseObject and
+ thus has not searched any entries; in this case it would return a
+ SearchResultDone containing a referral resultCode.
+
+ If a server holds a copy or partial copy of the subordinate naming
+ context, 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.
+ URLs for servers implementing the LDAP protocol are written according
+ to [LDAPURL]. The <dn> part MUST be present in the URL, with the new
+ target object name. The client MUST use this name in its next
+ request. Some servers (e.g. part of a distributed index exchange
+ system) may provide a different filter in the URLs of the
+ SearchResultReference. If the filter part of the URL is present in an
+ LDAP URL, the client MUST use the new filter in its next request to
+ progress the search, and if the filter part is absent the client will
+ use again the same filter. If the originating search scope was
+ singleLevel, the scope part of the URL will be baseObject. Other
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 21 \f
+ Lightweight Directory Access Protocol Version 3
+
+ aspects of the new search request may be the same or different as the
+ search which generated the continuation references.
+ Other kinds of URLs may be returned so long as the operation could be
+ performed using that protocol.
+
+ The name of an unexplored subtree in a SearchResultReference need not
+ be subordinate to the base object.
+
+ In order to complete the search, the client MUST issue a new search
+ operation for each SearchResultReference that is returned. Note that
+ the abandon operation described in section 4.11 applies only to a
+ particular operation sent on a connection between a client and
+ server, and if the client has multiple outstanding search operations,
+ it MUST abandon each operation individually.
+
+
+4.5.3.1. Example
+
+ 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 either LDAP-capable servers (hostb) or (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 subtree 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
+ ldap://hostc/OU=People,DC=Example,DC=NET
+ }
+ SearchResultReference {
+ ldap://hostd/OU=Roles,DC=Example,DC=NET
+ }
+ 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 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
+ }
+ SearchResultReference {
+ ldap://hostf/OU=Consultants,OU=People,DC=Example,DC=NET
+ }
+ SearchResultDone (success)
+
+
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 22 \f
+ Lightweight Directory Access Protocol Version 3
+
+ If the contacted server does not hold the base object for the search,
+ then it will return a referral to the client. For example, if the
+ client requests a subtree search of "DC=Example,DC=ORG" to hosta, the
+ server may return only 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,
+ modification SEQUENCE OF SEQUENCE {
+ operation ENUMERATED {
+ add (0),
+ delete (1),
+ replace (2) },
+ modification AttributeTypeAndValues } }
+
+ AttributeTypeAndValues ::= SEQUENCE {
+ type AttributeDescription,
+ vals SET OF AttributeValue }
+
+ Parameters of the Modify Request are:
+
+ - object: The object to be modified. The value of this field
+ contains the DN of the entry to be modified. The server will not
+ perform any alias dereferencing in determining the object to be
+ modified.
+
+ - modification: A list of modifications to be performed on the
+ entry. The entire list of entry modifications MUST be performed in
+ the order they are listed, as a single atomic operation. While
+ individual modifications may violate the directory schema, the
+ resulting entry after the entire list of modifications is
+ performed MUST conform to the requirements of the directory
+ schema. The values that may be taken on by the 'operation' field
+ in each modification construct have the following semantics
+ respectively:
+
+ add: add values listed to the given attribute, creating the
+ attribute if necessary;
+
+ delete: delete values listed from the given attribute,
+ removing the entire attribute if no values are listed, or
+ if all current values of the attribute are listed for
+ deletion;
+
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 23 \f
+ Lightweight Directory Access Protocol Version 3
+
+ replace: replace all existing values of the given 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.
+
+ The result of the modification attempted by the server upon receipt
+ of a Modify Request is returned in a Modify Response, defined as
+ follows:
+
+ ModifyResponse ::= [APPLICATION 7] LDAPResult
+
+ Upon receipt of a Modify Request, a server will perform the necessary
+ modifications to the DIT.
+
+ 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. Note that 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. If the connection fails, whether the
+ modification occurred or not is indeterminate.
+
+ The Modify Operation cannot be used to remove from an entry any of
+ its distinguished values, those values which form the entry's
+ relative distinguished name. An attempt to do so will result in the
+ server returning the error notAllowedOnRDN. The Modify DN Operation
+ described in section 4.9 is used to rename an entry.
+
+ Note that due to the simplifications made in LDAP, there is not a
+ direct mapping of the modifications in an LDAP ModifyRequest onto the
+ EntryModifications 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.
+
+
+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 SEQUENCE {
+ type AttributeDescription,
+ vals SET OF AttributeValue }
+
+ Parameters of the Add Request are:
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 24 \f
+ Lightweight Directory Access Protocol Version 3
+
+
+ - entry: the Distinguished Name of the entry to be added. Note that
+ the server will not dereference any aliases in locating the entry
+ to be added.
+
+ - attributes: the list of attributes that make up the content of the
+ entry being added. Clients MUST include distinguished values
+ (those forming the entry's own RDN) in this list, the objectClass
+ attribute, and values of any mandatory attributes of the listed
+ object classes. Clients MUST NOT supply NO-USER-MODIFICATION
+ attributes such as the createTimestamp or creatorsName attributes,
+ since the server maintains these automatically.
+
+ The entry named in the entry field of the AddRequest MUST NOT exist
+ for the AddRequest to succeed. The parent of the object and alias
+ entries 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 error noSuchObject with the matchedDN field containing
+ "DC=NET". If the parent entry exists but is not in a naming context
+ held by the server, the server SHOULD return a referral to the server
+ holding the parent entry.
+
+ Server implementations SHOULD NOT restrict where entries can be
+ located in the directory unless DIT structure rules are in place.
+ Some servers MAY allow the administrator to restrict the classes of
+ entries which can be added to the directory.
+
+ 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 is present in 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
+
+ The Delete Request consists of the Distinguished Name of the entry to
+ be deleted. Note that the server will not dereference aliases while
+ resolving the name of the target entry to be removed, and that only
+ leaf entries (those with no subordinate entries) can be deleted with
+ this operation.
+
+ The result of the delete attempted by the server upon receipt of a
+ Delete Request is returned in the Delete Response, defined as
+ follows:
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 25 \f
+ Lightweight Directory Access Protocol Version 3
+
+
+ DelResponse ::= [APPLICATION 11] LDAPResult
+
+ Upon receipt of a Delete Request, a server will attempt to perform
+ the entry removal requested. The result of the delete attempt will be
+ returned to the client in the Delete Response.
+
+
+4.9. Modify DN Operation
+
+ The Modify DN Operation allows a client to change the leftmost (least
+ significant) component of the name 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 }
+
+ Parameters of the Modify DN Request are:
+
+ - entry: the Distinguished Name of the entry to be changed. This
+ entry may or may not have subordinate entries. Note that the
+ server will not dereference any aliases in locating the entry to
+ be changed.
+
+ - newrdn: the RDN that will form the leftmost component of the new
+ name of the entry.
+
+ - deleteoldrdn: a boolean parameter 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 Distinguished Name of an
+ existing object entry which becomes the immediate superior of the
+ existing entry.
+
+ The result of the name change attempted by the server upon receipt of
+ a Modify DN Request is returned in the Modify DN Response, defined as
+ follows:
+
+ ModifyDNResponse ::= [APPLICATION 13] LDAPResult
+
+ Upon receipt of a ModifyDNRequest, a server will attempt to perform
+ the name change. The result of the name change attempt will be
+ returned to the client in the Modify DN Response.
+
+ For example, if the entry named in the "entry" parameter was "cn=John
+ Smith,c=US", the newrdn parameter was "cn=John Cougar Smith", and the
+ newSuperior parameter was absent, then this operation would attempt
+ to rename the entry to be "cn=John Cougar Smith,c=US". If there was
+
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 26 \f
+ Lightweight Directory Access Protocol Version 3
+
+ already an entry with that name, the operation would fail with error
+ code entryAlreadyExists.
+
+ If the deleteoldrdn parameter is TRUE, the values forming the old RDN
+ are deleted from the entry. If the deleteoldrdn parameter is FALSE,
+ the values forming the old RDN will be retained as non-distinguished
+ attribute values of the entry. The server may not perform the
+ operation and return an error code if the setting of the deleteoldrdn
+ parameter would cause a schema inconsistency in 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
+ resultCode affectsMultipleDSAs will be returned if this error
+ occurred. In general clients MUST NOT expect to be able to perform
+ arbitrary movements of entries and subtrees between servers.
+
+
+4.10. Compare Operation
+
+ The Compare Operation allows a client to compare an assertion
+ provided with an entry in the directory. The Compare Request is
+ defined as follows:
+
+ CompareRequest ::= [APPLICATION 14] SEQUENCE {
+ entry LDAPDN,
+ ava AttributeValueAssertion }
+
+ Parameters of the Compare Request are:
+
+ - entry: the name of the entry to be compared with. Note that the
+ server SHOULD NOT dereference any aliases in locating the entry to
+ be compared with.
+
+ - ava: the assertion with which an attribute in the entry is to be
+ compared.
+
+ The result of the compare attempted by the server upon receipt of a
+ Compare Request is returned in the Compare Response, defined as
+ follows:
+
+ CompareResponse ::= [APPLICATION 15] LDAPResult
+
+ Upon receipt of a Compare Request, a server will attempt to perform
+ the requested comparison using the EQUALITY matching rule for the
+ attribute type. The result of the comparison will be returned to the
+ client in the Compare Response. Note that errors and the result of
+ comparison are all returned in the same construct.
+
+ 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.
+
+
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 27 \f
+ Lightweight Directory Access Protocol Version 3
+
+4.11. Abandon Operation
+
+ The function of the Abandon Operation is to allow a client to request
+ that the server abandon an outstanding operation. The Abandon Request
+ is defined as follows:
+
+ AbandonRequest ::= [APPLICATION 16] MessageID
+
+ The MessageID MUST be that of an operation which was requested
+ earlier in this connection. The abandon request itself has its own
+ message id. This is distinct from the id of the earlier operation
+ being abandoned.
+
+ There is no response defined in the Abandon Operation. Upon
+ transmission of an Abandon Operation, the server MAY abandon the
+ operation identified by the Message ID in the Abandon Request.
+ Operation responses are not sent for successfully abandoned
+ operations. Clients can determine that an operation has been
+ abandoned by performing a subsequent bind operation.
+
+ Abandon and Unbind operations cannot be abandoned. The ability to
+ abandon other (particularly update) operations is at the discretion
+ of the server.
+
+ 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 SearchResponseDone. Of
+ course, the server MUST ensure that only properly encoded LDAPMessage
+ PDUs are transmitted.
+
+ Clients MUST 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).
+
+ 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
+
+ An extension mechanism has been added in this version of LDAP, in
+ order to allow additional operations to be defined for services not
+ available elsewhere in this protocol, for instance digitally signed
+ operations and results.
+
+ 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
+ request MUST have a unique OBJECT IDENTIFIER assigned to it.
+
+ ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 28 \f
+ Lightweight Directory Access Protocol Version 3
+
+ requestName [0] LDAPOID,
+ requestValue [1] OCTET STRING OPTIONAL }
+
+ The requestName is a dotted-decimal representation of the 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 the
+ ExtendedResponse.
+
+ ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
+ COMPONENTS OF LDAPResult,
+ responseName [10] LDAPOID OPTIONAL,
+ response [11] OCTET STRING OPTIONAL }
+
+ If the server does not recognize the request name, it MUST return
+ only the response fields from LDAPResult, containing the
+ protocolError result code.
+
+4.13. Start TLS Operation
+
+ The Start Transport Layer Security (StartTLS) operation provides the
+ ability to establish Transport Layer Security [RFC2246] on an LDAP
+ connection.
+
+4.13.1. Start TLS Request
+
+ A client requests TLS establishment by transmitting a Start TLS
+ request PDU to the server. The Start TLS request is defined in terms
+ of an ExtendedRequest. The requestName is "1.3.6.1.4.1.1466.20037",
+ and the requestValue field is absent.
+
+ The client MUST NOT send any PDUs on this connection following this
+ request until it receives a Start TLS extended response.
+
+4.13.2. Start TLS Response
+
+ When a Start TLS request is made, servers supporting the operation
+ MUST return a Start TLS response PDU to the requestor. The Start TLS
+ response responseName is also "1.3.6.1.4.1.1466.20037", and the
+ response field is absent.
+
+ The server MUST set the resultCode field to either success or one of
+ the other values outlined in section 4.13.2.2.
+
+4.13.2.1. "Success" Response
+
+ If the Start TLS Response contains a resultCode of success, this
+ indicates that the server is willing and able to negotiate TLS. Refer
+ to section 5.3 of [AuthMeth] for details.
+
+4.13.2.2. Response other than "success"
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 29 \f
+ Lightweight Directory Access Protocol Version 3
+
+
+ If the ExtendedResponse contains a resultCode other than success,
+ this indicates that the server is unwilling or unable to negotiate
+ TLS.
+
+ If the Start TLS extended request was not successful, the resultCode
+ will be one of:
+
+ operationsError (operations sequencing incorrect; e.g. TLS already
+ established)
+
+ protocolError (TLS not supported or incorrect PDU structure)
+
+ referral (this server doesn't do TLS, try this one)
+
+ unavailable (e.g. some major problem with TLS, or server is
+ shutting down)
+
+ The server MUST return operationsError if the client violates any of
+ the Start TLS extended operation sequencing requirements described in
+ section 5.3 of [AuthMeth].
+
+ If the server does not support TLS (whether by design or by current
+ configuration), it MUST set the resultCode to protocolError, or to
+ referral. The server MUST include an actual referral value in the
+ LDAP Result if it returns a resultCode of referral. The client's
+ current session is unaffected if the server does not support TLS. The
+ client MAY proceed with any LDAP operation, or it MAY close the
+ connection.
+
+ The server MUST return unavailable if it supports TLS but cannot
+ establish a TLS connection for some reason, e.g. the certificate
+ server not responding, it cannot contact its TLS implementation, or
+ if the server is in process of shutting down. The client MAY retry
+ the StartTLS operation, or it MAY proceed with any other LDAP
+ operation, or it MAY close the connection.
+
+4.13.3. Closing a TLS Connection
+
+ Two forms of TLS connection closure--graceful and abrupt--are
+ supported.
+
+4.13.3.1. Graceful Closure
+
+ Either the client or server MAY terminate the TLS connection and
+ leave the LDAP session intact by sending a TLS closure alert.
+
+ Before sending a TLS closure alert, the client MUST either wait for
+ any outstanding LDAP operations to complete, or explicitly abandon
+ them.
+
+ After the initiator of a close has sent a TLS closure alert, it MUST
+ discard any TLS messages until it has received a TLS closure alert
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 30 \f
+ Lightweight Directory Access Protocol Version 3
+
+ from the other party. It will cease to send TLS Record Protocol
+ PDUs, and following the receipt of the alert, MAY send and receive
+ LDAP PDUs.
+
+ The other party, if it receives a TLS closure alert, MUST immediately
+ transmit a TLS closure alert. It will subsequently cease to send TLS
+ Record Protocol PDUs, and MAY send and receive LDAP PDUs.
+
+4.13.3.2. Abrupt Closure
+
+ Either the client or server MAY abruptly close the TLS connection by
+ dropping the underlying transfer protocol connection. In this
+ circumstance, a server MAY send the client a Notice of Disconnection
+ before dropping the underlying connection.
+
+
+5. Protocol Element Encodings and Transfer
+
+ One underlying service is defined here. Clients and servers SHOULD
+ implement the mapping of LDAP over TCP described in 5.2.1.
+
+
+5.1. Protocol Encoding
+
+ The protocol elements of LDAP are encoded for exchange using the
+ Basic Encoding Rules (BER) [X.690] of ASN.1 [X.680]. However, due to
+ the high overhead involved in using certain elements of the BER, the
+ following additional restrictions are placed on BER-encodings of LDAP
+ protocol elements:
+
+ (1) Only the definite form of length encoding will be used.
+
+ (2) OCTET STRING values will be encoded in the primitive form only.
+
+ (3) If the value of a BOOLEAN type is true, the encoding MUST have
+ its contents octets set to hex "FF".
+
+ (4) If a value of a type is its default value, it MUST be absent.
+ Only some BOOLEAN and INTEGER types have default values in this
+ protocol definition.
+
+ These restrictions do not apply to ASN.1 types encapsulated inside of
+ OCTET STRING values, such as attribute values, unless otherwise
+ noted.
+
+
+5.2. Transfer Protocols
+
+ This protocol is designed to run over connection-oriented, reliable
+ transports, with all 8 bits in an octet being significant in the data
+ stream.
+
+
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 31 \f
+ Lightweight Directory Access Protocol Version 3
+
+5.2.1. 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 assigned port, 389. Servers may
+ instead provide a listener on a different port number. Clients MUST
+ support contacting servers on any valid TCP port.
+
+
+6. Implementation Guidelines
+
+
+6.1. Server Implementations
+
+ The server MUST be capable of recognizing all the mandatory attribute
+ type names and implement the syntaxes specified in [Syntaxes].
+ Servers MAY also recognize additional attribute type names.
+
+
+6.2. Client Implementations
+
+ Clients that follow referrals or 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
+ target entry name, scope and filter. 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 a DIT with at least
+ ten layers of naming contexts between the root and a leaf entry.
+
+ In the absence of prior agreements with servers, clients SHOULD NOT
+ assume that servers support any particular schemas beyond those
+ referenced in section 6.1. Different schemas can have different
+ attribute types with the same names. The client can retrieve the
+ subschema entries referenced by the subschemaSubentry attribute in
+ the entries held by the server.
+
+
+7. Security Considerations
+
+ When used with a connection-oriented transport, this version of the
+ protocol provides facilities for simple authentication using a
+ cleartext password, as well as any SASL mechanism [RFC2222]. SASL
+ allows for integrity and privacy services to be negotiated.
+
+ 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.
+
+ When used with SASL, it should be noted that the name field of the
+ BindRequest is not protected against modification. Thus if the
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 32 \f
+ Lightweight Directory Access Protocol Version 3
+
+ distinguished name of the client (an LDAPDN) is agreed through the
+ negotiation of the credentials, it takes precedence over any value in
+ the unprotected name field.
+
+ 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.
+
+ Protocol servers may return referrals which redirect protocol 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. Protocol clients are advised to be aware of
+ this, and possibly reject referrals when confidentiality measures are
+ in place. Protocol clients are advised to ignore referrals from the
+ Start TLS operation.
+
+
+8. Acknowledgements
+
+ This document is an update to RFC 2251, by Mark Wahl, Tim Howes, and
+ Steve Kille. Their work along with the input of individuals of the
+ IETF LDAPEXT, LDUP, LDAPBIS, and other Working Groups is gratefully
+ acknowledged.
+
+
+9. Normative References
+
+ [X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts,
+ Models and Service", 1993.
+
+ [Roadmap] K. Zeilenga (editor), "LDAP: Technical Specification Road
+ Map", draft-ietf-ldapbis-roadmap-xx.txt (a work in
+ progress).
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", RFC 2119, March 1997.
+
+ [X.680] ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998
+ Information Technology - Abstract Syntax Notation One
+ (ASN.1): Specification of basic notation
+
+ [X.690] ITU-T Rec. X.690, "Specification of ASN.1 encoding rules:
+ Basic, Canonical, and Distinguished Encoding Rules", 1994.
+
+ [LDAPIANA] K. Zeilenga, "IANA Considerations for LDAP", draft-ietf-
+ ldapbis-xx.txt (a work in progress).
+
+ [ISO10646] Universal Multiple-Octet Coded Character Set (UCS) -
+ Architecture and Basic Multilingual Plane, ISO/IEC 10646-1
+ : 1993.
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 33 \f
+ Lightweight Directory Access Protocol Version 3
+
+
+ [RFC2279] Yergeau, F., "UTF-8, a transformation format of Unicode
+ and ISO 10646", RFC 2279, January 1998.
+
+ [Models] K. Zeilenga, "LDAP: The Models", draft-ietf-ldapbis-
+ models-xx.txt (a work in progress).
+
+ [LDAPDN] K. Zeilenga (editor), "LDAP: String Representation of
+ Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, (a
+ work in progress).
+
+ [Syntaxes] K. Dally (editor), "LDAP: Syntaxes", draft-ietf-ldapbis-
+ syntaxes-xx.txt, (a work in progress).
+
+ [X.501] ITU-T Rec. X.501, "The Directory: Models", 1993.
+
+ [X.511] ITU-T Rec. X.511, "The Directory: Abstract Service
+ Definition", 1993.
+
+ [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter Uniform
+ Resource Identifiers (URI): Generic Syntax", RFC 2396,
+ August 1998.
+
+ [AuthMeth] R. Harrison (editor), "LDAP: Authentication Methods",
+ draft-ietf-ldapbis-authmeth-xx.txt, (a work in progress).
+
+ [RFC2222] Meyers, J., "Simple Authentication and Security Layer",
+ RFC 2222, October 1997.
+
+
+10. 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 Sep 2003 Page 34 \f
+ 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.10.
+
+ Additional result codes MAY be defined for use with extensions.
+ Client implementations SHALL treat any result code which they do not
+ recognize as an unknown error condition.
+
+A.1 Non-Error Result Codes
+ These result codes (called "non-error" result codes) do not indicate
+ an error condition:
+ success(0),
+ compareTrue(6),
+ compareFalse(7),
+ referral(10), and
+ saslBindInProgress(14).
+
+ The success(0), compareTrue(6), and compare(7) result codes indicate
+ successful completion (and, hence, are called to as "successful"
+ result codes).
+
+ The referral(10) and saslBindInProgress(14) indicate the client is
+ required to take additional action to complete the operation
+
+
+A.2 Error Result Codes
+
+A.3 Classes and Precedence of Error Result Codes
+
+ Result codes that indicate error conditions (and, hence, are called
+ "error" result codes) fall into 6 classes. The following list
+ specifies the precedence of error classes to be used when more than
+ one error is detected [X511]:
+ 1) Name Errors (codes 32 - 34, 36)
+ - a problem related to a name (DN or RDN),
+ 2) Update Errors (codes 64 - 69, 71)
+ - a problem related to an update operation,
+ 3) Attribute Errors (codes 16 - 21)
+ - a problem related to a supplied attribute,
+ 4) Security Errors (codes 8, 13, 48 - 50)
+ - a security related problem,
+ 5) Service Problem (codes 3, 4, 7, 11, 12, 51 - 54, 80)
+ - a problem related to the provision of the service, and
+ 6) Protocol Problem (codes 1, 2)
+ - a problem related to protocol structure or semantics.
+
+ If the server detects multiple errors simultaneously, the server
+ SHOULD report the error with the highest precedence.
+
+ Existing LDAP result codes are described as follows:
+
+ success (0)
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 35 \f
+ Lightweight Directory Access Protocol Version 3
+
+
+ Indicates successful completion of an operation.
+
+ This result code is normally not returned by the compare
+ operation, see compareFalse (5) and compareTrue (6). It is
+ possible that a future extension mechanism would allow this
+ to be returned by a compare operation.
+
+
+ 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
+ Start TLS [RFC2246] while there are other operations
+ outstanding or if TLS was already established.
+
+
+
+ protocolError (2)
+
+ Indicates the server received data which has incorrect
+ structure.
+
+ For bind operation only, the code may be resulted to indicate
+ the server does not support the requested protocol version.
+
+
+ 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 operation successfully completes and the
+ assertion has evaluated to FALSE.
+
+ This result code is normally only returned by the compare
+ operation.
+
+
+ compareTrue (6)
+
+ Indicates that the operation successfully completes and the
+ assertion has evaluated to TRUE.
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 36 \f
+ Lightweight Directory Access Protocol Version 3
+
+
+ This result code is normally only returned by the compare
+ operation.
+
+
+ authMethodNotSupported (7)
+
+ Indicates that the authentication method or mechanism is not
+ supported.
+
+
+ strongAuthRequired (8)
+
+ Except when returned in a Notice of Disconnect (see section
+ 4.4.1), this indicates that the server requires the client to
+ authentication using a strong(er) mechanism.
+
+
+ referral (10)
+
+ Indicates that a referral needs to be chased to complete the
+ operation (see section 4.1.11).
+
+
+ adminLimitExceeded (11)
+
+ Indicates that an administrative limit has been exceeded.
+
+
+ unavailableCriticalExtension (12)
+
+ Indicates that server cannot perform a critical extension
+ (see section 4.1.12).
+
+
+ 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)
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 37 \f
+ Lightweight Directory Access Protocol Version 3
+
+
+ Indicates that a request field contains an undefined
+ attribute type.
+
+
+ inappropriateMatching (18)
+
+ Indicates that a request cannot be completed due to an
+ inappropriate matching.
+
+
+ constraintViolation (19)
+
+ Indicates that the client supplied an attribute value which
+ does not conform to constraints placed upon it by the data
+ model.
+
+ For example, this code is returned when the 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 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. Typically an
+ alias has been dereferenced which names no object.
+
+
+ invalidDNSyntax (34)
+
+ Indicates that a 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 Sep 2003 Page 38 \f
+ 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 the supplied password or SASL credentials 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 busy.
+
+
+ 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.
+
+
+ namingViolation (64)
+
+ Indicates that the entry name violates naming restrictions.
+
+ objectClassViolation (65)
+
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 39 \f
+ Lightweight Directory Access Protocol Version 3
+
+ Indicates that the entry violates object class restrictions.
+
+
+ notAllowedOnNonLeaf (66)
+
+ Indicates that 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 added fulfilled as the
+ entry already exists.
+
+
+ objectClassModsProhibited (69)
+
+ Indicates that the attempt to modify the object class(es) of
+ an entry objectClass attribute is prohibited.
+
+ For example, this code is returned when a when a client
+ attempts to modify the structural object class of an entry.
+
+
+ affectsMultipleDSAs (71)
+
+ Indicates that the operation cannot be completed as it
+ affects multiple servers (DSAs).
+
+
+ other (80)
+
+ Indicates the server has encountered an internal error.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 40 \f
+ Lightweight Directory Access Protocol Version 3
+
+ Appendix B - Complete ASN.1 Definition
+
+ This appendix is normative.
+
+ Lightweight-Directory-Access-Protocol-V3 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,
+ ... },
+ 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
+
+ RelativeLDAPDN ::= LDAPString
+
+ AttributeDescription ::= LDAPString
+ -- Constrained to attributedescription
+ -- [Models]
+
+ AttributeDescriptionList ::= SEQUENCE OF
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 41 \f
+ Lightweight Directory Access Protocol Version 3
+
+ AttributeDescription
+
+ AttributeValue ::= OCTET STRING
+
+ AttributeValueAssertion ::= SEQUENCE {
+ attributeDesc AttributeDescription,
+ assertionValue AssertionValue }
+
+ AssertionValue ::= OCTET STRING
+
+ Attribute ::= SEQUENCE {
+ type AttributeDescription,
+ vals SET OF AttributeValue }
+
+ MatchingRuleId ::= LDAPString
+
+ LDAPResult ::= SEQUENCE {
+ resultCode ENUMERATED {
+ success (0),
+ operationsError (1),
+ protocolError (2),
+ timeLimitExceeded (3),
+ sizeLimitExceeded (4),
+ compareFalse (5),
+ compareTrue (6),
+ authMethodNotSupported (7),
+ strongAuthRequired (8),
+ -- 9 reserved --
+ referral (10),
+ 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 --
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 42 \f
+ Lightweight Directory Access Protocol Version 3
+
+ namingViolation (64),
+ objectClassViolation (65),
+ notAllowedOnNonLeaf (66),
+ notAllowedOnRDN (67),
+ entryAlreadyExists (68),
+ objectClassModsProhibited (69),
+ -- 70 reserved for CLDAP --
+ affectsMultipleDSAs (71),
+ -- 72-79 unused --
+ other (80),
+ ... },
+ -- 81-90 reserved for APIs --
+ matchedDN LDAPDN,
+ diagnosticMessage LDAPString,
+ referral [3] Referral OPTIONAL }
+
+ Referral ::= SEQUENCE OF LDAPURL
+
+ LDAPURL ::= LDAPString -- limited to characters permitted in
+ -- URLs
+
+ Controls ::= SEQUENCE OF 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),
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 43 \f
+ Lightweight Directory Access Protocol Version 3
+
+ 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 AttributeDescriptionList }
+
+ Filter ::= CHOICE {
+ and [0] SET SIZE (1..MAX) OF Filter,
+ or [1] SET SIZE (1..MAX) OF 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,
+ -- at least one must be present,
+ -- initial and final can occur at most once
+ substrings SEQUENCE OF CHOICE {
+ initial [0] AssertionValue,
+ any [1] AssertionValue,
+ final [2] AssertionValue } }
+
+ 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 SEQUENCE {
+ type AttributeDescription,
+ vals SET OF AttributeValue }
+
+ SearchResultReference ::= [APPLICATION 19] SEQUENCE OF LDAPURL
+
+ SearchResultDone ::= [APPLICATION 5] LDAPResult
+
+ ModifyRequest ::= [APPLICATION 6] SEQUENCE {
+ object LDAPDN,
+ modification SEQUENCE OF SEQUENCE {
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 44 \f
+ Lightweight Directory Access Protocol Version 3
+
+ operation ENUMERATED {
+ add (0),
+ delete (1),
+ replace (2) },
+ modification AttributeTypeAndValues } }
+
+ AttributeTypeAndValues ::= SEQUENCE {
+ type AttributeDescription,
+ vals SET OF AttributeValue }
+
+ ModifyResponse ::= [APPLICATION 7] LDAPResult
+
+ AddRequest ::= [APPLICATION 8] SEQUENCE {
+ entry LDAPDN,
+ attributes AttributeList }
+
+ AttributeList ::= SEQUENCE OF SEQUENCE {
+ type AttributeDescription,
+ vals SET OF AttributeValue }
+
+ 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,
+ response [11] OCTET STRING OPTIONAL }
+
+ END
+
+
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 45 \f
+ Lightweight Directory Access Protocol Version 3
+
+Appendix C - Change History
+ <Note to RFC editor: This section is to be removed prior to RFC
+ publication>
+
+C.1 Changes made to RFC 2251:
+
+C.1.1 Editorial
+
+ - Bibliography References: Changed all bibliography references to
+ use a long name form for readability.
+ - Changed occurrences of "unsupportedCriticalExtension"
+ "unavailableCriticalExtension"
+ - Fixed a small number of misspellings (mostly dropped letters).
+
+C.1.2 Section 1
+
+ - Removed IESG note.
+
+C.1.3 Section 9
+
+ - Added references to RFCs 1823, 2234, 2829 and 2830.
+
+
+C.2 Changes made to draft-ietf-ldapbis-protocol-00.txt:
+
+C.2.1 Section 4.1.6
+
+ - In the first paragraph, clarified what the contents of an
+ AttributeValue are. There was confusion regarding whether or not
+ an AttributeValue that is BER encoded (due to the "binary" option)
+ is to be wrapped in an extra OCTET STRING.
+ - To the first paragraph, added wording that doesn't restrict other
+ transfer encoding specifiers from being used. The previous wording
+ only allowed for the string encoding and the ;binary encoding.
+ - To the first paragraph, added a statement restricting multiple
+ options that specify transfer encoding from being present. This
+ was never specified in the previous version and was seen as a
+ potential interoperability problem.
+ - Added a third paragraph stating that the ;binary option is
+ currently the only option defined that specifies the transfer
+ encoding. This is for completeness.
+
+C.2.2 Section 4.1.7
+
+ - Generalized the second paragraph to read "If an option specifying
+ the transfer encoding is present in attributeDesc, the
+ AssertionValue is encoded as specified by the option...".
+ Previously, only the ;binary option was mentioned.
+
+C.2.3 Sections 4.2, 4.9, 4.10
+
+ - Added alias dereferencing specifications. In the case of modDN,
+ followed precedent set on other update operations (... alias is
+ not dereferenced...) In the case of bind and compare stated that
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 46 \f
+ Lightweight Directory Access Protocol Version 3
+
+ servers SHOULD NOT dereference aliases. Specifications were added
+ because they were missing from the previous version and caused
+ interoperability problems. Concessions were made for bind and
+ compare (neither should have ever allowed alias dereferencing) by
+ using SHOULD NOT language, due to the behavior of some existing
+ implementations.
+
+C.2.4 Sections 4.5 and Appendix A
+
+ - Changed SubstringFilter.substrings.initial, any, and all from
+ LDAPString to AssertionValue. This was causing an incompatibility
+ with X.500 and confusion among other TS RFCs.
+
+
+C.3 Changes made to draft-ietf-ldapbis-protocol-01.txt:
+
+C.3.1 Section 3.4
+
+ - Reworded text surrounding subschemaSubentry to reflect that it is
+ a single-valued attribute that holds the schema for the root DSE.
+ Also noted that if the server masters entries that use differing
+ schema, each entry's subschemaSubentry attribute must be
+ interrogated. This may change as further fine-tuning is done to
+ the data model.
+
+C.3.2 Section 4.1.12
+
+ - Specified that the criticality field is only used for requests and
+ not for unbind or abandon. Noted that it is ignored for all other
+ operations.
+
+C.3.3 Section 4.2
+
+ - Noted that Server behavior is undefined when the name is a null
+ value, simple authentication is used, and a password is specified.
+
+C.3.4 Section 4.2.(various)
+
+ - Changed "unauthenticated" to "anonymous" and "DN" and "LDAPDN" to
+ "name"
+
+C.3.5 Section 4.2.2
+
+ - Changed "there is no authentication or encryption being performed
+ by a lower layer" to "the underlying transport service cannot
+ guarantee confidentiality"
+
+C.3.6 Section 4.5.2
+
+ - Removed all mention of ExtendedResponse due to lack of
+ implementation.
+
+C.4 Changes made to draft-ietf-ldapbis-protocol-02.txt:
+
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 47 \f
+ Lightweight Directory Access Protocol Version 3
+
+C.4.1 Section 4
+
+ - Removed "typically" from "and is typically transferred" in the
+ first paragraph. We know of no (and can conceive of no) case where
+ this isn't true.
+ - Added "Section 5.1 specifies how the LDAP protocol is encoded." To
+ the first paragraph. Added this cross reference for readability.
+ - Changed "version 3 " to "version 3 or later" in the second
+ paragraph. This was added to clarify the original intent.
+ - Changed "protocol version" to "protocol versions" in the third
+ paragraph. This attribute is multi-valued with the intent of
+ holding all supported versions, not just one.
+
+C.4.2 Section 4.1.8
+
+ - Changed "when transferred in protocol" to "when transferred from
+ the server to the client" in the first paragraph. This is to
+ clarify that this behavior only happens when attributes are being
+ sent from the server.
+
+C.4.3 Section 4.1.10
+
+ - Changed "servers will return responses containing fields of type
+ LDAPResult" to "servers will return responses of LDAPResult or
+ responses containing the components of LDAPResponse". This
+ statement was incorrect and at odds with the ASN.1. The fix here
+ reflects the original intent.
+ - Dropped '--new' from result codes ASN.1. This simplification in
+ comments just reduces unneeded verbiage.
+
+C.4.4 Section 4.1.11
+
+ - Changed "It contains a reference to another server (or set of
+ servers)" to "It contains one or more references to one or more
+ servers or services" in the first paragraph. This reflects the
+ original intent and clarifies that the URL may point to non-LDAP
+ services.
+
+C.4.5 Section 4.1.12
+
+ - 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.4.6 Section 4.4
+
+ - Changed "One unsolicited notification is defined" to "One
+ unsolicited notification (Notice of Disconnection) is defined" in
+ the third paragraph. For clarity and readability.
+
+C.4.7 Section 4.5.1
+
+
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 48 \f
+ Lightweight Directory Access Protocol Version 3
+
+ - Changed "checking for the existence of the objectClass attribute"
+ to "checking for the presence of the objectClass attribute" in the
+ last paragraph. This was done as a measure of consistency (we use
+ the terms present and presence rather than exists and existence in
+ search filters).
+
+C.4.8 Section 4.5.3
+
+ - Changed "outstanding search operations to different servers," to
+ "outstanding search operations" in the fifth paragraph as they may
+ be to the same server. This is a point of clarification.
+
+C.4.9 Section 4.6
+
+ - Changed "clients MUST NOT attempt to delete" to "clients MUST NOT
+ attempt to add or delete" in the second to last paragraph.
+ - Change "using the "delete" form" to "using the "add" or "delete"
+ form" in the second to last paragraph.
+
+C.4.10 Section 4.7
+
+ - Changed "Clients MUST NOT supply the createTimestamp or
+ creatorsName attributes, since these will be generated
+ automatically by the server." to "Clients MUST NOT supply NO-USER-
+ MODIFICATION attributes such as createTimestamp or creatorsName
+ attributes, since these are provided by the server." in the
+ definition of the attributes field. This tightens the language to
+ reflect the original intent and to not leave a hole in which one
+ could interpret the two attributes mentioned as the only non-
+ writable attributes.
+
+C.4.11 Section 4.11
+
+ - Changed "has been" to "will be" in the fourth paragraph. This
+ clarifies that the server will (not has) abandon the operation.
+
+
+C.5 Changes made to draft-ietf-ldapbis-protocol-03.txt:
+
+C.5.1 Section 3.2.1
+
+ - Changed "An attribute is a type with one or more associated
+ values. The attribute type is identified by a short descriptive
+ name and an OID (object identifier). The attribute type governs
+ whether there can be more than one value of an attribute of that
+ type in an entry, the syntax to which the values must conform, the
+ kinds of matching which can be performed on values of that
+ attribute, and other functions." to " An attribute is a
+ description (a type and zero or more options) with one or more
+ associated values. The attribute type governs whether the
+ attribute can have multiple values, the syntax and matching rules
+ used to construct and compare values of that attribute, and other
+ functions. Options indicate modes of transfer and other
+
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 49 \f
+ Lightweight Directory Access Protocol Version 3
+
+ functions.". This points out that an attribute consists of both
+ the type and options.
+
+C.5.2 Section 4
+
+ - Changed "Section 5.1 specifies the encoding rules for the LDAP
+ protocol" to "Section 5.1 specifies how the protocol is encoded
+ and transferred."
+
+C.5.3 Section 4.1.2
+
+ - Added ABNF for the textual representation of LDAPOID. Previously,
+ there was no formal BNF for this construct.
+
+C.5.4 Section 4.1.4
+
+ - Changed "This identifier may be written as decimal digits with
+ components separated by periods, e.g. "2.5.4.10"" to "may be
+ written as defined by ldapOID in section 4.1.2" in the second
+ paragraph. This was done because we now have a formal BNF
+ definition of an oid.
+
+C.5.5 Section 4.1.5
+
+ - Changed the BNF for AttributeDescription to ABNF. This was done
+ for readability and consistency (no functional changes involved).
+ - Changed "Options present in an AttributeDescription are never
+ mutually exclusive." to "Options MAY be mutually exclusive. An
+ AttributeDescription with mutually exclusive options is treated as
+ an undefined attribute type." for clarity. It is generally
+ understood that this is the original intent, but the wording could
+ be easily misinterpreted.
+ - Changed "Any option could be associated with any AttributeType,
+ although not all combinations may be supported by a server." to
+ "Though any option or set of options could be associated with any
+ AttributeType, the server support for certain combinations may be
+ restricted by attribute type, syntaxes, or other factors.". This
+ is to clarify the meaning of 'combination' (it applies both to
+ combination of attribute type and options, and combination of
+ options). It also gives examples of *why* they might be
+ unsupported.
+
+C.5.6 Section 4.1.11
+
+ - Changed the wording regarding 'equally capable' referrals to "If
+ multiple URLs are present, the client assumes that any URL may be
+ used to progress the operation.". The previous language implied
+ that the server MUST enforce rules that it was practically
+ incapable of. The new language highlights the original intent--
+ that is, that any of the referrals may be used to progress the
+ operation, there is no inherent 'weighting' mechanism.
+
+C.5.7 Section 4.5.1 and Appendix A
+
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 50 \f
+ Lightweight Directory Access Protocol Version 3
+
+ - Added the comment "-- initial and final can occur at most once",
+ to clarify this restriction.
+
+C.5.8 Section 5.1
+
+ - Changed heading from "Mapping Onto BER-based Transport Services"
+ to "Protocol Encoding".
+
+C.5.9 Section 5.2.1
+
+ - Changed "The LDAPMessage PDUs" to "The encoded LDAPMessage PDUs"
+ to point out that the PDUs are encoded before being streamed to
+ TCP.
+
+C.6 Changes made to draft-ietf-ldapbis-protocol-04.txt:
+
+C.6.1 Section 4.5.1 and Appendix A
+
+ - Changed the ASN.1 for the and and or choices of Filter to have a
+ lower range of 1. This was an omission in the original ASN.1
+
+C.6.2 Various
+
+ - Fixed various typo's
+
+C.7 Changes made to draft-ietf-ldapbis-protocol-05.txt:
+
+C.7.1 Section 3.2.1
+
+ - Added "(as defined in Section 12.4.1 of [X.501])" to the fifth
+ paragraph when talking about "operational attributes". This is
+ because the term "operational attributes" is never defined.
+ Alternately, we could drag a definition into the spec, for now,
+ I'm just pointing to the reference in X.501.
+
+C.7.2 Section 4.1.5
+
+ - Changed "And is also case insensitive" to "The entire
+ AttributeDescription is case insensitive". This is to clarify
+ whether we're talking about the entire attribute description, or
+ just the options.
+
+ - Expounded on the definition of attribute description options. This
+ doc now specifies a difference between transfer and tagging
+ options and describes the semantics of each, and how and when
+ subtyping rules apply. Now allow options to be transmitted in any
+ order but disallow any ordering semantics to be implied. These
+ changes are the result of ongoing input from an engineering team
+ designed to deal with ambiguity issues surrounding attribute
+ options.
+
+C.7.3 Sections 4.1.5.1 and 4.1.6
+
+
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 51 \f
+ Lightweight Directory Access Protocol Version 3
+
+ - Refer to non "binary" transfer encodings as "native encoding"
+ rather than "string" encoding to clarify and avoid confusion.
+
+C.8 Changes made to draft-ietf-ldapbis-protocol-06.txt:
+
+C.8.1 Title
+
+ - Changed to "LDAP: The Protocol" to be consisted with other working
+ group documents
+
+C.8.2 Abstract
+
+ - Moved above TOC to conform to new guidelines
+
+ - Reworded to make consistent with other WG documents.
+
+ - Moved 2119 conventions to "Conventions" section
+
+C.8.3 Introduction
+
+ - Created to conform to new guidelines
+
+C.8.4 Models
+
+ - Removed section. There is only one model in this document
+ (Protocol Model)
+
+C.8.5 Protocol Model
+
+ - Removed antiquated paragraph: "In keeping with the goal of easing
+ the costs associated with use of the directory, it is an objective
+ of this protocol to minimize the complexity of clients so as to
+ facilitate widespread deployment of applications capable of using
+ the directory."
+
+ - Removed antiquated paragraph concerning LDAP v1 and v2 and
+ referrals.
+
+C.8.6 Data Model
+
+ - Removed Section 3.2 and subsections. These have been moved to
+ [Models]
+
+C.8.7 Relationship to X.500
+
+ - Removed section. It has been moved to [Roadmap]
+
+C.8.8 Server Specific Data Requirements
+
+ - Removed section. It has been moved to [Models]
+
+C.8.9 Elements of Protocol
+
+
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 52 \f
+ Lightweight Directory Access Protocol Version 3
+
+ - Added "Section 5.1 specifies how the protocol is encoded and
+ transferred." to the end of the first paragraph for reference.
+
+ - Reworded notes about extensibility, and now talk about implied
+ extensibility and the use of ellipses in the ASN.1
+
+ - Removed references to LDAPv2 in third and fourth paragraphs.
+
+C.8.10 Message ID
+
+ - Reworded second paragraph to "The message ID of a request MUST
+ have a non-zero value different from the values of any other
+ requests outstanding in the LDAP session of which this message is
+ a part. The zero value is reserved for the unsolicited
+ notification message." (Added notes about non-zero and the zero
+ value).
+
+C.8.11 String Types
+
+ - Removed ABNF for LDAPOID and added "Although an LDAPOID is encoded
+ as an OCTET STRING, values are limited to the definition of
+ numericoid given in Section 1.3 of [Models]."
+
+C.8.12 Distinguished Name and Relative Distinguished Name
+
+ - Removed ABNF and referred to [Models] and [LDAPDN] where this is
+ defined.
+
+C.8.13 Attribute Type
+
+ - Removed sections. It's now in the [Models] doc.
+
+C.8.14 Attribute Description
+
+ - Removed ABNF and aligned section with [Models]
+
+ - Moved AttributeDescriptionList here.
+
+C.8.15 Transfer Options
+
+ - Added section and consumed much of old options language (while
+ aligning with [Models]
+
+C.8.16 Binary Transfer Option
+
+ - Clarified intent regarding exactly what is to be BER encoded.
+
+ - Clarified that clients must not expect ;binary when not asking for
+ it (;binary, as opposed to ber encoded data).
+
+
+C.8.17 Attribute
+
+ - Use the term "attribute description" in lieu of "type"
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 53 \f
+ Lightweight Directory Access Protocol Version 3
+
+
+ - Clarified the fact that clients cannot rely on any apparent
+ ordering of attribute values.
+
+C.8.18 LDAPResult
+
+ - To resultCode, added ellipses "..." to the enumeration to indicate
+ extensibility. and added a note, pointing to [LDAPIANA]
+
+ - Removed error groupings ad refer to Appendix A.
+
+C.8.19 Bind Operation
+
+ - Added "Prior to the BindRequest, the implied identity is
+ anonymous. Refer to [AuthMeth] for the authentication-related
+ semantics of this operation." to the first paragraph.
+
+ - Added ellipses "..." to AuthenticationChoice and added a note
+ "This type is extensible as defined in Section 3.6 of [LDAPIANA].
+ Servers that do not support a choice supplied by a client will
+ return authMethodNotSupported in the result code of the
+ BindResponse."
+
+ - Simplified text regarding how the server handles unknown versions.
+ Removed references to LDAPv2
+
+C.8.20 Sequencing of the Bind Request
+
+ - Aligned with [AuthMeth] In particular, paragraphs 4 and 6 were
+ removed, while a portion of 4 was retained (see C.8.9)
+
+C.8.21 Authentication and other Security Service
+
+ - Section was removed. Now in [AuthMeth]
+
+C.8.22 Continuation References in the Search Result
+
+ - Added "If the originating search scope was singleLevel, the scope
+ part of the URL will be baseObject."
+
+C.8.23 Security Considerations
+
+ - Removed reference to LDAPv2
+
+C.8.24 Result Codes
+
+ - Added as normative appendix A
+
+C.8.25 ASN.1
+
+ - Added EXTENSIBILITY IMPLIED
+
+ - Added a number of comments holding referenced to [Models] and
+ [ISO10646].
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 54 \f
+ Lightweight Directory Access Protocol Version 3
+
+
+ - Removed AttributeType. It is not used.
+
+
+C.9 Changes made to draft-ietf-ldapbis-protocol-07.txt:
+
+ - Removed all mention of transfer encodings and the binary attribute
+ option
+
+ - Further alignment with [Models].
+
+ - Added extensibility ellipsis to protocol op choice
+
+ - In 4.1.1, clarified when connections may be dropped due to
+ malformed PDUs
+
+ - Specified which matching rules and syntaxes are used for various
+ filter items
+
+C.10 Changes made to draft-ietf-ldapbis-protocol-08.txt:
+
+C.10.1 Section 4.1.1.1:
+
+ - Clarified when it is and isn't appropriate to return an already
+ used message id.
+
+C.10.2 Section 4.1.11:
+
+ - Clarified that a control only applies to the message it's attached
+ to.
+
+ - Explained that the criticality field is only applicable to certain
+ request messages.
+
+ - Added language regarding the combination of controls.
+
+C.10.3 Section 4.11:
+
+ - Explained that Abandon and Unbind cannot be abandoned, and
+ illustrated how to determine whether an operation has been
+ abandoned.
+
+
+C.11 Changes made to draft-ietf-ldapbis-protocol-09.txt:
+
+ - Fixed formatting
+
+
+C.12 Changes made to draft-ietf-ldapbis-protocol-10.txt:
+
+C.12.1 Section 4.1.4:
+
+ - Removed second paragraph as this language exists in MODELS
+
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 55 \f
+ Lightweight Directory Access Protocol Version 3
+
+C.12.2 Section 4.2.1:
+
+ - Replaced fourth paragraph. It was accidentally removed in an
+ earlier edit.
+
+C.12.2 Section 4.13:
+
+ - Added section describing the StartTLS operation (moved from
+ authmeth)
+
+C.13 Changes made to draft-ietf-ldapbis-protocol-11.txt:
+
+C.13.1 Section 4.1.9
+
+ - Changed "errorMessage" to "diagnosticMessage". Simply to indicate
+ that the field may be non-empty even if a non-error resultCode is
+ present.
+
+C.13.2 Section 4.2:
+
+ - Reconciled language in "name" definition with [AuthMeth]
+
+C.13.3 Section 4.2.1
+
+ - Renamed to "Processing of the Bind Request", and moved some text
+ from 4.2 into this section.
+
+ - Rearranged paragraphs to flow better.
+
+ - Specified that (as well as failed) an abandoned bind operation
+ will leave the connection in an anonymous state.
+
+C.13.4 Section 4.5.3
+
+ - Generalized the second paragraph which cited indexing and
+ searchreferralreferences.
+
+C.14 Changes made to draft-ietf-ldapbis-protocol-12.txt:
+
+ - Reworked bind errors.
+ - General clarifications and edits
+
+Appendix D - Outstanding Work Items
+
+D.0 General
+ - Integrate notational consistency agreements WG will discuss
+ notation consistency. Once agreement happens, reconcile draft.
+
+ - Reconcile problems with [Models]. Section 3.2 was wholly removed.
+ There were some protocol semantics in that section that need to be
+ brought back. Specifically, there was the notion of the server
+ implicitly adding objectclass superclasses when a value is added.
+
+D.1 Make result code usage consistent.
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 56 \f
+ Lightweight Directory Access Protocol Version 3
+
+
+ - While there is a result code appendix, ensure it speaks of result
+ codes in a general sense, and only highlight specific result codes
+ in the context of an operation when that operation ties more
+ specific meanings to that result code.
+
+
+D.2 Verify references.
+
+ - Many referenced documents have changed. Ensure references and
+ section numbers are correct.
+
+D.3 Usage of Naming Context
+
+ - Make sure occurrences of "namingcontext" and "naming context" are
+ consistent with [Models]. Use in section 6.2 should be reworked.
+ It's layers of indirection that matter, not number of contexts.
+ (That is, referrals can be returned for a number of reasons (cross
+ reference, superior, subordinate, busy, not master, etc.)
+
+ Other uses are fine.
+
+D.4 Review 2119 usage
+
+
+D.5 Reconcile with I-D Nits
+
+
+D.23 Section 4.5.3
+
+ - A server MUST NOT return any SearchResultReference if it has not
+ located the baseObject and thus has not searched any entries; in
+ this case it would return a SearchResultDone containing a referral
+ resultCode.
+
+ - Add "Similarly, a server MUST NOT return a SearchResultReference
+ when the scope of the search is baseObject. If a client receives
+ such a SearchResultReference it MUST interpret is as a protocol
+ error and MUST NOT follow it." to the first paragraph.
+ The technical specification doesn't have to describe how a
+ protocol peer should react when its partner violates an absolute.
+
+ OR return noSuchObject.
+
+ - Add "If the scope part of the LDAP URL is present, the client MUST
+ use the new scope in its next request to progress the search. If
+ the scope part is absent the client MUST use subtree scope to
+ complete subtree searches and base scope to complete one level
+ searches." to the third paragraph.
+
+D.25 Section 4.6
+
+
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 57 \f
+ Lightweight Directory Access Protocol Version 3
+
+ - Resolve the meaning of "and is ignored if the attribute does not
+ exist". See "modify: "non-existent attribute"" on the list. Not
+ sure if there's really an issue here. Will look at archive
+
+D.27 Section 4.10
+
+ - Specify what happens when the attr is missing vs. attr isn't in
+ schema. Also what happens if there's no equality matching rule.
+ noSuchAttribute, undefinedAttributeType, inappropriateMatching
+
+D.30 Section 5.1
+
+ - Add "control and extended operation values" to last paragraph. See
+ "LBER (BER Restrictions)" on list.
+
+D.32 Section 6.1
+
+ - Add "that are used by those attributes" to the first paragraph.
+ - Add "Servers which support update operations MUST, and other
+ servers SHOULD, support strong authentication mechanisms described
+ in [RFC2829]." as a second paragraph. Likely should just say
+ Requirements of authentication methods, SASL mechanisms, and TLS
+ are described in [AUTHMETH]." (also apply to next two below)
+ - Add "Servers which provide access to sensitive information MUST,
+ and other servers SHOULD support privacy protections such as those
+ described in [RFC2829] and [RFC2830]." as a third paragraph.
+
+D.33 Section 7
+
+ - Add "Servers which support update operations MUST, and other
+ servers SHOULD, support strong authentication mechanisms described
+ in [RFC2829]." as a fourth paragraph.
+ - Add "In order to automatically follow referrals, clients may need
+ to hold authentication secrets. This poses significant privacy and
+ security concerns and SHOULD be avoided." as a sixth paragraph.
+ There are concerns with "automatic" chasing regardless of which,
+ if any, authentication method/mechanism is used.
+
+ - Add notes regarding DoS attack found by CERT advisories.
+
+D.34 Appendix C
+
+ - C.9. Explain why we removed ;binary, and what clients can do to
+ get around potential problems (likely refer to an I-D)
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 58 \f
+ Lightweight Directory Access Protocol Version 3
+
+ Full Copyright Statement
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim Internet-Draft - Expires Sep 2003 Page 59 \f
\ No newline at end of file
--- /dev/null
+
+
+
+
+
+
+INTERNET-DRAFT Editor: Kurt D. Zeilenga
+Intended Category: Standard Track OpenLDAP Foundation
+Expires in six months 1 March 2003
+Obsoletes: RFC 2251-2256, 2829-2830, 3377
+
+
+
+ LDAP: Technical Specification Road Map
+ <draft-ietf-ldapbis-roadmap-02.txt>
+
+
+Status of this Memo
+
+ This document is an Internet-Draft and is in full conformance with all
+ provisions of Section 10 of RFC2026.
+
+ This document is intended to be published as a Standard Track RFC.
+ Distribution of this memo is unlimited. Technical discussion of this
+ document will take place on the IETF LDAP Revision Working Group
+ mailing list <ietf-ldapbis@openldap.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
+
+ The Lightweight Directory Access Protocol (LDAP) is an Internet
+ protocol for accessing distributed directory services which act in
+ accordance with X.500 data and service models. This document provides
+ a roadmap of the LDAP Technical Specification.
+
+
+
+
+Zeilenga LDAP: TS Road Map [Page 1]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-roadmap-02 1 March 2003
+
+
+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].
+
+
+1. The LDAP Technical Specification
+
+ The technical specification detailing version 3 of the Lightweight
+ Directory Access Protocol (LDAP), an Internet Protocol, consists of
+ this document and the following documents:
+
+ LDAP: Directory Information Models [Models],
+ LDAP: The Protocol [Protocol],
+ LDAP: Authentication Methods and Connection Level Security
+ Mechanisms [AuthMeth],
+ LDAP: String Representation of Distinguished Names [LDAPDN],
+ LDAP: String Representation of Search Filters [Filters],
+ LDAP: Uniform Resource Locator [LDAPURL],
+ LDAP: Syntaxes [Syntaxes], and
+ LDAP: User Schema [Schema].
+
+ The terms "LDAP" and "LDAPv3" are commonly used to informally refer to
+ the protocol specified by this technical specification. The LDAP
+ suite, as defined here, should be formally identified in other
+ documents by a normative reference to this document.
+
+ Extensions to LDAP may be specified in other documents. Nomenclature
+ denoting such combinations of LDAP-plus-extension(s) is not defined by
+ this document but may be defined in some future document(s).
+
+ IANA (Internet Assigned Numbers Authority) considerations for LDAP
+ described in BCP 64 [RFC3383] apply fully to this revision of the LDAP
+ technical specification.
+
+
+2. Relationship to X.500
+
+ This technical specification defines LDAP in terms of [X.500] as an
+ X.500 access mechanism. An LDAP server MUST act in accordance with
+ X.500(1993) series of International Telephone Union (ITU)
+ Recommendations when providing the service. However, it is not
+ required that an LDAP server make use of any X.500 protocols in
+ providing this service, e.g. LDAP can be mapped onto any other
+ directory system so long as the X.500 data and service models
+ [X.501][X.511] as used in LDAP is not violated in the LDAP interface.
+
+
+
+
+Zeilenga LDAP: TS Road Map [Page 2]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-roadmap-02 1 March 2003
+
+
+ This technical specification explicitly incorporates portions of
+ X.500(93). Later revisions of X.500 do not automatically apply.
+
+
+3. Security Considerations
+
+ LDAP security considerations are discussed in each document comprising
+ the technical specification.
+
+
+4. Relationship to Obsolete Specifications
+
+ This technical specification, as defined in Section 1, obsoletes
+ entirely the previously defined LDAP technical specification [RFC3377]
+ (which consists of RFC 2251-2256, RFC 2829-2830 and [RFC3377] itself).
+ The technical specification was significantly reorganized.
+
+ This document replaces RFC 3377 as well as Section 3.3 of RFC 2251.
+ [Models] replaces portions of RFC 2251, RFC 2252 and RFC 2256.
+ [Protocol] replaces the majority RFC 2251 and portions of RFC 2252.
+ [AuthMeth] replaces RFC 2829, RFC 2830, and portions of RFC 2251.
+ [Syntax] replaces the majority of RFC 2252 and portions of RFC 2256.
+ [Schema] replaces the majority of RFC 2256. [LDAPDN] replaces RFC
+ 2253. [Filters] replaces RFC 2254. [LDAPURL] replaces RFC 2255.
+
+ Each document of this specification contains appendices summarizing
+ changes to all sections of the specifications they replace. Appendix
+ A.1 of this document details changes made to RFC 3377. Appendix A.2
+ of this document details changes made to Section 3.3 of RFC 2251.
+
+
+5. Acknowledgments
+
+ This document is based largely on RFC 3377 by J. Hodges and R.
+ Morgan, a product of the LDAPBIS and LDAPEXT Working Groups. The
+ document also borrows from RFC 2251 by M. Wahl, T. Howes, and S.
+ Kille, a product of the ASID Working Group.
+
+ This document is a product of the IETF LDAPBIS Working Group.
+
+
+6. Author's Address
+
+ Kurt Zeilenga
+ E-mail: <kurt@openldap.org>
+
+
+7. References
+
+
+
+Zeilenga LDAP: TS Road Map [Page 3]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-roadmap-02 1 March 2003
+
+
+7.1. Normative References
+
+ [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+
+ [RFC3383] K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also
+ RFC 3383), September 2002.
+
+ [Models] K. Zeilenga (editor), "LDAP: Directory Information Models",
+ draft-ietf-ldapbis-models-xx.txt, a work in progress.
+
+ [Protocol] J. Sermersheim (editor), "LDAP: The Protocol",
+ draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
+
+ [AuthMeth] R. Harrison (editor), "LDAP: Authentication Methods and
+ Connection Level Security Mechanisms",
+ draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
+
+ [LDAPDN] K. Zeilenga (editor), "LDAP: String Representation of
+ Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work
+ in progress.
+
+ [Filters] M. Smith (editor), LDAPbis WG, "LDAP: String Representation
+ of Search Filters", draft-ietf-ldapbis-filter-xx.txt, a
+ work in progress.
+
+ [LDAPURL] M. Smith (editor), "LDAP: Uniform Resource Locator",
+ draft-ietf-ldapbis-url-xx.txt, a work in progress.
+
+ [Syntaxes] S. Legg (editor), "LDAP: Syntaxes",
+ draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
+
+ [Schema] K. Dally (editor), "LDAP: User Schema",
+ draft-ietf-ldapbis-user-schema-xx.txt, a work in progress.
+
+ [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.
+
+
+7.2. Informative References
+
+ None.
+
+
+
+
+Zeilenga LDAP: TS Road Map [Page 4]
+\f
+INTERNET-DRAFT draft-ietf-ldapbis-roadmap-02 1 March 2003
+
+
+Appendix A. Changes to Previous Documents
+
+ This appendix outlines changes this document makes relative
+ to the documents it replaces (in whole or in part).
+
+
+Appendix A.1. Changes to RFC 3377
+
+ This document is nearly a complete rewrite of RFC 3377 as
+ much of the material of RFC 3377 is no longer applicable.
+ These changes include defining the terms "LDAP" and
+ "LDAPv3" to refer to this revision of the technical
+ specification.
+
+
+Appendix A.2. Changes to Section 3.3 of RFC 2251
+
+ The section was modified slightly (the word "document" was
+ replaced with "technical specification") to clarify that it
+ applies to the entire LDAP technical specification.
+
+
+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: TS Road Map [Page 5]
+\f
--- /dev/null
+
+
+
+
+
+
+Internet-Draft Kurt D. Zeilenga
+Intended Category: Standard Track OpenLDAP Foundation
+Expires in six months 26 May 2003
+
+
+
+ LDAP: Internationalized String Preparation
+ <draft-ietf-ldapbis-strprep-00.txt>
+
+
+Status of this Memo
+
+ This document is an Internet-Draft and is in full conformance with all
+ provisions of Section 10 of RFC2026.
+
+ Distribution of this memo is unlimited. Technical discussion of this
+ document will take place on the IETF LDAP Revision Working Group
+ mailing list <ietf-ldapbis@openldap.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 (C) The Internet Society (2003). All Rights Reserved.
+
+ Please see the Full Copyright section near the end of this document
+ for more information.
+
+
+Abstract
+
+ The previous Lightweight Directory Access Protocol (LDAP) technical
+ specifications did not precisely define how string matching is to be
+ performed. This lead to a number of usability and interoperability
+ problems. This document defines string preparation algorithms for
+ matching rules defined for use in LDAP.
+
+
+
+
+
+Zeilenga LDAPprep [Page 1]
+\f
+Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
+
+
+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].
+
+ 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>.
+ In the lists of mappings and the prohibited characters, the "U+" is
+ left off to make the lists easier to read. The comments for character
+ ranges are shown in square brackets (such as "[CONTROL CHARACTERS]")
+ and do not come from the standard.
+
+ 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].
+
+
+1. Introduction
+
+1.1. Background
+
+ A Lightweight Directory Access Protocol (LDAP) [Roadmap] matching rule
+ [Syntaxes] defines an algorithm for determining whether a presented
+ value matches an attribute value in accordance with the criteria
+ defined for the rule. The proposition may be evaluated to True,
+ False, or Undefined.
+
+ True - the attribute contains a matching value,
+
+ False - the attribute contains no matching value,
+
+ Undefined - it cannot be determined whether the attribute contains
+ a matching value or not.
+
+ For instance, the caseIgnoreMatch matching rule may be used to compare
+ whether the commonName attribute contains a particular value without
+ regard for case and insignificant spaces.
+
+
+1.2. X.500 String Matching Rules
+
+ "X.520: Selected attribute types" [X.520] provides (amongst other
+ things) value syntaxes and matching rules for comparing values
+ commonly used in the Directory. These specifications are inadequate
+ for strings composed of characters from the Universal Character Set
+ (UCS) [ISO10646], a superset of Unicode [Unicode].
+
+
+
+Zeilenga LDAPprep [Page 2]
+\f
+Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
+
+
+ The caseIgnoreMatch matching rule [X.520], for example, is simply
+ defined as being a case insensitive comparison where insignificant
+ spaces are ignored. For printableString, there is only one space
+ character and case mapping is bijective, hence this definition is
+ sufficient. However, for UCS-based string types such as
+ universalString, this is not sufficient. For example, a case
+ insensitive matching implementation which folded lower case characters
+ to upper case would yield different different results than an
+ implementation which used upper case to lower case folding. Or one
+ implementation may view space as referring to only SPACE (U+0020), a
+ second implementation may view any character with the space separator
+ (Zs) property as a space, and another implementation may view any
+ character with the whitespace (WS) category as a space.
+
+ The lack of precise specification for string matching has led to
+ significant interoperability problems. When used in certificate chain
+ validation, security vulnerabilities can arise. To address these
+ problems, this document defines precise algorithms for preparing
+ strings for matching.
+
+
+1.3. Relationship to "stringprep"
+
+ The string preparation algorithms described in this document are based
+ upon the "stringprep" approach [RFC3454]. In "stringprep", presented
+ and stored values are first prepared for comparison and so that a
+ character-by-character comparison yields the "correct" result.
+
+ The approach used here is a refinement of the "stringprep" [RFC3454]
+ approach. Each algorithm involves two additional preparation steps.
+
+ a) prior to applying the Unicode string preparation steps outlined in
+ "stringprep", the string is transcoded to Unicode;
+
+ b) after applying the Unicode string preparation steps outlined in
+ "stringprep", characters insignificant to the matching rules are
+ removed.
+
+ Hence, preparation of strings for X.500 matching involves the
+ following steps:
+
+ 1) Transcode
+ 2) Map
+ 3) Normalize
+ 4) Prohibit
+ 5) Check Bidi (Bidirectional)
+ 6) Insignificant Character Removal
+
+
+
+
+Zeilenga LDAPprep [Page 3]
+\f
+Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
+
+
+ These steps are described in Section 2.
+
+
+1.4. Relationship to the LDAP Technical Specification
+
+ This document is a integral part of the LDAP technical specification
+ [Roadmap] which obsoletes the previously defined LDAP technical
+ specification [RFC3377] in its entirety.
+
+ This document details new LDAP internationalized string preparation
+ algorithms used by [Syntaxes] and possible other technical
+ specifications defining LDAP syntaxes and/or matching rules.
+
+
+1.5. Relationship to X.500
+
+ LDAP is defined [Roadmap] in X.500 terms as an X.500 access mechanism.
+ As such, there is a strong desire for alignment between LDAP and X.500
+ syntax and semantics. The string preparation algorithms described in
+ this document are based upon "Internationalized String Matching Rules
+ for X.500" [XMATCH] proposal to ITU/ISO Joint Study Group 2.
+
+
+2. String Preparation
+
+ The following six-step process SHALL be applied to each presented and
+ attribute value in preparation for string match rule evaluation.
+
+ 1) Transcode
+ 2) Map
+ 3) Normalize
+ 4) Prohibit
+ 5) Check bidi
+ 6) Insignificant Character Removal
+
+ Failure in any step is be cause the assertion to be Undefined.
+
+ The character repertoire of this process is Unicode 3.2 [Unicode].
+
+
+2.1. Transcode
+
+ Each non-Unicode string value is transcoded to Unicode.
+
+ TeletexString [X.680][T.61] values are transcoded to Unicode as
+ described in Appendix A.
+
+ PrintableString [X.680] value are transcoded directly to Unicode.
+
+
+
+Zeilenga LDAPprep [Page 4]
+\f
+Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
+
+
+ UniversalString, UTF8String, and bmpString [X.680] values need not be
+ transcoded as they are Unicode-based strings (in the case of
+ bmpString, a subset of Unicode).
+
+ If the implementation is unable or unwilling to perform the
+ transcoding as described above, or the transcoding fails, this step
+ fails and the assertion is evaluated to Undefined.
+
+ The transcoded string is the output string.
+
+
+2.2. Map
+
+ SOFT HYPHEN (U+00AD) and MONGOLIAN TODO SOFT HYPHEN (U+1806) code
+ points are mapped to nothing. COMBINING GRAPHEME JOINER (U+034F) and
+ VARIATION SELECTORs (U+180B-180D,FF00-FE0F) code points are also
+ mapped to nothing. The OBJECT REPLACEMENT CHARACTER (U+FFFC) is
+ mapped to nothing.
+
+ CHARACTER TABULATION (U+0009), LINE FEED (LF) (U+000A), LINE
+ TABULATION (U+000B), FORM FEED (FF) (U+000C), CARRIAGE RETURN (CR)
+ (U+000D), and NEXT LINE (NEL) (U+0085) are mapped to SPACE (U+0020).
+
+ All other control code points (e.g., Cc) or code points with a control
+ function (e.g., Cf) are mapped to nothing.
+
+ ZERO WIDTH SPACE (U+200B) is mapped to nothing. All other code points
+ with Separator (space, line, or paragraph) property (e.g, Zs, Zl, or
+ Zp) are mapped to SPACE (U+0020).
+
+ For case ignore, numeric, and stored prefix string matching rules,
+ characters are case folded per B.2 of [RFC3454].
+
+
+2.3. Normalize
+
+ The input string is be normalized to Unicode Form KC (compatibility
+ composed) as described in [UAX15].
+
+
+2.4. Prohibit
+
+ All Unassigned, Private Use, and non-character code points are
+ prohibited. Surrogate codes (U+D800-DFFFF) are prohibited.
+
+ The REPLACEMENT CHARACTER (U+FFFD) code point is prohibited.
+
+ The first code point of a string is prohibited from being a combining
+
+
+
+Zeilenga LDAPprep [Page 5]
+\f
+Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
+
+
+ character.
+
+ Empty strings are prohibited.
+
+ The step fails and the assertion is evaluated to Undefined if the
+ input string contains any prohibited code point. The output string is
+ the input string.
+
+
+2.5. Check bidi
+
+ There are no bidirectional restrictions. The output string is the
+ input string.
+
+
+2.5. Insignificant Character Removal
+
+ In this step, characters insignificant to the matching rule are to be
+ removed. The characters to be removed differ from matching rule to
+ matching rule.
+
+ Section 2.6.1 applies to case ignore and exact string matching.
+ Section 2.6.2 applies to numericString matching.
+ Section 2.6.3 applies to telephoneNumber matching
+
+
+2.6.1. Insignificant Space Removal
+
+ For the purposes of this section, a space is defined to be the SPACE
+ (U+0020) code point followed by no combining marks.
+
+ NOTE - The previous steps ensure that the string cannot contain any
+ code points in the separator class, other than SPACE (U+0020).
+
+ The following spaces are regarded as not significant and are to be
+ removed:
+ - leading spaces (i.e. those preceding the first character that is
+ not a space);
+ - trailing spaces (i.e. those following the last character that is
+ not a space);
+ - multiple consecutive spaces (these are taken as equivalent to a
+ single space character).
+
+ A string consisting entirely of spaces is equivalent to a string
+ containing exactly one space.
+
+ For example, removal of spaces from the Form KC string:
+ "<SPACE><SPACE>foo<SPACE><SPACE>bar<SPACE><SPACE>"
+
+
+
+Zeilenga LDAPprep [Page 6]
+\f
+Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
+
+
+ would result in the output string:
+ "foo<SPACE>bar"
+ and the Form KC string:
+ "<SPACE><SPACE><SPACE>"
+ would result in the output string:
+ "<SPACE>".
+
+
+2.6.2. numericString Insignificant Character Removal
+
+ For the purposes of this section, a space is defined to be the SPACE
+ (U+0020) code point followed by no combining marks.
+
+ All spaces are regarded as not significant and are to be removed.
+
+ For example, removal of spaces from the Form KC string:
+ "<SPACE><SPACE>123<SPACE><SPACE>456<SPACE><SPACE>" would result in
+ the output string:
+ "123456"
+ and the Form KC string:
+ "<SPACE><SPACE><SPACE>"
+ would result in an empty output string.
+
+
+2.6.3. telephoneNumber Insignificant Character Removal
+
+ For the purposes of this section, a hyphen is defined to be
+ HYPHEN-MINUS (U+002D), ARMENIAN HYPHEN (U+058A), HYPHEN (U+2010),
+ NON-BREAKING HYPHEN (U+2011), MINUS SIGN (U+2212), SMALL HYPHEN-MINUS
+ (U+FE63), or FULLWIDTH HYPHEN-MINUS (U+FF0D) code point followed by no
+ combining marks and a space is defined to be the SPACE (U+0020) code
+ point followed by no combining marks.
+
+ All hyphens and spaces are regarded as not significant and are to be
+ removed.
+
+
+3. Security Considerations
+
+ "Preparation for International Strings ('stringprep')" [RFC3454]
+ security considerations generally apply to the algorithms described
+ here.
+
+
+4. Contributors
+
+ Appendix A and B of this document were authored by Howard Chu
+ <hyc@symas.com> of Symas Corporation (based upon information provided
+
+
+
+Zeilenga LDAPprep [Page 7]
+\f
+Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
+
+
+ in RFC 1345).
+
+
+5. Acknowledgments
+
+ The approach used in this document is based upon design principles and
+ algorithms described in "Preparation of Internationalized Strings
+ ('stringprep')" [RFC3454] by Paul Hoffman and Marc Blanchet. Some
+ additional guidance was drawn from Unicode Technical Standards,
+ Technical Reports, and Notes.
+
+
+6. Author's Address
+
+ Kurt Zeilenga
+ E-mail: <kurt@openldap.org>
+
+
+7. References
+
+7.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+
+ [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
+ Internationalized Strings ('stringprep')", RFC 3454,
+ December 2002.
+
+ [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
+ Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
+ progress.
+
+ [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
+ draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
+
+ [ISO10646] International Organization for Standardization,
+ "Universal Multiple-Octet Coded Character Set (UCS) -
+ Architecture and Basic Multilingual Plane", ISO/IEC
+ 10646-1 : 1993.
+
+ [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/).
+
+
+
+Zeilenga LDAPprep [Page 8]
+\f
+Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
+
+
+ [UAX15] Davis, M. and M. Duerst, "Unicode Standard Annex #15:
+ Unicode Normalization Forms, Version 3.2.0".
+ <http://www.unicode.org/unicode/reports/tr15/tr15-22.html>,
+ March 2002.
+
+ [X.680] International Telecommunication Union -
+ Telecommunication Standardization Sector, "Abstract
+ Syntax Notation One (ASN.1) - Specification of Basic
+ Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
+
+ [T.61] CCITT (now ITU), "Character Repertoire and Coded
+ Character Sets for the International Teletex Service",
+ T.61, 1988.
+
+7.2. Informative References
+
+ [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).
+
+ [X.501] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The Directory
+ -- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
+
+ [X.520] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory: Selected Attribute Types", X.520(1993) (also
+ ISO/IEC 9594-6:1994).
+
+ [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.
+
+ [XMATCH] Zeilenga, K., "Internationalized String Matching Rules
+ for X.500", draft-zeilenga-ldapbis-strmatch-xx.txt a
+ work in progress.
+
+ [RFC1345] Simonsen, K., "Character Mnemonics & Character Sets",
+ RFC 1345, June 1992.
+
+
+Appendix A. Teletex (T.61) to Unicode
+
+
+
+
+Zeilenga LDAPprep [Page 9]
+\f
+Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
+
+
+ This appendix defines an algorithm for transcoding [T.61] characters
+ to [Unicode] characters for use in string preparation for LDAP
+ matching rules. This appendix is a normative.
+
+ The transcoding algorithm is derived from the T.61-8bit definition
+ provided in [RFC1345]. With a few exceptions, the T.61 character
+ codes from x00 to x7f are equivalent to the corresponding [Unicode]
+ code points, and their values are left unchanged by this algorithm.
+ E.g. the T.61 code x20 is identical to (U+0020). The exceptions are
+ for these T.61 codes that are undefined: x23, x24, x5c, x5e, x60, x7b,
+ x7d, and x7e.
+
+ The codes from x80 to x9f are also equivalent to the corresponding
+ Unicode code points. This is specified for completeness only, as
+ these codes are control characters, and will be mapped to nothing in
+ the LDAP String Preparation Mapping step.
+
+ The remaining T.61 codes are mapped below in Table A.1. Table
+ positions marked "??" are undefined.
+
+ Input strings containing undefined T.61 codes SHALL produce an
+ Undefined matching result. For diagnostic purposes, this algorithm
+ does not fail for undefined input codes. Instead, undefined codes in
+ the input are mapped to the Unicode REPLACEMENT CHARACTER (U+FFFD).
+ As the LDAP String Preparation Probhibit step disallows the
+ REPLACEMENT CHARACTER from appearing in its output, this transcoding
+ yields the desired effect.
+
+ Note: RFC 1345 listed the non-spacing accent codepoints as residing in
+ the range starting at (U+E000). In the current Unicode
+ standard, the (U+E000) range is reserved for Private Use, and
+ the non-spacing accents are in the range starting at (U+0300).
+ The tables here use the (U+0300) range for these accents.
+
+ | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
+ --+------+------+------+------+------+------+------+------+
+ a0| 00a0 | 00a1 | 00a2 | 00a3 | 0024 | 00a5 | 0023 | 00a7 |
+ a8| 00a8 | ?? | ?? | 00ab | ?? | ?? | ?? | ?? |
+ b0| 00b0 | 00b1 | 00b2 | 00b3 | 00d7 | 00b5 | 00b6 | 00b7 |
+ b8| 00f7 | ?? | ?? | 00bb | 00bc | 00bd | 00be | 00bf |
+ c0| ?? | 0300 | 0301 | 0302 | 0303 | 0304 | 0306 | 0307 |
+ c8| 0308 | ?? | 030a | 0327 | 0332 | 030b | 0328 | 030c |
+ d0| ?? | ?? | ?? | ?? | ?? | ?? | ?? | ?? |
+ d8| ?? | ?? | ?? | ?? | ?? | ?? | ?? | ?? |
+ e0| 2126 | 00c6 | 00d0 | 00aa | ?? | 0126 | 0132 | 013f |
+ e8| 0141 | 00d8 | 0152 | 00ba | 00de | 0166 | 014a | 0149 |
+ f0| 0138 | 00e6 | 0111 | 00f0 | 0127 | 0131 | 0133 | 0140 |
+ f8| 0142 | 00f8 | 0153 | 00df | 00fe | 0167 | 014b | ?? |
+
+
+
+Zeilenga LDAPprep [Page 10]
+\f
+Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
+
+
+ --+------+------+------+------+------+------+------+------+
+ Table A.1: Mapping of 8-bit T.61 codes to Unicode
+
+ T.61 also defines a number of accented characters that are formed by
+ combining an accent prefix followed by a base character. These
+ prefixes are in the code range xc1 to xcf. If a prefix character
+ appears at the end of a string, the result is undefined. Otherwise
+ these sequences are mapped to Unicode by substituting the
+ corresponding non-spacing accent code (as listed in Table A.1) for the
+ accent prefix, and exchanging the order so that the base character
+ precedes the accent.
+
+
+Appendix B. Additional Teletex (T.61) to Unicode Tables
+
+ All of the accented characters in T.61 have a corresponding code point
+ in Unicode. For the sake of completeness, the combined character
+ codes are presented in the following tables. This is informational
+ only; for matching purposes it is sufficient to map the non-spacing
+ accent and exchange the order of the character pair as specified in
+ Appendix A.
+
+
+B.1. Combinations with SPACE
+
+ Accents may be combined with a <SPACE> to generate the accent by
+ itself. For each accent code, the result of combining with <SPACE> is
+ listed in Table B.1.
+
+ | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
+ --+------+------+------+------+------+------+------+------+
+ c0| ?? | 0060 | 00b4 | 005e | 007e | 00af | 02d8 | 02d9 |
+ c8| 00a8 | ?? | 02da | 00b8 | ?? | 02dd | 02db | 02c7 |
+ --+------+------+------+------+------+------+------+------+
+ Table B.1: Mapping of T.61 Accents with <SPACE> to Unicode
+
+
+B.2. Combinations for xc1: (Grave accent)
+
+ T.61 has predefined characters for combinations with A, E, I, O, and
+ U. Unicode also defines combinations for N, W, and Y. All of these
+ combinations are present in Table B.2.
+
+ | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
+ --+------+------+------+------+------+------+------+------+
+ 40| ?? | 00c0 | ?? | ?? | ?? | 00c8 | ?? | ?? |
+ 48| ?? | 00cc | ?? | ?? | ?? | ?? | 01f8 | 00d2 |
+ 50| ?? | ?? | ?? | ?? | ?? | 00d9 | ?? | 1e80 |
+
+
+
+Zeilenga LDAPprep [Page 11]
+\f
+Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
+
+
+ 58| ?? | 1ef2 | ?? | ?? | ?? | ?? | ?? | ?? |
+ 60| ?? | 00e0 | ?? | ?? | ?? | 00e8 | ?? | ?? |
+ 68| ?? | 00ec | ?? | ?? | ?? | ?? | 01f9 | 00f2 |
+ 70| ?? | ?? | ?? | ?? | ?? | 00f9 | ?? | 1e81 |
+ 78| ?? | 1ef3 | ?? | ?? | ?? | ?? | ?? | ?? |
+ --+------+------+------+------+------+------+------+------+
+ Table B.2: Mapping of T.61 Grave Accent Combinations
+
+
+B.3. Combinations for xc2: (Acute accent)
+
+ T.61 has predefined characters for combinations with A, E, I, O, U, Y,
+ C, L, N, R, S, and Z. Unicode also defines G, K, M, P, and W. All of
+ these combinations are present in Table B.3.
+
+ | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
+ --+------+------+------+------+------+------+------+------+
+ 40| ?? | 00c1 | ?? | 0106 | ?? | 00c9 | ?? | 01f4 |
+ 48| ?? | 00cd | ?? | 1e30 | 0139 | 1e3e | 0143 | 00d3 |
+ 50| 1e54 | ?? | 0154 | 015a | ?? | 00da | ?? | 1e82 |
+ 58| ?? | 00dd | 0179 | ?? | ?? | ?? | ?? | ?? |
+ 60| ?? | 00e1 | ?? | 0107 | ?? | 00e9 | ?? | 01f5 |
+ 68| ?? | 00ed | ?? | 1e31 | 013a | 1e3f | 0144 | 00f3 |
+ 70| 1e55 | ?? | 0155 | 015b | ?? | 00fa | ?? | 1e83 |
+ 78| ?? | 00fd | 017a | ?? | ?? | ?? | ?? | ?? |
+ --+------+------+------+------+------+------+------+------+
+ Table B.3: Mapping of T.61 Acute Accent Combinations
+
+
+B.4. Combinations for xc3: (Circumflex)
+
+ T.61 has predefined characters for combinations with A, E, I, O, U, Y,
+ C, G, H, J, S, and W. Unicode also defines the combination for Z.
+ All of these combinations are present in Table B.4.
+
+ | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
+ --+------+------+------+------+------+------+------+------+
+ 40| ?? | 00c2 | ?? | 0108 | ?? | 00ca | ?? | 011c |
+ 48| 0124 | 00ce | 0134 | ?? | ?? | ?? | ?? | 00d4 |
+ 50| ?? | ?? | ?? | 015c | ?? | 00db | ?? | 0174 |
+ 58| ?? | 0176 | 1e90 | ?? | ?? | ?? | ?? | ?? |
+ 60| ?? | 00e2 | ?? | 0109 | ?? | 00ea | ?? | 011d |
+ 68| 0125 | 00ee | 0135 | ?? | ?? | ?? | ?? | 00f4 |
+ 70| ?? | ?? | ?? | 015d | ?? | 00fb | ?? | 0175 |
+ 78| ?? | 0177 | 1e91 | ?? | ?? | ?? | ?? | ?? |
+ --+------+------+------+------+------+------+------+------+
+ Table B.4: Mapping of T.61 Circumflex Accent Combinations
+
+
+
+
+Zeilenga LDAPprep [Page 12]
+\f
+Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
+
+
+B.5. Combinations for xc4: (Tilde)
+
+ T.61 has predefined characters for combinations with A, I, O, U, and
+ N. Unicode also defines E, V, and Y. All of these combinations are
+ present in Table B.5.
+
+ | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
+ --+------+------+------+------+------+------+------+------+
+ 40| ?? | 00c3 | ?? | ?? | ?? | 1ebc | ?? | ?? |
+ 48| ?? | 0128 | ?? | ?? | ?? | ?? | 00d1 | 00d5 |
+ 50| ?? | ?? | ?? | ?? | ?? | 0168 | 1e7c | ?? |
+ 58| ?? | 1ef8 | ?? | ?? | ?? | ?? | ?? | ?? |
+ 60| ?? | 00e3 | ?? | ?? | ?? | 1ebd | ?? | ?? |
+ 68| ?? | 0129 | ?? | ?? | ?? | ?? | 00f1 | 00f5 |
+ 70| ?? | ?? | ?? | ?? | ?? | 0169 | 1e7d | ?? |
+ 78| ?? | 1ef9 | ?? | ?? | ?? | ?? | ?? | ?? |
+ --+------+------+------+------+------+------+------+------+
+ Table B.5: Mapping of T.61 Tilde Accent Combinations
+
+
+B.6. Combinations for xc5: (Macron)
+
+ T.61 has predefined characters for combinations with A, E, I, O, and
+ U. Unicode also defines Y, G, and AE. All of these combinations are
+ present in Table B.6.
+
+ | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
+ --+------+------+------+------+------+------+------+------+
+ 40| ?? | 0100 | ?? | ?? | ?? | 0112 | ?? | 1e20 |
+ 48| ?? | 012a | ?? | ?? | ?? | ?? | ?? | 014c |
+ 50| ?? | ?? | ?? | ?? | ?? | 016a | ?? | ?? |
+ 58| ?? | 0232 | ?? | ?? | ?? | ?? | ?? | ?? |
+ 60| ?? | 0101 | ?? | ?? | ?? | 0113 | ?? | 1e21 |
+ 68| ?? | 012b | ?? | ?? | ?? | ?? | ?? | 014d |
+ 70| ?? | ?? | ?? | ?? | ?? | 016b | ?? | ?? |
+ 78| ?? | 0233 | ?? | ?? | ?? | ?? | ?? | ?? |
+ e0| ?? | 01e2 | ?? | ?? | ?? | ?? | ?? | ?? |
+ f0| ?? | 01e3 | ?? | ?? | ?? | ?? | ?? | ?? |
+ --+------+------+------+------+------+------+------+------+
+ Table B.6: Mapping of T.61 Macron Accent Combinations
+
+
+B.7. Combinations for xc6: (Breve)
+
+ T.61 has predefined characters for combinations with A, U, and G.
+ Unicode also defines E, I, and O. All of these combinations are
+ present in Table B.7.
+
+
+
+
+Zeilenga LDAPprep [Page 13]
+\f
+Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
+
+
+ | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
+ --+------+------+------+------+------+------+------+------+
+ 40| ?? | 0102 | ?? | ?? | ?? | 0114 | ?? | 011e |
+ 48| ?? | 012c | ?? | ?? | ?? | ?? | ?? | 014e |
+ 50| ?? | ?? | ?? | ?? | ?? | 016c | ?? | ?? |
+ 58| ?? | ?? | ?? | ?? | ?? | ?? | ?? | ?? |
+ 60| ?? | 0103 | ?? | ?? | ?? | 0115 | ?? | 011f |
+ 68| ?? | 012d | ?? | ?? | ?? | ?? | 00f1 | 014f |
+ 70| ?? | ?? | ?? | ?? | ?? | 016d | ?? | ?? |
+ 78| ?? | ?? | ?? | ?? | ?? | ?? | ?? | ?? |
+ --+------+------+------+------+------+------+------+------+
+ Table B.7: Mapping of T.61 Breve Accent Combinations
+
+
+B.8. Combinations for xc7: (Dot Above)
+
+ T.61 has predefined characters for C, E, G, I, and Z. Unicode also
+ defines A, O, B, D, F, H, M, N, P, R, S, T, W, X, and Y. All of these
+ combinations are present in Table B.8.
+
+ | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
+ --+------+------+------+------+------+------+------+------+
+ 40| ?? | 0226 | 1e02 | 010a | 1e0a | 0116 | 1e1e | 0120 |
+ 48| 1e22 | 0130 | ?? | ?? | ?? | 1e40 | 1e44 | 022e |
+ 50| 1e56 | ?? | 1e58 | 1e60 | 1e6a | ?? | ?? | 1e86 |
+ 58| 1e8a | 1e8e | 017b | ?? | ?? | ?? | ?? | ?? |
+ 60| ?? | 0227 | 1e03 | 010b | 1e0b | 0117 | 1e1f | 0121 |
+ 68| 1e23 | ?? | ?? | ?? | ?? | 1e41 | 1e45 | 022f |
+ 70| 1e57 | ?? | 1e59 | 1e61 | 1e6b | ?? | ?? | 1e87 |
+ 78| 1e8b | 1e8f | 017c | ?? | ?? | ?? | ?? | ?? |
+ --+------+------+------+------+------+------+------+------+
+ Table B.8: Mapping of T.61 Dot Above Accent Combinations
+
+
+B.9. Combinations for xc8: (Diaeresis)
+
+ T.61 has predefined characters for A, E, I, O, U, and Y. Unicode also
+ defines H, W, X, and t. All of these combinations are present in
+ Table B.9.
+
+ | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
+ --+------+------+------+------+------+------+------+------+
+ 40| ?? | 00c4 | ?? | ?? | ?? | 00cb | ?? | ?? |
+ 48| 1e26 | 00cf | ?? | ?? | ?? | ?? | ?? | 00d6 |
+ 50| ?? | ?? | ?? | ?? | ?? | 00dc | ?? | 1e84 |
+ 58| 1e8c | 0178 | ?? | ?? | ?? | ?? | ?? | ?? |
+ 60| ?? | 00e4 | ?? | ?? | ?? | 00eb | ?? | ?? |
+ 68| 1e27 | 00ef | ?? | ?? | ?? | ?? | ?? | 00f6 |
+
+
+
+Zeilenga LDAPprep [Page 14]
+\f
+Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
+
+
+ 70| ?? | ?? | ?? | ?? | 1e97 | 00fc | ?? | 1e85 |
+ 78| 1e8d | 00ff | ?? | ?? | ?? | ?? | ?? | ?? |
+ --+------+------+------+------+------+------+------+------+
+ Table B.8: Mapping of T.61 Diaeresis Accent Combinations
+
+
+B.10. Combinations for xca: (Ring Above)
+
+ T.61 has predefined characters for A, and U. Unicode also defines w
+ and y. All of these combinations are present in Table B.10.
+
+ | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
+ --+------+------+------+------+------+------+------+------+
+ 40| ?? | 00c5 | ?? | ?? | ?? | ?? | ?? | ?? |
+ 48| ?? | ?? | ?? | ?? | ?? | ?? | ?? | ?? |
+ 50| ?? | ?? | ?? | ?? | ?? | 016e | ?? | ?? |
+ 58| ?? | ?? | ?? | ?? | ?? | ?? | ?? | ?? |
+ 60| ?? | 00e5 | ?? | ?? | ?? | ?? | ?? | ?? |
+ 68| ?? | ?? | ?? | ?? | ?? | ?? | ?? | ?? |
+ 70| ?? | ?? | ?? | ?? | ?? | 016f | ?? | 1e98 |
+ 78| ?? | 1e99 | ?? | ?? | ?? | ?? | ?? | ?? |
+ --+------+------+------+------+------+------+------+------+
+ Table B.10: Mapping of T.61 Ring Above Accent Combinations
+
+
+B.11. Combinations for xcb: (Cedilla)
+
+ T.61 has predefined characters for C, G, K, L, N, R, S, and T.
+ Unicode also defines E, D, and H. All of these combinations are
+ present in Table B.11.
+
+ | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
+ --+------+------+------+------+------+------+------+------+
+ 40| ?? | ?? | ?? | 00c7 | 1e10 | 0228 | ?? | 0122 |
+ 48| 1e28 | ?? | ?? | 0136 | 013b | ?? | 0145 | ?? |
+ 50| ?? | ?? | 0156 | 015e | 0162 | ?? | ?? | ?? |
+ 58| ?? | ?? | ?? | ?? | ?? | ?? | ?? | ?? |
+ 60| ?? | ?? | ?? | 00e7 | 1e11 | 0229 | ?? | 0123 |
+ 68| 1e29 | ?? | ?? | 0137 | 013c | ?? | 0146 | ?? |
+ 70| ?? | ?? | 0157 | 015f | 0163 | ?? | ?? | ?? |
+ 78| ?? | ?? | ?? | ?? | ?? | ?? | ?? | ?? |
+ --+------+------+------+------+------+------+------+------+
+ Table B.11: Mapping of T.61 Cedilla Accent Combinations
+
+
+B.12. Combinations for xcd: (Double Acute Accent)
+
+ T.61 has predefined characters for O, and U. These combinations are
+
+
+
+Zeilenga LDAPprep [Page 15]
+\f
+Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
+
+
+ present in Table B.12.
+
+ | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
+ --+------+------+------+------+------+------+------+------+
+ 48| ?? | ?? | ?? | ?? | ?? | ?? | ?? | 0150 |
+ 50| ?? | ?? | ?? | ?? | ?? | 0170 | ?? | ?? |
+ 68| ?? | ?? | ?? | ?? | ?? | ?? | ?? | 0151 |
+ 70| ?? | ?? | ?? | ?? | ?? | 0171 | ?? | ?? |
+ --+------+------+------+------+------+------+------+------+
+ Table B.12: Mapping of T.61 Double Acute Accent Combinations
+
+
+B.13. Combinations for xce: (Ogonek)
+
+ T.61 has predefined characters for A, E, I, and U. Unicode also
+ defines the combination for O. All of these combinations are present
+ in Table B.13.
+
+ | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
+ --+------+------+------+------+------+------+------+------+
+ 40| ?? | 0104 | ?? | ?? | ?? | 0118 | ?? | ?? |
+ 48| ?? | 012e | ?? | ?? | ?? | ?? | ?? | 01ea |
+ 50| ?? | ?? | ?? | ?? | ?? | 0172 | ?? | ?? |
+ 58| ?? | ?? | ?? | ?? | ?? | ?? | ?? | ?? |
+ 60| ?? | 0105 | ?? | ?? | ?? | 0119 | ?? | ?? |
+ 68| ?? | 012f | ?? | ?? | ?? | ?? | ?? | 01eb |
+ 70| ?? | ?? | ?? | ?? | ?? | 0173 | ?? | ?? |
+ 78| ?? | ?? | ?? | ?? | ?? | ?? | ?? | ?? |
+ --+------+------+------+------+------+------+------+------+
+ Table B.13: Mapping of T.61 Ogonek Accent Combinations
+
+
+B.14. Combinations for xcf: (Caron)
+
+ T.61 has predefined characters for C, D, E, L, N, R, S, T, and Z.
+ Unicode also defines A, I, O, U, G, H, j,and K. All of these
+ combinations are present in Table B.14.
+
+ | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
+ --+------+------+------+------+------+------+------+------+
+ 40| ?? | 01cd | ?? | 010c | 010e | 011a | ?? | 01e6 |
+ 48| 021e | 01cf | ?? | 01e8 | 013d | ?? | 0147 | 01d1 |
+ 50| ?? | ?? | 0158 | 0160 | 0164 | 01d3 | ?? | ?? |
+ 58| ?? | ?? | 017d | ?? | ?? | ?? | ?? | ?? |
+ 60| ?? | 01ce | ?? | 010d | 010f | 011b | ?? | 01e7 |
+ 68| 021f | 01d0 | 01f0 | 01e9 | 013e | ?? | 0148 | 01d2 |
+ 70| ?? | ?? | 0159 | 0161 | 0165 | 01d4 | ?? | ?? |
+ 78| ?? | ?? | 017e | ?? | ?? | ?? | ?? | ?? |
+
+
+
+Zeilenga LDAPprep [Page 16]
+\f
+Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
+
+
+ --+------+------+------+------+------+------+------+------+
+ Table B.14: Mapping of T.61 Caron Accent Combinations
+
+
+
+
+Intellectual Property Rights
+
+ The IETF takes no position regarding the validity or scope of any
+ intellectual property 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; neither does it represent that it has made any
+ effort to identify any such rights. Information on the IETF's
+ procedures with respect to rights in standards-track and
+ standards-related documentation can be found in BCP-11. Copies of
+ claims of rights made available for publication 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 implementors or users of this specification can be obtained
+ from the IETF Secretariat.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights which may cover technology that may be required to practice
+ this standard. Please address the information to the IETF Executive
+ Director.
+
+
+
+Full Copyright
+
+ Copyright (C) The Internet Society (2003). 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 implmentation 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.
+
+
+
+
+
+Zeilenga LDAPprep [Page 17]
+\f
--- /dev/null
+
+
+
+
+
+
+INTERNET-DRAFT S. Legg, Editor
+draft-ietf-ldapbis-syntaxes-05.txt Adacel Technologies
+Intended Category: Standard Track K. Dally
+Obsoletes: RFC 2252, RFC 2256 The MITRE Corp.
+ 27 February 2003
+
+
+ LDAP: Syntaxes and Matching Rules
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+ Status of this Memo
+
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC2026.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as
+ Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress".
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This document is intended to be, after appropriate review and
+ revision, submitted to the RFC Editor as a Standard Track document.
+ Distribution of this document is unlimited. Technical discussion of
+ this document should take place on the IETF LDAP Revision Working
+ Group (LDAPbis) mailing list <ietf-ldapbis@openldap.org>. Please
+ send editorial comments directly to the editor
+ <steven.legg@adacel.com.au>.
+
+ This Internet-Draft expires on 27 August 2003.
+
+
+Abstract
+
+ Each attribute stored in a Lightweight Directory Access Protocol
+ (LDAP) directory, and whose values may be transfered in the LDAP
+
+
+
+Legg & Dally Expires 27 August 2003 [Page 1]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+
+
+ protocol, has a defined syntax which constrains the structure and
+ format of its values. The comparison semantics for values of a
+ syntax are not part of the syntax definition but are instead provided
+ through separately defined matching rules. Matching rules specify an
+ argument, an assertion value, which also has a defined syntax. This
+ document defines a base set of syntaxes and matching rules for use in
+ defining attributes for LDAP directories.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Legg & Dally Expires 27 August 2003 [Page 2]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+
+
+1. Table of Contents
+
+ 1. Table of Contents ............................................. 3
+ 2. Introduction .................................................. 4
+ 3. Conventions ................................................... 5
+ 4. Syntaxes ...................................................... 5
+ 4.1 General Considerations .................................... 5
+ 4.2 Common Definitions ........................................ 6
+ 4.3 Syntax Definitions ........................................ 7
+ 4.3.1 Attribute Type Description ........................... 7
+ 4.3.2 Bit String ........................................... 7
+ 4.3.3 Boolean .............................................. 8
+ 4.3.4 Country String ....................................... 8
+ 4.3.5 Delivery Method ...................................... 9
+ 4.3.6 Directory String ..................................... 9
+ 4.3.7 DIT Content Rule Description ......................... 10
+ 4.3.8 DIT Structure Rule Description ....................... 11
+ 4.3.9 DN ................................................... 11
+ 4.3.10 Enhanced Guide ...................................... 12
+ 4.3.11 Facsimile Telephone Number .......................... 13
+ 4.3.12 Fax ................................................. 13
+ 4.3.13 Generalized Time .................................... 14
+ 4.3.14 Guide ............................................... 15
+ 4.3.15 IA5 String .......................................... 15
+ 4.3.16 Integer ............................................. 16
+ 4.3.17 JPEG ................................................ 16
+ 4.3.18 LDAP Syntax Description ............................. 16
+ 4.3.19 Matching Rule Description ........................... 17
+ 4.3.20 Matching Rule Use Description ....................... 17
+ 4.3.21 Name and Optional UID ............................... 18
+ 4.3.22 Name Form Description ............................... 18
+ 4.3.23 Numeric String ...................................... 19
+ 4.3.24 Object Class Description ............................ 19
+ 4.3.25 Octet String ........................................ 20
+ 4.3.26 OID ................................................. 20
+ 4.3.27 Other Mailbox ....................................... 21
+ 4.3.28 Postal Address ...................................... 21
+ 4.3.29 Printable String .................................... 22
+ 4.3.30 Substring Assertion ................................. 23
+ 4.3.31 Telephone Number .................................... 23
+ 4.3.32 Teletex Terminal Identifier ......................... 24
+ 4.3.33 Telex Number ........................................ 25
+ 4.3.34 UTC Time ............................................ 25
+ 5. Matching Rules ................................................ 26
+ 5.1 General Considerations .................................... 26
+ 5.2 Matching Rule Definitions ................................. 28
+ 5.2.1 bitStringMatch ....................................... 28
+ 5.2.2 caseExactIA5Match .................................... 28
+
+
+
+Legg & Dally Expires 27 August 2003 [Page 3]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+
+
+ 5.2.3 caseIgnoreIA5Match ................................... 29
+ 5.2.4 caseIgnoreIA5SubstringsMatch ......................... 29
+ 5.2.5 caseIgnoreListMatch .................................. 29
+ 5.2.6 caseIgnoreListSubstringsMatch ........................ 30
+ 5.2.7 caseIgnoreMatch ...................................... 31
+ 5.2.8 caseIgnoreOrderingMatch .............................. 31
+ 5.2.9 caseIgnoreSubstringsMatch ............................ 32
+ 5.2.10 distinguishedNameMatch .............................. 32
+ 5.2.11 generalizedTimeMatch ................................ 33
+ 5.2.12 generalizedTimeOrderingMatch ........................ 33
+ 5.2.13 integerFirstComponentMatch .......................... 34
+ 5.2.14 integerMatch ........................................ 34
+ 5.2.15 numericStringMatch .................................. 34
+ 5.2.16 numericStringSubstringsMatch ........................ 35
+ 5.2.17 objectIdentifierFirstComponentMatch ................. 35
+ 5.2.18 objectIdentifierMatch ............................... 36
+ 5.2.19 octetStringMatch .................................... 36
+ 5.2.20 telephoneNumberMatch ................................ 37
+ 5.2.21 telephoneNumberSubstringsMatch ...................... 37
+ 5.2.22 uniqueMemberMatch ................................... 38
+ 6. Security Considerations ....................................... 38
+ 7. Acknowledgements .............................................. 39
+ 8. IANA Considerations ........................................... 39
+ 9. Normative References .......................................... 40
+ 10. Informative References ....................................... 42
+ 11. Authors' Addresses ........................................... 42
+ 12. Copyright Notice ............................................. 43
+ Appendix A. Summary of Syntax Object Identifiers ................. 43
+ Appendix B. Changes from RFC 2252 & RFC 2256 ..................... 44
+
+
+2. Introduction
+
+ Each attribute stored in a Lightweight Directory Access Protocol
+ (LDAP) directory [ROADMAP], and whose values may be transfered in the
+ LDAP protocol [PROT], has a defined syntax (i.e. data type) which
+ constrains the structure and format of its values. The comparison
+ semantics for values of a syntax are not part of the syntax
+ definition but are instead provided through separately defined
+ matching rules. Matching rules specify an argument, an assertion
+ value, which also has a defined syntax. This document defines a base
+ set of syntaxes and matching rules for use in defining attributes for
+ LDAP directories.
+
+ Readers are advised to familiarize themselves with the Directory
+ Information Models [MODELS] before reading the rest of this document.
+ Section 4 provides definitions for the base set of LDAP syntaxes.
+ Section 5 provides definitions for the base set of matching rules for
+
+
+
+Legg & Dally Expires 27 August 2003 [Page 4]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+
+
+ LDAP.
+
+ This document is a integral part of the LDAP technical specification
+ [ROADMAP] which obsoletes the previously defined LDAP technical
+ specification [RFC3377] in its entirety.
+
+ Sections 4, 5 and 7 of RFC 2252 [RFC2252] are obsoleted by [MODELS].
+ The remainder of RFC 2252 is obsoleted by this document. Sections 6
+ and 8 of RFC 2256 are obsoleted by this document. The changes from
+ RFC 2252 and RFC 2256 [RFC2256] are described in Appendix B of this
+ document.
+
+
+3. 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 RFC 2119 [KEYWORD].
+
+ Syntax definitions are written according to the <SyntaxDescription>
+ ABNF [ABNF] rule specified in [MODELS], and matching rule definitions
+ are written according to the <MatchingRuleDescription> ABNF rule
+ specified in [MODELS], except that the syntax and matching rule
+ definitions provided in this document are line-wrapped for
+ readability. When such definitions are transfered as attribute
+ values in the LDAP protocol (e.g. as values of the ldapSyntaxes and
+ matchingRules attributes [MODELS] respectively) then those values
+ would not contain line breaks.
+
+
+4. Syntaxes
+
+ Syntax definitions constrain the structure of attribute values stored
+ in an LDAP directory, and determine the representation of attribute
+ and assertion values transfered in the LDAP protocol.
+
+ Syntaxes that are required for directory operation, or that are in
+ common use, are specified in this section. Servers SHOULD recognize
+ all the syntaxes listed in this document, but are NOT REQUIRED to
+ otherwise support them, and MAY recognise or support other syntaxes.
+ However, the definition of additional arbitrary syntaxes is
+ discouraged since it will hinder interoperability. Client and server
+ implementations typically do not have the ability to dynamically
+ recognize new syntaxes.
+
+
+4.1 General Considerations
+
+
+
+
+Legg & Dally Expires 27 August 2003 [Page 5]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+
+
+ The description of each syntax specifies how attribute or assertion
+ values conforming to the syntax are to be represented when transfered
+ in the LDAP protocol [PROT]. This representation is referred to as
+ the LDAP-specific encoding to distinguish it from other methods of
+ encoding attribute values (e.g. the BER encoding [BER] used by X.500
+ [X.500] directories).
+
+ The LDAP-specific encoding of a given attribute syntax always
+ produces octet-aligned values. To the greatest extent possible,
+ encoding rules for LDAP syntaxes should produce character strings
+ that can be displayed with little or no translation by clients
+ implementing LDAP. However, clients MUST NOT assume that the
+ LDAP-specific encoding of a value of an unrecognized syntax is a
+ human-readable character string. There are a few cases (e.g. the
+ JPEG syntax) when it is not reasonable to produce a human-readable
+ representation.
+
+ Each LDAP syntax is uniquely identified with an object identifier
+ [ASN.1] represented in the dotted-decimal format (short descriptive
+ names are not defined for syntaxes). These object identifiers are
+ not intended to be displayed to users. The object identifiers for
+ the syntaxes defined in this document are summarized in Appendix A.
+
+ A suggested minimum upper bound on the number of characters in an
+ attribute value with a string-based syntax, or the number of octets
+ in a value for all other syntaxes, MAY be indicated by appending the
+ bound inside of curly braces following the syntax's OBJECT IDENTIFIER
+ in an attribute type definition (see the <noidlen> rule in [MODELS]).
+ Such a bound is not considered part of the syntax identifier.
+
+ For example, "1.3.6.1.4.1.1466.115.121.1.15{64}" in an attribute
+ definition suggests that the directory server will allow a value of
+ the attribute to be up to 64 characters long, although it may allow
+ longer character strings. Note that a single character of the
+ Directory String syntax can be encoded in more than one octet since
+ UTF-8 [UTF-8] is a variable-length encoding. Therefore a 64
+ character string may be more than 64 octets in length.
+
+
+4.2 Common Definitions
+
+ The following ABNF rules are used in a number of the syntax
+ definitions in Section 4.3.
+
+ PrintableCharacter = ALPHA / DIGIT / SQUOTE / LPAREN / RPAREN /
+ PLUS / COMMA / HYPHEN / DOT / EQUALS /
+ SLASH / COLON / QUESTION / SPACE
+ PrintableString = 1*PrintableCharacter
+
+
+
+Legg & Dally Expires 27 August 2003 [Page 6]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+
+
+ IA5String = *(%x00-7F)
+ HEX-DIGIT = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
+ ; N.B. allows upper and lower case
+ SLASH = %x2F ; forward slash ("/")
+ COLON = %x3A ; colon (":")
+ QUESTION = %x3F ; question mark ("?")
+
+ The <OCTET>, <ALPHA>, <DIGIT>, <SQUOTE>, <LPAREN>, <RPAREN>, <PLUS>,
+ <COMMA>, <HYPHEN>, <DOT>, <EQUALS> and <SPACE> rules are defined in
+ [MODELS].
+
+
+4.3 Syntax Definitions
+
+4.3.1 Attribute Type Description
+
+ A value of the Attribute Type Description syntax is the definition of
+ an attribute type. The LDAP-specific encoding of a value of this
+ syntax is defined by the <AttributeTypeDescription> rule in [MODELS].
+ For example, the following definition of the createTimestamp
+ attribute type from [MODELS] is also a value of the Attribute Type
+ Description syntax (note: line breaks have been added for readability
+ - they are not part of the value when transfered in protocol).
+
+ ( 2.5.18.1 NAME 'createTimestamp'
+ EQUALITY generalizedTimeMatch
+ ORDERING generalizedTimeOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+ SINGLE-VALUE NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+ The LDAP definition for the Attribute Type Description syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' )
+
+ This syntax corresponds to the AttributeTypeDescription ASN.1 type
+ from [X.501].
+
+
+4.3.2 Bit String
+
+ A value of the Bit String syntax is a sequence of binary digits. The
+ LDAP-specific encoding of a value of this syntax is defined by the
+ following ABNF:
+
+ BitString = SQUOTE *binary-digit SQUOTE "B"
+ binary-digit = "0" / "1"
+
+
+
+
+Legg & Dally Expires 27 August 2003 [Page 7]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+
+
+ The <SQUOTE> rule is defined in [MODELS].
+
+ Example:
+ '0101111101'B
+
+ The LDAP definition for the Bit String syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' )
+
+ This syntax corresponds to the BIT STRING ASN.1 type from [ASN.1].
+
+
+4.3.3 Boolean
+
+ A value of the Boolean syntax is one of the Boolean values, true or
+ false. The LDAP-specific encoding of a value of this syntax is
+ defined by the following ABNF:
+
+ Boolean = "TRUE" / "FALSE"
+
+ The LDAP definition for the Boolean syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' )
+
+ This syntax corresponds to the BOOLEAN ASN.1 type from [ASN.1].
+
+
+4.3.4 Country String
+
+ A value of the Country String syntax is one of the two-character
+ codes from ISO 3166 [ISO3166] for representing a country. The
+ LDAP-specific encoding of a value of this syntax is defined by the
+ following ABNF:
+
+ CountryString = 2(PrintableCharacter)
+
+ The <PrintableCharacter> rule is defined in Section 4.2.
+
+ Examples:
+ US
+ AU
+
+ The LDAP definition for the Country String syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' )
+
+ This syntax corresponds to the following ASN.1 type from [X.520]:
+
+
+
+
+Legg & Dally Expires 27 August 2003 [Page 8]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+
+
+ PrintableString (SIZE (2)) -- IS 3166 codes only
+
+
+4.3.5 Delivery Method
+
+ A value of the Delivery Method syntax is a sequence of items that
+ indicate, in preference order, the service(s) by which an entity is
+ willing and/or capable of receiving messages. The LDAP-specific
+ encoding of a value of this syntax is defined by the following ABNF:
+
+ DeliveryMethod = pdm *( WSP DOLLAR WSP pdm )
+
+ pdm = "any" / "mhs" / "physical" / "telex" / "teletex" /
+ "g3fax" / "g4fax" / "ia5" / "videotex" / "telephone"
+
+ The <WSP> and <DOLLAR> rules are defined in [MODELS].
+
+ Example:
+ telephone $ videotex
+
+ The LDAP definition for the Delivery Method syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' )
+
+ This syntax corresponds to the following ASN.1 type from [X.520]:
+
+ SEQUENCE OF INTEGER {
+ any-delivery-method (0),
+ mhs-delivery (1),
+ physical-delivery (2),
+ telex-delivery (3),
+ teletex-delivery (4),
+ g3-facsimile-delivery (5),
+ g4-facsimile-delivery (6),
+ ia5-terminal-delivery (7),
+ videotex-delivery (8),
+ telephone-delivery (9) }
+
+
+4.3.6 Directory String
+
+ A value of the Directory String syntax is a string of one or more
+ arbitrary characters from the Universal Character Set (UCS) [UCS]. A
+ zero length character string is not permitted. The LDAP-specific
+ encoding of a value of this syntax is the UTF-8 encoding [UTF-8] of
+ the character string. Such encodings conform to the following ABNF:
+
+ DirectoryString = 1*UTF8
+
+
+
+Legg & Dally Expires 27 August 2003 [Page 9]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+
+
+ The <UTF8> rule is defined in [MODELS].
+
+ Example:
+ This is a value of Directory String containing #!%#@.
+
+ Servers and clients MUST be prepared to receive arbitrary UCS code
+ points, including code points outside the range of printable ASCII
+ and code points not presently assigned to any character.
+
+ Attribute type definitions using the Directory String syntax should
+ not restrict the format of Directory String values, e.g. by requiring
+ that the character string conforms to specific patterns described by
+ ABNF. A new syntax should be defined in such cases.
+
+ The LDAP definition for the Directory String syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' )
+
+ This syntax corresponds to the DirectoryString parameterized ASN.1
+ type from [X.520].
+
+ The DirectoryString ASN.1 type allows a choice between the
+ TeletexString, PrintableString or UniversalString ASN.1 types from
+ [ASN.1]. However, note that the chosen alternative is not indicated
+ in the LDAP-specific encoding of a Directory String value.
+
+ Implementations which convert Directory String values from the
+ LDAP-specific encoding to the BER encoding used by X.500 must choose
+ an alternative that permits the particular characters in the string,
+ and must convert the characters from the UTF-8 encoding into the
+ character encoding of the chosen alternative.
+
+ When converting Directory String values from the BER encoding to the
+ LDAP-specific encoding the characters must be converted from the
+ character encoding of the chosen alternative into the UTF-8 encoding.
+
+
+4.3.7 DIT Content Rule Description
+
+ A value of the DIT Content Rule Description syntax is the definition
+ of a DIT content rule. The LDAP-specific encoding of a value of this
+ syntax is defined by the <DITContentRuleDescription> rule in
+ [MODELS].
+
+ Example:
+ ( 2.5.6.4 DESC 'content rule for organization'
+ NOT ( x121Address $ telexNumber ) )
+
+
+
+
+Legg & Dally Expires 27 August 2003 [Page 10]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+
+
+ Note: a line break has been added for readability - it is not part of
+ the value.
+
+ The LDAP definition for the DIT Content Rule Description syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.16
+ DESC 'DIT Content Rule Description' )
+
+ This syntax corresponds to the DITContentRuleDescription ASN.1 type
+ from [X.501].
+
+
+4.3.8 DIT Structure Rule Description
+
+ A value of the DIT Structure Rule Description syntax is the
+ definition of a DIT structure rule. The LDAP-specific encoding of a
+ value of this syntax is defined by the <DITStructureRuleDescription>
+ rule in [MODELS].
+
+ Example:
+ ( 2 DESC 'organization structure rule' FORM 2.5.15.3 )
+
+ The LDAP definition for the DIT Structure Rule Description syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.17
+ DESC 'DIT Structure Rule Description' )
+
+ This syntax corresponds to the DITStructureRuleDescription ASN.1 type
+ from [X.501].
+
+
+4.3.9 DN
+
+ A value of the DN syntax is the (purported) distinguished name of an
+ entry [MODELS]. The LDAP-specific encoding of a value of this syntax
+ is defined by the <distinguishedName> rule in [LDAPDN].
+
+ Examples (from [LDAPDN]):
+ UID=jsmith,DC=example,DC=net
+ OU=Sales+CN=J. Smith,DC=example,DC=net
+ CN=John Smith\, III,DC=example,DC=net
+ CN=Before\0dAfter,DC=example,DC=net
+ 1.3.6.1.4.1.1466.0=#04024869,DC=example,DC=com
+ CN=Lu\C4\8Di\C4\87
+
+ The LDAP definition for the DN syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' )
+
+
+
+Legg & Dally Expires 27 August 2003 [Page 11]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+
+
+ The DN syntax corresponds to the DistinguishedName ASN.1 type from
+ [X.501]. Note that a BER encoded distinguished name (as used by
+ X.500) re-encoded into the LDAP-specific encoding is not necessarily
+ reversible to the original BER encoding since the chosen string type
+ in any DirectoryString components of the distinguished name is not
+ indicated in the LDAP-specific encoding of the distinguished name
+ (see Section 4.3.6).
+
+
+4.3.10 Enhanced Guide
+
+ A value of the Enhanced Guide syntax suggests criteria, which consist
+ of combinations of attribute types and filter operators, to be used
+ in constructing filters to search for entries of particular object
+ classes. The Enhanced Guide syntax improves upon the Guide syntax by
+ allowing the recommended depth of the search to be specified.
+
+ The LDAP-specific encoding of a value of this syntax is defined by
+ the following ABNF:
+
+ EnhancedGuide = object-class SHARP WSP criteria WSP
+ SHARP WSP subset
+ object-class = WSP oid WSP
+ subset = "baseobject" / "oneLevel" / "wholeSubtree"
+
+ criteria = and-term *( BAR and-term )
+ and-term = term *( AMPERSAND term )
+ term = EXCLAIM term /
+ attributetype DOLLAR match-type /
+ LPAREN criteria RPAREN /
+ true /
+ false
+ match-type = "EQ" / "SUBSTR" / "GE" / "LE" / "APPROX"
+ true = "?true"
+ false = "?false"
+ BAR = %x7C ; vertical bar ("|")
+ AMPERSAND = %x26 ; ampersand ("&")
+ EXCLAIM = %x21 ; exclamation mark ("!")
+
+ The <SHARP>, <WSP>, <oid>, <LPAREN>, <RPAREN>, <attributetype> and
+ <DOLLAR> rules are defined in [MODELS].
+
+ The LDAP definition for the Enhanced Guide syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.21 DESC 'Enhanced Guide' )
+
+
+ Example:
+
+
+
+Legg & Dally Expires 27 August 2003 [Page 12]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+
+
+ person#(sn$EQ)#oneLevel
+
+ The Enhanced Guide syntax corresponds to the EnhancedGuide ASN.1 type
+ from [X.520]. The EnhancedGuide type references the Criteria ASN.1
+ type, also from [X.520]. The <true> rule above represents an empty
+ "and" expression in a value of the Criteria type. The <false> rule
+ above represents an empty "or" expression in a value of the Criteria
+ type.
+
+
+4.3.11 Facsimile Telephone Number
+
+ A value of the Facsimile Telephone Number syntax is a subscriber
+ number of a facsimile device on the public switched telephone
+ network. The LDAP-specific encoding of a value of this syntax is
+ defined by the following ABNF:
+
+ fax-number = telephone-number *( DOLLAR fax-parameter )
+ telephone-number = PrintableString
+ fax-parameter = "twoDimensional" /
+ "fineResolution" /
+ "unlimitedLength" /
+ "b4Length" /
+ "a3Width" /
+ "b4Width" /
+ "uncompressed"
+
+ The <telephone-number> is a string of printable characters that
+ complies with the internationally agreed format for representing
+ international telephone numbers [E.123]. The <PrintableString> rule
+ is defined in Section 4.2. The <DOLLAR> rule is defined in [MODELS].
+
+ The LDAP definition for the Facsimile Telephone Number syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number')
+
+ The Facsimile Telephone Number syntax corresponds to the
+ FacsimileTelephoneNumber ASN.1 type from [X.520].
+
+
+4.3.12 Fax
+
+ A value of the Fax syntax is an image which is produced using the
+ Group 3 facsimile process [FAX] to duplicate an object, such as a
+ memo. The LDAP-specific encoding of a value of this syntax is the
+ string of octets for a Group 3 Fax image as defined in [FAX].
+
+ The LDAP definition for the Fax syntax is:
+
+
+
+Legg & Dally Expires 27 August 2003 [Page 13]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+
+
+ ( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' )
+
+ The ASN.1 type corresponding to the Fax syntax is defined as follows,
+ assuming EXPLICIT TAGS:
+
+ Fax ::= CHOICE {
+ g3-facsimile [3] G3FacsimileBodyPart
+ }
+
+ The G3FacsimileBodyPart ASN.1 type is defined in [X.420].
+
+
+4.3.13 Generalized Time
+
+ A value of the Generalized Time syntax is a character string
+ representing a date and time. The LDAP-specific encoding of a value
+ of this syntax is a restriction of the format defined in [ISO8601],
+ and is described by the following ABNF:
+
+ century = 2(%x30-39) ; "00" to "99"
+ year = 2(%x30-39) ; "00" to "99"
+ month = ( %x30 %x31-39 ) ; "01" (January) to "09"
+ / ( %x31 %x30-32 ) ; "10" to "12"
+ day = ( %x30 %x31-39 ) ; "01" to "09"
+ / ( %x31-32 %x30-39 ) ; "10" to "29"
+ / ( %x33 %x30-31 ) ; "30" to "31"
+ hour = ( %x30-31 %x30-39 ) / ( %x32 %x30-33 ) ; "00" to "23"
+ minute = %x30-35 %x30-39 ; "00" to "59"
+ second = %x30-35 %x30-39 ; "00" to "59"
+
+ GeneralizedTime = century year month day hour
+ [ minute [ second ] ] [ fraction ]
+ g-time-zone
+ fraction = ( DOT / COMMA ) 1*(%x30-39)
+ g-time-zone = %x5A ; "Z"
+ / g-differential
+ g-differential = ( MINUS / PLUS ) hour [ minute ]
+ MINUS = %x2D ; minus sign ("-")
+
+ The <DOT>, <COMMA> and <PLUS> rules are defined in [MODELS].
+
+ The time value represents coordinated universal time (equivalent to
+ Greenwich Mean Time) if the "Z" form of <g-time-zone> is used,
+ otherwise the value represents a local time in the time zone
+ indicated by <g-differential>. In the latter case, coordinated
+ universal time can be calculated by subtracting the differential from
+ the local time. The "Z" form of <g-time-zone> SHOULD be used in
+ preference to <g-differential>.
+
+
+
+Legg & Dally Expires 27 August 2003 [Page 14]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+
+
+ Examples:
+ 199412161032Z
+ 199412160532-0500
+
+ Both example values represent the same coordinated universal time:
+ 40:32 am, December 16, 1994.
+
+ The LDAP definition for the Generalized Time syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' )
+
+ This syntax corresponds to the GeneralizedTime ASN.1 type from
+ [ASN.1], with the constraint that local time without a differential
+ SHALL NOT be used.
+
+
+4.3.14 Guide
+
+ A value of the Guide syntax suggests criteria, which consist of
+ combinations of attribute types and filter operators, to be used in
+ constructing filters to search for entries of particular object
+ classes. The Guide syntax is obsolete and should not be used for
+ defining new attribute types.
+
+ The LDAP-specific encoding of a value of this syntax is defined by
+ the following ABNF:
+
+ Guide = [ object-class SHARP ] criteria
+
+ The <object-class> and <criteria> rules are defined in Section
+ 4.3.10. The <SHARP> rule is defined in [MODELS].
+
+ The LDAP definition for the Guide syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.25 DESC 'Guide' )
+
+ The Guide syntax corresponds to the Guide ASN.1 type from [X.520].
+
+
+4.3.15 IA5 String
+
+ A value of the IA5 String syntax is a string of zero, one or more
+ characters from International Alphabet 5 (IA5) [T.50], the
+ international version of the ASCII character set. The LDAP-specific
+ encoding of a value of this syntax is the unconverted string of
+ characters, which conforms to the <IA5String> rule in Section 4.2.
+
+ The LDAP definition for the IA5 String syntax is:
+
+
+
+Legg & Dally Expires 27 August 2003 [Page 15]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+
+
+ ( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' )
+
+ This syntax corresponds to the IA5String ASN.1 type from [ASN.1].
+
+
+4.3.16 Integer
+
+ A value of the Integer syntax is a whole number of unlimited
+ magnitude. The LDAP-specific encoding of a value of this syntax is
+ the optionally signed decimal digit character string representation
+ of the number (so, for example, the number 1321 is represented by the
+ character string "1321"). The encoding is defined by the following
+ ABNF:
+
+ Integer = [ HYPHEN ] number
+
+ The <HYPHEN> and <number> rules are defined in [MODELS].
+
+ The LDAP definition for the Integer syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' )
+
+ This syntax corresponds to the INTEGER ASN.1 type from [ASN.1].
+
+
+4.3.17 JPEG
+
+ A value of the JPEG syntax is an image in the JPEG File Interchange
+ Format (JFIF), as described in [JPEG]. The LDAP-specific encoding of
+ a value of this syntax is the sequence of octets of the JFIF encoding
+ of the image.
+
+ The LDAP definition for the JPEG syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' )
+
+ The JPEG syntax corresponds to the following ASN.1 type:
+
+ JPEG ::= OCTET STRING (CONSTRAINED BY
+ { -- contents octets are an image in the --
+ -- JPEG File Interchange Format -- })
+
+
+4.3.18 LDAP Syntax Description
+
+ A value of the LDAP Syntax Description syntax is the description of
+ an LDAP syntax. The LDAP-specific encoding of a value of this syntax
+ is defined by the <SyntaxDescription> rule in [MODELS].
+
+
+
+Legg & Dally Expires 27 August 2003 [Page 16]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+
+
+ The LDAP definition for the LDAP Syntax Description syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'LDAP Syntax Description' )
+
+ The above LDAP definition for the LDAP Syntax Description syntax is
+ itself a legal value of the LDAP Syntax Description syntax.
+
+ The ASN.1 type corresponding to the LDAP Syntax Description syntax is
+ defined as follows, assuming EXPLICIT TAGS:
+
+ LDAPSyntaxDescription ::= SEQUENCE {
+ identifier OBJECT IDENTIFIER,
+ description DirectoryString { ub-schema } OPTIONAL }
+
+ The DirectoryString parameterized ASN.1 type is defined in [X.520].
+
+ The value of ub-schema (an integer) is implementation defined. A
+ non-normative definition appears in [X.520].
+
+
+4.3.19 Matching Rule Description
+
+ A value of the Matching Rule Description syntax is the definition of
+ a matching rule. The LDAP-specific encoding of a value of this
+ syntax is defined by the <MatchingRuleDescription> rule in [MODELS].
+
+ Example:
+ ( 2.5.13.2 NAME 'caseIgnoreMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ Note: a line break has been added for readability - it is not part of
+ the syntax.
+
+ The LDAP definition for the Matching Rule Description syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' )
+
+ This syntax corresponds to the MatchingRuleDescription ASN.1 type
+ from [X.501].
+
+
+4.3.20 Matching Rule Use Description
+
+ A value of the Matching Rule Use Description syntax indicates the
+ attribute types to which a matching rule may be applied in an
+ extensibleMatch search filter [PROT]. The LDAP-specific encoding of
+ a value of this syntax is defined by the <MatchingRuleUseDescription>
+ rule in [MODELS].
+
+
+
+Legg & Dally Expires 27 August 2003 [Page 17]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+
+
+ Example:
+ ( 2.5.13.16 APPLIES ( givenName $ surname ) )
+
+ The LDAP definition for the Matching Rule Use Description syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.31
+ DESC 'Matching Rule Use Description' )
+
+ This syntax corresponds to the MatchingRuleUseDescription ASN.1 type
+ from [X.501].
+
+
+4.3.21 Name and Optional UID
+
+ A value of the Name and Optional UID syntax is the distinguished name
+ [MODELS] of an entity optionally accompanied by a unique identifier
+ that serves to differentiate the entity from others with an identical
+ distinguished name.
+
+ The LDAP-specific encoding of a value of this syntax is defined by
+ the following ABNF:
+
+ NameAndOptionalUID = distinguishedName [ SHARP BitString ]
+
+ The <BitString> rule is defined in Section 4.3.2. The
+ <distinguishedName> rule is defined in [LDAPDN]. The <SHARP> rule is
+ defined in [MODELS].
+
+ Note that although the '#' character may occur in the string
+ representation of a distinguished name, no additional escaping of
+ this character is performed when a <distinguishedName> is encoded in
+ a <NameAndOptionalUID>.
+
+ Example:
+ 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B
+
+ The LDAP definition for the Name and Optional UID syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Name And Optional UID' )
+
+ This syntax corresponds to the NameAndOptionalUID ASN.1 type from
+ [X.520].
+
+
+4.3.22 Name Form Description
+
+ A value of the Name Form Description syntax is the definition of a
+ name form, which regulates how entries may be named. The
+
+
+
+Legg & Dally Expires 27 August 2003 [Page 18]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+
+
+ LDAP-specific encoding of a value of this syntax is defined by the
+ <NameFormDescription> rule in [MODELS].
+
+ Example:
+ ( 2.5.15.3 NAME 'orgNameForm' OC organization MUST o )
+
+ The LDAP definition for the Name Form Description syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' )
+
+ This syntax corresponds to the NameFormDescription ASN.1 type from
+ [X.501].
+
+
+4.3.23 Numeric String
+
+ A value of the Numeric String syntax is a sequence of one or more
+ numerals and spaces. The LDAP-specific encoding of a value of this
+ syntax is the unconverted string of characters, which conforms to the
+ following ABNF:
+
+ NumericString = 1*(DIGIT / SPACE)
+
+ The <DIGIT> and <SPACE> rules are defined in [MODELS].
+
+ Example:
+ 15 079 672 281
+
+ The LDAP definition for the Numeric String syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' )
+
+ This syntax corresponds to the NumericString ASN.1 type from [ASN.1].
+
+
+4.3.24 Object Class Description
+
+ A value of the Object Class Description syntax is the definition of
+ an object class. The LDAP-specific encoding of a value of this
+ syntax is defined by the <ObjectClassDescription> rule in [MODELS].
+
+ Example:
+ ( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c
+ MAY ( searchGuide $ description ) )
+
+ Note: a line break has been added for readability - it is not part of
+ the syntax.
+
+
+
+
+Legg & Dally Expires 27 August 2003 [Page 19]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+
+
+ The LDAP definition for the Object Class Description syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description' )
+
+ This syntax corresponds to the ObjectClassDescription ASN.1 type from
+ [X.501].
+
+
+4.3.25 Octet String
+
+ A value of the Octet String syntax is a sequence of zero, one or more
+ arbitrary octets. The LDAP-specific encoding of a value of this
+ syntax is the unconverted sequence of octets, which conforms to the
+ following ABNF:
+
+ OctetString = *OCTET
+
+ The <OCTET> rule is defined in [MODELS]. Values of this syntax are
+ not generally human-readable.
+
+ The LDAP definition for the Octet String syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String' )
+
+ This syntax corresponds to the OCTET STRING ASN.1 type from [ASN.1].
+
+
+4.3.26 OID
+
+ A value of the OID syntax is an object identifier; a sequence of two
+ or more non-negative integers that uniquely identify some object or
+ item of specification. Many of the object identifiers used in LDAP
+ also have IANA registered names [RFC3383].
+
+ The LDAP-specific encoding of a value of this syntax is defined by
+ the <oid> rule in [MODELS].
+
+ Examples:
+ 1.2.3.4
+ cn
+
+ The LDAP definition for the OID syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' )
+
+ This syntax corresponds to the OBJECT IDENTIFIER ASN.1 type from
+ [ASN.1].
+
+
+
+
+Legg & Dally Expires 27 August 2003 [Page 20]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+
+
+4.3.27 Other Mailbox
+
+ A value of the Other Mailbox syntax identifies an electronic mailbox,
+ in a particular named mail system. The LDAP-specific encoding of a
+ value of this syntax is defined by the following ABNF:
+
+ OtherMailbox = mailbox-type DOLLAR mailbox
+ mailbox-type = PrintableString
+ mailbox = IA5String
+
+ The <mailbox-type> rule represents the type of mail system in which
+ the mailbox resides, for example "MCIMail", and <mailbox> is the
+ actual mailbox in the mail system described by <mailbox-type>. The
+ <PrintableString> and <IA5String> rules are defined in Section 4.2.
+ The <DOLLAR> rule is defined in [MODELS].
+
+ The LDAP definition for the Other Mailbox syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' )
+
+ The ASN.1 type corresponding to the Other Mailbox syntax is defined
+ as follows, assuming EXPLICIT TAGS:
+
+ OtherMailbox ::= SEQUENCE {
+ mailboxType PrintableString,
+ mailbox IA5String
+ }
+
+
+4.3.28 Postal Address
+
+ A value of the Postal Address syntax is a sequence of strings of one
+ or more arbitrary UCS characters, which form an address in a physical
+ mail system.
+
+ The LDAP-specific encoding of a value of this syntax is defined by
+ the following ABNF:
+
+ PostalAddress = line *( DOLLAR line )
+ line = 1*line-char
+ line-char = %x00-23
+ / (%x5C "24") ; escaped "$"
+ / %x25-5B
+ / (%x5C "5C") ; escaped "\"
+ / %x5D-7F
+ / UTFMB
+
+ Each character string (i.e. <line>) of a postal address value is
+
+
+
+Legg & Dally Expires 27 August 2003 [Page 21]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+
+
+ encoded as a UTF-8 [UTF-8] string except that "\" and "$" characters,
+ if they occur in the string, are escaped by a "\" character followed
+ by the two hexadecimal digit code for the character. The <HEX-DIGIT>
+ rule is defined in Section 4.2. The <DOLLAR> and <UTFMB> rules are
+ defined in [MODELS].
+
+ Many servers limit the postal address to no more than six lines of no
+ more than thirty characters each.
+
+ Example:
+ 1234 Main St.$Anytown, CA 12345$USA
+ \241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA
+
+ The LDAP definition for the Postal Address syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' )
+
+ This syntax corresponds to the PostalAddress ASN.1 type from [X.520],
+ i.e.
+
+ PostalAddress ::= SEQUENCE SIZE(1..ub-postal-line) OF
+ DirectoryString { ub-postal-string }
+
+ The values of ub-postal-line and ub-postal-string (both integers) are
+ implementation defined. Non-normative definitions appear in [X.520].
+
+
+4.3.29 Printable String
+
+ A value of the Printable String syntax is a string of latin
+ alphabetic, numeric, and (limited) punctuation characters as
+ specified by the <PrintableCharacter> rule in Section 4.2.
+
+ The LDAP-specific encoding of a value of this syntax is the
+ unconverted string of characters, which conforms to the
+ <PrintableString> rule in Section 4.2.
+
+ Example:
+ This is a PrintableString.
+
+ The LDAP definition for the PrintableString syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' )
+
+ This syntax corresponds to the PrintableString ASN.1 type from
+ [ASN.1].
+
+
+
+
+
+Legg & Dally Expires 27 August 2003 [Page 22]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+
+
+4.3.30 Substring Assertion
+
+ A value of the Substring Assertion syntax is a sequence of zero, one
+ or more character substrings used as an argument for substring
+ extensible matching of character string attribute values, i.e. as the
+ matchValue of a MatchingRuleAssertion [PROT]. Each substring is a
+ string of one or more arbitrary characters from the Universal
+ Character Set (UCS) [UCS]. A zero length substring is not permitted.
+
+ The LDAP-specific encoding of a value of this syntax is defined by
+ the following ABNF:
+
+ SubstringAssertion = [ initial ] any [ final ]
+
+ initial = substring
+ any = ASTERISK *(substring ASTERISK)
+ final = substring
+ ASTERISK = %x2A ; asterisk ("*")
+
+ substring = 1*substring-character
+ substring-character = %x00-29
+ / (%x5C "2A") ; escaped "*"
+ / %x2B-5B
+ / (%x5C "5C") ; escaped "\"
+ / %x5D-7F
+ / UTFMB
+
+ Each <substring> of a Substring Assertion value is encoded as a UTF-8
+ [UTF-8] string, except that "\" and "*" characters, if they occur in
+ the substring, are escaped by a "\" character followed by the two
+ hexadecimal digit code for the character.
+
+ The Substring Assertion syntax is used only as the syntax of
+ assertion values in the extensible match. It is not used as an
+ attribute syntax, or in the SubstringFilter [PROT].
+
+ The LDAP definition for the Substring Assertion syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' )
+
+ This syntax corresponds to the SubstringAssertion ASN.1 type from
+ [X.520].
+
+
+4.3.31 Telephone Number
+
+ A value of the Telephone Number syntax is a string of printable
+ characters that complies with the internationally agreed format for
+
+
+
+Legg & Dally Expires 27 August 2003 [Page 23]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+
+
+ representing international telephone numbers [E.123].
+
+ The LDAP-specific encoding of a value of this syntax is the
+ unconverted string of characters, which conforms to the
+ <PrintableString> rule in Section 4.2.
+
+ Example: +1 512 315 0280
+
+ The LDAP definition for the Telephone Number syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' )
+
+ The Telephone Number syntax corresponds to the following ASN.1 type
+ from [X.520]:
+
+ PrintableString (SIZE(1..ub-telephone-number))
+
+ The value of ub-telephone-number (an integer) is implementation
+ defined. A non-normative definition appears in [X.520].
+
+
+4.3.32 Teletex Terminal Identifier
+
+ A value of this syntax specifies the identifier and (optionally)
+ parameters of a teletex terminal.
+
+ The LDAP-specific encoding of a value of this syntax is defined by
+ the following ABNF:
+
+ teletex-id = ttx-term *(DOLLAR ttx-param)
+ ttx-term = PrintableString ; terminal identifier
+ ttx-param = ttx-key COLON ttx-value ; parameter
+ ttx-key = "graphic" / "control" / "misc" / "page" / "private"
+ ttx-value = *ttx-value-char
+
+ ttx-value-char = %x00-23
+ / (%x5C "24") ; escaped "$"
+ / %x25-5B
+ / (%x5C "5C") ; escaped "\"
+ / %x5D-FF
+
+ The <PrintableString> and <COLON> rules are defined in Section 4.2.
+ The <DOLLAR> rule is defined in [MODELS].
+
+ The LDAP definition for the Teletex Terminal Identifier syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.51
+ DESC 'Teletex Terminal Identifier' )
+
+
+
+Legg & Dally Expires 27 August 2003 [Page 24]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+
+
+ This syntax corresponds to the TeletexTerminalIdentifier ASN.1 type
+ from [X.520].
+
+
+4.3.33 Telex Number
+
+ A value of the Telex Number syntax specifies the telex number,
+ country code and answerback code of a telex terminal.
+
+ The LDAP-specific encoding of a value of this syntax is defined by
+ the following ABNF:
+
+ telex-number = actual-number DOLLAR country-code
+ DOLLAR answerback
+ actual-number = PrintableString
+ country-code = PrintableString
+ answerback = PrintableString
+
+ The <PrintableString> rule is defined in Section 4.2. The <DOLLAR>
+ rule is defined in [MODELS].
+
+ The LDAP definition for the Telex Number syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' )
+
+ This syntax corresponds to the TelexNumber ASN.1 type from [X.520].
+
+
+4.3.34 UTC Time
+
+ A value of the UTC Time syntax is a character string representing a
+ date and time to a precision of one minute or one second. The year
+ is given as a two-digit number. The LDAP-specific encoding of a
+ value of this syntax follows the format defined in [ASN.1] for the
+ UTCTime type and is described by the following ABNF:
+
+ UTCTime = year month day hour minute [ second ]
+ [ u-time-zone ]
+ u-time-zone = %x5A ; "Z"
+ / u-differential
+ u-differential = ( MINUS / PLUS ) hour minute
+
+ The <year>, <month>, <day>, <hour>, <minute>, <second> and <MINUS>
+ rules are defined in Section 4.3.13. The <PLUS> rule is defined in
+ [MODELS].
+
+ The time value represents coordinated universal time if the "Z" form
+ of <u-time-zone> is used, otherwise the value represents a local
+
+
+
+Legg & Dally Expires 27 August 2003 [Page 25]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+
+
+ time. In the latter case, if <u-differential> is provided then
+ coordinated universal time can be calculated by subtracting the
+ differential from the local time. The <u-time-zone> SHOULD be
+ present in time values and the "Z" form of <u-time-zone> SHOULD be
+ used in preference to <u-differential>.
+
+ The LDAP definition for the UTC Time syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.53 DESC 'UTC Time' )
+
+ Note: This syntax is deprecated in favor of the Generalized Time
+ syntax.
+
+ The UTC Time syntax corresponds to the UTCTime ASN.1 type from
+ [ASN.1].
+
+
+5. Matching Rules
+
+ Matching rules are used by directory implementations to compare
+ attribute values against assertion values when performing Search and
+ Compare operations [PROT]. They are also used when comparing a
+ purported distinguished name [MODELS] with the name of an entry.
+ When modifying entries, matching rules are used to identify values to
+ be deleted and to prevent an attribute from containing two equal
+ values.
+
+ Matching rules that are required for directory operation, or that are
+ in common use, are specified in this section.
+
+5.1 General Considerations
+
+ A matching rule is applied to attribute values through an
+ AttributeValueAssertion or MatchingRuleAssertion [PROT]. The
+ conditions under which an AttributeValueAssertion or
+ MatchingRuleAssertion evaluates to Undefined are specified in [PROT].
+ If an assertion is not Undefined then the result of the assertion is
+ the result of applying the selected matching rule. A matching rule
+ evaluates to TRUE, and in some cases Undefined, as specified in the
+ description of the matching rule, otherwise it evaluates to FALSE.
+
+ Each assertion contains an assertion value. The definition of each
+ matching rule specifies the syntax for the assertion value. The
+ syntax of the assertion value is typically, but not necessarily, the
+ same as the syntax of the attribute values to which the matching rule
+ may be applied. Note that the AssertionValue in a SubstringFilter
+ [PROT] MUST conform to the assertion syntax of the equality matching
+ rule for the attribute type rather than the assertion syntax of the
+
+
+
+Legg & Dally Expires 27 August 2003 [Page 26]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+
+
+ substrings matching rule for the attribute type. The entire
+ SubstringFilter is converted into an assertion value of the
+ substrings matching rule prior to applying the rule.
+
+ The definition of each matching rule indicates the attribute syntaxes
+ to which the rule may be applied, by specifying conditions the
+ corresponding ASN.1 type of a candidate attribute syntax must
+ satisfy. These conditions are also satisfied if the corresponding
+ ASN.1 type is a tagged or constrained derivative of the ASN.1 type
+ explicitly mentioned in the rule description (i.e. ASN.1 tags and
+ constraints are ignored in checking applicability), or an alternative
+ reference notation for the explicitly mentioned type. Each rule
+ description lists as examples of applicable attribute syntaxes, the
+ complete list of the syntaxes defined in this document to which the
+ matching rule applies. A matching rule may be applicable to
+ additional syntaxes defined in other documents if those syntaxes
+ satisfy the conditions on the corresponding ASN.1 type.
+
+ The description of each matching rule indicates whether the rule is
+ suitable for use as the equality matching rule (EQUALITY), ordering
+ matching rule (ORDERING) or substrings matching rule (SUBSTR) in an
+ attribute type definition [MODELS].
+
+ Each matching rule is uniquely identified with an object identifier.
+ The definition of a matching rule should not be subsequently changed.
+ If a change is desirable then a new matching rule with a different
+ object identifier should be defined instead.
+
+ Servers SHOULD implement all the matching rules in Section 5.2.
+ Servers MAY implement additional matching rules.
+
+ Servers which implement the extensibleMatch filter SHOULD allow the
+ matching rules listed in Section 5.2 to be used in the
+ extensibleMatch filter and SHOULD allow matching rules to be used
+ with all attribute types known to the server, where the assertion
+ syntax of the matching rule is the same as the value syntax of the
+ attribute.
+
+ Servers MUST publish in the matchingRules attribute, the definitions
+ of matching rules referenced by values of the attributeTypes and
+ matchingRuleUse attributes in the same subschema entry. Other
+ unreferenced matching rules MAY be published in the matchingRules
+ attribute.
+
+ If the server supports the extensibleMatch filter, then the server
+ MAY use the matchingRuleUse attribute to indicate the applicability
+ (in an extensibleMatch filter) of selected matching rules to
+ nominated attribute types.
+
+
+
+Legg & Dally Expires 27 August 2003 [Page 27]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+
+
+5.2 Matching Rule Definitions
+
+ When evaluating the caseExactIA5Match, caseIgnoreIA5Match,
+ caseIgnoreIA5SubstringsMatch, caseIgnoreListMatch,
+ caseIgnoreListSubstringsMatch, caseIgnoreMatch,
+ caseIgnoreOrderingMatch and caseIgnoreSubstringsMatch matching rules
+ multiple adjoining whitespace characters are treated the same as an
+ individual space, and leading and trailing whitespace is ignored.
+
+
+5.2.1 bitStringMatch
+
+ The bitStringMatch rule compares an assertion value of the Bit String
+ syntax to an attribute value of a syntax (e.g. the Bit String syntax)
+ whose corresponding ASN.1 type is BIT STRING.
+
+ If the corresponding ASN.1 type of the attribute syntax does not have
+ a named bit list (which is the case for the Bit String syntax) then
+ the rule evaluates to TRUE if and only if the attribute value has the
+ same number of bits as the assertion value and the bits match on a
+ bitwise basis.
+
+ If the corresponding ASN.1 type does have a named bit list then
+ bitStringMatch operates as above except that trailing zero bits in
+ the attribute and assertion values are treated as absent.
+
+ The LDAP definition for the bitStringMatch rule is:
+
+ ( 2.5.13.16 NAME 'bitStringMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
+
+ The bitStringMatch rule is an equality matching rule.
+
+
+5.2.2 caseExactIA5Match
+
+ The caseExactIA5Match rule compares an assertion value of the IA5
+ String syntax to an attribute value of a syntax (e.g the IA5 String
+ syntax) whose corresponding ASN.1 type is IA5String.
+
+ The rule evaluates to TRUE if and only if the attribute value and the
+ assertion value have the same number of characters and corresponding
+ characters are the same. Letter case is significant in the
+ comparison.
+
+ The LDAP definition for the caseExactIA5Match rule is:
+
+ ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match'
+
+
+
+Legg & Dally Expires 27 August 2003 [Page 28]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+
+
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+ The caseExactIA5Match rule is an equality matching rule.
+
+
+5.2.3 caseIgnoreIA5Match
+
+ The caseIgnoreIA5Match rule compares an assertion value of the IA5
+ String syntax to an attribute value of a syntax (e.g the IA5 String
+ syntax) whose corresponding ASN.1 type is IA5String.
+
+ The rule evaluates to TRUE if and only if the attribute value and the
+ assertion value have the same number of characters and corresponding
+ characters are the same, ignoring the case of letters.
+
+ The LDAP definition for the caseIgnoreIA5Match rule is:
+
+ ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+ The caseIgnoreIA5Match rule is an equality matching rule.
+
+
+5.2.4 caseIgnoreIA5SubstringsMatch
+
+ The caseIgnoreIA5SubstringsMatch rule compares an assertion value of
+ the Substring Assertion syntax to an attribute value of a syntax (e.g
+ the IA5 String syntax) whose corresponding ASN.1 type is IA5String.
+
+ The rule evaluates to TRUE if and only if the substrings of the
+ assertion value match disjoint portions of the attribute value in the
+ order of the substrings in the assertion value, and an <initial>
+ substring, if present, matches the beginning of the attribute value,
+ and a <final> substring, if present, matches the end of the attribute
+ value. A substring matches a portion of the attribute value if
+ corresponding characters are the same, ignoring the case of letters.
+
+ ( 1.3.6.1.4.1.1466.109.114.3 NAME 'caseIgnoreIA5SubstringsMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
+
+ The caseIgnoreIA5SubstringsMatch rule is a substrings matching rule.
+
+
+5.2.5 caseIgnoreListMatch
+
+ The caseIgnoreListMatch rule compares an assertion value that is a
+ sequence of strings to an attribute value of a syntax (e.g. the
+ Postal Address syntax) whose corresponding ASN.1 type is a SEQUENCE
+
+
+
+Legg & Dally Expires 27 August 2003 [Page 29]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+
+
+ OF the DirectoryString ASN.1 type.
+
+ The rule evaluates to TRUE if and only if the attribute value and the
+ assertion value have the same number of strings and corresponding
+ strings (by position) match according to the caseIgnoreMatch matching
+ rule.
+
+ In [X.520] the assertion syntax for this matching rule is defined to
+ be:
+
+ SEQUENCE OF DirectoryString {ub-match}
+
+ i.e. different from the corresponding type for the Postal Address
+ syntax. The choice of the Postal Address syntax for the assertion
+ syntax of the caseIgnoreListMatch in LDAP should not be seen as
+ limiting the matching rule to only apply to attributes with the
+ Postal Address syntax.
+
+ The LDAP definition for the caseIgnoreListMatch rule is:
+
+ ( 2.5.13.11 NAME 'caseIgnoreListMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
+
+ The caseIgnoreListMatch rule is an equality matching rule.
+
+
+5.2.6 caseIgnoreListSubstringsMatch
+
+ The caseIgnoreListSubstringsMatch rule compares an assertion value of
+ the Substring Assertion syntax to an attribute value of a syntax
+ (e.g. the Postal Address syntax) whose corresponding ASN.1 type is a
+ SEQUENCE OF the DirectoryString ASN.1 type.
+
+ The rule evaluates to TRUE if and only if the assertion value
+ matches, per the caseIgnoreSubstringsMatch rule, the character string
+ formed by concatenating the strings of the attribute value, except
+ that none of the <initial>, <any>, or <final> substrings of the
+ assertion value are considered to match a substring of the
+ concatenated string which spans more than one of the original strings
+ of the attribute value.
+
+ Note that, in terms of the LDAP-specific encoding of the Postal
+ Address syntax, the concatenated string omits the <DOLLAR> line
+ separator and the escaping of "\" and "$" characters.
+
+ The LDAP definition for the caseIgnoreListSubstringsMatch rule is:
+
+ ( 2.5.13.12 NAME 'caseIgnoreListSubstringsMatch'
+
+
+
+Legg & Dally Expires 27 August 2003 [Page 30]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+
+
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
+
+ The caseIgnoreListSubstringsMatch rule is a substrings matching rule.
+
+
+5.2.7 caseIgnoreMatch
+
+ The caseIgnoreMatch rule compares an assertion value of the Directory
+ String syntax to an attribute value of a syntax (e.g. the Directory
+ String, Printable String, Country String or Telephone Number syntax)
+ whose corresponding ASN.1 type is DirectoryString or one of the
+ alternative string types of DirectoryString, e.g. PrintableString
+ (the other alternatives do not correspond to any syntax defined in
+ this document).
+
+ The rule evaluates to TRUE if and only if the attribute value and the
+ assertion value have the same number of characters and corresponding
+ characters are the same, ignoring the case of letters.
+
+ The LDAP definition for the caseIgnoreMatch rule is:
+
+ ( 2.5.13.2 NAME 'caseIgnoreMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ The caseIgnoreMatch rule is an equality matching rule.
+
+
+5.2.8 caseIgnoreOrderingMatch
+
+ The caseIgnoreOrderingMatch rule compares an assertion value of the
+ Directory String syntax to an attribute value of a syntax (e.g. the
+ Directory String, Printable String, Country String or Telephone
+ Number syntax) whose corresponding ASN.1 type is DirectoryString or
+ one of its alternative string types.
+
+ The rule evaluates to TRUE if, and only if, in the normal collation
+ order for the attribute syntax after lower-case letters in both the
+ attribute and assertion values have been replaced by their upper-case
+ equivalents, the attribute value appears earlier than the assertion
+ value, i.e. the attribute value is "less than" the assertion value.
+
+ The collation order for values of the DirectoryString syntax is
+ implementation-defined. [Editor's note: this will be specified by a
+ stringprep profile before final publication.]
+
+ The LDAP definition for the caseIgnoreOrderingMatch rule is:
+
+ ( 2.5.13.3 NAME 'caseIgnoreOrderingMatch'
+
+
+
+Legg & Dally Expires 27 August 2003 [Page 31]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+
+
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ The caseIgnoreOrderingMatch rule is an ordering matching rule.
+
+
+5.2.9 caseIgnoreSubstringsMatch
+
+ The caseIgnoreSubstringsMatch rule compares an assertion value of the
+ Substring Assertion syntax to an attribute value of a syntax (e.g.
+ the Directory String, Printable String, Country String or Telephone
+ Number syntax) whose corresponding ASN.1 type is DirectoryString or
+ one of its alternative string types.
+
+ The rule evaluates to TRUE if and only if the substrings of the
+ assertion value match disjoint portions of the attribute value in the
+ order of the substrings in the assertion value, and an <initial>
+ substring, if present, matches the beginning of the attribute value,
+ and a <final> substring, if present, matches the end of the attribute
+ value. A substring matches a portion of the attribute value if
+ corresponding characters are the same, ignoring the case of letters.
+
+ The LDAP definition for the caseIgnoreSubstringsMatch rule is:
+
+ ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
+
+ The caseIgnoreSubstringsMatch rule is a substrings matching rule.
+
+
+5.2.10 distinguishedNameMatch
+
+ The distinguishedNameMatch rule compares an assertion value of the DN
+ syntax to an attribute value of a syntax (e.g. the DN syntax) whose
+ corresponding ASN.1 type is DistinguishedName.
+
+ The rule evaluates to TRUE if and only if the attribute value and the
+ assertion value have the same number of RDNs and corresponding RDNs
+ (by position) are the same. An RDN of the assertion value is the
+ same as an RDN of the attribute value if and only if they have the
+ same number of attribute value assertions (AVAs) and each AVA of the
+ first RDN is the same as the AVA of the second RDN with the same
+ attribute type. The order of the AVAs is not significant. Also note
+ that a particular attribute type may appear in at most one AVA in an
+ RDN. Two AVAs with the same attribute type are the same if their
+ values are equal according to the equality matching rule of the
+ attribute type. If one or more of the AVA comparisons evaluate to
+ Undefined and the remaining AVA comparisons return TRUE then the
+ distinguishedNameMatch rule evaluates to Undefined.
+
+
+
+Legg & Dally Expires 27 August 2003 [Page 32]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+
+
+ The LDAP definition for the distinguishedNameMatch rule is:
+
+ ( 2.5.13.1 NAME 'distinguishedNameMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+ The distinguishedNameMatch rule is an equality matching rule.
+
+
+5.2.11 generalizedTimeMatch
+
+ The generalizedTimeMatch rule compares an assertion value of the
+ Generalized Time syntax to an attribute value of a syntax (e.g the
+ Generalized Time syntax) whose corresponding ASN.1 type is
+ GeneralizedTime.
+
+ The rule evaluates to TRUE if and only if the attribute value
+ represents the same universal coordinated time as the assertion
+ value. If a time is specified with the minutes or seconds absent
+ then the number of minutes or seconds (respectively) is assumed to be
+ zero.
+
+ The LDAP definition for the generalizedTimeMatch rule is:
+
+ ( 2.5.13.27 NAME 'generalizedTimeMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
+
+ The generalizedTimeMatch rule is an equality matching rule.
+
+
+5.2.12 generalizedTimeOrderingMatch
+
+ The generalizedTimeMatch rule compares the time ordering of an
+ assertion value of the Generalized Time syntax to an attribute value
+ of a syntax (e.g the Generalized Time syntax) whose corresponding
+ ASN.1 type is GeneralizedTime.
+
+ The rule evaluates to TRUE if and only if the attribute value
+ represents a universal coordinated time which is earlier than the
+ universal coordinated time represented by the assertion value.
+
+ The LDAP definition for the generalizedTimeOrderingMatch rule is:
+
+ ( 2.5.13.28 NAME 'generalizedTimeOrderingMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
+
+ The generalizedTimeOrderingMatch rule is an ordering matching rule.
+
+
+
+
+
+Legg & Dally Expires 27 August 2003 [Page 33]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+
+
+5.2.13 integerFirstComponentMatch
+
+ The integerFirstComponentMatch rule compares an assertion value of
+ the Integer syntax to an attribute value of a syntax (e.g the DIT
+ Structure Rule Description syntax) whose corresponding ASN.1 type is
+ a SEQUENCE with a mandatory first component of the INTEGER ASN.1
+ type.
+
+ Note that the assertion syntax of this matching rule differs from the
+ attribute syntax of attributes for which this is the equality
+ matching rule.
+
+ The rule evaluates to TRUE if and only if the assertion value and the
+ first component of the attribute value are the same integer value.
+
+ The LDAP definition for the integerFirstComponentMatch matching rule
+ is:
+
+ ( 2.5.13.29 NAME 'integerFirstComponentMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
+
+ The integerFirstComponentMatch rule is an equality matching rule.
+ When using integerFirstComponentMatch to compare two attribute values
+ (of an applicable syntax), an assertion value must first be derived
+ from one of the attribute values. An assertion value can be derived
+ from an attribute value by taking the first component of that
+ attribute value.
+
+
+5.2.14 integerMatch
+
+ The integerMatch rule compares an assertion value of the Integer
+ syntax to an attribute value of a syntax (e.g the Integer syntax)
+ whose corresponding ASN.1 type is INTEGER.
+
+ The rule evaluates to TRUE if and only if the attribute value and the
+ assertion value are the same integer value.
+
+ The LDAP definition for the integerMatch matching rule is:
+
+ ( 2.5.13.14 NAME 'integerMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
+
+ The integerMatch rule is an equality matching rule.
+
+
+5.2.15 numericStringMatch
+
+
+
+
+Legg & Dally Expires 27 August 2003 [Page 34]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+
+
+ The numericStringMatch rule compares an assertion value of the
+ Numeric String syntax to an attribute value of a syntax (e.g the
+ Numeric String syntax) whose corresponding ASN.1 type is
+ NumericString.
+
+ The rule evaluates to TRUE if and only if the attribute value and the
+ assertion value are the same string of numerals, ignoring any space
+ characters.
+
+ The LDAP definition for the numericStringMatch matching rule is:
+
+ ( 2.5.13.8 NAME 'numericStringMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
+
+ The numericStringMatch rule is an equality matching rule.
+
+
+5.2.16 numericStringSubstringsMatch
+
+ The numericStringSubstringsMatch rule compares an assertion value of
+ the Substring Assertion syntax to an attribute value of a syntax (e.g
+ the Numeric String syntax) whose corresponding ASN.1 type is
+ NumericString.
+
+ The rule evaluates to TRUE if and only if the substrings of the
+ assertion value match disjoint portions of the attribute value in the
+ order of the substrings in the assertion value, and an <initial>
+ substring, if present, matches the beginning of the attribute value,
+ and a <final> substring, if present, matches the end of the attribute
+ value. A substring matches a portion of the attribute value if
+ corresponding characters are the same, ignoring any space characters.
+
+ ( 2.5.13.10 NAME 'numericStringSubstringsMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
+
+ The numericStringSubstringsMatch rule is a substrings matching rule.
+
+
+5.2.17 objectIdentifierFirstComponentMatch
+
+ The objectIdentifierFirstComponentMatch rule compares an assertion
+ value of the OID syntax to an attribute value of a syntax (e.g the
+ Attribute Type Description, DIT Content Rule Description, LDAP Syntax
+ Description, Matching Rule Description, Matching Rule Use
+ Description, Name Form Description or Object Class Description
+ syntax) whose corresponding ASN.1 type is a SEQUENCE with a mandatory
+ first component of the OBJECT IDENTIFIER ASN.1 type.
+
+
+
+
+Legg & Dally Expires 27 August 2003 [Page 35]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+
+
+ Note that the assertion syntax of this matching rule differs from the
+ attribute syntax of attributes for which this is the equality
+ matching rule.
+
+ The rule evaluates to TRUE if and only if the assertion value matches
+ the first component of the attribute value using the rules of
+ objectIdentifierMatch.
+
+ The LDAP definition for the objectIdentifierFirstComponentMatch
+ matching rule is:
+
+ ( 2.5.13.31 NAME 'objectIdentifierFirstComponentMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
+
+ The objectIdentifierFirstComponentMatch rule is an equality matching
+ rule. When using objectIdentifierFirstComponentMatch to compare two
+ attribute values (of an applicable syntax), an assertion value must
+ first be derived from one of the attribute values. An assertion
+ value can be derived from an attribute value by taking the first
+ component of that attribute value.
+
+
+5.2.18 objectIdentifierMatch
+
+ The objectIdentifierMatch rule compares an assertion value of the OID
+ syntax to an attribute value of a syntax (e.g the OID syntax) whose
+ corresponding ASN.1 type is OBJECT IDENTIFIER.
+
+ The rule evaluates to TRUE if and only if the assertion value and the
+ attribute value represent the same object identifier, that is, the
+ same sequence of integers, whether represented explicitly in the
+ <numericoid> form of <oid> or implicitly in the <descr> form (see
+ [MODELS]).
+
+ If an LDAP client supplies an assertion value in the <descr> form,
+ and the chosen descriptor is not recognized by the server, then the
+ objectIdentifierMatch rule evaluates to Undefined.
+
+ The LDAP definition for the objectIdentifierMatch matching rule is:
+
+ ( 2.5.13.0 NAME 'objectIdentifierMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
+
+ The objectIdentifierMatch rule is an equality matching rule.
+
+
+5.2.19 octetStringMatch
+
+
+
+
+Legg & Dally Expires 27 August 2003 [Page 36]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+
+
+ The octetStringMatch rule compares an assertion value of the Octet
+ String syntax to an attribute value of a syntax (e.g the Octet String
+ or JPEG syntax) whose corresponding ASN.1 type is the OCTET STRING
+ ASN.1 type.
+
+ The rule evaluates to TRUE if and only if the attribute value and the
+ assertion value are the same length and corresponding octets (by
+ position) are the same.
+
+ The LDAP definition for the octetStringMatch matching rule is:
+
+ ( 2.5.13.17 NAME 'octetStringMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
+
+ The octetStringMatch rule is an equality matching rule.
+
+
+5.2.20 telephoneNumberMatch
+
+ The telephoneNumberMatch rule compares an assertion value of the
+ Telephone Number syntax to an attribute value of a syntax (e.g the
+ Telephone Number syntax) whose corresponding ASN.1 type is a
+ PrintableString representing a telephone number.
+
+ The rule evaluates to TRUE if and only if the attribute value and the
+ assertion value have the same number of characters and corresponding
+ characters are the same, ignoring the case of letters, and ignoring
+ space and `-' characters.
+
+ The LDAP definition for the telephoneNumberMatch matching rule is:
+
+ ( 2.5.13.20 NAME 'telephoneNumberMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
+
+ The telephoneNumberMatch rule is an equality matching rule.
+
+
+5.2.21 telephoneNumberSubstringsMatch
+
+ The telephoneNumberSubstringsMatch rule compares an assertion value
+ of the Substring Assertion syntax to an attribute value of a syntax
+ (e.g the Telephone Number syntax) whose corresponding ASN.1 type is a
+ PrintableString representing a telephone number.
+
+ The rule evaluates to TRUE if and only if the substrings of the
+ assertion value match disjoint portions of the attribute value in the
+ order of the substrings in the assertion value, and an <initial>
+ substring, if present, matches the beginning of the attribute value,
+
+
+
+Legg & Dally Expires 27 August 2003 [Page 37]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+
+
+ and a <final> substring, if present, matches the end of the attribute
+ value. A substring matches a portion of the attribute value if
+ corresponding characters are the same, ignoring the case of letters,
+ and ignoring space and `-' characters.
+
+ The LDAP definition for the telephoneNumberSubstringsMatch matching
+ rule is:
+
+ ( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
+
+ The telephoneNumberSubstringsMatch rule is a substrings matching
+ rule.
+
+
+5.2.22 uniqueMemberMatch
+
+ The uniqueMemberMatch rule compares an assertion value of the Name
+ And Optional UID syntax to an attribute value of a syntax (e.g the
+ Name And Optional UID syntax) whose corresponding ASN.1 type is
+ NameAndOptionalUID.
+
+ The rule evaluates to TRUE if and only if the <distinguishedName>
+ components of the assertion value and attribute value match according
+ to the distinguishedNameMatch rule and the <BitString> component is
+ absent from the attribute value or matches the <BitString> component
+ of the assertion value according to the bitStringMatch rule.
+
+ The LDAP definition for the uniqueMemberMatch matching rule is:
+
+ ( 2.5.13.23 NAME 'uniqueMemberMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )
+
+ The uniqueMemberMatch rule is an equality matching rule.
+
+
+6. Security Considerations
+
+ In general, the LDAP-specific encodings for syntaxes defined in this
+ document do not define canonical encodings. That is, a
+ transformation from an LDAP-specific encoding into some other
+ encoding (e.g. BER) and back into the LDAP-specific encoding will not
+ necessarily reproduce exactly the original octets of the
+ LDAP-specific encoding. Therefore an LDAP-specific encoding should
+ not be used where a canonical encoding is required.
+
+ Furthermore, the LDAP-specific encodings do not necessarily enable an
+ alternative encoding of values of the Directory String and DN
+
+
+
+Legg & Dally Expires 27 August 2003 [Page 38]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+
+
+ syntaxes to be reconstructed, e.g. a transformation from DER to
+ LDAP-specific encoding and back to DER may not reproduce the original
+ DER encoding. Therefore LDAP-specific encodings should not be used
+ where reversibility to DER is needed, e.g. for the verification of
+ digital signatures. Instead, DER or a DER-reversible encoding should
+ be used.
+
+ When interpreting security-sensitive fields, and in particular fields
+ used to grant or deny access, implementations MUST ensure that any
+ matching rule comparisons are done on the underlying abstract value,
+ regardless of the particular encoding used.
+
+
+7. Acknowledgements
+
+ This document is an revision of RFC 2252 by M. Wahl, A. Coulbeck, T.
+ Howes, and S. Kille. RFC 2252 was a product of the IETF ASID Working
+ Group.
+
+ This document is based upon input of the IETF LDAPBIS working group.
+ The authors wish to thank J. Sermersheim and K. Zeilenga for their
+ significant contribution to this revision.
+
+
+8. IANA Considerations
+
+ The Internet Assigned Numbers Authority (IANA) is requested to update
+ the LDAP descriptors registry as indicated by the following
+ templates:
+
+ Subject: Request for LDAP Descriptor Registration Update
+ Descriptor (short name): see comment
+ Object Identifier: see comment
+ Person & email address to contact for further information:
+ Steven Legg <steven.legg@adacel.com.au>
+ Usage: see comment
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+ Comments:
+
+ The following descriptors (short names) should be updated to refer
+ to RFC XXXX.
+
+ NAME Type OID
+ ------------------------------------------------------------------
+ bitStringMatch M 2.5.13.16
+ caseExactIA5Match M 1.3.6.1.4.1.1466.109.114.1
+ caseIgnoreIA5Match M 1.3.6.1.4.1.1466.109.114.2
+
+
+
+Legg & Dally Expires 27 August 2003 [Page 39]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+
+
+ caseIgnoreListMatch M 2.5.13.11
+ caseIgnoreMatch M 2.5.13.2
+ caseIgnoreOrderingMatch M 2.5.13.3
+ caseIgnoreSubstringsMatch M 2.5.13.4
+ distinguishedNameMatch M 2.5.13.1
+ generalizedTimeMatch M 2.5.13.27
+ generalizedTimeOrderingMatch M 2.5.13.28
+ integerFirstComponentMatch M 2.5.13.29
+ integerMatch M 2.5.13.14
+ numericStringMatch M 2.5.13.8
+ numericStringSubstringsMatch M 2.5.13.10
+ objectIdentifierFirstComponentMatch M 2.5.13.31
+ octetStringMatch M 2.5.13.17
+ telephoneNumberMatch M 2.5.13.20
+ telephoneNumberSubstringsMatch M 2.5.13.21
+ uniqueMemberMatch M 2.5.13.23
+
+ The descriptor for the object identifier 2.5.13.0 was incorrectly
+ registered as objectIdentifiersMatch (extraneous `s') in RFC 3383.
+ It should be changed to the following with a reference to RFC
+ XXXX.
+
+ NAME Type OID
+ ------------------------------------------------------------------
+ objectIdentifierMatch M 2.5.13.0
+
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): caseIgnoreIA5SubstringsMatch
+ Object Identifier: 1.3.6.1.4.1.1466.109.114.3
+ Person & email address to contact for further information:
+ Steven Legg <steven.legg@adacel.com.au>
+ Usage: other (M)
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): caseIgnoreListSubstringsMatch
+ Object Identifier: 2.5.13.12
+ Person & email address to contact for further information:
+ Steven Legg <steven.legg@adacel.com.au>
+ Usage: other (M)
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+
+
+9. Normative References
+
+
+
+Legg & Dally Expires 27 August 2003 [Page 40]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+
+
+ [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 2279, January 1998.
+
+ [RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64, RFC
+ 3383, September 2002.
+
+ [LDAPDN] Zeilenga, K., "LDAP: String Representation of
+ Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work
+ in progress, August 2002.
+
+ [PROT] Sermersheim, J., "LDAP: The Protocol", draft-ietf-ldapbis-
+ protocol-xx.txt, a work in progress, December 2002.
+
+ [E.123] Notation for national and international telephone numbers,
+ ITU-T Recommendation E.123, 1988.
+
+ [FAX] Standardization of Group 3 facsimile apparatus for
+ document transmission - Terminal Equipment and Protocols
+ for Telematic Services, ITU-T Recommendation T.4, 1993
+
+ [T.50] International Reference Alphabet (IRA) (Formerly
+ International Alphabet No. 5 or IA5) Information
+ Technology - 7-Bit Coded Character Set for Information
+ Interchange, ITU-T Recommendation T.50, 1992
+
+ [X.420] ITU-T Recommendation X.420 (1996) | ISO/IEC 10021-7:1997,
+ Information Technology - Message Handling Systems (MHS):
+ Interpersonal messaging system
+
+ [X.501] ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994,
+ Information Technology - Open Systems Interconnection -
+ The Directory: Models
+
+ [X.520] ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994,
+ Information Technology - Open Systems Interconnection -
+ The Directory: Selected attribute types
+
+ [ASN.1] ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998
+ Information Technology - Abstract Syntax Notation One
+ (ASN.1): Specification of basic notation
+
+ [ISO3166] ISO 3166, "Codes for the representation of names of
+
+
+
+Legg & Dally Expires 27 August 2003 [Page 41]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+
+
+ countries".
+
+ [UCS] Universal Multiple-Octet Coded Character Set (UCS) -
+ Architecture and Basic Multilingual Plane, ISO/IEC
+ 10646-1: 1993 (with amendments).
+
+ [JPEG] JPEG File Interchange Format (Version 1.02). Eric
+ Hamilton, C-Cube Microsystems, Milpitas, CA, September 1,
+ 1992.
+
+
+10. Informative References
+
+ [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
+ "Lightweight Directory Access Protocol (v3): Attribute
+ Syntax Definitions", RFC 2252, December 1997.
+
+ [RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use
+ with LDAPv3", RFC 2256, December 1997.
+
+ [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
+
+ [X.500] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
+ Information Technology - Open Systems Interconnection -
+ The Directory: Overview of concepts, models and services
+
+ [BER] ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998
+ Information Technology - ASN.1 encoding rules:
+ Specification of Basic Encoding Rules (BER), Canonical
+ Encoding Rules (CER) and Distinguished Encoding Rules
+ (DER)
+
+
+11. Authors' Addresses
+
+ Steven Legg
+ Adacel Technologies Ltd.
+ 405-409 Ferntree Gully Road
+ Mount Waverley, Victoria 3149
+ AUSTRALIA
+
+ Phone: +61 3 9451 2107
+ Fax: +61 3 9541 2121
+ Email: steven.legg@adacel.com.au
+
+
+
+
+
+Legg & Dally Expires 27 August 2003 [Page 42]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+
+
+ Kathy Dally
+ The MITRE Corp.
+ 7515 Colshire Dr., ms-W650
+ McLean VA 22102
+ USA
+
+ Phone: +1 703 883 6058
+ Fax: +1 703 883 7142
+ Email: kdally@mitre.org
+
+
+12. Copyright Notice
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 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.
+
+
+Appendix A. Summary of Syntax Object Identifiers
+
+ The following list summarizes the object identifiers assigned to the
+ syntaxes defined in this document.
+
+ Syntax OBJECT IDENTIFIER
+ ==============================================================
+ Attribute Type Description 1.3.6.1.4.1.1466.115.121.1.3
+
+
+
+Legg & Dally Expires 27 August 2003 [Page 43]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+
+
+ Bit String 1.3.6.1.4.1.1466.115.121.1.6
+ Boolean 1.3.6.1.4.1.1466.115.121.1.7
+ Country String 1.3.6.1.4.1.1466.115.121.1.11
+ Delivery Method 1.3.6.1.4.1.1466.115.121.1.14
+ Directory String 1.3.6.1.4.1.1466.115.121.1.15
+ DIT Content Rule Description 1.3.6.1.4.1.1466.115.121.1.16
+ DIT Structure Rule Description 1.3.6.1.4.1.1466.115.121.1.17
+ DN 1.3.6.1.4.1.1466.115.121.1.12
+ Enhanced Guide 1.3.6.1.4.1.1466.115.121.1.21
+ Facsimile Telephone Number 1.3.6.1.4.1.1466.115.121.1.22
+ Fax 1.3.6.1.4.1.1466.115.121.1.23
+ Generalized Time 1.3.6.1.4.1.1466.115.121.1.24
+ Guide 1.3.6.1.4.1.1466.115.121.1.25
+ IA5 String 1.3.6.1.4.1.1466.115.121.1.26
+ Integer 1.3.6.1.4.1.1466.115.121.1.27
+ JPEG 1.3.6.1.4.1.1466.115.121.1.28
+ LDAP Syntax Description 1.3.6.1.4.1.1466.115.121.1.54
+ Matching Rule Description 1.3.6.1.4.1.1466.115.121.1.30
+ Matching Rule Use Description 1.3.6.1.4.1.1466.115.121.1.31
+ Name And Optional UID 1.3.6.1.4.1.1466.115.121.1.34
+ Name Form Description 1.3.6.1.4.1.1466.115.121.1.35
+ Numeric String 1.3.6.1.4.1.1466.115.121.1.36
+ Object Class Description 1.3.6.1.4.1.1466.115.121.1.37
+ Octet String 1.3.6.1.4.1.1466.115.121.1.40
+ OID 1.3.6.1.4.1.1466.115.121.1.38
+ Other Mailbox 1.3.6.1.4.1.1466.115.121.1.39
+ Postal Address 1.3.6.1.4.1.1466.115.121.1.41
+ Printable String 1.3.6.1.4.1.1466.115.121.1.44
+ Substring Assertion 1.3.6.1.4.1.1466.115.121.1.58
+ Telephone Number 1.3.6.1.4.1.1466.115.121.1.50
+ Teletex Terminal Identifier 1.3.6.1.4.1.1466.115.121.1.51
+ Telex Number 1.3.6.1.4.1.1466.115.121.1.52
+ UTC Time 1.3.6.1.4.1.1466.115.121.1.53
+
+
+Appendix B. Changes from RFC 2252 & RFC 2256
+
+ This annex lists the significant differences between this
+ specification and RFC 2252 and Sections 6 and 8 of RFC 2256.
+
+ This annex is provided for informational purposes only. It is not a
+ normative part of this specification.
+
+ 1. The IESG Note has been removed.
+
+ 2. The major part of Sections 4, 5 and 7 has been moved to [MODELS]
+ and revised. Changes to the parts of these sections moved to
+ [MODELS] are detailed in [MODELS].
+
+
+
+Legg & Dally Expires 27 August 2003 [Page 44]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+
+
+ 3. BNF descriptions of syntax formats have been replaced by ABNF
+ [ABNF] specifications.
+
+ 4. The ambiguous statement in RFC 2252, Section 4.3 regarding the
+ use of a backslash quoting mechanism to escape separator symbols
+ has been removed. The escaping mechanism is now explicitly
+ represented in the ABNF for the syntaxes where this provision
+ applies.
+
+ 5. The description of each of the LDAP syntaxes has been expanded so
+ that they are less dependent on knowledge of X.500 for
+ interpretation.
+
+ 6. The relationship of LDAP syntaxes to corresponding ASN.1 type
+ definitions has been made explicit.
+
+ 7. The set of characters allowed in a <PrintableString> (formerly
+ <printablestring>) has been corrected to align with the
+ PrintableString ASN.1 type in [ASN.1]. Specifically, the double
+ quote character has been removed and the single quote character
+ and equals sign have been added.
+
+ 8. Values of the Directory String, Printable String and Telephone
+ Number syntaxes are now required to have at least one character.
+
+ 9. The <DITContentRuleDescription>, <NameFormDescription> and
+ <DITStructureRuleDescription> rules have been moved to [MODELS].
+
+ 10. The corresponding ASN.1 type for the Other Mailbox syntax has
+ been incorporated from RFC 1274.
+
+ 11. A corresponding ASN.1 type for the LDAP Syntax Description syntax
+ has been invented.
+
+ 12. The Binary syntax has been removed because it was not adequately
+ specified, implementations with different incompatible
+ interpretations exist, and it was confused with the ;binary
+ transfer encoding.
+
+ 13. All discussion of transfer options, including the ";binary"
+ option, has been removed. All imperatives regarding binary
+ transfer of values have been removed.
+
+ 14. The Delivery Method, Enhanced Guide, Guide, Octet String, Teletex
+ Terminal Identifier and Telex Number syntaxes from RFC 2256 have
+ been incorporated.
+
+ 15. The <criteria> rule for the Enhanced Guide and Guide syntaxes has
+
+
+
+Legg & Dally Expires 27 August 2003 [Page 45]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+
+
+ been extended to accommodate empty "and" and "or" expressions.
+
+ 16. An encoding for the <ttx-value> rule in the Teletex Terminal
+ Identifier syntax has been defined.
+
+ 17. The PKI-related syntaxes (Certificate, Certificate List and
+ Certificate Pair from RFC 2252, and Supported Algorithm syntax
+ from RFC 2256) have been removed. They are to be reintroduced in
+ PKIX documents.
+
+ 18. The MHS OR Address syntax has been removed since its
+ specification (in RFC 2156) is not at draft standard maturity.
+
+ 19. The DL Submit Permission syntax has been removed as it depends on
+ the MHS OR Address syntax.
+
+ 20. The Presentation Address syntax has been removed since its
+ specification (in RFC 1278) is not at draft standard maturity.
+
+ 21. The ACI Item, Access Point, Audio, Data Quality, DSA Quality, DSE
+ Type, LDAP Schema Description, Master And Shadow Access Points,
+ Modify Rights, Protocol Information, Subtree Specification,
+ Supplier Information, Supplier Or Consumer and Supplier And
+ Consumer syntaxes have been removed. These syntaxes are
+ referenced in RFC 2252, but not defined.
+
+ 22. The LDAP Schema Definition syntax (defined in RFC 2927) and the
+ Mail Preference syntax have been removed on the grounds that they
+ are out of scope for a core specification.
+
+ 23. The description of each of the matching rules has been expanded
+ so that they are less dependent on knowledge of X.500 for
+ interpretation.
+
+ 24. The caseIgnoreIA5SubstringsMatch matching rule from RFC 2798 has
+ been added.
+
+ 25. The caseIgnoreIA5SubstringsMatch, caseIgnoreListSubstringsMatch,
+ caseIgnoreOrderingMatch and caseIgnoreSubstringsMatch matching
+ rules have been added to the list of matching rules for which the
+ provisions for handling leading, trailing and multiple adjoining
+ whitespace characters apply. This is consistent with the
+ definitions of these matching rules in X.500. The
+ telephoneNumberMatch rule has been removed from the list since it
+ completely ignores all space characters.
+
+ 26. The specification of the octetStringMatch matching rule from RFC
+ 2256 has been added to this document.
+
+
+
+Legg & Dally Expires 27 August 2003 [Page 46]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules February 27, 2003
+
+
+ 27. The presentationAddressMatch matching rule has been removed as it
+ depends on an assertion syntax (Presentation Address) that is not
+ at draft standard maturity.
+
+ 28. The protocolInformationMatch matching rule has been removed as it
+ depends on an undefined assertion syntax (Protocol Information).
+
+ 29. The definitive reference for ASN.1 has been changed from X.208 to
+ X.680 since X.680 is the version of ASN.1 referred to by X.500.
+
+ 30. The specification of the caseIgnoreListSubstringsMatch matching
+ rule from RFC 2798 & X.520 has been added to this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Legg & Dally Expires 27 August 2003 [Page 47]
+\f
--- /dev/null
+
+
+
+
+
+
+Network Working Group Mark Smith, Editor
+Request for Comments: DRAFT Netscape Communications Corp.
+Obsoletes: RFC 2255 Tim Howes
+Expires: 28 August 2003 Opsware, Inc.
+
+ 28 February 2003
+
+
+ LDAP: Uniform Resource Locator
+ <draft-ietf-ldapbis-url-03.txt>
+
+
+
+1. Status of this Memo
+
+ This document is an Internet-Draft and is subject to all provisions
+ of Section 10 of RFC2026.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet- Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/1id-abstracts.html
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html
+
+ Discussion of this document should take place on the LDAP (v3)
+ Revision (ldapbis) Working Group mailing list <ietf-
+ ldapbis@openldap.org>.
+
+Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+2. Abstract
+
+ This document describes a format for an LDAP Uniform Resource Locator
+ (URL). An LDAP URL describes an LDAP search operation that is used
+ to retrieve information from an LDAP directory, or, in the context of
+ an LDAPv3 referral or reference, an LDAP URL describes a service
+ where an LDAP operation may be progressed.
+
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 1]
+\f
+INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
+
+
+3. Table of Contents
+
+1. Status of this Memo............................................1
+2. Abstract.......................................................1
+3. Table of Contents..............................................2
+4. Introduction...................................................2
+5. URL Definition.................................................2
+6. Defaults for Fields of the LDAP URL............................5
+7. Examples.......................................................5
+8. Security Considerations........................................7
+9. Acknowledgements...............................................8
+10. Normative References...........................................9
+11. Informative References.........................................9
+12. Authors' Address...............................................9
+13. Full Copyright Statement.......................................10
+14. Appendix A: Changes Since RFC 2255.............................10
+14.1. Technical Changes...........................................10
+14.2. Editorial Changes...........................................11
+15. Appendix B: Changes Since Previous Document Revision...........13
+15.1. Technical Changes...........................................13
+15.2. Editorial Changes...........................................13
+
+4. Introduction
+
+ LDAP is the Lightweight Directory Access Protocol, defined in
+ [Protocol]. This document specifies the LDAP URL format for version
+ 3 of LDAP and clarifies how LDAP URLs are resolved. This document
+ also defines an extension mechanism for LDAP URLs, so that future
+ documents can extend their functionality, for example, to provide
+ access to new LDAPv3 extensions as they are defined. Note: not all
+ of the parameters of the LDAP search operation described in
+ [Protocol] can be expressed using the format defined in this
+ document.
+
+ This document is an integral part of the LDAP Technical Specification
+ [Roadmap].
+
+ This document replaces RFC 2255. See Appendix A for a list of changes
+ relative to RFC 2255.
+
+ The key words "MUST", "MAY", and "SHOULD" used in this document are
+ to be interpreted as described in [RFC2119].
+
+5. URL Definition
+
+ An LDAP URL begins with the protocol prefix "ldap" and is defined by
+ the following grammar, following the ABNF notation defined in
+ [RFC2234].
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 2]
+\f
+INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
+
+
+ ldapurl = scheme COLON SLASH SLASH [hostport] [SLASH dn
+ [QUESTION [attributes] [QUESTION [scope]
+ [QUESTION [filter] [QUESTION extensions]]]]]
+ scheme = "ldap"
+ hostport = <hostport from Section 3.2.2 of [RFC2396]>
+ ; as updated by [RFC2732] to allow IPv6 literal addresses
+ dn = <distinguishedName from Section 3 of [LDAPDN]>
+ attributes = attrdesc *(COMMA attrdesc)
+ attrdesc = <AttributeDescription from Section 4.1.4 of [Protocol]>
+ / ASTERIX
+ scope = "base" / "one" / "sub"
+ filter = <filter from Section 4 of [Filters]>
+ extensions = extension *(COMMA extension)
+ extension = [EXCLAMATION] extype [EQUALS exvalue]
+ extype = oid / oiddescr
+ exvalue = <LDAPString from section 4.1.2 of [Protocol]>
+ oid = <LDAPOID from section 4.1.2 of [Protocol]>
+ oiddescr = <name from section 3.3 of [LDAPIANA]>
+
+ EXCLAMATION = %x21 ; exclamation mark ("!")
+ ASTERIX = %x2A ; asterix ("*")
+ COLON = %x3A ; colon (":")
+ QUESTION = %x3F ; question mark ("?")
+ SLASH = %x5C; forward slash ("/")
+
+
+ The "ldap" prefix indicates an entry or entries residing in the LDAP
+ server running on the given hostname at the given portnumber. Note
+ that the hostport may contain literal IPv6 addresses as specified in
+ [RFC2732].
+
+ The dn is an LDAP Distinguished Name using the string format
+ described in [LDAPDN]. It identifies the base object of the LDAP
+ search or the target of a non-search operation.
+
+ The attributes construct is used to indicate which attributes should
+ be returned from the entry or entries. Individual attrdesc names are
+ as defined for AttributeDescription in [Protocol].
+
+ The scope construct is used to specify the scope of the search to
+ perform in the given LDAP server. The allowable scopes are "base"
+ for a base object search, "one" for a one-level search, or "sub" for
+ a subtree search.
+
+ The filter is used to specify the search filter to apply to entries
+ within the specified scope during the search. It has the format
+ specified in [Filters].
+
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 3]
+\f
+INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
+
+
+ The extensions construct provides the LDAP URL with an extensibility
+ mechanism, allowing the capabilities of the URL to be extended in the
+ future. Extensions are a simple comma-separated list of type=value
+ pairs, where the =value portion MAY be omitted for options not
+ requiring it. Each type=value pair is a separate extension. These
+ LDAP URL extensions are not necessarily related to any of the LDAPv3
+ extension mechanisms. Extensions may be supported or unsupported by
+ the client resolving the URL. An extension prefixed with a '!'
+ character (ASCII 33) is critical. An extension not prefixed with a
+ '!' character is non-critical.
+
+ If an extension is supported by the client, the client MUST obey the
+ extension if the extension is critical. The client SHOULD obey
+ supported extensions that are non-critical.
+
+ If an extension is unsupported by the client, the client MUST NOT
+ process the URL if the extension is critical. If an unsupported
+ extension is non-critical, the client MUST ignore the extension.
+
+ If a critical extension cannot be processed successfully by the
+ client, the client MUST NOT process the URL. If a non-critical
+ extension cannot be processed successfully by the client, the client
+ SHOULD ignore the extension.
+
+ The extension type (extype) MAY be specified using the oid form
+ (e.g., 1.2.3.4) or the oiddesc form (e.g., myLDAPURLExtension). Use
+ of the oiddesc form SHOULD be restricted to registered object
+ identifier descriptive names. See [LDAPIANA] for registration
+ details and usage guidelines for descriptive names.
+
+ No LDAP URL extensions are defined in this document. Other documents
+ or a future version of this document MAY define one or more
+ extensions.
+
+ A generated LDAP URL MUST consist only of the restricted set of
+ characters included in the uric production that is defined in section
+ 2 of [RFC2396]. Implementations SHOULD accept other valid UTF-8
+ strings as input. An octet MUST be escaped using the % method
+ described in section 2.4 of [RFC2396] in any of these situations:
+
+ The octet is not in the reserved set defined in section 2.2 of
+ [RFC2396] or in the unreserved set defined in section 2.3 of
+ [RFC2396].
+
+ It is the single Reserved character '?' and occurs inside a dn,
+ filter, or other element of an LDAP URL.
+
+ It is a comma character ',' that occurs inside an extension value.
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 4]
+\f
+INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
+
+
+6. Defaults for Fields of the LDAP URL
+
+ Some fields of the LDAP URL are optional, as described above. In the
+ absence of any other specification, the following general defaults
+ SHOULD be used when a field is absent. Note: other documents MAY
+ specify different defaulting rules; for example, section 4.1.11 of
+ [Protocol] specifies a different rule for determining the correct DN
+ to use when it is absent in an LDAP URL that is returned as a
+ referral.
+
+ hostport
+ The default LDAP port is TCP port 389. If no hostport is given,
+ the client must have some apriori knowledge of an appropriate LDAP
+ server to contact.
+
+ dn
+ If no dn is given, the default is the zero-length DN, "".
+
+ attributes
+ If the attributes part is omitted, all user attributes of the
+ entry or entries should be requested (e.g., by setting the
+ attributes field AttributeDescriptionList in the LDAP search
+ request to a NULL list, or (in LDAPv3) by requesting the special
+ attribute name "*").
+
+ scope
+ If scope is omitted, a scope of "base" is assumed.
+
+ filter
+ If filter is omitted, a filter of "(objectClass=*)" is assumed.
+
+ extensions
+ If extensions is omitted, no extensions are assumed.
+
+
+7. Examples
+
+ The following are some example LDAP URLs using the format defined
+ above. The first example is an LDAP URL referring to the University
+ of Michigan entry, available from an LDAP server of the client's
+ choosing:
+
+ ldap:///o=University%20of%20Michigan,c=US
+
+ The next example is an LDAP URL referring to the University of
+ Michigan entry in a particular ldap server:
+
+ ldap://ldap1.example.net/o=University%20of%20Michigan,c=US
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 5]
+\f
+INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
+
+
+ Both of these URLs correspond to a base object search of the
+ "o=University of Michigan,c=US" entry using a filter of
+ "(objectclass=*)", requesting all attributes.
+
+ The next example is an LDAP URL referring to only the postalAddress
+ attribute of the University of Michigan entry:
+
+ ldap://ldap1.example.net/o=University%20of%20Michigan,
+ c=US?postalAddress
+
+ The corresponding LDAP search operation is the same as in the
+ previous example, except that only the postalAddress attribute is
+ requested.
+
+ The next example is an LDAP URL referring to the set of entries found
+ by querying the given LDAP server on port 6666 and doing a subtree
+ search of the University of Michigan for any entry with a common name
+ of "Babs Jensen", retrieving all attributes:
+
+ ldap://ldap1.example.net:6666/o=University%20of%20Michigan,
+ c=US??sub?(cn=Babs%20Jensen)
+
+ The next example is an LDAP URL referring to all children of the c=GB
+ entry:
+
+ ldap://ldap1.example.com/c=GB?objectClass?one
+
+ The objectClass attribute is requested to be returned along with the
+ entries, and the default filter of "(objectclass=*)" is used.
+
+ The next example is an LDAP URL to retrieve the mail attribute for
+ the LDAP entry named "o=Question?,c=US" is given below, illustrating
+ the use of the escaping mechanism on the reserved character '?'.
+
+ ldap://ldap2.example.com/o=Question%3f,c=US?mail
+
+ The next example illustrates the interaction between the LDAP string
+ representation of filters quoting mechanism and URL quoting
+ mechanisms.
+
+ ldap://ldap3.example.com/o=Babsco,c=US???(int=%5c00%5c00%5c00%5c04)
+
+ The filter in this example uses the LDAP escaping mechanism of \ to
+ encode three zero or null bytes in the value. In LDAP, the filter
+ would be written as (int=\00\00\00\04). Because the \ character must
+ be escaped in a URL, the \'s are escaped as %5c in the URL encoding.
+
+ The next example illustrates the interaction between the LDAP string
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 6]
+\f
+INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
+
+
+ representation of DNs quoting mechanism and URL quoting mechanisms.
+
+ ldap://ldap.example.com/o=An%20Example%5c2c%20Inc.,c=US
+
+ The DN encoded in the above URL is:
+
+ o=An Example\2c Inc.,c=US
+
+ That is, the left-most RDN value is:
+
+ An Example, Inc.
+
+ The following three URLs that are equivalent, assuming that the
+ defaulting rules specified in section 4 of this document are used:
+
+ ldap://ldap.example.net
+ ldap://ldap.example.net/
+ ldap://ldap.example.net/?
+
+ These three URLs all point to the root DSE on the ldap.example.net
+ server.
+
+The final two examples show use of a hypothetical, experimental bind
+name extension (the value associated with the extension is an LDAP DN).
+
+ ldap:///??sub??e-bindname=cn=Manager%2cdc=example%2cdc=com
+ ldap:///??sub??!e-bindname=cn=Manager%2cdc=example%2cdc=com
+
+ The two URLs are the same, except that the second one marks the e-
+ bindname extension as critical. Notice the use of the % encoding
+ method to encode the commas within the distinguished name value in
+ the e-bindname extension.
+
+
+8. Security Considerations
+
+ General URL security considerations discussed in [RFC2396] are
+ relevant for LDAP URLs.
+
+ The use of security mechanisms when processing LDAP URLs requires
+ particular care, since clients may encounter many different servers
+ via URLs, and since URLs are likely to be processed automatically,
+ without user intervention. A client SHOULD have a user-configurable
+ policy about which servers to connect to using which security
+ mechanisms, and SHOULD NOT make connections that are inconsistent
+ with this policy. If a client chooses to reuse an existing
+ connection when resolving one or more LDAP URL, it MUST ensure that
+ the connection is compatible with the URL and that no security
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 7]
+\f
+INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
+
+
+ policies are violated.
+
+ Sending authentication information, no matter the mechanism, may
+ violate a user's privacy requirements. In the absence of specific
+ policy permitting authentication information to be sent to a server,
+ a client should use an anonymous connection. (Note that clients
+ conforming to previous LDAP URL specifications, where all connections
+ are anonymous and unprotected, are consistent with this
+ specification; they simply have the default security policy.) Simply
+ opening a connection to another server may violate some users'
+ privacy requirements, so clients should provide the user with a way
+ to control URL processing.
+
+ Some authentication methods, in particular reusable passwords sent to
+ the server, may reveal easily-abused information to the remote server
+ or to eavesdroppers in transit, and should not be used in URL
+ processing unless explicitly permitted by policy. Confirmation by
+ the human user of the use of authentication information is
+ appropriate in many circumstances. Use of strong authentication
+ methods that do not reveal sensitive information is much preferred.
+ If the URL represents a referral for an update operation, strong
+ authentication methods SHOULD be used. Please refer to the Security
+ Considerations section of [AuthMeth] for more information.
+
+ The LDAP URL format allows the specification of an arbitrary LDAP
+ search operation to be performed when evaluating the LDAP URL.
+ Following an LDAP URL may cause unexpected results, for example, the
+ retrieval of large amounts of data, the initiation of a long-lived
+ search, etc. The security implications of resolving an LDAP URL are
+ the same as those of resolving an LDAP search query.
+
+9. Acknowledgements
+
+ The LDAP URL format was originally defined at the University of
+ Michigan. This material is based upon work supported by the National
+ Science Foundation under Grant No. NCR-9416667. The support of both
+ the University of Michigan and the National Science Foundation is
+ gratefully acknowledged.
+
+ This document is an update to RFC 2255 by Tim Howes and Mark Smith.
+ Changes included in this revised specification are based upon
+ discussions among the authors, discussions within the LDAP (v3)
+ Revision Working Group (ldapbis), and discussions within other IETF
+ Working Groups. The contributions of individuals in these working
+ groups is gratefully acknowledged. Several people in particular have
+ made valuable comments on this document; RL "Bob" Morgan, Mark Wahl,
+ Kurt Zeilenga, Jim Sermersheim, and Hallvard Furuseth deserve special
+ thanks for their contributions.
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 8]
+\f
+INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
+
+
+10. Normative References
+
+ [LDAPDN] Zeilenga, K. (editor), "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-iana-xx.txt, a work in progress.
+
+ [Filters] Smith, M. and Howes, T., "LDAP: String Representation of
+ Search Filters", draft-ietf-ldapbis-filter-xx.txt, a work in
+ progress. [RFC2119] Bradner, S., "Key Words for use in RFCs to
+ Indicate Requirement Levels," RFC 2119, BCP 14, March 1997.
+
+ [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol", draft-
+ ietf-ldapbis-protocol-xx.txt, a work in progress.
+
+ [RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
+ RFC 2279, January 1998.
+
+ [RFC2396] Berners-Lee, T., Fielding, R., and Masinter, L., "Uniform
+ Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
+
+ [RFC2732] Hinden, R., Carpenter, B., Masinter, L., "Format for
+ Literal IPv6 Addresses in URL's", RFC 2732, December 1999.
+
+ [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods",
+ draft-ietf-ldapbis-authmeth-xx.txt, a work in progress. a work in
+ progress.
+
+ [Roadmap] K. Zeilenga (editor), "LDAP: Technical Specification Road
+ Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in progress.
+
+11. Informative References
+
+ None.
+
+12. Authors' Address
+
+ Mark Smith, Editor
+ Netscape Communications Corp.
+ 360 W. Caribbean Drive
+ Sunnyvale, CA 94089
+ USA
+ +1 650 937-3477
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 9]
+\f
+INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
+
+
+ mcs@netscape.com
+
+ Tim Howes
+ Opsware, Inc.
+ 599 N. Mathilda Ave.
+ Sunnyvale, CA 94085
+ USA
+ +1 408 744-7509
+ howes@opsware.com
+
+13. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 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.
+
+
+14. Appendix A: Changes Since RFC 2255
+
+14.1. Technical Changes
+
+ The following technical changes were made to the contents of the "URL
+ Definition" section:
+
+ Revised all of the ABNF to use common productions from [Models].
+
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 10]
+\f
+INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
+
+
+ Added note and references to [RFC2732] to allow literal IPv6
+ addresses inside the hostport portion of the URL.
+
+ Added missing ASTERIX as an alternative for the attrdesc part of the
+ URL. It is believed that existing implementations of RFC 2255
+ already support this.
+
+ Added angle brackets around free-form prose in the "dn", "hostport",
+ "attrdesc", "filter", and "exvalue" rules.
+
+ Changed the ABNF for ldapurl to group the dn component with the
+ preceding slash.
+
+ Changed the extype rule to be an LDAPOID from [Protocol] or an OID
+ description from [LDAPIANA].
+
+ Changed the text about extension types so it references [LDAPIANA].
+ Reordered rules to more closely follow the order the elements appear
+ in the URL.
+
+ "Bindname Extension": removed due to lack of known implementations.
+
+
+14.2. Editorial Changes
+
+ Changed document title to include "LDAP:" prefix.
+
+ IESG Note: removed note about lack of satisfactory mandatory
+ authentication mechanisms.
+
+ "Status of this Memo" section: updated boilerplate to match current
+ I-D guidelines.
+
+ "Abstract" section: separated from introductory material.
+
+ "Table of Contents" section: added.
+
+ "Introduction" section: new section; separated from the Abstract.
+ Changed the text indicate that RFC 2255 is replaced by this document
+ (instead of RFC 1959). Added text to indicate that LDAP URLs are
+ used for references and referrals. Fixed typo (replaced the nonsense
+ phrase "to perform to retrieve" with "used to retrieve"). Added a
+ note to let the reader know that not all of the parameters of the
+ LDAP search operation described in [Protocol] can be expressed using
+ this format.
+
+ "URL Definition" section: removed second copy of ldapurl grammar and
+ following two paragraphs (editorial error in RFC 2255). Fixed line
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 11]
+\f
+INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
+
+
+ break within '!' sequence. Reworded last paragraph to clarify which
+ characters must be URL escaped. Added text to indicate that LDAP
+ URLs are used for references and referrals. Added text that refers
+ to the ABNF from RFC 2234.
+
+ "Defaults for Fields of the LDAP URL" section: added; formed by
+ moving text about defaults out of the "URL Definition" section.
+
+ "URL Processing" section: clarified that connections MAY be reused
+ only if the open connection is compatible with the URL. Added text
+ to indicate that use of security services is encouraged and that they
+ SHOULD be used when updates are involved. Removed "dn" from
+ discussion of authentication methods. Added note that the client MAY
+ interrogate the server to determine the most appropriate method.
+
+ "Examples" section: Modified examples to use example.com and
+ example.net hostnames. Added missing '?' to the LDAP URL example
+ whose filter contains three null bytes. Removed space after one
+ comma within a DN. Revised the bindname example to use e-bindname.
+ Added an example that demonstrates the interaction between DN
+ escaping and URL escaping. Added some examples to show URL
+ equivalence with respect to the dn portion of the URL.
+
+ "Security Considerations" section: Added a note about connection
+ reuse. Added a note about using strong authentication methods for
+ updates. Added a reference to RFC 2829. Added note that simply
+ opening a connection may violate some users' privacy requirements.
+
+ "Acknowledgements" section: added statement about this being an
+ update to RFC 2255. Added Kurt Zeilenga, Jim Sermersheim, and
+ Hallvard Furuseth.
+
+ "Normative References" section: renamed from "References" per new RFC
+ guidelines. Changed from [1] style to [Protocol] style throughout the
+ document. Added references to RFCs 2234 and 2829. Updated RFC 1738
+ references to the appropriate sections within RFC 2396. Updated the
+ references to refer to LDAPBis WG documents. Removed the reference to
+ the LDAP Attribute Syntaxes document and added references to the LDAP
+ IANA and Roadmap documents.
+
+ "Informative References" section: added for clarity.
+
+ Header and "Authors' Address" sections: added "editor" next to Mark
+ Smith's name. Updated affiliation and contact information.
+
+ Copyright: updated the year.
+
+
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 12]
+\f
+INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
+
+
+15. Appendix B: Changes Since Previous Document Revision
+
+ This appendix lists all changes relative to the last published
+ revision, draft-ietf-ldapbis-url-02.txt. Note that when appropriate
+ these changes are also included in Appendix A, but are also included
+ here for the benefit of the people who have already reviewed draft-
+ ietf-ldapbis-url-02.txt. This section will be removed before this
+ document is published as an RFC.
+
+
+15.1. Technical Changes
+
+ "URL Definition" section: revised all of the ABNF to use common
+ productions from [Models] and added note and references to [RFC2732]
+ to allow literal IPv6 addresses inside the hostport portion of the
+ URL.
+
+
+15.2. Editorial Changes
+
+ "Status of this Memo" section: updated boilerplate to match current
+ I-D guidelines.
+
+ "URL Definition" section: replaced misleading phrase "MAY define
+ other extensions" with "MAY define one or more extensions" (this
+ document no longer defines any extensions). Rewrote the last
+ paragraph of this section to more clearly describe the escaping rules
+ and to reference [RFC2396] accurately.
+
+ "Examples" section: added an example that demonstrates the
+ interaction between DN escaping and URL escaping and clarified the
+ text that introduces the LDAP filter escaping interaction example.
+
+ "Acknowledgements" section: added Hallvard Furuseth.
+
+ "Normative References" section: added a reference to [RFC2732].
+
+ "Informative References" section: added for clarity.
+
+ Copyright: updated the year to 2003.
+
+ "Authors' Address" section: updated Tim's contact information.
+
+ Appendix A: added an older editorial change that was accidently
+ overlooked (Changed document title to include "LDAP:" prefix).
+
+
+This Internet Draft expires on 28 August 2003.
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 13]
+\f
--- /dev/null
+INTERNET-DRAFT K. Dally, Editor
+Intended Category: Standard Track The MITRE Corp.
+Expires: October 2003 April 2003
+Updates: RFC 2247
+Obsoletes: RFC 2256
+
+
+ LDAP: User Schema
+ <draft-ietf-ldapbis-user-schema-05>
+
+
+Status of this Memo
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC 2026.
+
+ 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 Revision Working
+ Group (LDAPbis) mailing list <ietf-ldapbis@openldap.org>. Please
+ send editorial comments directly to the author <kdally@mitre.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 Notice
+
+ Copyright 2003, The Internet Society. All Rights Reserved.
+
+
+Abstract
+
+ This document is a integral part of the LDAP technical specification
+ [ROADMAP]. It provides an overview of attribute types and object
+ classes intended for use by LDAP directory clients for many
+ directory services, such as, White Pages. Originally specified the
+ ISO/IEC 9594 and X.500 documents, these objects are widely used as a
+ basis for the schema in many LDAP directories. This document does
+ not cover attributes used for the administration of directory
+ servers, nor does it include directory objects defined for specific
+ uses in other documents.
+
+
+Dally Expires October 2003 [Page 1]
+INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
+
+
+ Table of Contents
+
+Status of this Memo 1
+
+Copyright Notice 1
+
+Abstract 1
+
+Table of Contents 2
+
+1. Introduction 4
+ 1.1 Situation 4
+ 1.2 Conventions 4
+ 1.3 General Issues 4
+ 1.4 Source 5
+
+2. Attribute Types 5
+ 2.1 businessCategory 5
+ 2.2 c 5
+ 2.3 cn 6
+ 2.4 dc 6
+ 2.5 description 6
+ 2.6 destinationIndicator 6
+ 2.7 distinguishedName 7
+ 2.8 dnQualifier 7
+ 2.9 enhancedSearchGuide 7
+ 2.10 facsimileTelephoneNumber 7
+ 2.11 generationQualifier 8
+ 2.12 givenName 8
+ 2.13 houseIdentifier 8
+ 2.14 initials 8
+ 2.15 internationalISDNNumber 8
+ 2.16 l 9
+ 2.17 member 9
+ 2.18 name 9
+ 2.19 o 9
+ 2.20 ou 9
+ 2.21 owner 10
+ 2.22 physicalDeliveryOfficeName 10
+ 2.23 postalAddress 10
+ 2.24 postalCode 10
+ 2.25 postOfficeBox 10
+ 2.26 preferredDeliveryMethod 11
+ 2.27 registeredAddress 11
+ 2.28 roleOccupant 11
+ 2.29 searchGuide 11
+ 2.30 seeAlso 12
+ 2.31 serialNumber 12
+ 2.32 sn 12
+ 2.33 st 12
+ 2.34 street 12
+ 2.35 telephoneNumber 12
+
+
+Dally Expires October 2003 [Page 2]
+INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
+
+
+ 2.36 teletexTerminalIdentifier 13
+ 2.37 telexNumber 13
+ 2.38 title 13
+ 2.39 uniqueMember 13
+ 2.40 userPassword 14
+ 2.41 x121Address 14
+ 2.42 x500UniqueIdentifier 14
+
+3. Object Classes 15
+ 3.1 applicationProcess 15
+ 3.2 country 15
+ 3.3 device 15
+ 3.4 domain 15
+ 3.5 groupOfNames 16
+ 3.6 groupOfUniqueNames 16
+ 3.7 locality 17
+ 3.8 organization 17
+ 3.9 organizationalPerson 17
+ 3.10 organizationalRole 18
+ 3.11 organizationalUnit 18
+ 3.12 person 18
+ 3.13 residentialPerson 19
+
+4. IANA Considerations 19
+
+5. Security Considerations 19
+
+6. Acknowledgements 19
+
+7. References 20
+ 7.1 Normative 20
+ 7.2 Informative 20
+
+8. Author's Address 21
+
+9. Full Copyright Statement 21
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dally Expires October 2003 [Page 3]
+INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2002
+
+
+1. Introduction
+
+ This document provides an overview of attribute types and object
+ classes intended for use by LDAP directory clients for many
+ directory services, such as, White Pages. Originally specified in
+ the ISO/IEC 9594 and X.500 documents, these objects are widely used
+ as a basis for the schema in many LDAP directories. This document
+ does not cover attributes used for the administration of directory
+ servers, nor does it include directory objects defined for specific
+ uses in other documents.
+
+1.1 Situation
+
+ This document is a integral part of the LDAP technical specification
+ [ROADMAP] which obsoletes the previously defined LDAP technical
+ specification [RFC3377] in its entirety. In terms of RFC 2256,
+ Sections 6 and 8 of RFC 2256 are obsoleted by [Syntaxes].
+ Sections 5.1, 5.2, 7.1 and 7.2 of RFC 2256 are obsoleted by [Models].
+ The remainder of RFC 2256 is obsoleted by this document. Sections
+ 3.4 and 4.4 of this document supercede the technical specifications
+ for the 'dc' attribute type and 'domain' object class found in
+ RFC 2247. The remainder of RFC 2247 remains in force.
+
+ A number of schema elements which were included in the previous
+ revision of the LDAP Technical Specification are not included in this
+ revision of LDAP. PKI-related schema elements are now specified in
+ [LDAP-PKI]. Unless reintroduced in future technical specifications,
+ the remainder are to be considered Historic.
+
+1.2 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 RFC 2119 [RFC2119].
+
+1.3 General Issues
+
+ This document references Syntaxes given in Section 3 of [Syntaxes]
+ and Matching Rules specified in Section 4 of [Syntaxes].
+
+ The definitions of Attribute Types and Object Classes are written
+ using the ABNF form of AttributeTypeDescription and
+ ObjectClassDescription given in [Models]. Lines have been folded
+ for readability.
+
+
+
+
+
+
+
+
+
+
+Dally Expires October 2003 [Page 4]
+INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
+
+
+1.4 Source
+
+ The schema definitions in this document are based on those found in
+ the X.500-series [X.520] and [X.521] and RFC 2247 [RFC2247],
+ specifically:
+
+ Sections Source
+ ============ ==================
+ 2.1 - 2.3 X.520 [X.520]
+ 2.4 RFC 2247 [RFC2247]
+ 2.5 - 2.42 X.520 [X.520]
+ 3.1 - 3.3 X.521 [X.521]
+ 3.4 RFC 2247 [RFC2247]
+ 3.5 - 3.13 X.521 [X.521]
+
+
+2. Attribute Types
+
+ The Attribute Types contained in this section hold user information.
+
+ There is no requirement that servers implement the following
+ Attribute Types:
+
+ searchGuide
+ teletexTerminalIdentifier
+
+ In fact, their use is greatly discouraged.
+
+ An LDAP server implementation SHOULD recognize the rest of the
+ Attribute Types described in this section.
+
+2.1 businessCategory
+
+ This Attribute Type describes the kind of business performed by
+ an organization.
+
+ ( 2.5.4.15 NAME 'businessCategory'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
+
+ The SYNTAX oid indicates the Directory String syntax.
+
+2.2 c
+
+ This is the X.520 [X.520] countryName Attribute Type, which contains
+ a two-letter ISO 3166 [ISO3166]country code.
+
+ ( 2.5.4.6 NAME 'c'
+ SUP name
+ SINGLE-VALUE )
+
+
+
+Dally Expires October 2003 [Page 5]
+INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
+
+
+2.3 cn
+
+ This is the X.520 [X.520] commonName Attribute Type, which contains
+ a name of an object. If the object corresponds to a person, it is
+ typically the person's full name.
+
+ ( 2.5.4.3 NAME 'cn'
+ SUP name )
+
+2.4 dc
+
+ The dc (short for domainComponent) attribute type is defined as
+ follows:
+
+ ( 0.9.2342.19200300.100.1.25 NAME 'dc'
+ EQUALITY caseIgnoreIA5Match
+ SUBSTR caseIgnoreIA5SubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
+ SINGLE-VALUE )
+
+ The value of this attribute is a string holding one component of a
+ DNS domain name. The encoding of IA5String for use in LDAP is simply
+ the characters of the string itself. The equality matching rule is
+ case insensitive, as is today's DNS.
+
+2.5 description
+
+ This Attribute Type contains a human-readable description of
+ the object.
+
+ ( 2.5.4.13 NAME 'description'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} )
+
+ The SYNTAX oid indicates the Directory String syntax.
+
+2.6 destinationIndicator
+
+ This attribute is used for the telegram service.
+
+ ( 2.5.4.27 NAME 'destinationIndicator'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{128} )
+
+ The SYNTAX oid indicates the Printable String syntax.
+
+
+
+
+
+
+
+Dally Expires October 2003 [Page 6]
+INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
+
+
+2.7 distinguishedName
+
+ This Attribute Type is not used as the name of the object itself,
+ but it is instead a base type from which attributes with DN syntax
+ inherit.
+
+ It is unlikely that values of this type itself will occur in an
+ entry. LDAP server implementations which do not support attribute
+ subtyping need not recognize this attribute in requests. Client
+ implementations MUST NOT assume that LDAP servers are capable of
+ performing attribute subtyping.
+
+ ( 2.5.4.49 NAME 'distinguishedName'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+ The SYNTAX oid indicates the DN syntax.
+
+2.8 dnQualifier
+
+ The dnQualifier Attribute Type specifies disambiguating information
+ to add to the relative distinguished name of an entry. It is
+ intended for use when merging data from multiple sources in order to
+ prevent conflicts between entries which would otherwise have the same
+ name. It is recommended that the value of the dnQualifier attribute
+ be the same for all entries from a particular source.
+
+ ( 2.5.4.46 NAME 'dnQualifier'
+ EQUALITY caseIgnoreMatch
+ ORDERING caseIgnoreOrderingMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
+
+ The SYNTAX oid indicates the Printable String syntax.
+
+2.9 enhancedSearchGuide
+
+ This attribute is for use by X.500 clients in constructing search
+ filters.
+
+ ( 2.5.4.47 NAME 'enhancedSearchGuide'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.21 )
+
+ The SYNTAX oid indicates the Enhanced Guide syntax.
+
+2.10 facsimileTelephoneNumber
+
+ A value of this Attribute Type is a telephone number for a facsimile
+ terminal (and, optionally, its parameters).
+
+ ( 2.5.4.23 NAME 'facsimileTelephoneNumber'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.22 )
+
+
+Dally Expires October 2003 [Page 7]
+INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
+
+
+ The SYNTAX oid indicates the Facsimile Telephone Number syntax.
+
+2.11 generationQualifier
+
+ The generationQualifier Attribute Type contains the part of a
+ person's name which typically is the suffix, as in "IIIrd".
+
+ ( 2.5.4.44 NAME 'generationQualifier'
+ SUP name )
+
+2.12 givenName
+
+ The givenName Attribute Type is used to hold the part of a person's
+ name which is not their surname nor middle name.
+
+ ( 2.5.4.42 NAME 'givenName'
+ SUP name )
+
+2.13 houseIdentifier
+
+ This Attribute Type is used to identify a building within a location.
+
+ ( 2.5.4.51 NAME 'houseIdentifier'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
+
+ The SYNTAX oid indicates the Directory String syntax.
+
+2.14 initials
+
+ The initials Attribute Type contains the initials of some or all of
+ an individuals names, except the surname(s).
+
+ ( 2.5.4.43 NAME 'initials'
+ SUP name )
+
+2.15 internationalISDNNumber
+
+ A value of this Attribute Type is an ISDN address, as defined in
+ ITU Recommendation E.164 [E.164].
+
+ ( 2.5.4.25 NAME 'internationalISDNNumber'
+ EQUALITY numericStringMatch
+ SUBSTR numericStringSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{16} ) i
+
+ The SYNTAX oid indicates the Numeric String syntax.
+
+
+
+
+
+
+Dally Expires October 2003 [Page 8]
+INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
+
+
+2.16 l
+
+ This is the X.520 [X.520] localityName Attribute Type, which
+ contains the name of a locality or place, such as a city, county or
+ other geographic region.
+
+ ( 2.5.4.7 NAME 'l'
+ SUP name )
+
+2.17 member
+
+ A value of this Attribute Type is the Distinguished Name of an
+ object that is on a list or in a group.
+
+ ( 2.5.4.31 NAME 'member'
+ SUP distinguishedName )
+
+2.18 name
+
+ The name Attribute Type is the attribute supertype from which string
+ Attribute Types typically used for naming may be formed. It is
+ unlikely that values of this type itself will occur in an entry.
+ LDAP server implementations which do not support attribute subtyping
+ need not recognize this attribute in requests. Client
+ implementations MUST NOT assume that LDAP servers are capable of
+ performing attribute subtyping.
+
+ ( 2.5.4.41 NAME 'name'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
+
+ The SYNTAX oid indicates the Directory String syntax.
+
+2.19 o
+
+ This is the X.520 [X.520] organizationName Attribute Type, which
+ contains the name of an organization.
+
+ ( 2.5.4.10 NAME 'o'
+ SUP name )
+
+2.20 ou
+
+ This is the X.520 [X.520] organizationalUnitName Attribute Type,
+ which contains the name of an organizational unit.
+
+ ( 2.5.4.11 NAME 'ou'
+ SUP name )
+
+
+
+
+
+Dally Expires October 2003 [Page 9]
+INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
+
+
+2.21 owner
+
+ A value of this Attribute Type is the Distinguished Name of an
+ object that has an ownership responsibility for the object that
+ is owned.
+
+ ( 2.5.4.32 NAME 'owner'
+ SUP distinguishedName )
+
+2.22 physicalDeliveryOfficeName
+
+ This attribute contains the name that a Postal Service uses to
+ identify a post office.
+
+ ( 2.5.4.19 NAME 'physicalDeliveryOfficeName'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
+
+ The SYNTAX oid indicates the Directory String syntax.
+
+2.23 postalAddress
+
+ This attribute contains an address used by a Postal Service to
+ perform services for the object.
+
+ ( 2.5.4.16 NAME 'postalAddress'
+ EQUALITY caseIgnoreListMatch
+ SUBSTR caseIgnoreListSubstringsMatch
+ SYNTAX 1.5.6.1.4.1.1466.115.121.1.41 )
+
+ The SYNTAX oid indicates the Postal Address syntax.
+
+2.24 postalCode
+
+ This attribute contains a code used by a Postal Service to identify
+ a postal service zone, such as the southern quadrant of a city.
+
+ ( 2.5.4.17 NAME 'postalCode'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.5.6.1.4.1.1466.115.121.1.15{40} )
+
+ The SYNTAX oid indicates the Directory String syntax.
+
+2.25 postOfficeBox
+
+ This attribute contains the number that a Postal Service uses when a
+ customer arranges to receive mail at a box on premises of the Postal
+ Service.
+
+
+
+
+Dally Expires October 2003 [Page 10]
+INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
+
+
+ ( 2.5.4.18 NAME 'postOfficeBox'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.5.6.1.4.1.1466.115.121.1.15{40} )
+
+ The SYNTAX oid indicates the Directory String syntax.
+
+2.26 preferredDeliveryMethod
+
+ This attribute contains an indication of the preferred method of
+ getting a message to the object.
+
+ ( 2.5.4.28 NAME 'preferredDeliveryMethod'
+ SYNTAX 1.5.6.1.4.1.1466.115.121.1.14
+ SINGLE-VALUE )
+
+ The SYNTAX oid indicates the Delivery Method syntax.
+
+2.27 registeredAddress
+
+ This attribute holds a postal address suitable for reception of
+ telegrams or expedited documents, where it is necessary to have the
+ recipient accept delivery.
+
+ ( 2.5.4.26 NAME 'registeredAddress'
+ SUP postalAddress
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
+
+ The SYNTAX oid indicates the Postal Address syntax.
+
+2.28 roleOccupant
+
+ A value of this Attribute Type is the Distinguished Name of an
+ object (normally a person) that fulfills the responsibilities of a
+ role object.
+
+ ( 2.5.4.33 NAME 'roleOccupant'
+ SUP distinguishedName )
+
+2.29 searchGuide
+
+ This Attribute Type is for use by clients in constructing search
+ filters. It is superseded by enhancedSearchGuide, described above
+ in section 2.9.
+
+ ( 2.5.4.14 NAME 'searchGuide'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.25 ) ; Guide
+
+The SYNTAX oid indicates the Guide syntax.
+
+
+
+
+
+Dally Expires October 2003 [Page 11]
+INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
+
+
+2.30 seeAlso
+
+ A value of this Attribute Type is the Distinguished Name of an
+ object that is related to the subject object.
+
+ ( 2.5.4.34 NAME 'seeAlso'
+ SUP distinguishedName )
+
+2.31 serialNumber
+
+ This attribute contains the serial number of a device.
+
+ ( 2.5.4.5 NAME 'serialNumber'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{64} )
+
+ The SYNTAX oid indicates the Printable String syntax.
+
+2.32 sn
+
+ This is the X.520 [X.520] surname Attribute Type, which contains the
+ family name of a person.
+
+ ( 2.5.4.4 NAME 'sn'
+ SUP name )
+
+2.33 st
+
+ This is the X.520 [X.520] stateOrProvinceName attribute, which
+ contains the full name of a state or province.
+
+ ( 2.5.4.8 NAME 'st'
+ SUP name )
+
+2.34 street
+
+ This is the X.520 [X.520] streetAddress attribute, which contains the
+ physical address of the object to which the entry corresponds, such
+ as an address for package delivery.
+
+ ( 2.5.4.9 NAME 'street'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
+
+ The SYNTAX oid indicates the Directory String syntax.
+
+2.35 telephoneNumber
+
+ A value of this Attribute Type is a telephone number complying with
+ ITU Recommendation E.123 [E.123].
+
+
+Dally Expires October 2003 [Page 12]
+INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
+
+
+ ( 2.5.4.20 NAME 'telephoneNumber'
+ EQUALITY telephoneNumberMatch
+ SUBSTR telephoneNumberSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.50{32} )
+
+ The SYNTAX oid indicates the Telephone Number syntax.
+
+2.36 teletexTerminalIdentifier
+
+ The withdrawal of Rec. F.200 has resulted in the withdrawal of this
+ attribute.
+
+ ( 2.5.4.22 NAME 'teletexTerminalIdentifier'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.51 )
+
+ The SYNTAX oid indicates the Teletex Terminal Identifier syntax.
+
+2.37 telexNumber
+
+ A value of this Attribute Type is a telex number, country code, and
+ answerback code of a telex terminal.
+
+ ( 2.5.4.21 NAME 'telexNumber'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.52 )
+
+ The SYNTAX oid indicates the Telex Number syntax.
+
+2.38 title
+
+ This attribute contains the title, such as "Vice President", of a
+ person in their organizational context. The "personalTitle"
+ attribute would be used for a person's title independent of their
+ job function.
+
+ ( 2.5.4.12 NAME 'title'
+ SUP name )
+
+2.39 uniqueMember
+
+ A value of this Attribute Type is the Distinguished Name of an
+ object that is on a list or in a group, where the Relative
+ Distinguished Name of the object includes a value that distinguishs
+ between objects when a distinguished name has been reused.
+
+ ( 2.5.4.50 NAME 'uniqueMember'
+ EQUALITY uniqueMemberMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )
+
+The SYNTAX oid indicates the Name and Optional UID syntax.
+
+
+
+
+
+Dally Expires October 2003 [Page 13]
+INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
+
+
+2.40 userPassword
+
+ A value of this Attribute Type is a character string that is known
+ only to the user and the system to which the user has access.
+
+ ( 2.5.4.35 NAME 'userPassword'
+ EQUALITY octetStringMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )
+
+ The SYNTAX oid indicates the Octet String syntax.
+
+ Passwords are stored using an Octet String syntax and are not
+ encrypted. Transfer of cleartext passwords is strongly discouraged
+ where the underlying transport service cannot guarantee
+ confidentiality and may result in disclosure of the password to
+ unauthorized parties.
+
+2.41 x121Address
+
+ A value of this Attribute Type is a data network address as defined
+ by ITU Recommendation X.121 [X.121].
+
+ ( 2.5.4.24 NAME 'x121Address'
+ EQUALITY numericStringMatch
+ SUBSTR numericStringSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{15} )
+
+ The SYNTAX oid indicates the Numeric String syntax.
+
+2.42 x500UniqueIdentifier
+
+ The x500UniqueIdentifier Attribute Type is used to distinguish
+ between objects when a distinguished name has been reused. In X.520
+ [X.520], this Attribute Type is called uniqueIdentifier. This is a
+ different Attribute Type from both the "uid" and "uniqueIdentifier"
+ Attribute Types.
+
+ ( 2.5.4.45 NAME 'x500UniqueIdentifier'
+ EQUALITY bitStringMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
+
+ The SYNTAX oid indicates the Bit String syntax.
+
+
+
+
+
+
+
+
+
+
+
+
+Dally Expires October 2003 [Page 14]
+INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
+
+
+3. Object Classes
+
+ LDAP servers SHOULD recognize all the Object Classes listed here as
+ values of the objectClass attribute.
+
+3.1 applicationProcess
+
+ The applicationProcess Object Class definition is the basis of an
+ entry which represents an application executing in a computer system.
+
+ ( 2.5.6.11 NAME 'applicationProcess'
+ SUP top
+ STRUCTURAL
+ MUST cn
+ MAY ( seeAlso $
+ ou $
+ l $
+ description ) )
+
+3.2 country
+
+ The country Object Class definition is the basis of an entry which
+ represents a country.
+
+ ( 2.5.6.2 NAME 'country'
+ SUP top
+ STRUCTURAL
+ MUST c
+ MAY ( searchGuide $
+ description ) )
+
+3.3 device
+
+ The device Object Class is the basis of an entry which represents
+ an appliance or computer or network element.
+
+ ( 2.5.6.14 NAME 'device'
+ SUP top
+ STRUCTURAL
+ MUST cn
+ MAY ( serialNumber $
+ seeAlso $
+ owner $
+ ou $
+ o $
+ l $
+ description ) )
+
+3.4 domain
+
+ The domain Object Class is the basis of an entry which represents a
+ portion of a network, as organized by DNS.
+
+
+Dally Expires October 2003 [Page 15]
+INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
+
+
+ ( 0.9.2342.19200300.100.4.13 NAME 'domain'
+ SUP top
+ STRUCTURAL
+ MUST dc
+ MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
+ x121Address $ registeredAddress $ destinationIndicator $
+ preferredDeliveryMethod $ telexNumber $
+ teletexTerminalIdentifier $ telephoneNumber $
+ internationaliSDNNumber $ facsimileTelephoneNumber $ street $
+ postOfficeBox $ postalCode $ postalAddress $
+ physicalDeliveryOfficeName $ st $ l $ description $ o $
+ associatedName ) )
+
+ An example entry would be:
+
+ dn: dc=tcp,dc=critical-angle,dc=com
+ objectClass: top
+ objectClass: domain
+ dc: tcp
+ description: a placeholder entry used with SRV records
+
+3.5 groupOfNames
+
+ The groupOfNames Object Class is the basis of an entry which
+ represents a set of named objects including information related to
+ the purpose or maintenance of the set.
+
+ ( 2.5.6.9 NAME 'groupOfNames'
+ SUP top
+ STRUCTURAL
+ MUST ( member $
+ cn )
+ MAY ( businessCategory $
+ seeAlso $
+ owner $
+ ou $
+ o $
+ description ) )
+
+3.6 groupOfUniqueNames
+
+ The groupOfUniqueNames Object Class is the same as the groupOfNames
+ object class except that the object names are not repeated or
+ reassigned within a set scope.
+
+ ( 2.5.6.17 NAME 'groupOfUniqueNames'
+ SUP top
+ STRUCTURAL
+ MUST ( uniqueMember $
+ cn )
+ MAY ( businessCategory $
+ seeAlso $
+
+
+Dally Expires October 2003 [Page 16]
+INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
+
+
+ owner $
+ ou $
+ o $
+ description ) )
+
+3.7 locality
+
+ The locality Object Class is the basis of an entry which
+ represents a place in the physical world.
+
+ ( 2.5.6.3 NAME 'locality'
+ SUP top
+ STRUCTURAL
+ MAY ( street $
+ seeAlso $
+ searchGuide $
+ st $
+ l $
+ description ) )
+
+3.8 organization
+
+ The organization Object Class is the basis of an entry which
+ represents a structured group of people.
+
+ ( 2.5.6.4 NAME 'organization'
+ SUP top
+ STRUCTURAL
+ MUST o
+ MAY ( userPassword $ searchGuide $ seeAlso $
+ businessCategory $ x121Address $ registeredAddress $
+ destinationIndicator $ preferredDeliveryMethod $
+ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $
+ internationaliSDNNumber $ facsimileTelephoneNumber $
+ street $ postOfficeBox $ postalCode $
+ postalAddress $ physicalDeliveryOfficeName $ st $
+ l $ description ) )
+
+3.9 organizationalPerson
+
+ The organizationalPerson Object Class is the basis of an entry which
+ represents a person in relation to an organization.
+
+ ( 2.5.6.7 NAME 'organizationalPerson'
+ SUP person
+ STRUCTURAL
+ MAY ( title $ x121Address $ registeredAddress $
+ destinationIndicator $ preferredDeliveryMethod $
+ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $
+ internationaliSDNNumber $ facsimileTelephoneNumber $
+ street $ postOfficeBox $ postalCode $ postalAddress $
+ physicalDeliveryOfficeName $ ou $ st $ l ) )
+
+
+Dally Expires October 2003 [Page 17]
+INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
+
+
+3.10 organizationalRole
+
+ The organizationalRole Object Class is the basis of an entry which
+ represents a job or function or position in an organization.
+
+ ( 2.5.6.8 NAME 'organizationalRole'
+ SUP top
+ STRUCTURAL
+ MUST cn
+ MAY ( x121Address $ registeredAddress $ destinationIndicator $
+ preferredDeliveryMethod $ telexNumber $
+ teletexTerminalIdentifier $ telephoneNumber $
+ internationaliSDNNumber $ facsimileTelephoneNumber $
+ seeAlso $ roleOccupant $ preferredDeliveryMethod $
+ street $ postOfficeBox $ postalCode $ postalAddress $
+ physicalDeliveryOfficeName $ ou $ st $ l $ description ) )
+
+3.11 organizationalUnit
+
+ The organizationalUnit Object Class is the basis of an entry which
+ represents a piece of an organization.
+
+ ( 2.5.6.5 NAME 'organizationalUnit'
+ SUP top
+ STRUCTURAL
+ MUST ou
+ MAY ( businessCategory $ description $ destinationIndicator $
+ facsimileTelephoneNumber $ internationaliSDNNumber $ l $
+ physicalDeliveryOfficeName $ postalAddress $ postalCode $
+ postOfficeBox $ preferredDeliveryMethod $
+ registeredAddress $ searchGuide $ seeAlso $ st $ street $
+ telephoneNumber $ teletexTerminalIdentifier $ telexNumber $
+ userPassword $ x121Address ) )
+
+3.12 person
+
+ The person Object Class is the basis of an entry which represents a
+ human being.
+
+ ( 2.5.6.6 NAME 'person'
+ SUP top
+ STRUCTURAL
+ MUST ( sn $
+ cn )
+ MAY ( userPassword $
+ telephoneNumber $
+ seeAlso $
+ description ) )
+
+
+
+
+
+
+Dally Expires October 2003 [Page 18]
+INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
+
+
+3.13 residentialPerson
+
+ The residentialPerson Object Class is the basis of an entry which
+ includes a person's residence in the representation of the person.
+
+ ( 2.5.6.10 NAME 'residentialPerson'
+ SUP person
+ STRUCTURAL
+ MUST l
+ MAY ( businessCategory $ x121Address $ registeredAddress $
+ destinationIndicator $ preferredDeliveryMethod $
+ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $
+ internationaliSDNNumber $ facsimileTelephoneNumber $
+ preferredDeliveryMethod $ street $ postOfficeBox $
+ postalCode $ postalAddress $ physicalDeliveryOfficeName $
+ st $ l ) )
+
+
+4. IANA Considerations
+
+ It is requested that the Internet Assigned Numbers Authority (IANA)
+ update the LDAP descriptors registry as indicated in the following
+ template:
+
+ Subject: Request for LDAP Descriptor Registration Update
+ Descriptor (short name): see comment
+ Object Identifier: see comment
+ Person & email address to contact for further information:
+ Kathy Dally <kdally@mitre.org>
+ Usage: (A = Attribute Type, O = Object Class) see comment
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+
+
+
+Dally Expires October 2003 [Page 19]
+INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
+
+
+ Comments:
+ The following descriptors (short names) should be updated to
+ refer to RFC XXXX.
+
+ NAME Type OID
+ ------------------------ ---- ----------------------------
+ applicationProcess O 2.5.6.11
+ businessCategory A 2.5.4.15
+ c A 2.5.4.6
+ cn A 2.5.4.3
+ country O 2.5.6.2
+ dc A 0.9.2342.19200300.100.1.25
+ description A 2.5.4.13
+ destinationIndicator A 2.5.4.27
+ device O 2.5.6.14
+ distinguishedName A 2.5.4.49
+ dnQualifier A 2.5.4.46
+ domain O 0.9.2342.19200300.100.4.13
+ enhancedSearchGuide A 2.5.4.47
+ facsimileTelephoneNumber A 2.5.4.23
+ generationQualifier A 2.5.4.44
+ givenName A 2.5.4.42
+ groupOfNames O 2.5.6.9
+ groupOfUniqueNames O 2.5.6.17
+ houseIdentifier A 2.5.4.51
+ initials A 2.5.4.43
+ internationalISDNNumber A 2.5.4.25
+ l A 2.5.4.7
+ locality O 2.5.6.3
+ member A 2.5.4.31
+ name A 2.5.4.41
+ o A 2.5.4.10
+ organization O 2.5.6.4
+ organizationalPerson O 2.5.6.7
+ organizationalRole O 2.5.6.8
+ organizationalUnit O 2.5.6.5
+ ou A 2.5.4.11
+ owner A 2.5.4.32
+ person O 2.5.6.6
+ physicalDeliveryOfficeName A 2.5.4.19
+ postalAddress A 2.5.4.16
+ postalCode A 2.5.4.17
+ postOfficeBox A 2.5.4.18
+ preferredDeliveryMethod A 2.5.4.28
+ registeredAddress A 2.5.4.26
+ residentialPerson O 2.5.6.10
+ roleOccupant A 2.5.4.33
+ searchGuide A 2.5.4.14
+ seeAlso A 2.5.4.34
+ serialNumber A 2.5.4.5
+ sn A 2.5.4.4
+
+
+Dally Expires October 2003 [Page 20]
+INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
+
+
+ st A 2.5.4.8
+ street A 2.5.4.9
+ telephoneNumber A 2.5.4.20
+ teletexTerminalIdentifier A 2.5.4.22
+ telexNumber A 2.5.4.21
+ title A 2.5.4.12
+ uniqueMember A 2.5.4.50
+ userPassword A 2.5.4.35
+ x121Address A 2.5.4.24
+ x500UniqueIdentifier A 2.5.4.45
+
+
+5. Security Considerations
+
+ Attributes of directory entries are used to provide descriptive
+ information about the real-world objects they represent, which can be
+ people, organizations or devices. Most countries have privacy laws
+ regarding the publication of information about people.
+
+ Transfer of cleartext passwords is strongly discouraged where the
+ underlying transport service cannot guarantee confidentiality and may
+ result in disclosure of the password to unauthorized parties.
+
+ It is required that strong authentication be performed in order to
+ modify directory entries using LDAP.
+
+
+6. Acknowledgements
+
+ The definitions, on which this document is based, have been developed
+ by committees for telecommunications and international standards.
+ No new attribute definitions have been added.
+
+ This document is an update of RFC 2256 by Mark Wahl. RFC 2256 was a
+ product of the IETF ASID Working Group.
+
+ This document is based upon input of the IETF LDAPBIS working group.
+ The author wishes to thank S. Legg and K. Zeilenga for their
+ significant contribution to this update.
+
+
+7. References
+
+7.1 Normative
+
+ [E.123] Notation for national and international telephone numbers,
+ ITU-T Recommendation E.123, 1988
+
+ [E.164] The international public telecommunication numbering plan,
+ ITU-T Recommendation E.164, 1997
+
+
+
+Dally Expires October 2003 [Page 21]
+INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
+
+
+ [ISO3166] ISO 3166, "Codes for the representation of names of
+ countries".
+
+ [LDAP-PKI] Chadwick, D. W., Legg S., "LDAP Schema and Syntaxes for
+ PKIs", draft-ietf-pkix-ldap-pki-schema-xx (a work in
+ progress)
+
+ [Models] K. Zeilenga, "LDAP: The Models", draft-ietf-ldapbis-
+ models-xx (a work in progress)
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", RFC 2119, March 1997
+
+ [RFC3377] Hodges, J., Morgan, R., "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002
+
+...[ROADMAP] Zeilenga, K., "LDAP: Technical Specification Road Map",
+ draft-ietf-ldapbis-roadmap-xx (a work in progress)
+
+ [Syntaxes] S. Legg (editor), "LDAP: Syntaxes",
+ draft-ietf-ldapbis-syntaxes-xx (a work in progress)
+
+ [X.121] International numbering plan for public data networks,
+ ITU-T Recommendation X.121, 1996
+
+ [X.509] The Directory: Authentication Framework, ITU-T
+ Recommendation X.509, 1993
+
+ [X.520] The Directory: Selected Attribute Types, ITU-T
+ Recommendation X.520, 1993
+
+ [X.521] The Directory: Selected Object Classes. ITU-T
+ Recommendation X.521, 1993
+
+7.2 Informative
+
+ [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., and
+ Sataluri, S., "Using Domains in LDAP/X.500 Distinguished Names",
+ RFC 2247, January 1998
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dally Expires October 2003 [Page 22]
+INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
+
+
+8. Author's Address
+
+ Kathy Dally
+ The MITRE Corp.
+ 1575 Colshire Dr., H300
+ McLean VA 22102
+ USA
+
+ Phone: +1 703 883 6058
+ Email: kdally@mitre.org
+
+
+9. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dally Expires October 2003 [Page 23]
+INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
+
+
+ Appendix A Changes RFC 2256
+
+ This appendix lists the changes that have been made from RFC 2256 to
+ this I-D.
+
+ 1. Revised the Status of this Memo.
+
+ 2. Removed the IESG Note.
+
+ 3. Dependencies on RFC 1274 have been eliminated.
+
+ 4. Added a Security Considerations section, requiring strong
+ authentication in order to modify directory entries.
+
+ 5. Deleted the conformance requirement for subschema object
+ classes in favor of a statement in [Syntaxes].
+
+ 6. Added a Table of Contents.
+
+ 7. Added explanations to many attributes.
+
+ 8. Removed Section 4, Syntaxes, and Section 6, Matching Rules,
+ (moved to [Syntaxes]).
+
+ 9. Reordered Section 3, Attributes, and Section 4, Object
+ Classes, alphabetically.
+
+ 10. Added an explanation for each object class.
+
+ 11. Removed the certificate-related Attribute Types:
+ authorityRevocationList,
+ cACertificate,
+ certificateRevocationList,
+ crossCertificatePair,
+ deltaRevocationList,
+ supportedAlgorithms, and
+ userCertificate.
+
+ Removed the certificate-related Object Classes:
+ certificationAuthority,
+ certificationAuthority-V2,
+ cRLDistributionPoint,
+ strongAuthenticationUser, and
+ userSecurityInformation
+
+ Noted that they are covered in PKIX WG documents.
+
+ 12. Removed the dmdName Attribute Type and dmd Object Class
+ because they are not in the version of X.500 which
+ is referenced.
+
+
+
+Dally Expires October 2003 [Page 24]
+INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
+
+
+......13. Deleted the 'aliasedObjectName' and 'objectClass' attribute
+ type definitions. They are included in [Models].
+
+ 14. Deleted the 'alias' and 'top' object class definitions. They
+ are included in [Models].
+
+ 15. Replaced the document title.
+
+ 16. Added the 'dc' attribute and the 'domain' object class from
+ RFC 2247.
+
+ 17. Deleted the 'knowledgeInformation', 'presentationAddress',
+ 'protocolInformation', and 'supportedApplicationContext'
+ attributes.
+
+ 18. Deleted the 'applicationEntity' and 'dSA' object classes.
+
+ 19. Added an IANA Considerations section.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dally Expires October 2003 [Page 25]
+++ /dev/null
-
-
-
-
-
-
-Network Working Group Paul J. Leach, Microsoft
-INTERNET-DRAFT Rich Salz, Certco
-<draft-leach-uuids-guids-01.txt>
-Category: Standards Track
-Expires August 4, 1998 February 4, 1998
-
-
-
- UUIDs and GUIDs
-
-STATUS OF THIS MEMO
-
- This document is an Internet-Draft. Internet-Drafts are working
- documents of the Internet Engineering Task Force (IETF), its areas,
- and its working groups. Note that other groups may also distribute
- working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress".
-
- To learn the current status of any Internet-Draft, please check the
- "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
- Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
- munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
- ftp.isi.edu (US West Coast).
-
- Distribution of this document is unlimited. Please send comments to
- the authors or the CIFS mailing list at <cifs@discuss.microsoft.com>.
- Discussions of the mailing list are archived at
- <URL:http://discuss.microsoft.com/archives/index.
-
-
-ABSTRACT
-
- This specification defines the format of UUIDs (Universally Unique
- IDentifier), also known as GUIDs (Globally Unique IDentifier). A UUID
- is 128 bits long, and if generated according to the one of the
- mechanisms in this document, is either guaranteed to be different
- from all other UUIDs/GUIDs generated until 3400 A.D. or extremely
- likely to be different (depending on the mechanism chosen). UUIDs
- were originally used in the Network Computing System (NCS) [1] and
- later in the Open Software Foundation's (OSF) Distributed Computing
- Environment [2].
-
- This specification is derived from the latter specification with the
- kind permission of the OSF.
-
-
-Table of Contents
-
-1. Introduction .......................................................3
-
-
-[Page 1]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
-2. Motivation .........................................................3
-
-3. Specification ......................................................3
-
- 3.1 Format............................................................4
-
- 3.1.1 Variant......................................................4
-
- 3.1.2 UUID layout..................................................5
-
- 3.1.3 Version......................................................5
-
- 3.1.4 Timestamp....................................................6
-
- 3.1.5 Clock sequence...............................................6
-
- 3.1.6 Node.........................................................7
-
- 3.1.7 Nil UUID.....................................................7
-
- 3.2 Algorithms for creating a time-based UUID.........................7
-
- 3.2.1 Basic algorithm..............................................7
-
- 3.2.2 Reading stable storage.......................................8
-
- 3.2.3 System clock resolution......................................8
-
- 3.2.4 Writing stable storage.......................................9
-
- 3.2.5 Sharing state across processes...............................9
-
- 3.2.6 UUID Generation details......................................9
-
- 3.3 Algorithm for creating a name-based UUID.........................10
-
- 3.4 Algorithms for creating a UUID from truly random or pseudo-random
- numbers .............................................................11
-
- 3.5 String Representation of UUIDs...................................12
-
- 3.6 Comparing UUIDs for equality.....................................12
-
- 3.7 Comparing UUIDs for relative order...............................13
-
- 3.8 Byte order of UUIDs..............................................13
-
-4. Node IDs when no IEEE 802 network card is available ...............14
-
-5. Obtaining IEEE 802 addresses ......................................15
-
-6. Security Considerations ...........................................15
-
-7. Acknowledgements ..................................................15
-
- Leach, Salz expires Aug 1998 [Page 2]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
-8. References ........................................................15
-
-9. Authors' addresses ................................................16
-
-10.Notice ............................................................16
-
-11.Full Copyright Statement ..........................................16
-
-Appendix A _ UUID Sample Implementation...............................17
-
-Appendix B _ Sample output of utest...................................27
-
-Appendix C _ Some name space IDs......................................27
-
-
-
-
-1. Introduction
-
- This specification defines the format of UUIDs (Universally Unique
- IDentifiers), also known as GUIDs (Globally Unique IDentifiers). A
- UUID is 128 bits long, and if generated according to the one of the
- mechanisms in this document, is either guaranteed to be different
- from all other UUIDs/GUIDs generated until 3400 A.D. or extremely
- likely to be different (depending on the mechanism chosen).
-
-
-2. Motivation
-
- One of the main reasons for using UUIDs is that no centralized
- authority is required to administer them (beyond the one that
- allocates IEEE 802.1 node identifiers). As a result, generation on
- demand can be completely automated, and they can be used for a wide
- variety of purposes. The UUID generation algorithm described here
- supports very high allocation rates: 10 million per second per
- machine if you need it, so that they could even be used as
- transaction IDs.
-
- UUIDs are fixed-size (128-bits) which is reasonably small relative to
- other alternatives. This fixed, relatively small size lends itself
- well to sorting, ordering, and hashing of all sorts, storing in
- databases, simple allocation, and ease of programming in general.
-
-
-3. Specification
-
- A UUID is an identifier that is unique across both space and time,
- with respect to the space of all UUIDs. To be precise, the UUID
- consists of a finite bit space. Thus the time value used for
- constructing a UUID is limited and will roll over in the future
- (approximately at A.D. 3400, based on the specified algorithm). A
- UUID can be used for multiple purposes, from tagging objects with an
- extremely short lifetime, to reliably identifying very persistent
- objects across a network.
-
- Leach, Salz expires Aug 1998 [Page 3]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
- The generation of UUIDs does not require that a registration
- authority be contacted for each identifier. Instead, it requires a
- unique value over space for each UUID generator. This spatially
- unique value is specified as an IEEE 802 address, which is usually
- already available to network-connected systems. This 48-bit address
- can be assigned based on an address block obtained through the IEEE
- registration authority. This section of the UUID specification
- assumes the availability of an IEEE 802 address to a system desiring
- to generate a UUID, but if one is not available section 4 specifies a
- way to generate a probabilistically unique one that can not conflict
- with any properly assigned IEEE 802 address.
-
-
-3.1 Format
-
- In its most general form, all that can be said of the UUID format is
- that a UUID is 16 octets, and that some bits of octet 8 of the UUID
- called the variant field (specified in the next section) determine
- finer structure.
-
-
-3.1.1 Variant
- The variant field determines the layout of the UUID. That is, the
- interpretation of all other bits in the UUID depends on the setting
- of the bits in the variant field. The variant field consists of a
- variable number of the msbs of octet 8 of the UUID.
-
- The following table lists the contents of the variant field.
-
- Msb0 Msb1 Msb2 Description
-
- 0 - - Reserved, NCS backward compatibility.
-
- 1 0 - The variant specified in this document.
-
- 1 1 0 Reserved, Microsoft Corporation backward
- compatibility
-
- 1 1 1 Reserved for future definition.
-
-
-
- Other UUID variants may not interoperate with the UUID variant
- specified in this document, where interoperability is defined as the
- applicability of operations such as string conversion and lexical
- ordering across different systems. However, UUIDs allocated according
- to the stricture of different variants, though they may define
- different interpretations of the bits outside the variant field, will
- not result in duplicate UUID allocation, because of the differing
- values of the variant field itself.
-
- The remaining fields described below (version, timestamp, etc.) are
- defined only for the UUID variant noted above.
-
-
- Leach, Salz expires Aug 1998 [Page 4]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
-3.1.2 UUID layout
- The following table gives the format of a UUID for the variant
- specified herein. The UUID consists of a record of 16 octets. To
- minimize confusion about bit assignments within octets, the UUID
- record definition is defined only in terms of fields that are
- integral numbers of octets. The fields are in order of significance
- for comparison purposes, with "time_low" the most significant, and
- "node" the least significant.
-
- Field Data Type Octet Note
- #
-
- time_low unsigned 32 0-3 The low field of the
- bit integer timestamp.
-
- time_mid unsigned 16 4-5 The middle field of the
- bit integer timestamp.
-
- time_hi_and_version unsigned 16 6-7 The high field of the
- bit integer timestamp multiplexed
- with the version number.
-
- clock_seq_hi_and_rese unsigned 8 8 The high field of the
- rved bit integer clock sequence
- multiplexed with the
- variant.
-
- clock_seq_low unsigned 8 9 The low field of the
- bit integer clock sequence.
-
- node unsigned 48 10-15 The spatially unique
- bit integer node identifier.
-
-
-
-
-3.1.3 Version
- The version number is in the most significant 4 bits of the time
- stamp (time_hi_and_version).
-
- The following table lists currently defined versions of the UUID.
-
- Msb0 Msb1 Msb2 Msb3 Version Description
-
- 0 0 0 1 1 The time-based version
- specified in this
- document.
-
- 0 0 1 0 2 Reserved for DCE
- Security version, with
- embedded POSIX UIDs.
-
- 0 0 1 1 3 The name-based version
- specified in this
-
- Leach, Salz expires Aug 1998 [Page 5]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
- document
-
- 0 1 0 0 4 The randomly or pseudo-
- randomly generated
- version specified in
- this document
-
-
-3.1.4 Timestamp
- The timestamp is a 60 bit value. For UUID version 1, this is
- represented by Coordinated Universal Time (UTC) as a count of 100-
- nanosecond intervals since 00:00:00.00, 15 October 1582 (the date of
- Gregorian reform to the Christian calendar).
-
- For systems that do not have UTC available, but do have local time,
- they MAY use local time instead of UTC, as long as they do so
- consistently throughout the system. This is NOT RECOMMENDED, however,
- and it should be noted that all that is needed to generate UTC, given
- local time, is a time zone offset.
-
- For UUID version 3, it is a 60 bit value constructed from a name.
-
- For UUID version 4, it is a randomly or pseudo-randomly generated 60
- bit value.
-
-
-3.1.5 Clock sequence
- For UUID version 1, the clock sequence is used to help avoid
- duplicates that could arise when the clock is set backwards in time
- or if the node ID changes.
-
- If the clock is set backwards, or even might have been set backwards
- (e.g., while the system was powered off), and the UUID generator can
- not be sure that no UUIDs were generated with timestamps larger than
- the value to which the clock was set, then the clock sequence has to
- be changed. If the previous value of the clock sequence is known, it
- can be just incremented; otherwise it should be set to a random or
- high-quality pseudo random value.
-
- Similarly, if the node ID changes (e.g. because a network card has
- been moved between machines), setting the clock sequence to a random
- number minimizes the probability of a duplicate due to slight
- differences in the clock settings of the machines. (If the value of
- clock sequence associated with the changed node ID were known, then
- the clock sequence could just be incremented, but that is unlikely.)
-
- The clock sequence MUST be originally (i.e., once in the lifetime of
- a system) initialized to a random number to minimize the correlation
- across systems. This provides maximum protection against node
- identifiers that may move or switch from system to system rapidly.
- The initial value MUST NOT be correlated to the node identifier.
-
- For UUID version 3, it is a 14 bit value constructed from a name.
-
-
- Leach, Salz expires Aug 1998 [Page 6]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
- For UUID version 4, it is a randomly or pseudo-randomly generated 14
- bit value.
-
-
-3.1.6 Node
- For UUID version 1, the node field consists of the IEEE address,
- usually the host address. For systems with multiple IEEE 802
- addresses, any available address can be used. The lowest addressed
- octet (octet number 10) contains the global/local bit and the
- unicast/multicast bit, and is the first octet of the address
- transmitted on an 802.3 LAN.
-
- For systems with no IEEE address, a randomly or pseudo-randomly
- generated value may be used (see section 4). The multicast bit must
- be set in such addresses, in order that they will never conflict with
- addresses obtained from network cards.
-
- For UUID version 3, the node field is a 48 bit value constructed from
- a name.
-
- For UUID version 4, the node field is a randomly or pseudo-randomly
- generated 48 bit value.
-
-
-3.1.7 Nil UUID
- The nil UUID is special form of UUID that is specified to have all
- 128 bits set to 0 (zero).
-
-
-3.2 Algorithms for creating a time-based UUID
-
- Various aspects of the algorithm for creating a version 1 UUID are
- discussed in the following sections. UUID generation requires a
- guarantee of uniqueness within the node ID for a given variant and
- version. Interoperability is provided by complying with the specified
- data structure.
-
-
-3.2.1 Basic algorithm
- The following algorithm is simple, correct, and inefficient:
-
- . Obtain a system wide global lock
-
- . From a system wide shared stable store (e.g., a file), read the
- UUID generator state: the values of the time stamp, clock sequence,
- and node ID used to generate the last UUID.
-
- . Get the current time as a 60 bit count of 100-nanosecond intervals
- since 00:00:00.00, 15 October 1582
-
- . Get the current node ID
-
-
-
-
- Leach, Salz expires Aug 1998 [Page 7]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
- . If the state was unavailable (non-existent or corrupted), or the
- saved node ID is different than the current node ID, generate a
- random clock sequence value
-
- . If the state was available, but the saved time stamp is later than
- the current time stamp, increment the clock sequence value
-
- . Format a UUID from the current time stamp, clock sequence, and node
- ID values according to the structure in section 3.1 (see section
- 3.2.6 for more details)
-
- . Save the state (current time stamp, clock sequence, and node ID)
- back to the stable store
-
- . Release the system wide global lock
-
- If UUIDs do not need to be frequently generated, the above algorithm
- may be perfectly adequate. For higher performance requirements,
- however, issues with the basic algorithm include:
-
- . Reading the state from stable storage each time is inefficient
-
- . The resolution of the system clock may not be 100-nanoseconds
-
- . Writing the state to stable storage each time is inefficient
-
- . Sharing the state across process boundaries may be inefficient
-
- Each of these issues can be addressed in a modular fashion by local
- improvements in the functions that read and write the state and read
- the clock. We address each of them in turn in the following sections.
-
-
-3.2.2 Reading stable storage
- The state only needs to be read from stable storage once at boot
- time, if it is read into a system wide shared volatile store (and
- updated whenever the stable store is updated).
-
- If an implementation does not have any stable store available, then
- it can always say that the values were unavailable. This is the least
- desirable implementation, because it will increase the frequency of
- creation of new clock sequence numbers, which increases the
- probability of duplicates.
-
- If the node ID can never change (e.g., the net card is inseparable
- from the system), or if any change also reinitializes the clock
- sequence to a random value, then instead of keeping it in stable
- store, the current node ID may be returned.
-
-
-3.2.3 System clock resolution
- The time stamp is generated from the system time, whose resolution
- may be less than the resolution of the UUID time stamp.
-
-
- Leach, Salz expires Aug 1998 [Page 8]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
- If UUIDs do not need to be frequently generated, the time stamp can
- simply be the system time multiplied by the number of 100-nanosecond
- intervals per system time interval.
-
- If a system overruns the generator by requesting too many UUIDs
- within a single system time interval, the UUID service MUST either:
- return an error, or stall the UUID generator until the system clock
- catches up.
-
- A high resolution time stamp can be simulated by keeping a count of
- how many UUIDs have been generated with the same value of the system
- time, and using it to construction the low-order bits of the time
- stamp. The count will range between zero and the number of 100-
- nanosecond intervals per system time interval.
-
- Note: if the processors overrun the UUID generation frequently,
- additional node identifiers can be allocated to the system, which
- will permit higher speed allocation by making multiple UUIDs
- potentially available for each time stamp value.
-
-
-3.2.4 Writing stable storage
- The state does not always need to be written to stable store every
- time a UUID is generated. The timestamp in the stable store can be
- periodically set to a value larger than any yet used in a UUID; as
- long as the generated UUIDs have time stamps less than that value,
- and the clock sequence and node ID remain unchanged, only the shared
- volatile copy of the state needs to be updated. Furthermore, if the
- time stamp value in stable store is in the future by less than the
- typical time it takes the system to reboot, a crash will not cause a
- reinitialization of the clock sequence.
-
-
-3.2.5 Sharing state across processes
- If it is too expensive to access shared state each time a UUID is
- generated, then the system wide generator can be implemented to
- allocate a block of time stamps each time it is called, and a per-
- process generator can allocate from that block until it is exhausted.
-
-
-3.2.6 UUID Generation details
- UUIDs are generated according to the following algorithm:
-
- - Determine the values for the UTC-based timestamp and clock sequence
- to be used in the UUID, as described above.
-
- - For the purposes of this algorithm, consider the timestamp to be a
- 60-bit unsigned integer and the clock sequence to be a 14-bit
- unsigned integer. Sequentially number the bits in a field, starting
- from 0 (zero) for the least significant bit.
-
- - Set the time_low field equal to the least significant 32-bits (bits
- numbered 0 to 31 inclusive) of the time stamp in the same order of
- significance.
-
- Leach, Salz expires Aug 1998 [Page 9]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
- - Set the time_mid field equal to the bits numbered 32 to 47
- inclusive of the time stamp in the same order of significance.
-
- - Set the 12 least significant bits (bits numbered 0 to 11 inclusive)
- of the time_hi_and_version field equal to the bits numbered 48 to 59
- inclusive of the time stamp in the same order of significance.
-
- - Set the 4 most significant bits (bits numbered 12 to 15 inclusive)
- of the time_hi_and_version field to the 4-bit version number
- corresponding to the UUID version being created, as shown in the
- table in section 3.1.3.
-
- - Set the clock_seq_low field to the 8 least significant bits (bits
- numbered 0 to 7 inclusive) of the clock sequence in the same order of
- significance.
-
- - Set the 6 least significant bits (bits numbered 0 to 5 inclusive)
- of the clock_seq_hi_and_reserved field to the 6 most significant bits
- (bits numbered 8 to 13 inclusive) of the clock sequence in the same
- order of significance.
-
- - Set the 2 most significant bits (bits numbered 6 and 7) of the
- clock_seq_hi_and_reserved to 0 and 1, respectively.
-
- - Set the node field to the 48-bit IEEE address in the same order of
- significance as the address.
-
-
-3.3 Algorithm for creating a name-based UUID
-
- The version 3 UUID is meant for generating UUIDs from "names" that
- are drawn from, and unique within, some "name space". Some examples
- of names (and, implicitly, name spaces) might be DNS names, URLs, ISO
- Object IDs (OIDs), reserved words in a programming language, or X.500
- Distinguished Names (DNs); thus, the concept of name and name space
- should be broadly construed, and not limited to textual names. The
- mechanisms or conventions for allocating names from, and ensuring
- their uniqueness within, their name spaces are beyond the scope of
- this specification.
-
- The requirements for such UUIDs are as follows:
-
- . The UUIDs generated at different times from the same name in the
- same namespace MUST be equal
-
- . The UUIDs generated from two different names in the same namespace
- should be different (with very high probability)
-
- . The UUIDs generated from the same name in two different namespaces
- should be different with (very high probability)
-
- . If two UUIDs that were generated from names are equal, then they
- were generated from the same name in the same namespace (with very
- high probability).
-
- Leach, Salz expires Aug 1998 [Page 10]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
- The algorithm for generating the a UUID from a name and a name space
- are as follows:
-
- . Allocate a UUID to use as a "name space ID" for all UUIDs generated
- from names in that name space
-
- . Convert the name to a canonical sequence of octets (as defined by
- the standards or conventions of its name space); put the name space
- ID in network byte order
-
- . Compute the MD5 [3] hash of the name space ID concatenated with the
- name
-
- . Set octets 0-3 of time_low field to octets 0-3 of the MD5 hash
-
- . Set octets 0-1 of time_mid field to octets 4-5 of the MD5 hash
-
- . Set octets 0-1 of time_hi_and_version field to octets 6-7 of the
- MD5 hash
-
- . Set the clock_seq_hi_and_reserved field to octet 8 of the MD5 hash
-
- . Set the clock_seq_low field to octet 9 of the MD5 hash
-
- . Set octets 0-5 of the node field to octets 10-15 of the MD5 hash
-
- . Set the 2 most significant bits (bits numbered 6 and 7) of the
- clock_seq_hi_and_reserved to 0 and 1, respectively.
-
- . Set the 4 most significant bits (bits numbered 12 to 15 inclusive)
- of the time_hi_and_version field to the 4-bit version number
- corresponding to the UUID version being created, as shown in the
- table above.
-
- . Convert the resulting UUID to local byte order.
-
-
-3.4 Algorithms for creating a UUID from truly random or pseudo-random
-numbers
-
- The version 4 UUID is meant for generating UUIDs from truly-random or
- pseudo-random numbers.
-
- The algorithm is as follows:
-
- . Set the 2 most significant bits (bits numbered 6 and 7) of the
- clock_seq_hi_and_reserved to 0 and 1, respectively.
-
- . Set the 4 most significant bits (bits numbered 12 to 15 inclusive)
- of the time_hi_and_version field to the 4-bit version number
- corresponding to the UUID version being created, as shown in the
- table above.
-
-
-
- Leach, Salz expires Aug 1998 [Page 11]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
- . Set all the other bits to randomly (or pseudo-randomly) chosen
- values.
-
- Here are several possible ways to generate the random values:
-
- . Use a physical source of randomness: for example, a white noise
- generator, radioactive decay, or a lava lamp.
-
- . Use a cryptographic strength random number generator.
-
-
-3.5 String Representation of UUIDs
-
- For use in human readable text, a UUID string representation is
- specified as a sequence of fields, some of which are separated by
- single dashes.
-
- Each field is treated as an integer and has its value printed as a
- zero-filled hexadecimal digit string with the most significant digit
- first. The hexadecimal values a to f inclusive are output as lower
- case characters, and are case insensitive on input. The sequence is
- the same as the UUID constructed type.
-
- The formal definition of the UUID string representation is provided
- by the following extended BNF:
-
- UUID = <time_low> "-" <time_mid> "-"
- <time_high_and_version> "-"
- <clock_seq_and_reserved>
- <clock_seq_low> "-" <node>
- time_low = 4*<hexOctet>
- time_mid = 2*<hexOctet>
- time_high_and_version = 2*<hexOctet>
- clock_seq_and_reserved = <hexOctet>
- clock_seq_low = <hexOctet>
- node = 6*<hexOctet
- hexOctet = <hexDigit> <hexDigit>
- hexDigit =
- "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"
- | "a" | "b" | "c" | "d" | "e" | "f"
- | "A" | "B" | "C" | "D" | "E" | "F"
-
- The following is an example of the string representation of a UUID:
-
- f81d4fae-7dec-11d0-a765-00a0c91e6bf6
-
-3.6 Comparing UUIDs for equality
-
- Consider each field of the UUID to be an unsigned integer as shown in
- the table in section 3.1. Then, to compare a pair of UUIDs,
- arithmetically compare the corresponding fields from each UUID in
- order of significance and according to their data type. Two UUIDs are
- equal if and only if all the corresponding fields are equal.
-
-
- Leach, Salz expires Aug 1998 [Page 12]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
- Note: as a practical matter, on many systems comparison of two UUIDs
- for equality can be performed simply by comparing the 128 bits of
- their in-memory representation considered as a 128 bit unsigned
- integer. Here, it is presumed that by the time the in-memory
- representation is obtained the appropriate byte-order
- canonicalizations have been carried out.
-
-
-3.7 Comparing UUIDs for relative order
-
- Two UUIDs allocated according to the same variant can also be ordered
- lexicographically. For the UUID variant herein defined, the first of
- two UUIDs follows the second if the most significant field in which
- the UUIDs differ is greater for the first UUID. The first of a pair
- of UUIDs precedes the second if the most significant field in which
- the UUIDs differ is greater for the second UUID.
-
-
-3.8 Byte order of UUIDs
-
- UUIDs may be transmitted in many different forms, some of which may
- be dependent on the presentation or application protocol where the
- UUID may be used. In such cases, the order, sizes and byte orders of
- the UUIDs fields on the wire will depend on the relevant presentation
- or application protocol. However, it is strongly RECOMMENDED that
- the order of the fields conform with ordering set out in section 3.1
- above. Furthermore, the payload size of each field in the application
- or presentation protocol MUST be large enough that no information
- lost in the process of encoding them for transmission.
-
- In the absence of explicit application or presentation protocol
- specification to the contrary, a UUID is encoded as a 128-bit object,
- as follows: the fields are encoded as 16 octets, with the sizes and
- order of the fields defined in section 3.1, and with each field
- encoded with the Most Significant Byte first (also known as network
- byte order).
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | time_low |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | time_mid | time_hi_and_version |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |clk_seq_hi_res | clk_seq_low | node (0-1) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | node (2-5) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-
-
-
-
-
- Leach, Salz expires Aug 1998 [Page 13]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
-4. Node IDs when no IEEE 802 network card is available
-
- If a system wants to generate UUIDs but has no IEE 802 compliant
- network card or other source of IEEE 802 addresses, then this section
- describes how to generate one.
-
- The ideal solution is to obtain a 47 bit cryptographic quality random
- number, and use it as the low 47 bits of the node ID, with the most
- significant bit of the first octet of the node ID set to 1. This bit
- is the unicast/multicast bit, which will never be set in IEEE 802
- addresses obtained from network cards; hence, there can never be a
- conflict between UUIDs generated by machines with and without network
- cards.
-
- If a system does not have a primitive to generate cryptographic
- quality random numbers, then in most systems there are usually a
- fairly large number of sources of randomness available from which one
- can be generated. Such sources are system specific, but often
- include:
-
- - the percent of memory in use
- - the size of main memory in bytes
- - the amount of free main memory in bytes
- - the size of the paging or swap file in bytes
- - free bytes of paging or swap file
- - the total size of user virtual address space in bytes
- - the total available user address space bytes
- - the size of boot disk drive in bytes
- - the free disk space on boot drive in bytes
- - the current time
- - the amount of time since the system booted
- - the individual sizes of files in various system directories
- - the creation, last read, and modification times of files in various
- system directories
- - the utilization factors of various system resources (heap, etc.)
- - current mouse cursor position
- - current caret position
- - current number of running processes, threads
- - handles or IDs of the desktop window and the active window
- - the value of stack pointer of the caller
- - the process and thread ID of caller
- - various processor architecture specific performance counters
- (instructions executed, cache misses, TLB misses)
-
- (Note that it precisely the above kinds of sources of randomness that
- are used to seed cryptographic quality random number generators on
- systems without special hardware for their construction.)
-
- In addition, items such as the computer's name and the name of the
- operating system, while not strictly speaking random, will help
- differentiate the results from those obtained by other systems.
-
- The exact algorithm to generate a node ID using these data is system
- specific, because both the data available and the functions to obtain
-
- Leach, Salz expires Aug 1998 [Page 14]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
- them are often very system specific. However, assuming that one can
- concatenate all the values from the randomness sources into a buffer,
- and that a cryptographic hash function such as MD5 [3] is available,
- then any 6 bytes of the MD5 hash of the buffer, with the multicast
- bit (the high bit of the first byte) set will be an appropriately
- random node ID.
-
- Other hash functions, such as SHA-1 [4], can also be used. The only
- requirement is that the result be suitably random _ in the sense that
- the outputs from a set uniformly distributed inputs are themselves
- uniformly distributed, and that a single bit change in the input can
- be expected to cause half of the output bits to change.
-
-
-5. Obtaining IEEE 802 addresses
-
- At the time of writing, the following URL
-
- http://standards.ieee.org/db/oui/forms/
-
- contains information on how to obtain an IEEE 802 address block. At
- the time of writing, the cost is $1250 US.
-
-
-6. Security Considerations
-
- It should not be assumed that UUIDs are hard to guess; they should
- not be used as capabilities.
-
-
-7. Acknowledgements
-
- This document draws heavily on the OSF DCE specification for UUIDs.
- Ted Ts'o provided helpful comments, especially on the byte ordering
- section which we mostly plagiarized from a proposed wording he
- supplied (all errors in that section are our responsibility,
- however).
-
-
-8. References
-
- [1] Lisa Zahn, et. al., Network Computing Architecture, Prentice
- Hall, Englewood Cliffs, NJ, 1990
-
- [2] DCE: Remote Procedure Call, Open Group CAE Specification C309
- ISBN 1-85912-041-5 28cm. 674p. pbk. 1,655g. 8/94
-
- [3] R. Rivest, RFC 1321, "The MD5 Message-Digest Algorithm",
- 04/16/1992.
-
- [4] NIST FIPS PUB 180-1, "Secure Hash Standard," National Institute
- of Standards and Technology, U.S. Department of Commerce, DRAFT, May
- 31, 1994.
-
-
- Leach, Salz expires Aug 1998 [Page 15]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
-9. Authors' addresses
-
- Paul J. Leach
- Microsoft
- 1 Microsoft Way
- Redmond, WA, 98052, U.S.A.
- paulle@microsoft.com
- Tel. 425 882 8080
- Fax. 425 936 7329
-
- Rich Salz
- 100 Cambridge Park Drive
- Cambridge MA 02140
- salzr@certco.com
- Tel. 617 499 4075
- Fax. 617 576 0019
-
-
-10. Notice
-
- The IETF takes no position regarding the validity or scope of any
- intellectual property 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; neither does it represent that it
- has made any effort to identify any such rights. Information on the
- IETF's procedures with respect to rights in standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication 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 implementors or users of this specification can
- be obtained from the IETF Secretariat.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights which may cover technology that may be required to practice
- this standard. Please address the information to the IETF Executive
- Director.
-
-
-11. Full Copyright Statement
-
- Copyright (C) The Internet Society 1997. 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
-
- Leach, Salz expires Aug 1998 [Page 16]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 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.
-
-
- Appendix A _ UUID Sample Implementation
-
- This implementation consists of 5 files: uuid.h, uuid.c, sysdep.h,
- sysdep.c and utest.c. The uuid.* files are the system independent
- implementation of the UUID generation algorithms described above,
- with all the optimizations described above except efficient state
- sharing across processes included. The code has been tested on Linux
- (Red Hat 4.0) with GCC (2.7.2), and Windows NT 4.0 with VC++ 5.0. The
- code assumes 64 bit integer support, which makes it a lot clearer.
-
- All the following source files should be considered to have the
- following copyright notice included:
-
- copyrt.h
-
- /*
- ** Copyright (c) 1990- 1993, 1996 Open Software Foundation, Inc.
- ** Copyright (c) 1989 by Hewlett-Packard Company, Palo Alto, Ca. &
- ** Digital Equipment Corporation, Maynard, Mass.
- ** Copyright (c) 1998 Microsoft.
- ** To anyone who acknowledges that this file is provided "AS IS"
- ** without any express or implied warranty: permission to use, copy,
- ** modify, and distribute this file for any purpose is hereby
- ** granted without fee, provided that the above copyright notices and
- ** this notice appears in all source code copies, and that none of
- ** the names of Open Software Foundation, Inc., Hewlett-Packard
- ** Company, or Digital Equipment Corporation be used in advertising
- ** or publicity pertaining to distribution of the software without
- ** specific, written prior permission. Neither Open Software
- ** Foundation, Inc., Hewlett-Packard Company, Microsoft, nor Digital
- Equipment
- ** Corporation makes any representations about the suitability of
- ** this software for any purpose.
- */
-
-
- uuid.h
-
-
- Leach, Salz expires Aug 1998 [Page 17]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
- #include "copyrt.h"
- #undef uuid_t
- typedef struct _uuid_t {
- unsigned32 time_low;
- unsigned16 time_mid;
- unsigned16 time_hi_and_version;
- unsigned8 clock_seq_hi_and_reserved;
- unsigned8 clock_seq_low;
- byte node[6];
- } uuid_t;
-
- /* uuid_create -- generate a UUID */
- int uuid_create(uuid_t * uuid);
-
- /* uuid_create_from_name -- create a UUID using a "name"
- from a "name space" */
- void uuid_create_from_name(
- uuid_t * uuid, /* resulting UUID */
- uuid_t nsid, /* UUID to serve as context, so identical
- names from different name spaces generate
- different UUIDs */
- void * name, /* the name from which to generate a UUID */
- int namelen /* the length of the name */
- );
-
- /* uuid_compare -- Compare two UUID's "lexically" and return
- -1 u1 is lexically before u2
- 0 u1 is equal to u2
- 1 u1 is lexically after u2
- Note: lexical ordering is not temporal ordering!
- */
- int uuid_compare(uuid_t *u1, uuid_t *u2);
-
- uuid.c
-
- #include "copyrt.h"
- #include <string.h>
- #include <stdio.h>
- #include <stdlib.h>
- #include <time.h>
- #include "sysdep.h"
- #include "uuid.h"
-
- /* various forward declarations */
- static int read_state(unsigned16 *clockseq, uuid_time_t *timestamp,
- uuid_node_t * node);
- static void write_state(unsigned16 clockseq, uuid_time_t timestamp,
- uuid_node_t node);
- static void format_uuid_v1(uuid_t * uuid, unsigned16 clockseq,
- uuid_time_t timestamp, uuid_node_t node);
- static void format_uuid_v3(uuid_t * uuid, unsigned char hash[16]);
- static void get_current_time(uuid_time_t * timestamp);
- static unsigned16 true_random(void);
-
-
- Leach, Salz expires Aug 1998 [Page 18]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
- /* uuid_create -- generator a UUID */
- int uuid_create(uuid_t * uuid) {
- uuid_time_t timestamp, last_time;
- unsigned16 clockseq;
- uuid_node_t node;
- uuid_node_t last_node;
- int f;
-
- /* acquire system wide lock so we're alone */
- LOCK;
-
- /* get current time */
- get_current_time(×tamp);
-
- /* get node ID */
- get_ieee_node_identifier(&node);
-
- /* get saved state from NV storage */
- f = read_state(&clockseq, &last_time, &last_node);
-
- /* if no NV state, or if clock went backwards, or node ID changed
- (e.g., net card swap) change clockseq */
- if (!f || memcmp(&node, &last_node, sizeof(uuid_node_t)))
- clockseq = true_random();
- else if (timestamp < last_time)
- clockseq++;
-
- /* stuff fields into the UUID */
- format_uuid_v1(uuid, clockseq, timestamp, node);
-
- /* save the state for next time */
- write_state(clockseq, timestamp, node);
-
- UNLOCK;
- return(1);
- };
-
- /* format_uuid_v1 -- make a UUID from the timestamp, clockseq,
- and node ID */
- void format_uuid_v1(uuid_t * uuid, unsigned16 clock_seq, uuid_time_t
- timestamp, uuid_node_t node) {
- /* Construct a version 1 uuid with the information we've gathered
- * plus a few constants. */
- uuid->time_low = (unsigned long)(timestamp & 0xFFFFFFFF);
- uuid->time_mid = (unsigned short)((timestamp >> 32) & 0xFFFF);
- uuid->time_hi_and_version = (unsigned short)((timestamp >> 48) &
- 0x0FFF);
- uuid->time_hi_and_version |= (1 << 12);
- uuid->clock_seq_low = clock_seq & 0xFF;
- uuid->clock_seq_hi_and_reserved = (clock_seq & 0x3F00) >> 8;
- uuid->clock_seq_hi_and_reserved |= 0x80;
- memcpy(&uuid->node, &node, sizeof uuid->node);
- };
-
-
- Leach, Salz expires Aug 1998 [Page 19]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
- /* data type for UUID generator persistent state */
- typedef struct {
- uuid_time_t ts; /* saved timestamp */
- uuid_node_t node; /* saved node ID */
- unsigned16 cs; /* saved clock sequence */
- } uuid_state;
-
- static uuid_state st;
-
- /* read_state -- read UUID generator state from non-volatile store */
- int read_state(unsigned16 *clockseq, uuid_time_t *timestamp,
- uuid_node_t *node) {
- FILE * fd;
- static int inited = 0;
-
- /* only need to read state once per boot */
- if (!inited) {
- fd = fopen("state", "rb");
- if (!fd)
- return (0);
- fread(&st, sizeof(uuid_state), 1, fd);
- fclose(fd);
- inited = 1;
- };
- *clockseq = st.cs;
- *timestamp = st.ts;
- *node = st.node;
- return(1);
- };
-
- /* write_state -- save UUID generator state back to non-volatile
- storage */
- void write_state(unsigned16 clockseq, uuid_time_t timestamp,
- uuid_node_t node) {
- FILE * fd;
- static int inited = 0;
- static uuid_time_t next_save;
-
- if (!inited) {
- next_save = timestamp;
- inited = 1;
- };
- /* always save state to volatile shared state */
- st.cs = clockseq;
- st.ts = timestamp;
- st.node = node;
- if (timestamp >= next_save) {
- fd = fopen("state", "wb");
- fwrite(&st, sizeof(uuid_state), 1, fd);
- fclose(fd);
- /* schedule next save for 10 seconds from now */
- next_save = timestamp + (10 * 10 * 1000 * 1000);
- };
- };
-
- Leach, Salz expires Aug 1998 [Page 20]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
-
- /* get-current_time -- get time as 60 bit 100ns ticks since whenever.
- Compensate for the fact that real clock resolution is
- less than 100ns. */
- void get_current_time(uuid_time_t * timestamp) {
- uuid_time_t time_now;
- static uuid_time_t time_last;
- static unsigned16 uuids_this_tick;
- static int inited = 0;
-
- if (!inited) {
- get_system_time(&time_now);
- uuids_this_tick = UUIDS_PER_TICK;
- inited = 1;
- };
-
- while (1) {
- get_system_time(&time_now);
-
- /* if clock reading changed since last UUID generated... */
- if (time_last != time_now) {
- /* reset count of uuids gen'd with this clock reading */
- uuids_this_tick = 0;
- break;
- };
- if (uuids_this_tick < UUIDS_PER_TICK) {
- uuids_this_tick++;
- break;
- };
- /* going too fast for our clock; spin */
- };
- /* add the count of uuids to low order bits of the clock reading */
- *timestamp = time_now + uuids_this_tick;
- };
-
- /* true_random -- generate a crypto-quality random number.
- This sample doesn't do that. */
- static unsigned16
- true_random(void)
- {
- static int inited = 0;
- uuid_time_t time_now;
-
- if (!inited) {
- get_system_time(&time_now);
- time_now = time_now/UUIDS_PER_TICK;
- srand((unsigned int)(((time_now >> 32) ^ time_now)&0xffffffff));
- inited = 1;
- };
-
- return (rand());
- }
-
-
-
- Leach, Salz expires Aug 1998 [Page 21]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
- /* uuid_create_from_name -- create a UUID using a "name" from a "name
- space" */
- void uuid_create_from_name(
- uuid_t * uuid, /* resulting UUID */
- uuid_t nsid, /* UUID to serve as context, so identical
- names from different name spaces generate
- different UUIDs */
- void * name, /* the name from which to generate a UUID */
- int namelen /* the length of the name */
- ) {
- MD5_CTX c;
- unsigned char hash[16];
- uuid_t net_nsid; /* context UUID in network byte order */
-
- /* put name space ID in network byte order so it hashes the same
- no matter what endian machine we're on */
- net_nsid = nsid;
- htonl(net_nsid.time_low);
- htons(net_nsid.time_mid);
- htons(net_nsid.time_hi_and_version);
-
- MD5Init(&c);
- MD5Update(&c, &net_nsid, sizeof(uuid_t));
- MD5Update(&c, name, namelen);
- MD5Final(hash, &c);
-
- /* the hash is in network byte order at this point */
- format_uuid_v3(uuid, hash);
- };
-
- /* format_uuid_v3 -- make a UUID from a (pseudo)random 128 bit number
- */
- void format_uuid_v3(uuid_t * uuid, unsigned char hash[16]) {
- /* Construct a version 3 uuid with the (pseudo-)random number
- * plus a few constants. */
-
- memcpy(uuid, hash, sizeof(uuid_t));
-
- /* convert UUID to local byte order */
- ntohl(uuid->time_low);
- ntohs(uuid->time_mid);
- ntohs(uuid->time_hi_and_version);
-
- /* put in the variant and version bits */
- uuid->time_hi_and_version &= 0x0FFF;
- uuid->time_hi_and_version |= (3 << 12);
- uuid->clock_seq_hi_and_reserved &= 0x3F;
- uuid->clock_seq_hi_and_reserved |= 0x80;
- };
-
- /* uuid_compare -- Compare two UUID's "lexically" and return
- -1 u1 is lexically before u2
- 0 u1 is equal to u2
- 1 u1 is lexically after u2
-
- Leach, Salz expires Aug 1998 [Page 22]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
- Note: lexical ordering is not temporal ordering!
- */
- int uuid_compare(uuid_t *u1, uuid_t *u2)
- {
- int i;
-
- #define CHECK(f1, f2) if (f1 != f2) return f1 < f2 ? -1 : 1;
- CHECK(u1->time_low, u2->time_low);
- CHECK(u1->time_mid, u2->time_mid);
- CHECK(u1->time_hi_and_version, u2->time_hi_and_version);
- CHECK(u1->clock_seq_hi_and_reserved, u2->clock_seq_hi_and_reserved);
- CHECK(u1->clock_seq_low, u2->clock_seq_low)
- for (i = 0; i < 6; i++) {
- if (u1->node[i] < u2->node[i])
- return -1;
- if (u1->node[i] > u2->node[i])
- return 1;
- }
- return 0;
- };
-
- sysdep.h
-
- #include "copyrt.h"
- /* remove the following define if you aren't running WIN32 */
- #define WININC 0
-
- #ifdef WININC
- #include <windows.h>
- #else
- #include <sys/types.h>
- #include <sys/time.h>
- #include <sys/sysinfo.h>
- #endif
-
- /* change to point to where MD5 .h's live */
- /* get MD5 sample implementation from RFC 1321 */
- #include "global.h"
- #include "md5.h"
-
- /* set the following to the number of 100ns ticks of the actual
- resolution of
- your system's clock */
- #define UUIDS_PER_TICK 1024
-
- /* Set the following to a call to acquire a system wide global lock
- */
- #define LOCK
- #define UNLOCK
-
- typedef unsigned long unsigned32;
- typedef unsigned short unsigned16;
- typedef unsigned char unsigned8;
- typedef unsigned char byte;
-
- Leach, Salz expires Aug 1998 [Page 23]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
-
- /* Set this to what your compiler uses for 64 bit data type */
- #ifdef WININC
- #define unsigned64_t unsigned __int64
- #define I64(C) C
- #else
- #define unsigned64_t unsigned long long
- #define I64(C) C##LL
- #endif
-
-
- typedef unsigned64_t uuid_time_t;
- typedef struct {
- char nodeID[6];
- } uuid_node_t;
-
- void get_ieee_node_identifier(uuid_node_t *node);
- void get_system_time(uuid_time_t *uuid_time);
- void get_random_info(char seed[16]);
-
-
- sysdep.c
-
- #include "copyrt.h"
- #include <stdio.h>
- #include "sysdep.h"
-
- /* system dependent call to get IEEE node ID.
- This sample implementation generates a random node ID
- */
- void get_ieee_node_identifier(uuid_node_t *node) {
- char seed[16];
- FILE * fd;
- static inited = 0;
- static uuid_node_t saved_node;
-
- if (!inited) {
- fd = fopen("nodeid", "rb");
- if (fd) {
- fread(&saved_node, sizeof(uuid_node_t), 1, fd);
- fclose(fd);
- }
- else {
- get_random_info(seed);
- seed[0] |= 0x80;
- memcpy(&saved_node, seed, sizeof(uuid_node_t));
- fd = fopen("nodeid", "wb");
- if (fd) {
- fwrite(&saved_node, sizeof(uuid_node_t), 1, fd);
- fclose(fd);
- };
- };
- inited = 1;
- };
-
- Leach, Salz expires Aug 1998 [Page 24]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
- *node = saved_node;
- };
-
- /* system dependent call to get the current system time.
- Returned as 100ns ticks since Oct 15, 1582, but resolution may be
- less than 100ns.
- */
- #ifdef _WINDOWS_
-
- void get_system_time(uuid_time_t *uuid_time) {
- ULARGE_INTEGER time;
-
- GetSystemTimeAsFileTime((FILETIME *)&time);
-
- /* NT keeps time in FILETIME format which is 100ns ticks since
- Jan 1, 1601. UUIDs use time in 100ns ticks since Oct 15, 1582.
- The difference is 17 Days in Oct + 30 (Nov) + 31 (Dec)
- + 18 years and 5 leap days.
- */
-
- time.QuadPart +=
- (unsigned __int64) (1000*1000*10) // seconds
- * (unsigned __int64) (60 * 60 * 24) // days
- * (unsigned __int64) (17+30+31+365*18+5); // # of days
-
- *uuid_time = time.QuadPart;
-
- };
-
- void get_random_info(char seed[16]) {
- MD5_CTX c;
- typedef struct {
- MEMORYSTATUS m;
- SYSTEM_INFO s;
- FILETIME t;
- LARGE_INTEGER pc;
- DWORD tc;
- DWORD l;
- char hostname[MAX_COMPUTERNAME_LENGTH + 1];
- } randomness;
- randomness r;
-
- MD5Init(&c);
- /* memory usage stats */
- GlobalMemoryStatus(&r.m);
- /* random system stats */
- GetSystemInfo(&r.s);
- /* 100ns resolution (nominally) time of day */
- GetSystemTimeAsFileTime(&r.t);
- /* high resolution performance counter */
- QueryPerformanceCounter(&r.pc);
- /* milliseconds since last boot */
- r.tc = GetTickCount();
- r.l = MAX_COMPUTERNAME_LENGTH + 1;
-
- Leach, Salz expires Aug 1998 [Page 25]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
- GetComputerName(r.hostname, &r.l );
- MD5Update(&c, &r, sizeof(randomness));
- MD5Final(seed, &c);
- };
- #else
-
- void get_system_time(uuid_time_t *uuid_time)
- {
- struct timeval tp;
-
- gettimeofday(&tp, (struct timezone *)0);
-
- /* Offset between UUID formatted times and Unix formatted times.
- UUID UTC base time is October 15, 1582.
- Unix base time is January 1, 1970.
- */
- *uuid_time = (tp.tv_sec * 10000000) + (tp.tv_usec * 10) +
- I64(0x01B21DD213814000);
- };
-
- void get_random_info(char seed[16]) {
- MD5_CTX c;
- typedef struct {
- struct sysinfo s;
- struct timeval t;
- char hostname[257];
- } randomness;
- randomness r;
-
- MD5Init(&c);
- sysinfo(&r.s);
- gettimeofday(&r.t, (struct timezone *)0);
- gethostname(r.hostname, 256);
- MD5Update(&c, &r, sizeof(randomness));
- MD5Final(seed, &c);
- };
-
- #endif
-
- utest.c
-
- #include "copyrt.h"
- #include "sysdep.h"
- #include <stdio.h>
- #include "uuid.h"
-
- uuid_t NameSpace_DNS = { /* 6ba7b810-9dad-11d1-80b4-00c04fd430c8 */
- 0x6ba7b810,
- 0x9dad,
- 0x11d1,
- 0x80, 0xb4, 0x00, 0xc0, 0x4f, 0xd4, 0x30, 0xc8
- };
-
-
-
- Leach, Salz expires Aug 1998 [Page 26]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
- /* puid -- print a UUID */
- void puid(uuid_t u);
-
- /* Simple driver for UUID generator */
- void main(int argc, char **argv) {
- uuid_t u;
- int f;
-
- uuid_create(&u);
- printf("uuid_create() -> "); puid(u);
-
- f = uuid_compare(&u, &u);
- printf("uuid_compare(u,u): %d\n", f); /* should be 0 */
- f = uuid_compare(&u, &NameSpace_DNS);
- printf("uuid_compare(u, NameSpace_DNS): %d\n", f); /* s.b. 1 */
- f = uuid_compare(&NameSpace_DNS, &u);
- printf("uuid_compare(NameSpace_DNS, u): %d\n", f); /* s.b. -1 */
-
- uuid_create_from_name(&u, NameSpace_DNS, "www.widgets.com", 15);
- printf("uuid_create_from_name() -> "); puid(u);
- };
-
- void puid(uuid_t u) {
- int i;
-
- printf("%8.8x-%4.4x-%4.4x-%2.2x%2.2x-", u.time_low, u.time_mid,
- u.time_hi_and_version, u.clock_seq_hi_and_reserved,
- u.clock_seq_low);
- for (i = 0; i < 6; i++)
- printf("%2.2x", u.node[i]);
- printf("\n");
- };
-
-Appendix B _ Sample output of utest
-
- uuid_create() -> 7d444840-9dc0-11d1-b245-5ffdce74fad2
- uuid_compare(u,u): 0
- uuid_compare(u, NameSpace_DNS): 1
- uuid_compare(NameSpace_DNS, u): -1
- uuid_create_from_name() -> e902893a-9d22-3c7e-a7b8-d6e313b71d9f
-
-Appendix C _ Some name space IDs
-
- This appendix lists the name space IDs for some potentially
- interesting name spaces, as initialized C structures and in the
- string representation defined in section 3.5
-
- uuid_t NameSpace_DNS = { /* 6ba7b810-9dad-11d1-80b4-00c04fd430c8 */
- 0x6ba7b810,
- 0x9dad,
- 0x11d1,
- 0x80, 0xb4, 0x00, 0xc0, 0x4f, 0xd4, 0x30, 0xc8
- };
-
-
- Leach, Salz expires Aug 1998 [Page 27]\f
-
-
- Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98
-
-
- uuid_t NameSpace_URL = { /* 6ba7b811-9dad-11d1-80b4-00c04fd430c8 */
- 0x6ba7b811,
- 0x9dad,
- 0x11d1,
- 0x80, 0xb4, 0x00, 0xc0, 0x4f, 0xd4, 0x30, 0xc8
- };
-
- uuid_t NameSpace_OID = { /* 6ba7b812-9dad-11d1-80b4-00c04fd430c8 */
- 0x6ba7b812,
- 0x9dad,
- 0x11d1,
- 0x80, 0xb4, 0x00, 0xc0, 0x4f, 0xd4, 0x30, 0xc8
- };
-
- uuid_t NameSpace_X500 = { /* 6ba7b814-9dad-11d1-80b4-00c04fd430c8 */
- 0x6ba7b814,
- 0x9dad,
- 0x11d1,
- 0x80, 0xb4, 0x00, 0xc0, 0x4f, 0xd4, 0x30, 0xc8
- };
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
INTERNET-DRAFT S. Legg
-draft-legg-ldap-acm-admin-01.txt Adacel Technologies
-Intended Category: Standards Track September 18, 2002
+draft-legg-ldap-acm-admin-02.txt Adacel Technologies
+Intended Category: Standards Track February 25, 2003
Access Control Administration in LDAP
- Copyright (C) The Internet Society (2002). All Rights Reserved.
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
Status of this Memo
to the LDUP working group mailing list <ietf-ldup@imc.org> or to the
author.
- This Internet-Draft expires on 18 March 2003.
+ This Internet-Draft expires on 25 August 2003.
1. Abstract
-Legg Expires 18 March 2003 [Page 1]
+Legg Expires 25 August 2003 [Page 1]
\f
-INTERNET-DRAFT Access Control Administration September 18, 2002
-
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [RFC2119].
+INTERNET-DRAFT Access Control Administration February 25, 2003
2. Table of Contents
- 1. Abstract .................................................... 1
- 2. Table of Contents ........................................... 2
- 3. Introduction ................................................ 2
- 4. Access Control Administrative Areas ......................... 3
- 5. Access Control Scheme Indication ............................ 3
- 6. Access Control Information .................................. 4
- 7. Access Control Subentries ................................... 4
- 8. Applicable Access Control Information ....................... 5
- 9. Security Considerations ..................................... 5
- 10. Acknowledgements ........................................... 6
- 11. Normative References ....................................... 6
- 12. Informative References ..................................... 6
- 13. Copyright Notice ........................................... 7
- 14. Author's Address ........................................... 7
+ 1. Abstract ...................................................... 1
+ 2. Table of Contents ............................................. 2
+ 3. Introduction .................................................. 2
+ 4. Conventions ................................................... 2
+ 5. Access Control Administrative Areas ........................... 3
+ 6. Access Control Scheme Indication .............................. 3
+ 7. Access Control Information .................................... 4
+ 8. Access Control Subentries ..................................... 4
+ 9. Applicable Access Control Information ......................... 5
+ 10. Security Considerations ...................................... 6
+ 11. Acknowledgements ............................................. 6
+ 12. IANA Considerations .......................................... 6
+ 13. Normative References ......................................... 7
+ 14. Informative References ....................................... 7
+ 15. Copyright Notice ............................................. 7
+ 16. Author's Address ............................................. 8
3. Introduction
This document adapts the X.500 directory administrative model [X501],
as it pertains to access control administration, for use by the
- Lightweight Directory Access Protocol (LDAP) [RFC2251].
+ Lightweight Directory Access Protocol (LDAP) [RFC3377].
The administrative model [ADMIN] partitions the Directory Information
Tree (DIT) for various aspects of directory data administration, e.g.
employing access control schemes but does not define a particular
access control scheme. Two access control schemes known as Basic
Access Control and Simplified Access Control are defined by [BAC].
- Other access control schemes MAY be defined by other documents.
+ Other access control schemes may be defined by other documents.
- Schema definitions are provided using LDAP description formats
- [RFC2252]. Note that the LDAP descriptions have been rendered with
- additional white-space and line breaks for the sake of readability.
+ This document is derived from, and duplicates substantial portions
+ of, Sections 4 and 8 of [X501].
+
+4. Conventions
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-Legg Expires 18 March 2003 [Page 2]
+Legg Expires 25 August 2003 [Page 2]
\f
-INTERNET-DRAFT Access Control Administration September 18, 2002
+INTERNET-DRAFT Access Control Administration February 25, 2003
- This document is derived from, and duplicates substantial portions
- of, Sections 4 and 8 of [X501].
+ document are to be interpreted as described in RFC 2119 [RFC2119].
+
+ Schema definitions are provided using LDAP description formats
+ [RFC2252]. Note that the LDAP descriptions have been rendered with
+ additional white-space and line breaks for the sake of readability.
-4. Access Control Administrative Areas
+5. Access Control Administrative Areas
The specific administrative area [ADMIN] for access control is termed
an Access Control Specific Area (ACSA). The root of the ACSA is
Control Information (ACI).
-5. Access Control Scheme Indication
+6. Access Control Scheme Indication
The access control scheme (e.g. Basic Access Control [BAC]) in force
in an ACSA is indicated by the accessControlScheme operational
( 2.5.24.1 NAME 'accessControlScheme'
EQUALITY objectIdentifierMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
- SINGLE-VALUE USAGE directoryOperation )
-
- An access control scheme conforming to the access control framework
-Legg Expires 18 March 2003 [Page 3]
+Legg Expires 25 August 2003 [Page 3]
\f
-INTERNET-DRAFT Access Control Administration September 18, 2002
+INTERNET-DRAFT Access Control Administration February 25, 2003
+
+ SINGLE-VALUE USAGE directoryOperation )
+ An access control scheme conforming to the access control framework
described in this document MUST define a distinct OBJECT IDENTIFIER
value to identify it through the accessControlScheme attribute.
+ Object Identifier Descriptors for access control scheme identifiers
+ may be registered with IANA [RFC3383].
Only administrative entries for ACSPs are permitted to contain an
accessControlScheme attribute. If the accessControlScheme attribute
attribute of the ACSP.
-6. Access Control Information
+7. Access Control Information
There are three categories of Access Control Information (ACI):
entry, subentry and prescriptive.
subentries are within the subtree or subtree refinement.
-7. Access Control Subentries
+8. Access Control Subentries
Each subentry which contains prescriptive ACI MUST have
- accessControlSubentry as a value of its objectClass attribute. Such
- a subentry is called an access control subentry.
-
- The LDAP description [RFC2252] for the accessControlSubentry
- auxiliary object class is:
-Legg Expires 18 March 2003 [Page 4]
+Legg Expires 25 August 2003 [Page 4]
\f
-INTERNET-DRAFT Access Control Administration September 18, 2002
+INTERNET-DRAFT Access Control Administration February 25, 2003
+
+
+ accessControlSubentry as a value of its objectClass attribute. Such
+ a subentry is called an access control subentry.
+ The LDAP description [RFC2252] for the accessControlSubentry
+ auxiliary object class is:
( 2.5.17.1 NAME 'accessControlSubentry' AUXILIARY )
within a given ACSA may arbitrarily overlap.
-8. Applicable Access Control Information
+9. Applicable Access Control Information
Although particular items of ACI may specify attributes or values as
the protected items, ACI is logically associated with entries.
administrative point as the subentry for which the decision is
being made.
- (3) Subentry ACI from the administrative point associated with the
- subentry.
-9. Security Considerations
+Legg Expires 25 August 2003 [Page 5]
+\f
+INTERNET-DRAFT Access Control Administration February 25, 2003
+ (3) Subentry ACI from the administrative point associated with the
+ subentry.
-Legg Expires 18 March 2003 [Page 5]
-\f
-INTERNET-DRAFT Access Control Administration September 18, 2002
+10. Security Considerations
This document defines a framework for employing an access control
scheme, i.e. the means by which access to directory information and
general [ADMIN] also apply to access control administration.
-10. Acknowledgements
+11. Acknowledgements
This document is derived from, and duplicates substantial portions
of, Sections 4 and 8 of [X501].
-11. Normative References
+12. IANA Considerations
+
+ The Internet Assigned Numbers Authority (IANA) is requested to update
+ the LDAP descriptors registry as indicated by the following
+ templates:
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): accessControlScheme
+ Object Identifier: 2.5.24.1
+ Person & email address to contact for further information:
+ Steven Legg <steven.legg@adacel.com.au>
+ Usage: attribute type
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): accessControlSubentry
+ Object Identifier: 2.5.17.1
+ Person & email address to contact for further information:
+ Steven Legg <steven.legg@adacel.com.au>
+ Usage: object class
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+
+
+
+
+Legg Expires 25 August 2003 [Page 6]
+\f
+INTERNET-DRAFT Access Control Administration February 25, 2003
+
+
+13. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
- Access Protocol (v3)", RFC 2251, December 1997.
-
[RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
"Lightweight Directory Access Protocol (v3): Attribute
Syntax Definitions", RFC 2252, December 1997.
- [ADMIN] Legg, S., "Directory Administrative Model in LDAP",
- draft-legg-ldap-admin-xx.txt, a work in progress,
+ [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
September 2002.
+ [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA
+ Considerations for the Lightweight Directory Access
+ Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
+
+ [ADMIN] Legg, S., "Directory Administrative Model in LDAP",
+ draft-legg-ldap-admin-xx.txt, a work in progress, February
+ 2003.
+
[SUBENTRY] Zeilenga, K. and S. Legg, "Subentries in LDAP",
draft-zeilenga-ldap-subentry-xx.txt, a work in progress,
August 2002.
-12. Informative References
+14. Informative References
[BAC] Legg, S., "Basic and Simplified Access Control in LDAP",
draft-legg-ldap-acm-bac-xx.txt, a work in progress,
- September 2002.
+ February 2003.
[COLLECT] Zeilenga, K., "Collective Attributes in LDAP",
draft-zeilenga-ldap-collective-xx.txt, a work in progress,
August 2002.
-
-
-Legg Expires 18 March 2003 [Page 6]
-\f
-INTERNET-DRAFT Access Control Administration September 18, 2002
-
-
[X501] ITU-T Recommendation X.501 (02/2001), Information
technology - Open Systems Interconnection - The Directory:
Models
-13. Copyright Notice
+15. Copyright Notice
- Copyright (C) The Internet Society (2002). All Rights Reserved.
+ Copyright (C) The Internet Society (2003). 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
+
+
+
+Legg Expires 25 August 2003 [Page 7]
+\f
+INTERNET-DRAFT Access Control Administration February 25, 2003
+
+
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
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-14. Author's Address
+16. Author's Address
Steven Legg
Adacel Technologies Ltd.
- 405-409 Ferntree Gully Road
- Mount Waverley, Victoria 3149
+ 250 Bay Street
+ Brighton, Victoria 3186
AUSTRALIA
- Phone: +61 3 9451 2107
- Fax: +61 3 9541 2121
+ Phone: +61 3 8530 7710
+ Fax: +61 3 8530 7888
EMail: steven.legg@adacel.com.au
-15. Appendix A - Changes From Previous Drafts
+Appendix A - Changes From Previous Drafts
+
+A.1 Changes in Draft 01
+
+ Section 4 has been extracted to become a separate Internet draft,
+ draft-legg-ldap-admin-00.txt. The subsections of Section 5 have
+ become the new Sections 4 to 8. Editorial changes have been made to
+ accommodate this split. No technical changes have been introduced.
+
+A.2 Changes in Draft 02
+ RFC 3377 replaces RFC 2251 as the reference for LDAP.
-Legg Expires 18 March 2003 [Page 7]
+
+
+Legg Expires 25 August 2003 [Page 8]
\f
-INTERNET-DRAFT Access Control Administration September 18, 2002
+INTERNET-DRAFT Access Control Administration February 25, 2003
+
+
+ An IANA Considerations section has been added.
+
+
-15.1 Changes in Draft 01
- Section 4 has been extracted to become a separate Internet draft,
- draft-legg-ldap-admin-00.txt. The subsections of Section 5 have
- become the new Sections 4 to 8. Editorial changes have been made to
- accommodate this split. No technical changes have been introduced.
-Legg Expires 18 March 2003 [Page 8]
+Legg Expires 25 August 2003 [Page 9]
\f
--- /dev/null
+
+
+
+
+
+
+INTERNET-DRAFT S. Legg
+draft-legg-ldap-acm-bac-02.txt Adacel Technologies
+Intended Category: Standards Track February 25, 2003
+Updates: RFC 2252
+
+
+ Basic and Simplified Access Control in LDAP
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+ Status of this Memo
+
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC2026.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as
+ Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress".
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ Distribution of this document is unlimited. Comments should be sent
+ to the LDUP working group mailing list <ietf-ldup@imc.org> or to the
+ author.
+
+ This Internet-Draft expires on 25 August 2003.
+
+
+1. Abstract
+
+ An access control scheme describes the means by which access to
+ directory information and potentially to access rights themselves may
+ be controlled. This document adapts the X.500 directory Basic Access
+ Control and Simplied Access Control schemes for use by the
+ Lightweight Directory Access Protocol.
+
+
+
+
+
+Legg Expires 25 August 2003 [Page 1]
+\f
+INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
+
+
+2. Table of Contents
+
+ 1. Abstract ...................................................... 1
+ 2. Table of Contents ............................................. 2
+ 3. Introduction .................................................. 3
+ 4. Conventions ................................................... 3
+ 5. Basic Access Control .......................................... 4
+ 5.1 Permissions ............................................... 5
+ 5.1.1 Read ................................................. 5
+ 5.1.2 Compare .............................................. 6
+ 5.1.3 Browse ............................................... 6
+ 5.1.4 ReturnDN ............................................. 6
+ 5.1.5 FilterMatch .......................................... 6
+ 5.1.6 Modify ............................................... 6
+ 5.1.7 Add .................................................. 7
+ 5.1.8 Remove ............................................... 7
+ 5.1.9 DiscloseOnError ...................................... 7
+ 5.1.10 Rename .............................................. 7
+ 5.1.11 Export .............................................. 8
+ 5.1.12 Import .............................................. 8
+ 5.1.13 Invoke .............................................. 8
+ 5.2 Representation of Access Control Information .............. 8
+ 5.2.1 Identification Tag ................................... 11
+ 5.2.2 Precedence ........................................... 11
+ 5.2.3 Authentication Level ................................. 12
+ 5.2.4 itemFirst and userFirst Components ................... 13
+ 5.2.5 Determining Group Membership ......................... 16
+ 5.3 ACI Operational Attributes ................................ 17
+ 5.3.1 Prescriptive ACI ..................................... 17
+ 5.3.2 Entry ACI ............................................ 18
+ 5.3.3 Subentry ACI ......................................... 18
+ 5.3.4 Protecting the ACI ................................... 18
+ 5.4 Access Control Decision Points for LDAP Operations ........ 19
+ 5.4.1 Common Elements of Procedure ......................... 19
+ 5.4.1.1 Alias Dereferencing ............................. 19
+ 5.4.1.2 Return of Names in Errors ....................... 20
+ 5.4.1.3 Non-disclosure of the Existence of an Entry ..... 20
+ 5.4.2 Compare Operation Decision Points .................... 21
+ 5.4.3 Search Operation Decision Points ..................... 21
+ 5.4.4 Add Operation Decision Points ........................ 24
+ 5.4.5 Delete Operation Decision Points ..................... 25
+ 5.4.6 Modify Operation Decision Points ..................... 25
+ 5.4.7 Modify DN Operation Decision Points .................. 26
+ 5.5 Access Control Decision Function .......................... 27
+ 5.5.1 Inputs ............................................... 27
+ 5.5.2 Tuples ............................................... 27
+ 5.5.3 Discarding Irrelevant Tuples ......................... 28
+ 5.5.4 Highest Precedence and Specificity ................... 29
+
+
+
+Legg Expires 25 August 2003 [Page 2]
+\f
+INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
+
+
+ 6. Simplified Access Control ..................................... 29
+ 7. Security Considerations ....................................... 30
+ 8. Acknowledgements .............................................. 30
+ 9. IANA Considerations ........................................... 30
+ 10. Normative References ......................................... 31
+ 11. Informative References ....................................... 32
+ 12. Copyright Notice ............................................. 33
+ 13. Author's Address ............................................. 33
+ Appendix A. LDAP Specific Encoding for the ACI Item Syntax ....... 33
+
+
+3. Introduction
+
+ An access control scheme describes the means by which access to
+ directory information and potentially to access rights themselves may
+ be controlled. Control of access to information means the prevention
+ of unauthorized detection, disclosure, or modification of that
+ information. The definition of an access control scheme in the
+ context of a Lightweight Directory Access Protocol (LDAP) [RFC3371]
+ directory includes methods to specify Access Control Information
+ (ACI), and to enforce access rights defined by that ACI.
+
+ This document adapts the X.500 Basic Access Control and Simplied
+ Access Control schemes [X501] for use in LDAP. Both schemes conform
+ to, and make use of, the access control administrative framework
+ described in [ACA].
+
+ Section 5 describes the Basic Access Control scheme and defines how
+ it applies to LDAP operations [RFC2251].
+
+ Simplified Access Control is a functional subset of the Basic Access
+ Control scheme. This subset is described in Section 6.
+
+ As a matter of security policy, an implementation supporting Basic
+ Access Control or Simplified Access Control is permitted to grant or
+ deny any form of access to particular attributes (e.g. password
+ attributes) irrespective of access controls which may otherwise
+ apply. However, since such security policy has no standardized
+ representation, it cannot be propagated in replicated information.
+
+ This document is derived from, and duplicates substantial portions
+ of, Section 8 of [X501], and selected extracts from [X511].
+
+4. 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 RFC 2119 [RFC2119].
+
+
+
+Legg Expires 25 August 2003 [Page 3]
+\f
+INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
+
+
+ Schema definitions are provided using LDAP description formats
+ [RFC2252]. Note that the LDAP descriptions have been rendered with
+ additional white-space and line breaks for the sake of readability.
+
+
+5. Basic Access Control
+
+ This section describes the functionality of the Basic Access Control
+ scheme.
+
+ When Basic Access Control is used, the accessControlScheme
+ operational attribute [ACA] SHALL have the value basic-access-control
+ (2.5.28.1).
+
+ This LDAP profile for Basic Access Control defines, for every LDAP
+ operation, one or more points at which access control decisions take
+ place. An access control decision will involve a requestor,
+ protected items, and permissions.
+
+ A requestor is the user requesting the operation. Basic Access
+ Control requires a user's authorization identity to be represented as
+ a distinguished name (with an optional unique identifier). The
+ mapping of the authentication identity to an authorization identity,
+ and the mapping of the authorization identity to a distinguished name
+ and optional unique identifier, are outside the scope of this
+ document.
+
+ A protected item is the element of directory information being
+ accessed. The protected items are entries, attributes, attribute
+ values and distinguished names. Access to each protected item can be
+ separately controlled through ACI.
+
+ A permission is a particular right necessary to complete a portion of
+ the operation.
+
+ The Access Control Information, which is used to make access control
+ decisions, associates protected items and user classes with
+ permissions. ACI is represented in the directory as values of
+ operational attributes with the ACI Item syntax [RFC2252]. Each such
+ value is referred to as an ACI item.
+
+ The scope of access controls can be a single entry or a collection of
+ entries that are logically related by being within the scope of an
+ access control subentry of an administrative point (see [ACA]).
+
+ The Access Control Decision Function (ACDF) (Section 5.5) is used to
+ decide whether a particular requestor has a particular access right
+ by virtue of applicable ACI items.
+
+
+
+Legg Expires 25 August 2003 [Page 4]
+\f
+INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
+
+
+ Access to DSEs and operational attributes is controlled in the same
+ way as for entries and user attributes.
+
+ For query purposes, collective attributes [COLLECT] that are
+ associated with an entry are protected precisely as if they were
+ attributes actually stored in that entry.
+
+ For the purposes of modification, collective attributes are
+ associated with the subentry that holds them, not with entries within
+ the scope of the subentry. Modify-related access controls are
+ therefore not relevant to collective attributes, except when they
+ apply to the collective attribute and its values within the subentry.
+
+
+5.1 Permissions
+
+ Access is controlled by granting or denying permissions. Access is
+ allowed only when there is an explicitly provided grant present in
+ the ACI used to make the access control decision. The only default
+ access decision provided in the model is to deny access in the
+ absence of explicit ACI that grants access. All other factors being
+ equal, a denial specified in ACI always overrides a grant.
+
+ Certain combinations of grants or denials are illogical, but it is
+ the responsibility of directory clients, rather than the directory
+ server, to ensure that such combinations are absent.
+
+ The decision whether or not to permit access to an entry or its
+ contents is strictly determined by the position of the entry in the
+ Directory Information Tree (DIT), in terms of its distinguished name,
+ and is independent of how the directory server locates that entry.
+
+ The following sections introduce the permissions by indicating the
+ intent associated with the granting of each. The actual influence of
+ a particular granted permission on access control decisions are,
+ however, determined by the ACDF and the access control decision
+ points for each LDAP operation, described in detail in Section 5.4.
+
+
+5.1.1 Read
+
+ If granted for an entry, Read permits the entry to be accessed using
+ LDAP Compare and baseObject Search operations, but does not imply
+ access to all the attributes and values.
+
+ If granted for an attribute type, Read permits the attribute type to
+ be returned as entry information in a Search result. Read or Browse
+ permission for the entry is a prerequisite.
+
+
+
+Legg Expires 25 August 2003 [Page 5]
+\f
+INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
+
+
+ If granted for an attribute value, Read permits the attribute value
+ to be returned as entry information in a Search result. Read or
+ Browse permission for the entry and Read permission for the attribute
+ type are prerequisites.
+
+
+5.1.2 Compare
+
+ If granted for an attribute type, Compare permits the attribute type
+ to be tested by the assertion in an LDAP Compare operation. Read
+ permission for the entry is a prerequisite.
+
+ If granted for an attribute value, Compare permits the value to be
+ tested by the assertion in an LDAP Compare operation. Read
+ permission for the entry and Compare permission for the attribute
+ type are prerequisites.
+
+
+5.1.3 Browse
+
+ If granted for an entry, Browse permits the entry to be accessed by
+ the LDAP Search operation, including baseObject searches, but does
+ not imply access to all the attributes and values.
+
+
+5.1.4 ReturnDN
+
+ If granted for an entry, ReturnDN allows the distinguished name of
+ the entry to be disclosed in a search result.
+
+
+5.1.5 FilterMatch
+
+ If granted for an attribute type, Filtermatch permits the attribute
+ type to satisfy a Filter item.
+
+ If granted for an attribute value, Filtermatch permits the attribute
+ value to satisfy a Filter item. FilterMatch permission for the
+ attribute type is a prerequisite.
+
+
+5.1.6 Modify
+
+ If granted for an entry, Modify permits the information contained
+ within an entry to be modified by the LDAP Modify operation, subject
+ to controls on the attribute types and values.
+
+
+
+
+
+Legg Expires 25 August 2003 [Page 6]
+\f
+INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
+
+
+5.1.7 Add
+
+ If granted for an entry, Add permits creation of an entry in the DIT,
+ subject to being able to add all specified attributes and attribute
+ values. Add permission granted for an entry is ineffective if Add
+ permission is not also granted for at least the mandatory attributes
+ and their values. There is no specific "add subordinate permission".
+ Permission to add an entry is controlled using prescriptive ACI.
+
+ If granted for an attribute type, Add permits adding a new attribute,
+ subject to being able to add all specified attribute values. Add or
+ Modify permission for the entry is a prerequisite.
+
+ If granted for an attribute value, Add permits adding that value to
+ an existing attribute. Add or Modify permission for the entry is a
+ prerequisite.
+
+
+5.1.8 Remove
+
+ If granted for an entry, Remove permits the entry to be removed from
+ the DIT regardless of controls on attributes or attribute values
+ within the entry.
+
+ If granted for an attribute, Remove permits removing an attribute,
+ subject to being able to remove any explicitly specified attribute
+ values. Remove permission for values not explicitly specified is not
+ required.
+
+ If granted for an attribute value, Remove permits the attribute value
+ to be removed from an existing attribute.
+
+
+5.1.9 DiscloseOnError
+
+ If granted for an entry, DiscloseOnError permits the name of an entry
+ to be disclosed in an error result.
+
+ If granted for an attribute, DiscloseOnError permits the presence of
+ the attribute to be disclosed by an error.
+
+ If granted for an attribute value, DiscloseOnError permits the
+ presence of the attribute value to be disclosed by an error.
+
+
+5.1.10 Rename
+
+ If granted for an entry, Rename permits an entry to be renamed with a
+
+
+
+Legg Expires 25 August 2003 [Page 7]
+\f
+INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
+
+
+ new RDN. No permissions are required for the attributes and values
+ altered by the operation, even if they are added or removed as a
+ result of the changes to the RDN.
+
+
+5.1.11 Export
+
+ If granted for an entry, Export permits the entry and its
+ subordinates, if any, to be removed from the current location and
+ placed in a new location, subject to the granting of Import
+ permission at the destination.
+
+ If the last RDN is changed, Rename permission at the current location
+ is also required
+
+
+5.1.12 Import
+
+ If granted for an entry, Import permits an entry and its
+ subordinates, if any, to be placed at the location to which the
+ permission applies, subject to the granting of Export permission at
+ the source location.
+
+
+5.1.13 Invoke
+
+ Invoke, if granted for an operational attribute, or value thereof,
+ permits the directory server to carry out some function associated
+ with the operational attribute on behalf of the user. The specific
+ function carried out by invocation depends on the attribute. No
+ other permissions are required by user for the operational attribute,
+ or on the entry/subentry that holds it, in order for it to be
+ "invoked".
+
+
+5.2 Representation of Access Control Information
+
+ Access Control Information is represented as a set of ACI items,
+ where each ACI item grants or denies permissions in regard to certain
+ specified users and protected items.
+
+ An ACI item is represented as a value of an operational attribute
+ with the ACI Item syntax (1.3.6.1.4.1.1466.115.121.1.1) [RFC2252].
+
+ This document updates [RFC2252] by specifying a human-readable
+ LDAP-specific encoding for ACI items. The LDAP-specific encoding of
+ values of the ACI Item syntax is defined by the Generic String
+ Encoding Rules described in [GSER]. Appendix A provides an
+
+
+
+Legg Expires 25 August 2003 [Page 8]
+\f
+INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
+
+
+ equivalent ABNF for this syntax.
+
+ For convenience in specifying access control policies, the ACI Item
+ syntax provides the means to identify collections of related items,
+ such as attributes in an entry or all attribute values of a given
+ attribute, and to specify a common protection for them.
+
+ The ACI Item syntax corresponds to the ACIItem ASN.1 type defined in
+ [X501]. It is reproduced here for convenience:
+
+ ACIItem ::= SEQUENCE {
+ identificationTag DirectoryString { ub-tag },
+ precedence Precedence,
+ authenticationLevel AuthenticationLevel,
+ itemOrUserFirst CHOICE {
+ itemFirst [0] SEQUENCE {
+ protectedItems ProtectedItems,
+ itemPermissions SET OF ItemPermission },
+ userFirst [1] SEQUENCE {
+ userClasses UserClasses,
+ userPermissions SET OF UserPermission } } }
+
+ Precedence ::= INTEGER (0..255)
+
+ ProtectedItems ::= SEQUENCE {
+ entry [0] NULL OPTIONAL,
+ allUserAttributeTypes [1] NULL OPTIONAL,
+ attributeType [2] SET SIZE (1..MAX) OF
+ AttributeType OPTIONAL,
+ allAttributeValues [3] SET SIZE (1..MAX) OF
+ AttributeType OPTIONAL,
+ allUserAttributeTypesAndValues [4] NULL OPTIONAL,
+ attributeValue [5] SET SIZE (1..MAX) OF
+ AttributeTypeAndValue OPTIONAL,
+ selfValue [6] SET SIZE (1..MAX) OF
+ AttributeType OPTIONAL,
+ rangeOfValues [7] Filter OPTIONAL,
+ maxValueCount [8] SET SIZE (1..MAX) OF
+ MaxValueCount OPTIONAL,
+ maxImmSub [9] INTEGER OPTIONAL,
+ restrictedBy [10] SET SIZE (1..MAX) OF
+ RestrictedValue OPTIONAL,
+ contexts [11] SET SIZE (1..MAX) OF
+ ContextAssertion OPTIONAL,
+ classes [12] Refinement OPTIONAL }
+
+ MaxValueCount ::= SEQUENCE {
+ type AttributeType,
+
+
+
+Legg Expires 25 August 2003 [Page 9]
+\f
+INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
+
+
+ maxCount INTEGER }
+
+ RestrictedValue ::= SEQUENCE {
+ type AttributeType,
+ valuesIn AttributeType }
+
+ UserClasses ::= SEQUENCE {
+ allUsers [0] NULL OPTIONAL,
+ thisEntry [1] NULL OPTIONAL,
+ name [2] SET SIZE (1..MAX) OF NameAndOptionalUID OPTIONAL,
+ userGroup [3] SET SIZE (1..MAX) OF NameAndOptionalUID OPTIONAL,
+ -- dn component shall be the name of an
+ -- entry of GroupOfUniqueNames
+ subtree [4] SET SIZE (1..MAX) OF
+ SubtreeSpecification OPTIONAL }
+
+ NameAndOptionalUID ::= SEQUENCE {
+ dn DistinguishedName,
+ uid UniqueIdentifier OPTIONAL }
+
+ UniqueIdentifier ::= BIT STRING
+
+ ItemPermission ::= SEQUENCE {
+ precedence Precedence OPTIONAL,
+ -- defaults to precedence in ACIItem
+ userClasses UserClasses,
+ grantsAndDenials GrantsAndDenials }
+
+ UserPermission ::= SEQUENCE {
+ precedence Precedence OPTIONAL,
+ -- defaults to precedence in ACIItem
+ protectedItems ProtectedItems,
+ grantsAndDenials GrantsAndDenials }
+
+ AuthenticationLevel ::= CHOICE {
+ basicLevels SEQUENCE {
+ level ENUMERATED { none(0), simple(1), strong(2) },
+ localQualifier INTEGER OPTIONAL,
+ signed BOOLEAN DEFAULT FALSE },
+ other EXTERNAL }
+
+ GrantsAndDenials ::= BIT STRING {
+ -- permissions that may be used in conjunction
+ -- with any component of ProtectedItems
+ grantAdd (0),
+ denyAdd (1),
+ grantDiscloseOnError (2),
+ denyDiscloseOnError (3),
+
+
+
+Legg Expires 25 August 2003 [Page 10]
+\f
+INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
+
+
+ grantRead (4),
+ denyRead (5),
+ grantRemove (6),
+ denyRemove (7),
+ -- permissions that may be used only in conjunction
+ -- with the entry component
+ grantBrowse (8),
+ denyBrowse (9),
+ grantExport (10),
+ denyExport (11),
+ grantImport (12),
+ denyImport (13),
+ grantModify (14),
+ denyModify (15),
+ grantRename (16),
+ denyRename (17),
+ grantReturnDN (18),
+ denyReturnDN (19),
+ -- permissions that may be used in conjunction
+ -- with any component, except entry, of ProtectedItems
+ grantCompare (20),
+ denyCompare (21),
+ grantFilterMatch (22),
+ denyFilterMatch (23),
+ grantInvoke (24),
+ denyInvoke (25) }
+
+ AttributeTypeAndValue ::= SEQUENCE {
+ type ATTRIBUTE.&id ({SupportedAttributes}),
+ value ATTRIBUTE.&Type ({SupportedAttributes}{@type}) }
+
+ The SubtreeSpecification and Refinement ASN.1 types are defined in
+ [X501], and separately described in [SUBENTRY].
+
+ The following sections describe the components of ACIItem.
+
+
+5.2.1 Identification Tag
+
+ identificationTag is used to identify a particular ACI item. This is
+ used to discriminate among individual ACI items for the purposes of
+ protection and administration.
+
+
+5.2.2 Precedence
+
+ Precedence is used to control the relative order in which ACI items
+ are considered during the course of making an access control decision
+
+
+
+Legg Expires 25 August 2003 [Page 11]
+\f
+INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
+
+
+ using the ACDF. ACI items having higher precedence values prevail
+ over others with lower precedence values, other factors being equal.
+ Precedence values are integers and are compared as such.
+
+
+5.2.3 Authentication Level
+
+ AuthenticationLevel defines the minimum requestor authentication
+ level required for this ACI item. It has two forms:
+
+ 1) basicLevels: which indicates the level of authentication,
+ optionally qualified by positive or negative integer
+ localQualifier.
+
+ 2) other: an externally defined measure.
+
+ When basicLevels is used, an AuthenticationLevel consisting of a
+ level and optional localQualifier SHALL be assigned to the requestor
+ by the directory server according to local policy. For a requestor's
+ authentication level to meet or exceed the minimum requirement, the
+ requestor's level must meet or exceed that specified in the ACI item,
+ and in addition the requestor's localQualifier must be arithmetically
+ greater than or equal to that of the ACI item. Strong authentication
+ of the requestor is considered to exceed a requirement for simple or
+ no authentication, and simple authentication exceeds a requirement
+ for no authentication. For access control purposes, the "simple"
+ authentication level requires at least a password; the case of
+ identification only, with no password supplied, is considered "none".
+ If a localQualifier is not specified in the ACI item, then the
+ requestor need not have a corresponding value (if such a value is
+ present it is ignored).
+
+ The signed component of basicLevels is ignored for LDAP.
+
+ When other is used, an appropriate AuthenticationLevel shall be
+ assigned to the requestor by the directory server according to local
+ policy. The form of this AuthenticationLevel and the method by which
+ it is compared with the AuthenticationLevel in the ACI is a local
+ matter.
+
+ An authentication level associated with an explicit grant indicates
+ the minimum level to which a requestor shall be authenticated in
+ order to be granted access.
+
+ An authentication level associated with an explicit deny indicates
+ the minimum level to which a requestor shall be authenticated in
+ order not to be denied access. For example, an ACI item that denies
+ access to a particular user class and requires strong authentication
+
+
+
+Legg Expires 25 August 2003 [Page 12]
+\f
+INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
+
+
+ will deny access to all requestors who cannot prove, by means of a
+ strongly authenticated identity, that they are not in that user
+ class.
+
+ The directory server may base authentication level on factors other
+ than values received in protocol exchanges.
+
+
+5.2.4 itemFirst and userFirst Components
+
+ Each ACI item contains a choice of itemFirst or userFirst. The
+ choice allows grouping of permissions depending on whether they are
+ most conveniently grouped by user classes or by protected items. The
+ itemFirst and userFirst components are equivalent in the sense that
+ they capture the same access control information; however, they
+ organize that information differently. The choice between them is
+ based on administrative convenience. The subcomponents of itemFirst
+ and userFirst are described below.
+
+ a) ProtectedItems defines the items to which the specified access
+ controls apply. It is defined as a set selected from the
+ following:
+
+ - entry means the entry contents as a whole. It does not
+ necessarily include the information in these entries. This
+ element SHALL be ignored if the classes component is present,
+ since this latter element selects protected entries on the basis
+ of their object class.
+
+ - allUserAttributeTypes means all user attribute type information
+ associated with the entry, but not values associated with those
+ attributes.
+
+ - allUserAttributeTypesAndValues means all user attribute
+ information associated with the entry, including all values of
+ all user attributes.
+
+ The allUserAttributeTypes and allUserAttributeTypesAndValues
+ components do not include operational attributes, which MUST be
+ specified on a per attribute basis, using attributeType,
+ allAttributeValues or attributeValue.
+
+ - attributeType means attribute type information pertaining to
+ specific attributes but not values associated with the type.
+
+ - allAttributeValues means all attribute value information
+ pertaining to specific attributes.
+
+
+
+
+Legg Expires 25 August 2003 [Page 13]
+\f
+INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
+
+
+ - attributeValue means specific values of specific attribute
+ types.
+
+ - selfValue means the attribute values of the specified attribute
+ types that match the distinguished name (and unique identifier)
+ of the requestor. It can only apply in the specific case where
+ the attribute specified is of DN syntax
+ (1.3.6.1.4.1.1466.115.121.1.12) or Name And Optional UID syntax
+ (1.3.6.1.4.1.1466.115.121.1.34) [RFC2252].
+
+ - rangeOfValues means any attribute value which matches the
+ specified filter, i.e. for which the specified filter evaluated
+ on that attribute value would return TRUE. The filter is not
+ evaluated on any entries in the DIB, rather it is evaluated
+ using the semantics defined in 7.8 of [X511], operating on a
+ fictitious entry that contains only the single attribute value
+ which is the protected item. Note that the filter is an X.500
+ search Filter. It has a different syntax from the LDAP search
+ Filter, but the same semantics.
+
+ The following items provide constraints that may disable the
+ granting of certain permissions to protected items in the same
+ value of ProtectedItems:
+
+ - maxValueCount restricts the maximum number of attribute values
+ allowed for a specified attribute type. It is examined if the
+ protected item is an attribute value of the specified type and
+ the permission sought is Add. Values of that attribute in the
+ entry are counted, without regard to attribute options and
+ access control, as though the operation which is attempting to
+ add the values is successful. If the number of values in the
+ attribute exceeds maxCount, the ACI item is treated as not
+ granting Add permission.
+
+ - maxImmSub restricts the maximum number of immediate subordinates
+ of the superior entry to an entry being added or imported. It
+ is examined if the protected item is an entry, the permission
+ sought is Add or Import, and the immediate superior entry is in
+ the same server as the entry being added or imported. Immediate
+ subordinates of the superior entry are counted, without regard
+ to access control, as though the entry addition or importing is
+ successful. If the number of subordinates exceeds maxImmSub,
+ the ACI item is treated as not granting Add or Import
+ permission.
+
+ - restrictedBy restricts values added to the attribute type to
+ being values that are already present in the same entry as
+ values of the attribute identified by the valuesIn component.
+
+
+
+Legg Expires 25 August 2003 [Page 14]
+\f
+INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
+
+
+ It is examined if the protected item is an attribute value of
+ the specified type and the permission sought is Add. Values of
+ the valuesIn attribute are checked, without regard to attribute
+ options and access control, as though the operation which adds
+ the values is successful. If the value to be added is not
+ present in valuesIn the ACI item is treated as not granting Add
+ permission.
+
+ - contexts is not used in this version of the LDAP profile for
+ Basic Access Control.
+
+ - classes means the contents of entries that have object class
+ values that satisfy the predicate defined by Refinement (see
+ [SUBENTRY]).
+
+ b) UserClasses defines a set of zero or more users the permissions
+ apply to. The set of users is selected from the following:
+
+ - allUsers means every directory user (with possible requirements
+ for AuthenticationLevel).
+
+ - thisEntry means the user with the same distinguished name as the
+ entry being accessed.
+
+ - name is the set of users with the specified distinguished names
+ (each with an optional unique identifier).
+
+ - userGroup is the set of users who are members of the groups
+ (i.e. groupOfNames or groupOfUniqueNames entries [RFC2256])
+ identified by the specified distinguished names (each with an
+ optional unique identifier). Members of a group of unique names
+ are treated as individual user distinguished names, and not as
+ the names of other groups of unique names. How group membership
+ is determined is described in 5.2.5.
+
+ - subtree is the set of users whose distinguished names fall
+ within the scope of the unrefined subtrees (specificationFilter
+ components SHOULD NOT be used - they SHALL be ignored if
+ present).
+
+ c) SubtreeSpecification is used to specify a subtree relative to the
+ root DSE, and is not constrained by administrative areas. The
+ specificationFilter component SHOULD NOT be used. It SHALL be
+ ignored if present.
+
+ A subtree refinement is not allowed because membership in a
+ subtree whose specification includes only base and/or a
+ ChopSpecification can be evaluated in isolation, whereas
+
+
+
+Legg Expires 25 August 2003 [Page 15]
+\f
+INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
+
+
+ membership in a subtree definition using specificationFilter can
+ only be evaluated by obtaining information from the user's entry,
+ which is potentially in another directory server. Basic Access
+ Control is designed to avoid remote operations in the course of
+ making an access control decision.
+
+ d) ItemPermission contains a collection of users and their
+ permissions with respect to ProtectedItems within an itemFirst
+ specification. The permissions are specified in grantsAndDenials
+ as discussed in item f). Each of the permissions specified in
+ grantsAndDenials is considered to have the precedence level
+ specified in precedence for the purpose of the ACDF. If
+ precedence is omitted within ItemPermission, then precedence is
+ taken from the precedence specified for ACIItem.
+
+ e) UserPermission contains a collection of protected items and the
+ associated permissions with respect to userClasses within a
+ userFirst specification. The associated permissions are specified
+ in grantsAndDenials as discussed in item f). Each of the
+ permissions specified in grantsAndDenials is considered to have
+ the precedence level specified in precedence for the purpose of
+ the ACDF. If precedence is omitted within UserPermission, the
+ precedence is taken from the precedence specified for ACIItem.
+
+ f) GrantsAndDenials specify the access rights that are granted or
+ denied by the ACI item.
+
+ g) UniqueIdentifier may be used by the authentication mechanism to
+ distinguish between instances of distinguished name reuse. If
+ this component is present, then for a requestor's name to match
+ the UserClasses of an ACIItem that grants permissions, in addition
+ to the requirement that the requestor's distinguished name match
+ the specified distinguished name, the authentication of the
+ requestor shall yield an associated unique identifier, and that
+ value shall match for equality with the specified value.
+
+
+5.2.5 Determining Group Membership
+
+ Determining whether a given requestor is a group member requires
+ checking two criteria. The determination may also be constrained if
+ the group definition is not known locally. The criteria for
+ membership and the treatment of non-local groups are discussed below.
+
+ a) A directory server is NOT REQUIRED to perform a remote operation
+ to determine whether the requestor belongs to a particular group
+ for the purposes of Basic Access Control. If membership in the
+ group cannot be evaluated, the server shall assume that the
+
+
+
+Legg Expires 25 August 2003 [Page 16]
+\f
+INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
+
+
+ requestor does not belong to the group if the ACI item grants the
+ permission sought, and does belong to the group if it denies the
+ permission sought.
+
+ Access control administrators should beware of basing access
+ controls on membership of non-locally available groups or groups
+ which are available only through replication (and which may,
+ therefore, be out of date).
+
+ b) In order to determine whether the requestor is a member of a
+ userGroup user class, the following criteria apply:
+
+ - The entry named by the userGroup specification is an instance of
+ the object class groupOfNames or groupOfUniqueNames.
+
+ - The name of the requestor is a value of the member or
+ uniqueMember attribute of that entry.
+
+ Values of the member or uniqueMember attribute that do not match
+ the name of the requestor are ignored, even if they represent the
+ names of groups of which the originator could be found to be a
+ member. Hence, nested groups are not supported when evaluating
+ access controls.
+
+
+5.3 ACI Operational Attributes
+
+ ACI is stored as values of operational attributes of entries and
+ subentries. The operational attributes are multi-valued, which
+ allows ACI to be represented as a set of ACI items.
+
+
+5.3.1 Prescriptive ACI
+
+ The prescriptiveACI attribute is defined as an operational attribute
+ of an access control subentry. It contains prescriptive ACI
+ applicable to entries within that subentry's scope.
+
+ The LDAP description [RFC2252] for the prescriptiveACI operational
+ attribute is:
+
+ ( 2.5.24.4 NAME 'prescriptiveACI'
+ EQUALITY directoryStringFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.1
+ USAGE directoryOperation )
+
+ The directoryStringFirstComponentMatch matching rule is described in
+ [SCHEMA].
+
+
+
+Legg Expires 25 August 2003 [Page 17]
+\f
+INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
+
+
+ Prescriptive ACI within the subentries of a particular administrative
+ point never applies to the same or any other subentry of that
+ administrative point, but can be applicable to the subentries of
+ subordinate administrative points.
+
+ Note that prescriptiveACI attributes are not collective attributes.
+ Although the values of a prescriptiveACI attribute contribute to
+ access control decisions for each entry within the scope of the
+ subentry that holds the attribute, the prescriptiveACI attribute does
+ not appear as part of those entries.
+
+
+5.3.2 Entry ACI
+
+ The entryACI attribute is defined as an operational attribute of an
+ entry or subentry (not just access control subentries). It contains
+ entry ACI applicable to the entry or subentry in which it appears,
+ and that (sub)entry's contents.
+
+ The LDAP description [RFC2252] for the entryACI operational attribute
+ is:
+
+ ( 2.5.24.5 NAME 'entryACI'
+ EQUALITY directoryStringFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.1
+ USAGE directoryOperation )
+
+
+5.3.3 Subentry ACI
+
+ The subentryACI attribute is defined as an operational attribute of
+ administrative entries [ADMIN] (for any aspect of administration).
+ It contains subentry ACI that applies to each of the subentries of
+ the administrative entry in which it appears. Only administrative
+ entries are permitted to contain a subentryACI attribute.
+
+ The LDAP description [RFC2252] for the subentryACI operational
+ attribute is:
+
+ ( 2.5.24.6 NAME 'subentryACI'
+ EQUALITY directoryStringFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.1
+ USAGE directoryOperation )
+
+
+5.3.4 Protecting the ACI
+
+ ACI operational attributes are subject to the same protection
+
+
+
+Legg Expires 25 August 2003 [Page 18]
+\f
+INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
+
+
+ mechanisms as other attributes.
+
+ The identificationTag provides an identifier for each ACI item. This
+ tag can be used to remove a specific ACI item value, or to protect it
+ by prescriptive ACI, entry ACI or subentry ACI. Directory rules
+ ensure that only one ACI item per access control operational
+ attribute possesses any specific identificationTag value.
+
+ The creation of subentries for an administrative entry may be
+ controlled by means of the subentryACI operational attribute in the
+ administrative entry. The right to create prescriptive access
+ controls may also be governed directly by security policy; this
+ provision is required to create access controls in new autonomous
+ administrative areas [ADMIN].
+
+
+5.4 Access Control Decision Points for LDAP Operations
+
+ Each LDAP operation involves making a series of access control
+ decisions on the various protected items that the operation accesses.
+
+ For some operations (e.g. the Modify operation), each such access
+ control decision must grant access for the operation to succeed; if
+ access is denied to any protected item, the whole operation fails.
+ For other operations (e.g. the Search operation), protected items to
+ which access is denied are simply omitted from the operation result
+ and processing continues.
+
+ If the requested access is denied, further access control decisions
+ may be needed to determine if the user has DiscloseOnError
+ permissions to the protected item. Only if DiscloseOnError
+ permission is granted may the server respond with an error that
+ reveals the existence of the protected item. In all other cases, the
+ server MUST act so as to conceal the existence of the protected item.
+
+ The permissions required to access each protected item, are specified
+ for each operation in the following sections. The algorithm by which
+ a permission is determined to be granted or not granted is specified
+ in Section 5.5.
+
+
+5.4.1 Common Elements of Procedure
+
+ This section defines the elements of procedure that are common to all
+ LDAP operations when Basic Access Control is in effect.
+
+
+5.4.1.1 Alias Dereferencing
+
+
+
+Legg Expires 25 August 2003 [Page 19]
+\f
+INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
+
+
+ If, in the process of locating a target object entry (nominated in an
+ LDAP request), alias dereferencing is required, no specific
+ permissions are necessary for alias dereferencing to take place.
+ However, if alias dereferencing would result in a referral being
+ returned, the following sequence of access controls applies.
+
+ 1) Read permission is required to the alias entry. If permission is
+ not granted, the operation fails in accordance to the procedure
+ described in 5.4.1.3.
+
+ 2) Read permission is required to the aliasedEntryName attribute and
+ to the single value that it contains. If permission is not
+ granted, the operation fails and the resultCode
+ aliasDereferencingProblem SHALL be returned. The matchedDN field
+ of the LDAPResult SHALL contain the name of the alias entry.
+
+ In addition to the access controls described above, security policy
+ may prevent the disclosure of knowledge of other servers which would
+ otherwise be conveyed in a referral. If such a policy is in effect
+ the resultCode insufficientAccessRights SHALL be returned.
+
+
+5.4.1.2 Return of Names in Errors
+
+ Certain LDAP result codes, i.e. noSuchObject, aliasProblem,
+ invalidDNSyntax and aliasDereferencingProblem, provide the name of an
+ entry in the matchedDN field of an LDAPResult. The DN of an entry
+ SHALL only be provided in the matchedDN field if DiscloseOnError
+ permission is granted to that entry, otherwise, the matchedDN field
+ of the LDAPResult SHALL either contain the name of the next superior
+ entry to which DiscloseOnError permission is granted, or, if
+ DiscloseOnError permission is not granted to any superior entry, the
+ name of the root DSE (i.e. a zero-length LDAPDN).
+
+
+5.4.1.3 Non-disclosure of the Existence of an Entry
+
+ If, while performing an LDAP operation, the necessary entry level
+ permission is not granted to the specified target object entry - e.g.
+ the entry to be modified - the operation fails; if DiscloseOnError
+ permission is granted to the target entry, the resultCode
+ insufficientAccessRights SHALL be returned, otherwise, the resultCode
+ noSuchObject SHALL be returned. The matchedDN field of the
+ LDAPResult SHALL either contain the name of the next superior entry
+ to which DiscloseOnError permission is granted, or, if
+ DiscloseOnError permission is not granted to any superior entry, the
+ name of the root DSE (i.e. a zero-length LDAPDN).
+
+
+
+
+Legg Expires 25 August 2003 [Page 20]
+\f
+INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
+
+
+ Additionally, whenever the server detects an operational error
+ (including a referral resultCode), it shall ensure that in returning
+ that error it does not compromise the existence of the named target
+ entry and any of its superiors. For example, before returning a
+ resultCode of timeLimitExceeded or notAllowedOnNonLeaf, the server
+ verifies that DiscloseOnError permission is granted to the target
+ entry. If it is not, the procedure described in the paragraph above
+ SHALL be followed.
+
+
+5.4.2 Compare Operation Decision Points
+
+ The following sequence of access controls applies for an entry being
+ compared.
+
+ 1) Read permission for the entry to be compared is required. If
+ permission is not granted, the operation fails in accordance with
+ 5.4.1.3.
+
+ 2) Compare permission for the attribute to be compared is required.
+ If permission is not granted, the operation fails: if
+ DiscloseOnError permission is granted to the attribute being
+ compared, a resultCode of insufficientAccessRight SHALL be
+ returned, otherwise, the resultCode noSuchAttribute SHALL be
+ returned.
+
+ 3) If there exists a value within the attribute being compared that
+ matches the purported argument and for which Compare permission is
+ granted, the operation returns the resultCode compareTrue,
+ otherwise the operation returns the resultCode compareFalse.
+
+
+5.4.3 Search Operation Decision Points
+
+ The following sequence of access controls applies for a portion of
+ the DIT being searched.
+
+ 1) No specific permission is required to the entry identified by the
+ baseObject argument in order to initiate a search. However, if
+ the baseObject is within the scope of the SearchArgument (i.e.
+ when the subset argument specifies baseObject or wholeSubtree) the
+ access controls specified in 2) through 5) will apply.
+
+ 2) Browse or Read permission is required for the single entry within
+ the scope of a baseObject search. An entry for which neither of
+ these permissions is granted is ignored.
+
+ This differs from the X.500 DAP Search operation where the Browse
+
+
+
+Legg Expires 25 August 2003 [Page 21]
+\f
+INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
+
+
+ permission alone is required. An entry with Read permission but
+ not Browse permission cannot be searched but can still be examined
+ with an X.500 DAP Read operation. LDAP relies on baseObject
+ search operations to provide the functionality of the DAP Read
+ operation. Accepting Read permission for the target entry in a
+ baseObject search gives an LDAP baseObject search the same access
+ rights to the entry as the DAP Read operation.
+
+ 3) Browse permission is required for an entry within the scope of a
+ singleLevel or wholeSubtree search to be a candidate for
+ consideration. Entries for which this permission is not granted
+ are ignored.
+
+ 4) The filter argument is applied to each entry left to be considered
+ after taking 2) and 3) into account, in accordance with the
+ following:
+
+ a) For a present Filter item, if there exists an attribute value
+ such that the attribute type of the value (possibly a subtype
+ of the attribute type in the FilterItem) satisfies the Filter
+ item and FilterMatch permission is granted for the value and
+ for the attribute type then the FilterItem evaluates to TRUE,
+ otherwise, it evaluates to FALSE.
+
+ If a directory server does not support True/False filters
+ [FILTER] on LDAP searches, or if directory clients do not
+ exploit this capability, then access control administrators
+ SHOULD grant FilterMatch permission for the objectClass
+ attribute over entries where Read permission is also granted so
+ that an LDAP baseObject search with a filter testing for the
+ presence of the objectClass attribute will have the same access
+ rights to the target entry as the DAP Read operation. An LDAP
+ baseObject search with a True filter does not require
+ FilterMatch permission for any particular attribute type.
+
+ b) For an equalityMatch, substrings, greaterOrEqual, lessOrEqual,
+ approxMatch or extensibleMatch Filter item, if there exists an
+ attribute value such that the value satisfies the Filter item
+ and FilterMatch permission is granted for the value and for its
+ attribute type (possibly a subtype of the attribute type in the
+ FilterItem) then the FilterItem evaluates to TRUE, otherwise,
+ it evaluates to FALSE.
+
+ Once the access controls defined in 2) through 4) have been applied,
+ an entry is either selected or discarded.
+
+ 5) For each selected entry the information returned is as follows:
+
+
+
+
+Legg Expires 25 August 2003 [Page 22]
+\f
+INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
+
+
+ a) ReturnDN permission for an entry is required in order to return
+ its distinguished name in a SearchResultEntry response. If
+ this permission is not granted, the server SHALL either, return
+ the name of a valid alias to the entry, or, omit the entry from
+ the search result.
+
+ If the base entry of the search was located using an alias,
+ then that alias is known to be a valid alias. Otherwise, how
+ it is ensured that the alias is valid is outside the scope of
+ this specification.
+
+ Where a server has a choice of alias names available to it for
+ return, it is RECOMMENDED that where possible it choose the
+ same alias name for repeated requests by the same client, in
+ order to provide a consistent service.
+
+ b) If the typesOnly field of the SearchRequest is TRUE then, for
+ each attribute type that is to be returned, Read permission for
+ the attribute type and Read permission for at least one value
+ of the attribute is required. If permission is not granted,
+ the attribute type is omitted from the attribute list in the
+ SearchResultEntry. If as a consequence of applying these
+ controls no attribute type information is selected, the
+ SearchResultEntry is returned but no attribute type information
+ is conveyed with it (i.e. the attribute list is empty).
+
+ c) If the typesOnly field of the SearchRequest is FALSE then Read
+ permission is required for each attribute type and for each
+ attribute value that is to be returned. If permission to an
+ attribute type is not granted, the attribute is omitted from
+ the SearchResultEntry. If permission to an attribute value is
+ not granted, the value is omitted from its corresponding
+ attribute. If all values of an attribute are omitted then the
+ attribute type is omitted from the attribute list in the
+ SearchResultEntry. If as a consequence of applying these
+ controls no attribute information is selected, the
+ SearchResultEntry is returned but no attribute information is
+ conveyed with it (i.e. the attribute list is empty).
+
+ 6) If as a consequence of applying the above controls to the entire
+ scoped subtree the search result contains no entries (excluding
+ any SearchResultReferences) and if DiscloseOnError permission is
+ not granted to the entry identified by the baseObject argument,
+ the operation fails and the resultCode noSuchObject SHALL be
+ returned. The matchedDN field of the LDAPResult SHALL either
+ contain the name of the next superior entry to which
+ DiscloseOnError permission is granted, or the name of the root DSE
+ (i.e. a zero-length LDAPDN). Otherwise, the operation succeeds
+
+
+
+Legg Expires 25 August 2003 [Page 23]
+\f
+INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
+
+
+ but no subordinate information is conveyed with it.
+
+ Security policy may prevent the disclosure of knowledge of other
+ servers which would otherwise be conveyed as SearchResultReferences.
+ If such a policy is in effect SearchResultReferences are omitted from
+ the search result.
+
+ No specific permissions are necessary to allow alias dereferencing to
+ take place in the course of a search operation. However, for each
+ alias entry encountered, if alias dereferencing would result in a
+ SearchResultReference being returned, the following access controls
+ apply: Read permission is required to the alias entry, the
+ aliasedEntryName attribute and to the single value that it contains.
+ If any of these permissions is not granted, the SearchResultReference
+ SHALL be omitted from the search result.
+
+
+5.4.4 Add Operation Decision Points
+
+ The following sequence of access controls apply for an entry being
+ added.
+
+ 1) No specific permission is required for the immediate superior of
+ the entry identified by the entry field of the AddRequest.
+
+ 2) If an entry already exists with a distinguished name equal to the
+ entry field the operation fails; if DiscloseOnError or Add
+ permission is granted to the existing entry, the resultCode
+ entryAlreadyExists SHALL be returned, otherwise, the procedure
+ described in 5.4.1.3 is followed with respect to the entry being
+ added.
+
+ 3) Add permission is required for the new entry being added. If this
+ permission is not granted, the operation fails; the procedure
+ described in 5.4.1.3 is followed with respect to the entry being
+ added.
+
+ The Add permission is provided as prescriptive ACI when attempting
+ to add an entry and as prescriptive ACI or subentry ACI when
+ attempting to add a subentry. Any values of the entryACI
+ attribute in the entry being added SHALL be ignored.
+
+ 4) Add permission is required for each attribute type and for each
+ value that is to be added. If any permission is absent, the
+ operation fails and the resultCode insufficientAccessRights SHALL
+ be returned.
+
+
+
+
+
+Legg Expires 25 August 2003 [Page 24]
+\f
+INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
+
+
+5.4.5 Delete Operation Decision Points
+
+ The following sequence of access controls apply for an entry being
+ removed.
+
+ 1) Remove permission is required for the entry being removed. If
+ this permission is not granted, the operation fails in accordance
+ with 5.4.1.3.
+
+ 2) No specific permissions are required for any of the attributes and
+ attribute values present within the entry being removed.
+
+
+5.4.6 Modify Operation Decision Points
+
+ The following sequence of access controls apply for an entry being
+ modified.
+
+ 1) Modify permission is required for the entry being modified. If
+ this permission is not granted, the operation fails in accordance
+ with 5.4.1.3.
+
+ 2) For each of the specified modification arguments applied in
+ sequence, the following permissions are required:
+
+ a) Add permission is required for each of the attribute values
+ specified in an add modification. If the attribute does not
+ currently exist then Add permission for the attribute type is
+ also required. If these permissions are not granted, or any of
+ the attribute values already exist, the operation fails; if an
+ attribute value already exists and DiscloseOnError or Add is
+ granted to that attribute value, the resultCode
+ attributeOrValueExists SHALL be returned, otherwise, the
+ resultCode insufficientAccessRights SHALL be returned.
+
+ b) Remove permission is required for the attribute type specified
+ in a delete modification with no listed attribute values. If
+ this permission is not granted, the operation fails; if
+ DiscloseOnError permission is granted to the attribute being
+ removed and the attribute exists, the resultCode
+ insufficientAccessRights SHALL be returned, otherwise, the
+ resultCode noSuchAttribute SHALL be returned.
+
+ No specific permissions are required for any of the attribute
+ values present within the attribute being removed.
+
+ c) Remove permission is required for each of the values in a
+ delete modification with listed attribute values. If all
+
+
+
+Legg Expires 25 August 2003 [Page 25]
+\f
+INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
+
+
+ current values of the attribute are specified to be removed
+ (which causes the attribute itself to be removed), then Remove
+ permission for the attribute type is also required. If these
+ permissions are not granted, the operation fails; if
+ DiscloseOnError permission is granted to any of the attribute
+ values being removed, the resultCode insufficientAccessRights
+ SHALL be returned, otherwise, the resultCode noSuchAttribute
+ SHALL be returned.
+
+ d) Remove and Add permission is required for the attribute type,
+ and Add permission is required for each of the specified
+ attribute values, in a replace modification. If these
+ permissions are not granted the operation fails and the
+ resultCode insufficientAccessRights SHALL be returned.
+
+ No specific permissions are required to remove any existing
+ attribute values of the attribute being replaced.
+
+
+5.4.7 Modify DN Operation Decision Points
+
+ The following sequence of access controls apply for an entry having
+ its DN modified.
+
+ 1) If the effect of the operation is to change the RDN of the entry
+ then Rename permission (determined with respect to its original
+ name) is required for the entry. If this permission is not
+ granted, the operation fails; the procedure described in 5.4.1.3
+ is followed with respect to the entry being renamed (considered
+ with its original name).
+
+ No additional permissions are required even if, as a result of
+ modifying the RDN of the entry, a new distinguished value needs to
+ be added, or an old one removed. No specific permissions are
+ required for the subordinates of the renamed entry.
+
+ 2) If the effect of the operation is to move an entry to a new
+ superior in the DIT then Export permission (determined with
+ respect to its original name) and Import permission (determined
+ with respect to its new name) are required for the entry. If
+ either of these permissions is not granted, the operation fails;
+ the procedure described in 5.4.1.3 is followed with respect to the
+ entry being moved (considered with its original name).
+
+ The Import permission is provided as prescriptive ACI when
+ attempting to move an entry and as prescriptive ACI or subentry
+ ACI when attempting to move a subentry. Any values of the
+ entryACI attribute in the entry or subentry being moved SHALL be
+
+
+
+Legg Expires 25 August 2003 [Page 26]
+\f
+INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
+
+
+ ignored.
+
+ No specific permissions are required for the subordinates of the
+ moved entry.
+
+ Note that a single Modify DN Operation may simultaneously rename and
+ move an entry.
+
+
+5.5 Access Control Decision Function
+
+ This section describes how ACI items are processed in order to decide
+ whether to grant or deny a particular requestor a specified
+ permission to a given protected item.
+
+ Section 5.5.1 describes the inputs to the ACDF. Sections 5.5.2
+ through 5.5.4 describe the steps in the ACDF. The output is a
+ decision to grant or deny access to the protected item.
+
+
+5.5.1 Inputs
+
+ For each invocation of the ACDF, the inputs are:
+
+ a) the requestor's Distinguished Name, unique identifier, and
+ authentication level, or as many of these as are available;
+
+ b) the protected item (an entry, an attribute, or an attribute value)
+ being considered at the current decision point for which the ACDF
+ was invoked;
+
+ c) the requested permission specified for the current decision point;
+
+ d) the ACI items applicable to the entry containing (or which is) the
+ protected item.
+
+ In addition, if the ACI items include any of the protected item
+ constraints described in 5.2.1.4, the whole entry and the number of
+ immediate subordinates of its superior entry may also be required as
+ inputs.
+
+
+5.5.2 Tuples
+
+ For each ACI item, expand the item into a set of tuples, one tuple
+ for each element of the itemPermissions and userPermissions sets,
+ containing the following elements:
+
+
+
+
+Legg Expires 25 August 2003 [Page 27]
+\f
+INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
+
+
+ ( userClasses, authenticationLevel, protectedItems,
+ grantsAndDenials, precedence )
+
+ Collect all tuples from all ACI items into a single set.
+
+ For any tuple whose grantsAndDenials specify both grants and denials,
+ replace the tuple with two tuples - one specifying only grants and
+ the other specifying only denials.
+
+
+5.5.3 Discarding Irrelevant Tuples
+
+ Perform the following steps to discard all irrelevant tuples:
+
+ 1) Discard all tuples that do not include the requestor in the
+ tuple's userClasses as follows:
+
+ a) For tuples that grant access, discard all tuples that do not
+ include the requestor's identity in the tuples's userClasses
+ element, taking into account UniqueIdentifier elements if
+ relevant. Where a tuple's userClasses specifies a
+ UniqueIdentifier, a matching value shall be present in the
+ requestor's identity if the tuple is not to be discarded.
+ Discard tuples that specify an authentication level higher than
+ that associated with the requestor.
+
+ b) For tuples that deny access, retain all tuples that include the
+ requestor in the tuple's userClasses element, taking into
+ account uniqueIdentifier elements if relevant. Also retain all
+ tuples that deny access and which specify an authentication
+ level higher than that associated with the requestor. This
+ reflects the fact that the requestor has not adequately proved
+ non-membership in the user class for which the denial is
+ specified. All other tuples that deny access are discarded.
+
+ 2) Discard all tuples that do not include the protected item in
+ protectedItems.
+
+ 3) Examine all tuples that include maxValueCount, maxImmSub or
+ restrictedBy. Discard all such tuples which grant access and
+ which do not satisfy any of these constraints.
+
+ 4) Discard all tuples that do not include the requested permission as
+ one of the set bits in grantsAndDenials.
+
+ The order in which tuples are discarded does not change the output of
+ the ACDF.
+
+
+
+
+Legg Expires 25 August 2003 [Page 28]
+\f
+INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
+
+
+5.5.4 Highest Precedence and Specificity
+
+ Perform the following steps to select those tuples of highest
+ precedence and specificity:
+
+ 1) Discard all tuples having a precedence less than the highest
+ precedence among the remaining tuples.
+
+ 2) If more than one tuple remains, choose the tuples with the most
+ specific user class. If there are any tuples matching the
+ requestor with UserClasses element name or thisEntry, discard all
+ other tuples. Otherwise if there are any tuples matching
+ UserGroup, discard all other tuples. Otherwise if there are any
+ tuples matching subtree, discard all other tuples.
+
+ 3) If more than one tuple remains, choose the tuples with the most
+ specific protected item. If the protected item is an attribute
+ and there are tuples that specify the attribute type explicitly,
+ discard all other tuples. If the protected item is an attribute
+ value, and there are tuples that specify the attribute value
+ explicitly, discard all other tuples. A protected item which is a
+ rangeOfValues is to be treated as specifying an attribute value
+ explicitly.
+
+ Grant access if and only if one or more tuples remain and all grant
+ access. Otherwise deny access.
+
+
+6. Simplified Access Control
+
+ This section describes the functionality of the Simplified Access
+ Control scheme. It provides a subset of the functionality found in
+ Basic Access Control.
+
+ When Simplified Access Control is used, the accessControlScheme
+ operational attribute [ACA] SHALL have the value
+ simplified-access-control (2.5.28.2).
+
+ The functionality of Simplified Access Control is the same as Basic
+ Access Control except that:
+
+ 1) Access control decisions shall be made only on the basis of values
+ of prescriptiveACI and subentryACI operational attributes. Values
+ of the entryACI attribute, if present, SHALL NOT be used to make
+ access control decisions.
+
+ 2) Access Control Inner Areas are not used. Values of
+ prescriptiveACI attributes appearing in subentries of ACIPs SHALL
+
+
+
+Legg Expires 25 August 2003 [Page 29]
+\f
+INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
+
+
+ NOT be used to make access control decisions.
+
+ All other provisions SHALL be as defined for Basic Access Control.
+
+
+7. Security Considerations
+
+ Access control administrators should beware of basing access controls
+ on membership of non-locally available groups or groups which are
+ available only through replication (and which may, therefore, be out
+ of date).
+
+ A particular DSA might not have the ACI governing any data that it
+ caches. Administrators should be aware that a directory server with
+ the capability of caching may pose a significant security risk to
+ other directory servers, in that it may reveal information to
+ unauthorized users.
+
+
+8. Acknowledgements
+
+ This document is derived from, and duplicates substantial portions
+ of, Section 8 of [X501], and selected extracts from [X511].
+
+
+9. IANA Considerations
+
+ The Internet Assigned Numbers Authority (IANA) is requested to update
+ the LDAP descriptors registry as indicated by the following
+ templates:
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): basic-access-control
+ Object Identifier: 2.5.28.1
+ Person & email address to contact for further information:
+ Steven Legg <steven.legg@adacel.com.au>
+ Usage: other (access control scheme)
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): simplified-access-control
+ Object Identifier: 2.5.28.2
+ Person & email address to contact for further information:
+ Steven Legg <steven.legg@adacel.com.au>
+ Usage: other (access control scheme)
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+
+
+
+Legg Expires 25 August 2003 [Page 30]
+\f
+INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
+
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): prescriptiveACI
+ Object Identifier: 2.5.24.4
+ Person & email address to contact for further information:
+ Steven Legg <steven.legg@adacel.com.au>
+ Usage: attribute type
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): entryACI
+ Object Identifier: 2.5.24.5
+ Person & email address to contact for further information:
+ Steven Legg <steven.legg@adacel.com.au>
+ Usage: attribute type
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): subentryACI
+ Object Identifier: 2.5.24.6
+ Person & email address to contact for further information:
+ Steven Legg <steven.legg@adacel.com.au>
+ Usage: attribute type
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+
+
+10. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
+ Access Protocol (v3)", RFC 2251, December 1997.
+
+ [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
+ "Lightweight Directory Access Protocol (v3): Attribute
+ Syntax Definitions", RFC 2252, December 1997.
+
+ [RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use
+ with LDAPv3", RFC 2256, December 1997.
+
+ [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
+
+ [GSER] Legg, S., "Generic String Encoding Rules for ASN.1 Types",
+
+
+
+Legg Expires 25 August 2003 [Page 31]
+\f
+INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
+
+
+ draft-legg-ldap-gser-xx.txt, a work in progress, October
+ 2002.
+
+ [SUBENTRY] Zeilenga, K. and S. Legg, "Subentries in LDAP",
+ draft-zeilenga-ldap-subentry-xx.txt, a work in progress,
+ August 2002.
+
+ [COLLECT] Zeilenga, K., "Collective Attributes in LDAP",
+ draft-zeilenga-ldap-collective-xx.txt, a work in progress,
+ August 2002.
+
+ [ADMIN] Legg, S., "Directory Administrative Model in LDAP",
+ draft-legg-ldap-admin-xx.txt, a work in progress, February
+ 2003.
+
+ [ACA] Legg, S., "Access Control Administration in LDAP",
+ draft-legg-ldap-acm-admin-xx.txt, a work in progress,
+ February 2003.
+
+ [SCHEMA] Zeilenga, K., "LDAPv3: A Collection of User Schema",
+ draft-zeilenga-ldap-user-schema-xx.txt, a work in
+ progress, May 2002.
+
+ [FILTER] Zeilenga, K., "LDAP Absolute True/False Filters",
+ draft-zeilenga-ldap-t-f-xx.txt, a work in progress,
+ November 2002.
+
+ [X680] ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998
+ Information Technology - Abstract Syntax Notation One
+ (ASN.1): Specification of basic notation
+
+
+11. Informative References
+
+ [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [GCE] Legg, S., "Common Elements of GSER Encodings",
+ draft-legg-ldap-gser-abnf-xx.txt, a work in progress,
+ October 2002.
+
+ [X501] ITU-T Recommendation X.501 (02/2001), Information
+ technology - Open Systems Interconnection - The Directory:
+ Models
+
+ [X511] ITU-T Recommendation X.511 (02/2001), Information
+ technology - Open Systems Interconnection - The Directory:
+ Abstract service definition
+
+
+
+Legg Expires 25 August 2003 [Page 32]
+\f
+INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
+
+
+12. Copyright Notice
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 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.
+
+
+13. Author's Address
+
+ Steven Legg
+ Adacel Technologies Ltd.
+ 250 Bay Street
+ Brighton, Victoria 3186
+ AUSTRALIA
+
+ Phone: +61 3 8530 7710
+ Fax: +61 3 8530 7888
+ EMail: steven.legg@adacel.com.au
+
+
+Appendix A. LDAP Specific Encoding for the ACI Item Syntax
+
+ This appendix is non-normative.
+
+ The LDAP-specific encoding for the ACI Item syntax is specified by
+ the Generic String Encoding Rules in [GSER]. The ABNF [RFC2234] in
+
+
+
+Legg Expires 25 August 2003 [Page 33]
+\f
+INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
+
+
+ this appendix for this syntax is provided only as a convenience and
+ is equivalent to the encoding specified by the application of [GSER].
+ Since the ACI Item ASN.1 type may be extended in future editions of
+ [X501], the provided ABNF should be regarded as a snapshot in time.
+ The LDAP-specific encoding for any extension to the ACI Item ASN.1
+ type can be determined from [GSER].
+
+ In the event that there is a discrepancy between this ABNF and the
+ encoding determined by [GSER], [GSER] is to be taken as definitive.
+
+ ACIItem = "{" sp aci-identificationTag ","
+ sp aci-precedence ","
+ sp aci-authenticationLevel ","
+ sp aci-itemOrUserFirst
+ sp "}"
+
+ aci-identificationTag = id-identificationTag msp
+ DirectoryString
+ aci-precedence = id-precedence msp Precedence
+ aci-authenticationLevel = id-authenticationLevel msp
+ AuthenticationLevel
+ aci-itemOrUserFirst = id-itemOrUserFirst msp
+ ItemOrUserFirst
+ id-identificationTag = %x69.64.65.6E.74.69.66.69.63.61.74.69.6F
+ %x6E.54.61.67 ; "identificationTag"
+ id-precedence = %x70.72.65.63.65.64.65.6E.63.65
+ ; "precedence"
+ id-authenticationLevel = %x61.75.74.68.65.6E.74.69.63.61.74.69.6F
+ %x6E.4C.65.76.65.6C
+ ; "authenticationLevel"
+ id-itemOrUserFirst = %x69.74.65.6D.4F.72.55.73.65.72.46.69.72
+ %x73.74 ; "itemOrUserFirst"
+
+ Precedence = INTEGER-0-MAX ; MUST be less than 256
+
+ AuthenticationLevel = al-basicLevels / al-other
+ al-basicLevels = id-basicLevels ":" BasicLevels
+ al-other = id-other ":" EXTERNAL
+ id-basicLevels = %x62.61.73.69.63.4C.65.76.65.6C.73
+ ; "basicLevels"
+ id-other = %x6F.74.68.65.72 ; "other"
+
+ BasicLevels = "{" sp bl-level
+ [ "," sp bl-localQualifier ]
+ [ "," sp bl-signed ]
+ sp "}"
+
+ bl-level = id-level msp Level
+
+
+
+Legg Expires 25 August 2003 [Page 34]
+\f
+INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
+
+
+ bl-localQualifier = id-localQualifier msp INTEGER
+ bl-signed = id-signed msp BOOLEAN
+ Level = id-none / id-simple / id-strong
+ id-level = %x6C.65.76.65.6C ; "level"
+ id-localQualifier = %x6C.6F.63.61.6C.51.75.61.6C.69.66.69.65.72
+ ; "localQualifier"
+ id-signed = %x73.69.67.6E.65.64 ; "signed"
+ id-none = %x6E.6F.6E.65 ; "none"
+ id-simple = %x73.69.6D.70.6C.65 ; "simple"
+ id-strong = %x73.74.72.6F.6E.67 ; "strong"
+
+ ItemOrUserFirst = ( id-itemFirst ":" ItemFirst ) /
+ ( id-userFirst ":" UserFirst )
+ id-itemFirst = %x69.74.65.6D.46.69.72.73.74 ; "itemFirst"
+ id-userFirst = %x75.73.65.72.46.69.72.73.74 ; "userFirst"
+
+ ItemFirst = "{" sp if-protectedItems ","
+ sp if-itemPermissions
+ sp "}"
+ if-protectedItems = id-protectedItems msp ProtectedItems
+ if-itemPermissions = id-itemPermissions msp ItemPermissions
+ id-protectedItems = %x70.72.6F.74.65.63.74.65.64.49.74.65.6D.73
+ ; "protectedItems"
+ id-itemPermissions = %x69.74.65.6D.50.65.72.6D.69.73.73.69.6F.6E
+ %x73 ; "itemPermissions"
+
+ UserFirst = "{" sp uf-userClasses ","
+ sp uf-userPermissions
+ sp "}"
+ uf-userClasses = id-userClasses msp UserClasses
+ uf-userPermissions = id-userPermissions msp UserPermissions
+ id-userClasses = %x75.73.65.72.43.6C.61.73.73.65.73
+ ; "userClasses"
+ id-userPermissions = %x75.73.65.72.50.65.72.6D.69.73.73.69.6F.6E
+ %x73 ; "userPermissions"
+
+ ItemPermissions = "{" [ sp ItemPermission
+ *( "," sp ItemPermission ) ] sp "}"
+ ItemPermission = "{" [ sp ip-precedence "," ]
+ sp ip-userClasses ","
+ sp ip-grantsAndDenials
+ sp "}"
+ ip-precedence = id-precedence msp Precedence
+ ip-userClasses = id-userClasses msp UserClasses
+ ip-grantsAndDenials = id-grantsAndDenials msp GrantsAndDenials
+ id-grantsAndDenials = %x67.72.61.6E.74.73.41.6E.64.44.65.6E.69.61
+ %x6C.73 ; "grantsAndDenials"
+
+
+
+
+Legg Expires 25 August 2003 [Page 35]
+\f
+INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
+
+
+ UserClasses = "{" [ sp uc-allUsers ]
+ [ sep sp uc-thisEntry ]
+ [ sep sp uc-name ]
+ [ sep sp uc-userGroup ]
+ [ sep sp uc-subtree ]
+ sp "}"
+ uc-allUsers = id-allUsers msp NULL
+ uc-thisEntry = id-thisEntry msp NULL
+ uc-name = id-name msp NameAndOptionalUIDs
+ uc-userGroup = id-userGroup msp NameAndOptionalUIDs
+ uc-subtree = id-subtree msp SubtreeSpecifications
+ id-allUsers = %x61.6C.6C.55.73.65.72.73 ; "allUsers"
+ id-thisEntry = %x74.68.69.73.45.6E.74.72.79 ; "thisEntry"
+ id-name = %x6E.61.6D.65 ; "name"
+ id-userGroup = %x75.73.65.72.47.72.6F.75.70 ; "userGroup"
+ id-subtree = %x73.75.62.74.72.65.65 ; "subtree"
+
+ NameAndOptionalUIDs = "{" sp NameAndOptionalUID
+ *( "," sp NameAndOptionalUID ) sp "}"
+ NameAndOptionalUID = "{" sp nu-dn
+ [ "," sp nu-uid ]
+ sp "}"
+ nu-dn = id-dn msp DistinguishedName
+ nu-uid = id-uid msp UniqueIdentifier
+ UniqueIdentifier = BIT-STRING
+ id-dn = %x64.6E ; "dn"
+ id-uid = %x75.69.64 ; "uid"
+
+ SubtreeSpecifications = "{" sp SubtreeSpecification
+ *( "," sp SubtreeSpecification ) sp "}"
+
+ UserPermissions = "{" [ sp UserPermission
+ *( "," sp UserPermission ) ] sp "}"
+ UserPermission = "{" [ sp up-precedence "," ]
+ sp up-protectedItems ","
+ sp up-grantsAndDenials
+ sp "}"
+ up-precedence = id-precedence msp Precedence
+ up-protectedItems = id-protectedItems msp ProtectedItems
+ up-grantsAndDenials = id-grantsAndDenials msp GrantsAndDenials
+
+ ProtectedItems = "{" [ sp pi-entry ]
+ [ sep sp pi-allUserAttributeTypes ]
+ [ sep sp pi-attributeType ]
+ [ sep sp pi-allAttributeValues ]
+ [ sep sp pi-allUserTypesAndValues ]
+ [ sep sp pi-attributeValue ]
+ [ sep sp pi-selfValue ]
+
+
+
+Legg Expires 25 August 2003 [Page 36]
+\f
+INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
+
+
+ [ sep sp pi-rangeOfValues ]
+ [ sep sp pi-maxValueCount ]
+ [ sep sp pi-maxImmSub ]
+ [ sep sp pi-restrictedBy ]
+ ; contexts omitted
+ [ sep sp pi-classes ]
+ sp "}"
+
+ pi-entry = id-entry msp NULL
+ pi-allUserAttributeTypes = id-allUserAttributeTypes msp NULL
+ pi-attributeType = id-attributeType msp AttributeTypes
+ pi-allAttributeValues = id-allAttributeValues msp
+ AttributeTypes
+ pi-allUserTypesAndValues = id-allUserAttributeTypesAndValues msp
+ NULL
+ pi-attributeValue = id-attributeValue msp
+ AttributeTypeAndValues
+ pi-selfValue = id-selfValue msp AttributeTypes
+ pi-rangeOfValues = id-rangeOfValues msp Filter
+ pi-maxValueCount = id-maxValueCount msp MaxValueCounts
+ pi-maxImmSub = id-maxImmSub msp INTEGER
+ pi-restrictedBy = id-restrictedBy msp RestrictedValues
+ pi-classes = id-classes msp Refinement
+ id-entry = %x65.6E.74.72.79 ; "entry"
+ id-allUserAttributeTypes = %x61.6C.6C.55.73.65.72.41.74.74.72.69
+ %x62.75.74.65.54.79.70.65.73
+ ; "allUserAttributeTypes"
+ id-attributeType = %x61.74.74.72.69.62.75.74.65.54.79.70
+ %x65 ; "attributeType"
+ id-allAttributeValues = %x61.6C.6C.41.74.74.72.69.62.75.74.65
+ %x56.61.6C.75.65.73
+ ; "allAttributeValues"
+ id-attributeValue = %x61.74.74.72.69.62.75.74.65.56.61.6C
+ %x75.65 ; "attributeValue"
+ id-selfValue = %x73.65.6C.66.56.61.6C.75.65
+ ; "selfValue"
+ id-rangeOfValues = %x72.61.6E.67.65.4F.66.56.61.6C.75.65
+ %x73 ; "rangeOfValues"
+ id-maxValueCount = %x6D.61.78.56.61.6C.75.65.43.6F.75.6E
+ %x74 ; "maxValueCount"
+ id-maxImmSub = %x6D.61.78.49.6D.6D.53.75.62
+ ; "maxImmSub"
+ id-restrictedBy = %x72.65.73.74.72.69.63.74.65.64.42.79
+ ; "restrictedBy"
+ id-classes = %x63.6C.61.73.73.65.73 ; "classes"
+
+ id-allUserAttributeTypesAndValues = %x61.6C.6C.55.73.65.72.41.74
+ %x74.72.69.62.75.74.65.54.79.70.65.73
+
+
+
+Legg Expires 25 August 2003 [Page 37]
+\f
+INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
+
+
+ %x41.6E.64.56.61.6C.75.65.73
+ ; "allUserAttributeTypesAndValues"
+
+ AttributeTypes = "{" sp AttributeType
+ *( "," sp AttributeType ) sp "}"
+
+ AttributeTypeAndValues = "{" sp AttributeTypeAndValue
+ *( "," sp AttributeTypeAndValue )
+ sp "}"
+
+ AttributeTypeAndValue = "{" sp atav-type ","
+ sp atav-value
+ sp "}"
+ atav-type = id-type msp AttributeType
+ atav-value = id-value msp Value
+ id-type = %x74.79.70.65 ; "type"
+ id-value = %x76.61.6C.75.65 ; "value"
+
+ MaxValueCounts = "{" sp MaxValueCount
+ *( "," sp MaxValueCount ) sp "}"
+ MaxValueCount = "{" sp mvc-type ","
+ sp mvc-maxCount
+ sp "}"
+ mvc-type = id-type msp AttributeType
+ mvc-maxCount = id-maxCount msp INTEGER
+ id-maxCount = %x6D.61.78.43.6F.75.6E.74 ; "maxCount"
+
+ RestrictedValues = "{" sp RestrictedValue
+ *( "," sp RestrictedValue ) sp "}"
+ RestrictedValue = "{" sp rv-type ","
+ sp rv-valuesin
+ sp "}"
+ rv-type = id-type msp AttributeType
+ rv-valuesin = id-valuesin msp AttributeType
+ id-valuesin = %x76.61.6C.75.65.73.69.6E ; "valuesin"
+
+ GrantsAndDenials = "{" [ sp grantOrDeny
+ *( "," sp grantOrDeny ) ] sp "}"
+ grantOrDeny = id-grantAdd
+ / id-denyAdd
+ / id-grantDiscloseOnError
+ / id-denyDiscloseOnError
+ / id-grantRead
+ / id-denyRead
+ / id-grantRemove
+ / id-denyRemove
+ / id-grantBrowse
+ / id-denyBrowse
+
+
+
+Legg Expires 25 August 2003 [Page 38]
+\f
+INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
+
+
+ / id-grantExport
+ / id-denyExport
+ / id-grantImport
+ / id-denyImport
+ / id-grantModify
+ / id-denyModify
+ / id-grantRename
+ / id-denyRename
+ / id-grantReturnDN
+ / id-denyReturnDN
+ / id-grantCompare
+ / id-denyCompare
+ / id-grantFilterMatch
+ / id-denyFilterMatch
+ ; grantInvoke omitted
+ ; denyInvoke omitted
+
+ id-grantAdd = %x67.72.61.6E.74.41.64.64 ; "grantAdd"
+ id-denyAdd = %x64.65.6E.79.41.64.64 ; "denyAdd"
+ id-grantBrowse = %x67.72.61.6E.74.42.72.6F.77.73.65
+ ; "grantBrowse"
+ id-denyBrowse = %x64.65.6E.79.42.72.6F.77.73.65 ; "denyBrowse"
+ id-grantCompare = %x67.72.61.6E.74.43.6F.6D.70.61.72.65
+ ; "grantCompare"
+ id-denyCompare = %x64.65.6E.79.43.6F.6D.70.61.72.65
+ ; "denyCompare"
+
+ id-grantDiscloseOnError = %x67.72.61.6E.74.44.69.73.63.6C.6F.73.65
+ %x4F.6E.45.72.72.6F.72
+ ; "grantDiscloseOnError"
+ id-denyDiscloseOnError = %x64.65.6E.79.44.69.73.63.6C.6F.73.65.4F
+ %x6E.45.72.72.6F.72
+ ; "denyDiscloseOnError"
+
+ id-grantExport = %x67.72.61.6E.74.45.78.70.6F.72.74
+ ; "grantExport"
+ id-denyExport = %x64.65.6E.79.45.78.70.6F.72.74
+ ; "denyExport"
+ id-grantFilterMatch = %x67.72.61.6E.74.46.69.6C.74.65.72.4D.61.74
+ %x63.68 ; "grantFilterMatch"
+ id-denyFilterMatch = %x64.65.6E.79.46.69.6C.74.65.72.4D.61.74.63
+ %x68 ; "denyFilterMatch"
+ id-grantImport = %x67.72.61.6E.74.49.6D.70.6F.72.74
+ ; "grantImport"
+ id-denyImport = %x64.65.6E.79.49.6D.70.6F.72.74
+ ; "denyImport"
+ id-grantModify = %x67.72.61.6E.74.4D.6F.64.69.66.79
+ ; "grantModify"
+
+
+
+Legg Expires 25 August 2003 [Page 39]
+\f
+INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
+
+
+ id-denyModify = %x64.65.6E.79.4D.6F.64.69.66.79
+ ; "denyModify"
+ id-grantRead = %x67.72.61.6E.74.52.65.61.64 ; "grantRead"
+ id-denyRead = %x64.65.6E.79.52.65.61.64 ; "denyRead"
+ id-grantRemove = %x67.72.61.6E.74.52.65.6D.6F.76.65
+ ; "grantRemove"
+ id-denyRemove = %x64.65.6E.79.52.65.6D.6F.76.65
+ ; "denyRemove"
+ id-grantRename = %x67.72.61.6E.74.52.65.6E.61.6D.65
+ ; "grantRename"
+ id-denyRename = %x64.65.6E.79.52.65.6E.61.6D.65
+ ; "denyRename"
+ id-grantReturnDN = %x67.72.61.6E.74.52.65.74.75.72.6E.44.4E
+ ; "grantReturnDN"
+ id-denyReturnDN = %x64.65.6E.79.52.65.74.75.72.6E.44.4E
+ ; "denyReturnDN"
+
+ The <sp>, <msp>, <sep>, <AttributeType>, <BIT-STRING>, <BOOLEAN>,
+ <DirectoryString>, <DistinguishedName>, <EXTERNAL>, <INTEGER>,
+ <INTEGER-0-MAX> and <NULL> rules are described in [GCE].
+
+ The <SubtreeSpecification> and <Refinement> rules are described in
+ [SUBENTRY].
+
+ The <Value> rule is described in [GSER].
+
+ Filter = filter-item / filter-and / filter-or / filter-not
+ filter-item = id-item ":" FilterItem
+ filter-and = id-and ":" SetOfFilter
+ filter-or = id-or ":" SetOfFilter
+ filter-not = id-not ":" Filter
+ id-and = %x61.6E.64 ; "and"
+ id-item = %x69.74.65.6D ; "item"
+ id-not = %x6E.6F.74 ; "not"
+ id-or = %x6F.72 ; "or"
+
+ SetOfFilter = "{" [ sp Filter *( "," sp Filter ) ] sp "}"
+
+ FilterItem = fi-equality
+ / fi-substrings
+ / fi-greaterOrEqual
+ / fi-lessOrEqual
+ / fi-present
+ / fi-approximateMatch
+ / fi-extensibleMatch
+ ; contextPresent omitted
+
+ fi-equality = id-equality ":" AttributeValueAssertion
+
+
+
+Legg Expires 25 August 2003 [Page 40]
+\f
+INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
+
+
+ fi-substrings = id-substrings ":" SubstringsAssertion
+ fi-greaterOrEqual = id-greaterOrEqual ":"
+ AttributeValueAssertion
+ fi-lessOrEqual = id-lessOrEqual ":" AttributeValueAssertion
+ fi-present = id-present ":" AttributeType
+ fi-approximateMatch = id-approximateMatch ":"
+ AttributeValueAssertion
+ fi-extensibleMatch = id-extensibleMatch ":" MatchingRuleAssertion
+ id-equality = %x65.71.75.61.6C.69.74.79 ; "equality"
+ id-substrings = %x73.75.62.73.74.72.69.6E.67.73
+ ; "substrings"
+ id-greaterOrEqual = %x67.72.65.61.74.65.72.4F.72.45.71.75.61.6C
+ ; "greaterOrEqual"
+ id-lessOrEqual = %x6C.65.73.73.4F.72.45.71.75.61.6C
+ ; "lessOrEqual"
+ id-present = %x70.72.65.73.65.6E.74 ; "present"
+ id-approximateMatch = %x61.70.70.72.6F.78.69.6D.61.74.65.4D.61.74
+ %x63.68 ; "approximateMatch"
+ id-extensibleMatch = %x65.78.74.65.6E.73.69.62.6C.65.4D.61.74.63
+ %x68 ; "extensibleMatch"
+
+ AttributeValueAssertion = "{" sp ava-type ","
+ sp ava-assertion
+ ; assertedContexts omitted
+ sp "}"
+
+ ava-type = id-type msp AttributeType
+ ava-assertion = id-assertion msp Value
+ id-assertion = %x61.73.73.65.72.74.69.6F.6E ; "assertion"
+
+ SubstringsAssertion = "{" sp sa-type ","
+ sp sa-strings
+ sp "}"
+
+ sa-type = id-type msp AttributeType
+ sa-strings = id-strings msp Substrings
+ id-strings = %x73.74.72.69.6E.67.73 ; "strings"
+
+ Substrings = "{" [ sp Substring *( "," sp Substring ) ] sp "}"
+ Substring = ss-initial
+ / ss-any
+ / ss-final
+ ; control omitted
+ ss-initial = id-initial ":" Value
+ ss-any = id-any ":" Value
+ ss-final = id-final ":" Value
+ id-initial = %x69.6E.69.74.69.61.6C ; "initial"
+ id-any = %x61.6E.79 ; "any"
+
+
+
+Legg Expires 25 August 2003 [Page 41]
+\f
+INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
+
+
+ id-final = %x66.69.6E.61.6C ; "final"
+
+ MatchingRuleAssertion = "{" sp mra-matchingRule
+ [ "," sp mra-type ]
+ "," sp mra-matchValue
+ [ "," sp mra-dnAttributes ]
+ sp "}"
+
+ mra-matchingRule = id-matchingRule msp MatchingRuleIds
+ mra-type = id-type msp AttributeType
+ mra-matchValue = id-matchValue msp Value
+ mra-dnAttributes = id-dnAttributes msp BOOLEAN
+ id-matchingRule = %x6D.61.74.63.68.69.6E.67.52.75.6C.65
+ ; "matchingRule"
+ id-matchValue = %x6D.61.74.63.68.56.61.6C.75.65 ; "matchValue"
+ id-dnAttributes = %x64.6E.41.74.74.72.69.62.75.74.65.73
+ ; "dnAttributes"
+
+ MatchingRuleIds = "{" sp MatchingRuleId *( "," sp MatchingRuleId ) sp "}"
+ MatchingRuleId = OBJECT-IDENTIFIER
+
+ The <OBJECT-IDENTIFIER> rule is described in [GCE].
+
+
+Appendix B. Changes From Previous Drafts
+
+B.1 Changes in Draft 01
+
+ The Internet draft draft-legg-ldap-acm-admin-00.txt has been split
+ into two drafts, draft-legg-ldap-admin-00.txt and
+ draft-legg-ldap-acm-admin-01.txt. Section 8 of
+ draft-legg-ldapext-component-matching-06.txt has been extracted to
+ become a separate Internet draft, draft-legg-ldap-gser-xx.txt. The
+ references in this document have been updated accordingly.
+
+ The term "native LDAP encoding" has been replaced by the term
+ "LDAP-specific encoding" to align with terminology anticipated to be
+ used in the revision of RFC 2252.
+
+ Changes have been made to the Search Operation Decision Points
+ (Section 5.4.3):
+
+ In 4) a), the assumed FilterMatch permission for a present match of
+ the objectClass attribute has been removed. An LDAP search with a
+ True filter [FILTER] is the best analogue of the DAP read operation.
+ A True filter does not filter any attribute type and therefore does
+ not require FilterMatch permissions to succeed.
+
+
+
+
+Legg Expires 25 August 2003 [Page 42]
+\f
+INTERNET-DRAFT Basic & Simplified Access Control February 25, 2003
+
+
+ In 5) b) and c), there is an additional requirement for Read
+ permission for at least one attribute value before an attribute type
+ can be returned in a search result. Without this change a search
+ result could, in some circumstances, disclose the existence of
+ particular hidden attribute values.
+
+B.2 Changes in Draft 02
+
+ RFC 3377 replaces RFC 2251 as the reference for LDAP.
+
+ An IANA Considerations section has been added.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Legg Expires 25 August 2003 [Page 43]
+\f
INTERNET-DRAFT S. Legg
-draft-legg-ldap-admin-00.txt Adacel Technologies
-Intended Category: Standards Track September 18, 2002
+draft-legg-ldap-admin-01.txt Adacel Technologies
+Intended Category: Standards Track February 25, 2003
Directory Administrative Model in LDAP
- Copyright (C) The Internet Society (2002). All Rights Reserved.
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
Status of this Memo
to the LDUP working group mailing list <ietf-ldup@imc.org> or to the
author.
- This Internet-Draft expires on 18 March 2003.
+ This Internet-Draft expires on 25 August 2003.
1. Abstract
-Legg Expires 18 March 2003 [Page 1]
+Legg Expires 25 August 2003 [Page 1]
\f
-INTERNET-DRAFT Directory Administrative Model September 18, 2002
-
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [RFC2119].
+INTERNET-DRAFT Directory Administrative Model February 25, 2003
2. Table of Contents
- 1. Abstract .................................................... 1
- 2. Table of Contents ........................................... 2
- 3. Introduction ................................................ 2
- 4. Administrative Areas ........................................ 2
- 5. Autonomous Administrative Areas ............................. 3
- 6. Specific Administrative Areas ............................... 3
- 7. Inner Administrative Areas .................................. 4
- 8. Administrative Entries ...................................... 5
- 9. Security Considerations ..................................... 5
- 10. Acknowledgements ........................................... 5
- 11. Normative References ....................................... 5
- 12. Informative References ..................................... 6
- 13. Copyright Notice ........................................... 6
- 14. Author's Address ........................................... 6
+ 1. Abstract ...................................................... 1
+ 2. Table of Contents ............................................. 2
+ 3. Introduction .................................................. 2
+ 4. Conventions ................................................... 2
+ 5. Administrative Areas .......................................... 3
+ 6. Autonomous Administrative Areas ............................... 3
+ 7. Specific Administrative Areas ................................. 3
+ 8. Inner Administrative Areas .................................... 4
+ 9. Administrative Entries ........................................ 5
+ 10. Security Considerations ...................................... 5
+ 11. Acknowledgements ............................................. 5
+ 12. Normative References ......................................... 5
+ 13. Informative References ....................................... 6
+ 14. Copyright Notice ............................................. 6
+ 15. Author's Address ............................................. 7
3. Introduction
This document adapts the X.500 directory administrative model [X501]
for use by the Lightweight Directory Access Protocol (LDAP)
- [RFC2251]. The administrative model partitions the Directory
+ [RFC3377]. The administrative model partitions the Directory
Information Tree (DIT) for various aspects of directory data
administration, e.g. subschema, access control and collective
attributes. This document provides the definitions for the generic
parts of the administrative model that apply to every aspect of
directory data administration.
- Sections 4 to 8, in conjunction with [SUBENTRY], describe the means
+ Sections 5 to 9, in conjunction with [SUBENTRY], describe the means
by which administrative authority is aportioned and exercised in the
DIT.
This document is derived from, and duplicates substantial portions
of, Sections 4 and 8 of [X501].
+4. 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 RFC 2119 [RFC2119].
-4. Administrative Areas
-Legg Expires 18 March 2003 [Page 2]
+Legg Expires 25 August 2003 [Page 2]
\f
-INTERNET-DRAFT Directory Administrative Model September 18, 2002
+INTERNET-DRAFT Directory Administrative Model February 25, 2003
+5. Administrative Areas
+
An administrative area is a subtree of the DIT considered from the
perspective of administration. The root entry of the subtree is an
administrative point. An administrative point is represented by an
of this attribute identify the kind of administrative point.
-5. Autonomous Administrative Areas
+6. Autonomous Administrative Areas
The DIT may be partitioned into one or more non-overlapping subtrees
termed autonomous administrative areas. It is expected that the
begins.
-6. Specific Administrative Areas
+7. Specific Administrative Areas
Entries in an administrative area may be considered in terms of a
specific administrative function. When viewed in this context, an
Alternatively, for each specific aspect of administration, the
autonomous administrative area may be partitioned into
- non-overlapping specific administrative areas.
-
-Legg Expires 18 March 2003 [Page 3]
+Legg Expires 25 August 2003 [Page 3]
\f
-INTERNET-DRAFT Directory Administrative Model September 18, 2002
+INTERNET-DRAFT Directory Administrative Model February 25, 2003
+ non-overlapping specific administrative areas.
+
If so partitioned for a particular aspect of administration, each
entry of the autonomous administrative area is contained in one and
only one specific administrative area for that aspect, i.e. specific
purposes only.
-7. Inner Administrative Areas
+8. Inner Administrative Areas
For some aspects of administration, e.g. access control or collective
attributes, inner administrative areas may be defined within the
specific administrative area) extends from its inner administrative
point downwards until a specific administrative point of the same
administrative aspect is encountered. An inner administrative area
- is bounded by the specific administrative area within which it is
- defined.
-Legg Expires 18 March 2003 [Page 4]
+Legg Expires 25 August 2003 [Page 4]
\f
-INTERNET-DRAFT Directory Administrative Model September 18, 2002
+INTERNET-DRAFT Directory Administrative Model February 25, 2003
-8. Administrative Entries
+ is bounded by the specific administrative area within which it is
+ defined.
+
+
+9. Administrative Entries
An entry located at an administrative point is an administrative
entry. Administrative entries MAY have subentries [SUBENTRY] as
aspect.
-9. Security Considerations
+10. Security Considerations
This document defines a generic framework for employing policy of
various kinds, e.g. access controls, to entries in the DIT. Such
unauthorized examination or changes by appropriate access controls.
-10. Acknowledgements
+11. Acknowledgements
This document is derived from, and duplicates substantial portions
of, Sections 4 and 8 of [X501].
-11. Normative References
+12. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
- Access Protocol (v3)", RFC 2251, December 1997.
+ [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
- [SUBENTRY] Zeilenga, K. and S. Legg, "Subentries in LDAP",
- draft-zeilenga-ldap-subentry-xx.txt, a work in progress,
- August 2002.
+Legg Expires 25 August 2003 [Page 5]
+\f
+INTERNET-DRAFT Directory Administrative Model February 25, 2003
-Legg Expires 18 March 2003 [Page 5]
-\f
-INTERNET-DRAFT Directory Administrative Model September 18, 2002
+ [SUBENTRY] Zeilenga, K. and S. Legg, "Subentries in LDAP",
+ draft-zeilenga-ldap-subentry-xx.txt, a work in progress,
+ August 2002.
-12. Informative References
+13. Informative References
[ACA] Legg, S., "Access Control Administration in LDAP",
draft-legg-ldap-acm-admin-xx.txt, a work in progress,
- September 2002.
+ February 2003.
[COLLECT] Zeilenga, K., "Collective Attributes in LDAP",
draft-zeilenga-ldap-collective-xx.txt, a work in progress,
Models
-13. Copyright Notice
+14. Copyright Notice
- Copyright (C) The Internet Society (2002). All Rights Reserved.
+ Copyright (C) The Internet Society (2003). 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
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-14. Author's Address
-
- Steven Legg
- Adacel Technologies Ltd.
-
-Legg Expires 18 March 2003 [Page 6]
+Legg Expires 25 August 2003 [Page 6]
\f
-INTERNET-DRAFT Directory Administrative Model September 18, 2002
+INTERNET-DRAFT Directory Administrative Model February 25, 2003
+
+15. Author's Address
- 405-409 Ferntree Gully Road
- Mount Waverley, Victoria 3149
+ Steven Legg
+ Adacel Technologies Ltd.
+ 250 Bay Street
+ Brighton, Victoria 3186
AUSTRALIA
- Phone: +61 3 9451 2107
- Fax: +61 3 9541 2121
+ Phone: +61 3 8530 7710
+ Fax: +61 3 8530 7888
EMail: steven.legg@adacel.com.au
-15. Appendix A - Changes From Previous Drafts
+Appendix A - Changes From Previous Drafts
+
+A.1 Changes in Draft 00
This document reproduces Section 4 from
draft-legg-ldap-acm-admin-00.txt as a standalone document. All
changes made are purely editorial. No technical changes have been
introduced.
+A.2 Changes in Draft 01
+ RFC 3377 replaces RFC 2251 as the reference for LDAP.
-
-
-
-
-
-
-
-
-Legg Expires 18 March 2003 [Page 7]
+Legg Expires 25 August 2003 [Page 7]
\f
INTERNET-DRAFT S. Legg
-draft-legg-ldap-gser-abnf-04.txt Adacel Technologies
-Intended Category: Informational August 19, 2002
+draft-legg-ldap-gser-abnf-06.txt Adacel Technologies
+Intended Category: Informational May 7, 2003
Common Elements of GSER Encodings
- Copyright (C) The Internet Society (2002). All Rights Reserved.
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
Status of this Memo
to the LDAPEXT working group mailing list <ietf-ldapext@netscape.com>
or to the author.
- This Internet-Draft expires on 19 February 2002.
+ This Internet-Draft expires on 7 November 2003.
-1. Abstract
+Abstract
The Generic String Encoding Rules (GSER) describe a human readable
text encoding for an ASN.1 value of any ASN.1 type. Specifications
-Legg Expires 19 February 2002 [Page 1]
+Legg Expires 7 November 2003 [Page 1]
\f
-INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
+INTERNET-DRAFT Common Elements of GSER Encodings May 7, 2003
-2. Table of Contents
+1. Table of Contents
- 1. Abstract .................................................... 1
- 2. Table of Contents ........................................... 2
- 3. Introduction ................................................ 2
- 4. Conventions ................................................. 2
- 5. Separators .................................................. 2
- 6. ASN.1 Built-in Types ........................................ 3
- 7. ASN.1 Restricted String Types ............................... 7
- 8. Directory ASN.1 Types ....................................... 8
- 9. Security Considerations ..................................... 9
- 10. Normative References ....................................... 10
- 11. Informative References ..................................... 10
- 12. Copyright Notice ........................................... 10
- 13. Author's Address ........................................... 11
+ 1. Table of Contents ............................................. 2
+ 2. Introduction .................................................. 2
+ 3. Conventions ................................................... 2
+ 4. Separators .................................................... 2
+ 5. ASN.1 Built-in Types .......................................... 3
+ 6. ASN.1 Restricted String Types ................................. 7
+ 7. Directory ASN.1 Types ......................................... 9
+ 8. Security Considerations ....................................... 10
+ 9. Normative References .......................................... 11
+ 10. Informative References ....................................... 11
+ 11. Copyright Notice ............................................. 11
+ 12. Author's Address ............................................. 12
-3. Introduction
+2. Introduction
- The Generic String Encoding Rules (GSER) defined in [9] define a
- human readable text encoding, based on ASN.1 [7] value notation, for
+ The Generic String Encoding Rules (GSER) defined in [7] define a
+ human readable text encoding, based on ASN.1 [8] value notation, for
an ASN.1 value of any ASN.1 type. Specifications making use of GSER
may wish to provide a non-normative equivalent ABNF [3] description
of the GSER encoding for a particular ASN.1 type as a convenience for
implementors unfamiliar with ASN.1. This document supports such
specifications by providing equivalent ABNF for the GSER encodings
- for ASN.1 types commonly occuring in LDAP [8] or X.500 [10] attribute
+ for ASN.1 types commonly occuring in LDAP [9] or X.500 [10] attribute
and assertion syntaxes, as well as equivalent ABNF for the GSER
encodings for the ASN.1 built-in types.
The ABNF given in this document does not replace or alter GSER in any
way. If there is a discrepancy between the ABNF specified here and
- the encoding defined by GSER in [9] then [9] is to be taken as
+ the encoding defined by GSER in [7] then [7] is to be taken as
definitive.
-4. Conventions
+3. 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 RFC 2119 [1].
-5. Separators
+4. Separators
Certain separators are commonly used in constructing equivalent ABNF
for SET and SEQUENCE types.
+ sp = *%x20 ; zero, one or more space characters
-Legg Expires 19 February 2002 [Page 2]
+Legg Expires 7 November 2003 [Page 2]
\f
-INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
+INTERNET-DRAFT Common Elements of GSER Encodings May 7, 2003
- sp = *%x20 ; zero, one or more space characters
msp = 1*%x20 ; one or more space characters
sep = [ "," ]
the SET or SEQUENCE value being encoded.
-6. ASN.1 Built-in Types
+5. ASN.1 Built-in Types
This section describes the GSER encoding of values of the ASN.1
built-in types, except for the restricted character string types.
-Legg Expires 19 February 2002 [Page 3]
+
+Legg Expires 7 November 2003 [Page 3]
\f
-INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
+INTERNET-DRAFT Common Elements of GSER Encodings May 7, 2003
CHARACTER-STRING = "{" sp id-identification msp Identification ","
-Legg Expires 19 February 2002 [Page 4]
+Legg Expires 7 November 2003 [Page 4]
\f
-INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
+INTERNET-DRAFT Common Elements of GSER Encodings May 7, 2003
INTEGER-0-MAX = "0" / positive-number
The <EMBEDDED-PDV> rule describes the GSER encoding of values of the
associated type for the EMBEDDED PDV type.
- EMBEDDED-PDV = "{" sp id-identification msp Identification
- [ "," sp id-data-value-descriptor msp
- ObjectDescriptor ]
- "," sp id-data-value msp OCTET-STRING
- sp "}"
+ EMBEDDED-PDV = "{" sp id-identification msp Identification ","
+ sp id-data-value msp OCTET-STRING
+ sp "}"
+
+ The <EXTERNAL> rule describes the GSER encoding of values of the
+ associated type for the EXTERNAL type.
+ EXTERNAL = "{" [ sp id-direct-reference msp
+ OBJECT-IDENTIFIER "," ]
+ [ sp id-indirect-reference msp INTEGER "," ]
+ [ sp id-data-value-descriptor msp
+ ObjectDescriptor "," ]
+ sp id-encoding msp Encoding
+ sp "}"
+
+ id-direct-reference = %x64.69.72.65.63.74.2D.72.65.66.65.72
+ %x65.6E.63.65
+ ; "direct-reference"
+ id-indirect-reference = %x69.6E.64.69.72.65.63.74.2D.72.65.66
+ %x65.72.65.6E.63.65
+ ; "indirect-reference"
id-data-value-descriptor = %x64.61.74.61.2D.76.61.6C.75.65.2D.64
%x65.73.63.72.69.70.74.6F.72
; "data-value-descriptor"
+ id-encoding = %x65.6E.63.6F.64.69.6E.67
+ ; "encoding"
- The <EXTERNAL> rule describes the GSER encoding of values of the
- associated type for the EXTERNAL type.
+ Encoding = ( id-single-ASN1-type ":" Value ) /
+ ( id-octet-aligned ":" OCTET-STRING ) /
+ ( id-arbitrary ":" BIT-STRING )
+
+ id-single-ASN1-type = %x73.69.6E.67.6C.65.2D.41.53.4E.31.2D.74.79
+ %x70.65
+ ; "single-ASN1-type"
+ id-octet-aligned = %x6F.63.74.65.74.2D.61.6C.69.67.6E.65.64
+ ; "octet-aligned"
+ id-arbitrary = %x61.72.62.69.74.72.61.72.79
+ ; "arbitrary"
- EXTERNAL = "{" sp id-identification msp E-Identification
- [ "," sp id-data-value-descriptor msp
- ObjectDescriptor ]
- "," sp id-data-value msp OCTET-STRING
- sp "}"
- E-Identification = ( id-syntax ":" OBJECT-IDENTIFIER ) /
- ( id-presentation-context-id ":" INTEGER ) /
- ( id-context-negotiation ":"
- ContextNegotiation )
+
+
+Legg Expires 7 November 2003 [Page 5]
+\f
+INTERNET-DRAFT Common Elements of GSER Encodings May 7, 2003
+
+
+ The <Value> rule is defined in [7]. It represents the GSER encoding
+ of a single value of the ASN.1 type identified by the direct-
+ reference and/or indirect-reference components.
The <NULL> rule describes the GSER encoding of values of the NULL
type.
An OBJECT IDENTIFIER value is encoded using either the dotted decimal
representation or an object descriptor name, i.e. <descr>. The
<descr> rule is described in [4]. An object descriptor name is
-
-
-
-Legg Expires 19 February 2002 [Page 5]
-\f
-INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
-
-
potentially ambiguous and should be used with care.
The <OCTET-STRING> rule describes the GSER encoding of values of the
MINUS-INFINITY = %x4D.49.4E.55.53.2D.49.4E.46.49.4E.49.54.59
; "MINUS-INFINITY"
+
+
+
+Legg Expires 7 November 2003 [Page 6]
+\f
+INTERNET-DRAFT Common Elements of GSER Encodings May 7, 2003
+
+
realnumber = mantissa exponent
mantissa = (positive-number [ "." *decimal-digit ])
/ ( "0." *("0") positive-number )
RELATIVE-OID = oid-component *( "." oid-component )
-
-
-Legg Expires 19 February 2002 [Page 6]
-\f
-INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
-
-
-7. ASN.1 Restricted String Types
+6. ASN.1 Restricted String Types
This section describes the GSER encoding of values of the ASN.1
restricted character string types. The characters of a value of a
restricted character string type are always encoded as a UTF8
character string between double quotes. For some of the ASN.1 string
- types this requires a translation to or form the UTF8 encoding. Some
+ types this requires a translation to or from the UTF8 encoding. Some
of the ASN.1 string types permit only a subset of the characters
representable in UTF8. Any double quote characters in the character
string, where allowed by the character set, are escaped by being
%xF8-FB 4(%x80-BF) / ; 5 byte UTF8 character
%xFC-FD 5(%x80-BF) ; 6 byte UTF8 character
+
+
+Legg Expires 7 November 2003 [Page 7]
+\f
+INTERNET-DRAFT Common Elements of GSER Encodings May 7, 2003
+
+
The <NumericString>, <PrintableString>, <VisibleString>,
<ISO646String>, <IA5String>, <GeneralizedTime> and <UTCTime> rules
describe the GSER encoding of values of the correspondingly named
/ %x2B-2F ; + , - . /
/ %x3A ; :
/ %x3D ; =
-
-
-
-Legg Expires 19 February 2002 [Page 7]
-\f
-INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
-
-
/ %x3F ; ?
ISO646String = VisibleString
SafeIA5Character = %x00-21 / %x23-7F ; ASCII minus dquote
/ dquote dquote ; escaped double quote
- UTCTime = dquote 10(decimal-digit) [2(decimal-digit)]
- [ "Z" / u-differential ] dquote
- u-differential = ( "-" / "+" ) 4(decimal-digit)
- GeneralizedTime = dquote 10(decimal-digit)
- *2(2(decimal-digit))
- fraction [ "Z" / g-differential ] dquote
- fraction = ( "." / "," ) 1*decimal-digit
- g-differential = ( "-" / "+" ) 1*2(2(decimal-digit))
+ century = 2(%x30-39) ; "00" to "99"
+ year = 2(%x30-39) ; "00" to "99"
+ month = ( %x30 %x31-39 ) ; "01" (January) to "09"
+ / ( %x31 %x30-32 ) ; "10" to "12"
+ day = ( %x30 %x31-39 ) ; "01" to "09"
+ / ( %x31-32 %x30-39 ) ; "10" to "29"
+ / ( %x32 %x30-31 ) ; "30" to "31"
+ hour = ( %x30-31 %x30-39 ) / ( %x32 %x30-33 ) ; "00" to "23"
+ minute = %x30-36 %x30-39 ; "00" to "59"
+ second = %x30-36 %x30-39 ; "00" to "59"
+
+ UTCTime = dquote year month day hour minute [ second ]
+ [ %x5A / u-differential ] dquote
+ u-differential = ( "-" / "+" ) hour minute
+ GeneralizedTime = dquote century year month day hour
+ [ minute [ second ] ] [ fraction ]
+ [ %x5A / g-differential ] dquote
+
+
+
+Legg Expires 7 November 2003 [Page 8]
+\f
+INTERNET-DRAFT Common Elements of GSER Encodings May 7, 2003
+
+
+ fraction = ( "." / "," ) 1*(%x30-39)
+ g-differential = ( "-" / "+" ) hour [ minute ]
The <BMPString> and <UniversalString> rules describe the GSER
encoding of values of the BMPString and UniversalString types
ObjectDescriptor = GraphicString
-8. Directory ASN.1 Types
+7. Directory ASN.1 Types
This section describes the GSER encoding of values of selected ASN.1
-
-
-
-Legg Expires 19 February 2002 [Page 8]
-\f
-INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
-
-
types defined for LDAP and X.500. The ABNF rule names beginning with
uppercase letters describe the GSER encoding of values of the ASN.1
type with the same name.
characters as required before being encoded between double quotes
with any embedded double quotes escaped by being repeated.
- DirectoryString = dquote *SafeUTF8Character dquote
+ DirectoryString = StringValue /
+ ( id-teletexString ":" TeletexString ) /
+ ( id-printableString ":" PrintableString ) /
+ ( id-bmpString ":" BMPString ) /
+ ( id-universalString ":" UniversalString ) /
+ ( id-uTF8String ":" UTF8String )
+
+ id-teletexString = %x74.65.6C.65.74.65.78.53.74.72.69.6E.67
+
+
+
+Legg Expires 7 November 2003 [Page 9]
+\f
+INTERNET-DRAFT Common Elements of GSER Encodings May 7, 2003
+
+
+ ; "teletexString"
+ id-printableString = %x70.72.69.6E.74.61.62.6C.65
+ %x53.74.72.69.6E.67 ; "printableString"
+ id-bmpString = %x62.6D.70.53.74.72.69.6E.67 ; "bmpString"
+ id-universalString = %x75.6E.69.76.65.72.73.61.6C
+ %x53.74.72.69.6E.67 ; "universalString"
+ id-uTF8String = %x75.54.46.38.53.74.72.69.6E.67
+ ; "uTF8String"
The <RDNSequence> rule describes the GSER encoding of values of the
RDNSequence type, which is syntactically equivalent to the
ORAddress = dquote *SafeIA5Character dquote
-9. Security Considerations
+8. Security Considerations
- GSER, and therefore the ABNF encodings described in this document, do
+ This document contains an alternative description of parts of the
+ Generic String Encoding Rules, but does not replace or alter GSER in
+ any way. For the full security implications of using GSER see the
+ Security Considerations section of [7].
-Legg Expires 19 February 2002 [Page 9]
+Legg Expires 7 November 2003 [Page 10]
\f
-INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
-
+INTERNET-DRAFT Common Elements of GSER Encodings May 7, 2003
- not necessarily enable the exact octet encoding of values of the
- TeletexString, VideotexString, GraphicString or GeneralString types
- to be reconstructed, so a transformation from DER to GSER and back to
- DER may not reproduce the original DER encoding. This has
- consequences for the verification of digital signatures.
-
-10. Normative References
+9. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998.
- [7] ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998
+ [7] Legg, S., "Generic String Encoding Rules for ASN.1 Types",
+ draft-legg-ldap-gser-xx.txt, a work in progress, May 2003.
+
+ [8] ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998
Information Technology - Abstract Syntax Notation One (ASN.1):
Specification of basic notation
-11. Informative References
-
- [8] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
- Protocol (v3)", RFC 2251, December 1997.
+10. Informative References
- [9] Legg, S., "Generic String Encoding Rules for ASN.1 Types",
- draft-legg-ldap-gser-xx.txt, a work in progress, August 2002.
+ [9] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol
+ (v3): Technical Specification", RFC 3377, September 2002.
[10] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
Information Technology - Open Systems Interconnection - The
Directory: Overview of concepts, models and services
-12. Copyright Notice
-
-
+11. Copyright Notice
-Legg Expires 19 February 2002 [Page 10]
-\f
-INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
-
-
- Copyright (C) The Internet Society (2002). All Rights Reserved.
+ Copyright (C) The Internet Society (2003). 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
+
+
+
+Legg Expires 7 November 2003 [Page 11]
+\f
+INTERNET-DRAFT Common Elements of GSER Encodings May 7, 2003
+
+
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
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-13. Author's Address
+12. Author's Address
Steven Legg
Adacel Technologies Ltd.
- 405-409 Ferntree Gully Road
- Mount Waverley, Victoria 3149
+ 250 Bay Street
+ Brighton, Victoria 3186
AUSTRALIA
- Phone: +61 3 9451 2107
- Fax: +61 3 9541 2121
+ Phone: +61 3 8530 7710
+ Fax: +61 3 8530 7888
EMail: steven.legg@adacel.com.au
-Legg Expires 19 February 2002 [Page 11]
+
+
+
+
+
+
+Legg Expires 7 November 2003 [Page 12]
\f
INTERNET-DRAFT S. Legg
-draft-legg-ldap-gser-01.txt Adacel Technologies
-Intended Category: Standard Track August 19, 2002
+draft-legg-ldap-gser-03.txt Adacel Technologies
+Intended Category: Standard Track May 7, 2003
Generic String Encoding Rules for ASN.1 Types
- Copyright (C) The Internet Society (2002). All Rights Reserved.
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
Status of this Memo
to the LDAPEXT working group mailing list <ietf-ldapext@netscape.com>
or to the author.
- This Internet-Draft expires on 19 February 2002.
+ This Internet-Draft expires on 7 November 2003.
-1. Abstract
+Abstract
This document defines a set of Abstract Syntax Notation One (ASN.1)
encoding rules, called the Generic String Encoding Rules, that
-Legg Expires 19 February 2002 [Page 1]
+Legg Expires 7 November 2003 [Page 1]
\f
-INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
-
-
-2. Table of Contents
-
- 1. Abstract ...................................................... 1
- 2. Table of Contents ............................................. 2
- 3. Introduction .................................................. 2
- 4. Conventions ................................................... 3
- 5. Generic String Encoding Rules ................................. 3
- 5.1 Type Referencing Notations ................................ 4
- 5.2 Restricted Character String Types ......................... 4
- 5.3 ChoiceOfStrings Types ..................................... 5
- 5.4 Identifiers ............................................... 7
- 5.5 BIT STRING ................................................ 7
- 5.6 BOOLEAN ................................................... 8
- 5.7 ENUMERATED ................................................ 8
- 5.8 INTEGER ................................................... 8
- 5.9 NULL ...................................................... 8
- 5.10 OBJECT IDENTIFIER and RELATIVE-OID ....................... 9
- 5.11 OCTET STRING ............................................. 9
- 5.12 CHOICE ................................................... 9
- 5.13 SEQUENCE and SET ......................................... 10
- 5.14 SEQUENCE OF and SET OF ................................... 11
- 5.15 CHARACTER STRING ......................................... 11
- 5.16 EMBEDDED PDV ............................................. 11
- 5.17 EXTERNAL ................................................. 11
- 5.18 INSTANCE OF .............................................. 12
- 5.19 REAL ..................................................... 12
- 5.20 Variant Encodings ........................................ 12
- 6. GSER Transfer Syntax .......................................... 13
- 7. Security Considerations ....................................... 13
- 8. Normative References .......................................... 13
- 9. Informative References ........................................ 14
- 10. Copyright Notice ............................................. 15
- 11. Author's Address ............................................. 15
-
-
-3. Introduction
+INTERNET-DRAFT Generic String Encoding Rules May 7, 2003
+
+
+1. Table of Contents
+
+ 1. Table of Contents ............................................. 2
+ 2. Introduction .................................................. 2
+ 3. Conventions ................................................... 3
+ 4. Generic String Encoding Rules ................................. 3
+ 4.1 Type Referencing Notations ................................ 4
+ 4.2 Restricted Character String Types ......................... 4
+ 4.3 ChoiceOfStrings Types ..................................... 5
+ 4.4 Identifiers ............................................... 7
+ 4.5 BIT STRING ................................................ 7
+ 4.6 BOOLEAN ................................................... 8
+ 4.7 ENUMERATED ................................................ 8
+ 4.8 INTEGER ................................................... 8
+ 4.9 NULL ...................................................... 8
+ 4.10 OBJECT IDENTIFIER and RELATIVE-OID ....................... 9
+ 4.11 OCTET STRING ............................................. 9
+ 4.12 CHOICE ................................................... 9
+ 4.13 SEQUENCE and SET ......................................... 10
+ 4.14 SEQUENCE OF and SET OF ................................... 11
+ 4.15 CHARACTER STRING ......................................... 11
+ 4.16 EMBEDDED PDV ............................................. 11
+ 4.17 EXTERNAL ................................................. 11
+ 4.18 INSTANCE OF .............................................. 12
+ 4.19 REAL ..................................................... 12
+ 4.20 Variant Encodings ........................................ 12
+ 5. GSER Transfer Syntax .......................................... 13
+ 6. Security Considerations ....................................... 13
+ 7. Normative References .......................................... 14
+ 8. Informative References ........................................ 15
+ 9. Copyright Notice .............................................. 15
+ 10. Author's Address ............................................. 16
+
+
+2. Introduction
This document defines a set of ASN.1 [8] encoding rules, called the
Generic String Encoding Rules or GSER, that produce a human readable
UTF8 [6] character string encoding of ASN.1 values of any given
arbitrary ASN.1 type.
- Note that "ASN.1 value" does not mean a BER [17] encoded value. The
+ Note that "ASN.1 value" does not mean a BER [13] encoded value. The
ASN.1 value is an abstract concept that is independent of any
particular encoding. BER is just one possible encoding of an ASN.1
value.
GSER is based on ASN.1 value notation [8], with changes to
+ accommodate the notation's use as a transfer syntax, and to support
-Legg Expires 19 February 2002 [Page 2]
+Legg Expires 7 November 2003 [Page 2]
\f
-INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
+INTERNET-DRAFT Generic String Encoding Rules May 7, 2003
- accommodate the notation's use as a transfer syntax, and to support
- well established ad-hoc string encodings for LDAP [13] directory data
+ well established ad-hoc string encodings for LDAP [14] directory data
types.
Though primarily intended for defining the LDAP-specific encoding of
type, however other specifications may wish to provide a customized
ABNF [3] description, independent of the ASN.1, as a convenience for
the implementor (equivalent ABNF for the GSER encodings for ASN.1
- types commonly occuring in LDAP syntaxes is provided in [14]). Such
+ types commonly occuring in LDAP syntaxes is provided in [15]). Such
a specification SHOULD state that if there is a discrepancy between
the customized ABNF and the GSER encoding defined by this document,
that the GSER encoding takes precedence.
-4. Conventions
+3. Conventions
Throughout this document "type" shall be taken to mean an ASN.1 type,
and "value" shall be taken to mean an ASN.1 value.
document are to be interpreted as described in RFC 2119 [1].
-5. Generic String Encoding Rules
+4. Generic String Encoding Rules
The GSER encoding of a value of any ASN.1 type is described by the
following ABNF [3]:
NullValue /
ObjectDescriptorValue /
ObjectIdentifierValue /
+ OctetStringValue /
-Legg Expires 19 February 2002 [Page 3]
+Legg Expires 7 November 2003 [Page 3]
\f
-INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
+INTERNET-DRAFT Generic String Encoding Rules May 7, 2003
- OctetStringValue /
RealValue /
RelativeOIDValue /
SequenceOfValue /
sections.
-5.1 Type Referencing Notations
+4.1 Type Referencing Notations
A value of a type with a defined type name is encoded according to
the type definition on the right hand side of the type assignment for
15 of [10]) is encoded according to the governing type.
-5.2 Restricted Character String Types
+4.2 Restricted Character String Types
+ The contents of a string value are encoded as a UTF8 character string
-Legg Expires 19 February 2002 [Page 4]
+Legg Expires 7 November 2003 [Page 4]
\f
-INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
+INTERNET-DRAFT Generic String Encoding Rules May 7, 2003
- The contents of a string value are encoded as a UTF8 character string
between double quotes, regardless of the ASN.1 string type.
Depending on the ASN.1 string type, and an application's internal
representation of that string type, a translation to or from the UTF8
ObjectDescriptorValue = StringValue
-5.3 ChoiceOfStrings Types
+4.3 ChoiceOfStrings Types
It is not uncommon for ASN.1 specifications to define types that are
a CHOICE between two or more alternative ASN.1 string types, where
to avoid having to use a complicated character encoding for all
values when most values could use a simpler string type, or to deal
with evolving requirements that compel the use of a broader character
+ set while still maintaining backward compatibility.
-Legg Expires 19 February 2002 [Page 5]
+Legg Expires 7 November 2003 [Page 5]
\f
-INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
+INTERNET-DRAFT Generic String Encoding Rules May 7, 2003
- set while still maintaining backward compatibility.
-
GSER encodes values of all the ASN.1 string types as UTF8 character
strings so the alternative chosen in a purely syntactic CHOICE of
string types makes no material difference to the final encoding of
those constructs does not necessarily mean a CHOICE type is purely
syntactic. Therefore, it is necessary for specifications to declare
the purely syntactic CHOICE types so that they may be more compactly
- encoded (see Section 5.12). These declared CHOICE types are referred
+ encoded (see Section 4.12). These declared CHOICE types are referred
to as ChoiceOfStrings types.
To be eligible to be declared a ChoiceOfStrings type an ASN.1 type
parameter defines a ASN.1 type that satisfies the above conditions.
Recognising that the alternative within a DirectoryString carries no
semantic significance, this document declares (each and every use of)
+ DirectoryString{} to be a ChoiceOfStrings type.
-Legg Expires 19 February 2002 [Page 6]
-\f
-INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
+Legg Expires 7 November 2003 [Page 6]
+\f
+INTERNET-DRAFT Generic String Encoding Rules May 7, 2003
- DirectoryString{} to be a ChoiceOfStrings type.
Other specifications MAY declare other types satisfying the above
conditions to be ChoiceOfStrings types. The declaration SHOULD be
attribute or assertion syntax.
-5.4 Identifiers
+4.4 Identifiers
An <identifier> conforms to the definition of an identifier in ASN.1
notation (Clause 11.3 of [8]). It begins with a lowercase letter and
hyphen = "-"
-5.5 BIT STRING
+4.5 BIT STRING
A value of the BIT STRING type is encoded according to the
<BitStringValue> rule. If the definition of the BIT STRING type
includes a named bit list, the <bit-list> form of <BitStringValue>
- rule MAY be used. If the number of bits in a BIT STRING value is a
+ MAY be used. If the number of bits in a BIT STRING value is a
multiple of four the <hstring> form of <BitStringValue> MAY be used.
The <bstring> form of <BitStringValue> is used otherwise.
bit-list = "{" [ sp identifier
*( "," sp identifier ) ] sp "}"
+ hstring = squote *hexadecimal-digit squote %x48 ; '...'H
+
-Legg Expires 19 February 2002 [Page 7]
+Legg Expires 7 November 2003 [Page 7]
\f
-INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
+INTERNET-DRAFT Generic String Encoding Rules May 7, 2003
- hstring = squote *hexadecimal-digit squote %x48 ; '...'H
hexadecimal-digit = %x30-39 / ; "0" to "9"
%x41-46 ; "A" to "F"
squote = %x27 ; ' (single quote)
-5.6 BOOLEAN
+4.6 BOOLEAN
A value of the BOOLEAN type is encoded according to the
<BooleanValue> rule.
%x46.41.4C.53.45 ; "FALSE"
-5.7 ENUMERATED
+4.7 ENUMERATED
A value of the ENUMERATED type is encoded according to the
<EnumeratedValue> rule. The <identifier> MUST be one of those in the
EnumeratedValue = identifier
-5.8 INTEGER
+4.8 INTEGER
A value of the INTEGER type is encoded according to the
<IntegerValue> rule. If the definition of the INTEGER type includes
non-zero-digit = %x31-39 ; "1" to "9"
-5.9 NULL
+4.9 NULL
+ A value of the NULL type is encoded according to the <NullValue>
-Legg Expires 19 February 2002 [Page 8]
+Legg Expires 7 November 2003 [Page 8]
\f
-INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
+INTERNET-DRAFT Generic String Encoding Rules May 7, 2003
- A value of the NULL type is encoded according to the <NullValue>
rule.
NullValue = %x4E.55.4C.4C ; "NULL"
-5.10 OBJECT IDENTIFIER and RELATIVE-OID
+4.10 OBJECT IDENTIFIER and RELATIVE-OID
A value of the OBJECT IDENTIFIER type is encoded according to the
<ObjectIdentifierValue> rule. The <ObjectIdentifierValue> rule
RelativeOIDValue = oid-component *( "." oid-component )
-5.11 OCTET STRING
+4.11 OCTET STRING
A value of the OCTET STRING type is encoded according to the
<OctetStringValue> rule. The octets are encoded in order from the
OctetStringValue = hstring
-5.12 CHOICE
+4.12 CHOICE
A value of a CHOICE type is encoded according to the <ChoiceValue>
rule. The <ChoiceOfStringsValue> encoding MAY be used if the
corresponding CHOICE type has been declared a ChoiceOfStrings type.
This document declares DirectoryString to be a ChoiceOfStrings type
- (see Section 5.3). The <IdentifiedChoiceValue> form of <ChoiceValue>
+ (see Section 4.3). The <IdentifiedChoiceValue> form of <ChoiceValue>
is used otherwise.
ChoiceValue = IdentifiedChoiceValue /
+ ChoiceOfStringsValue
-Legg Expires 19 February 2002 [Page 9]
+Legg Expires 7 November 2003 [Page 9]
\f
-INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
-
+INTERNET-DRAFT Generic String Encoding Rules May 7, 2003
- ChoiceOfStringsValue
IdentifiedChoiceValue = identifier ":" Value
ChoiceOfStringsValue = StringValue
For implementations that recognise the internal structure of the
- DirectoryString CHOICE type (e.g. X.500 directories [15]), if the
+ DirectoryString CHOICE type (e.g. X.500 directories [16]), if the
character string between the quotes in a <StringValue> contains only
characters that are permitted in a PrintableString the
DirectoryString is assumed to use the printableString alternative,
<IdentifiedChoiceValue> form for a DirectoryString value, though the
particular identifier found will be of no interest.
-5.13 SEQUENCE and SET
+4.13 SEQUENCE and SET
A value of a SEQUENCE type is encoded according to the
<SequenceValue> rule. The <ComponentList> rule encodes a comma
SetValue = ComponentList
+ SEQUENCE and SET type definitions are sometimes extended by the
+ inclusion of additional component types, so an implementation SHOULD
-Legg Expires 19 February 2002 [Page 10]
+Legg Expires 7 November 2003 [Page 10]
\f
-INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
+INTERNET-DRAFT Generic String Encoding Rules May 7, 2003
- SEQUENCE and SET type definitions are sometimes extended by the
- inclusion of additional component types, so an implementation SHOULD
be capable of skipping over any <NamedValue> encoding with an
identifier that is not recognised, on the assumption that the sender
is using a more recent definition of the SEQUENCE or SET type.
-5.14 SEQUENCE OF and SET OF
+4.14 SEQUENCE OF and SET OF
A value of a SEQUENCE OF type is encoded according to the
<SequenceOfValue> rule, as a comma separated list of the instances in
SetOfValue = "{" [ sp Value *( "," sp Value) ] sp "}"
-5.15 CHARACTER STRING
+4.15 CHARACTER STRING
A value of the unrestricted CHARACTER STRING type is encoded
according to the corresponding SEQUENCE type defined in Clause 39.5
- of [8] (see [14] for equivalent ABNF).
+ of [8] (see [15] for equivalent ABNF).
CharacterStringValue = SequenceValue
-5.16 EMBEDDED PDV
+4.16 EMBEDDED PDV
A value of the EMBEDDED PDV type is encoded according to the
- corresponding SEQUENCE type defined in Clause 32.5 of [8] (see [14]
+ corresponding SEQUENCE type defined in Clause 32.5 of [8] (see [15]
for equivalent ABNF).
EmbeddedPDVValue = SequenceValue
-5.17 EXTERNAL
+4.17 EXTERNAL
A value of the EXTERNAL type is encoded according to the
- corresponding SEQUENCE type defined in Clause 33.5 of [8] (see [14]
- for equivalent ABNF).
+ corresponding SEQUENCE type defined in Clause 8.18.1 of [13] (see
+ [15] for equivalent ABNF).
ExternalValue = SequenceValue
-Legg Expires 19 February 2002 [Page 11]
+
+
+Legg Expires 7 November 2003 [Page 11]
\f
-INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
+INTERNET-DRAFT Generic String Encoding Rules May 7, 2003
-5.18 INSTANCE OF
+4.18 INSTANCE OF
A value of the INSTANCE OF type is encoded according to the
corresponding SEQUENCE type defined in Annex C of [10].
InstanceOfValue = SequenceValue
-5.19 REAL
+4.19 REAL
A value of the REAL type MUST be encoded as "0" if it is zero,
otherwise it is encoded as either the special value <PLUS-INFINITY>,
the special value <MINUS-INFINITY>, an optionally signed <realnumber>
- (based on the extended value notation for REAL from [16]) or as a
+ (based on the extended value notation for REAL from [17]) or as a
value of the corresponding SEQUENCE type for REAL defined in Clause
- 20.5 of [8] (see [14] for equivalent ABNF).
+ 20.5 of [8] (see [15] for equivalent ABNF).
RealValue = "0" ; zero REAL value
/ PLUS-INFINITY ; positive infinity
; "MINUS-INFINITY"
-5.20 Variant Encodings
+4.20 Variant Encodings
The values of some named complex ASN.1 types have special string
encodings. These special encodings are always used instead of the
-Legg Expires 19 February 2002 [Page 12]
+Legg Expires 7 November 2003 [Page 12]
\f
-INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
+INTERNET-DRAFT Generic String Encoding Rules May 7, 2003
the <distinguishedName> rule in Section 3 of [5], and then it is
ORAddressValue = StringValue
-6. GSER Transfer Syntax
+5. GSER Transfer Syntax
The following OBJECT IDENTIFIER has been assigned to identify the
Generic String Encoding Rules:
{ 1 2 36 79672281 0 0 }
This OBJECT IDENTIFIER would be used, for example, to describe the
- transfer syntax for a GSER encoded data-value in an EXTERNAL or
- EMBEDDED PDV value.
+ transfer syntax for a GSER encoded data-value in an EMBEDDED PDV
+ value.
+
+6. Security Considerations
-7. Security Considerations
+ The Generic String Encoding Rules do not define a canonical encoding.
+ That is, a transformation from a GSER encoding into some other
+ encoding (e.g. BER) and back into GSER will not necessarily reproduce
+ exactly the original GSER octet encoding. Therefore GSER SHOULD NOT
+ be used where a canonical encoding is needed.
- The Generic String Encoding Rules do not necessarily enable the exact
- octet encoding of values of the TeletexString, VideotexString,
+ Furthermore, GSER does not necessarily enable the exact octet
+ encoding of values of the TeletexString, VideotexString,
GraphicString or GeneralString types to be reconstructed, so a
transformation from DER to GSER and back to DER may not reproduce the
- original DER encoding. This has consequences for the verification of
- digital signatures.
+ original DER encoding. Therefore GSER SHOULD NOT be used where
-8. Normative References
- [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+Legg Expires 7 November 2003 [Page 13]
+\f
+INTERNET-DRAFT Generic String Encoding Rules May 7, 2003
+ reversibility to DER is needed, e.g. for the verification of digital
+ signatures. Instead, DER or a DER-reversible encoding should be
+ used.
-Legg Expires 19 February 2002 [Page 13]
-\f
-INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
+ When interpreting security-sensitive fields, and in particular fields
+ used to grant or deny access, implementations MUST ensure that any
+ comparisons are done on the underlying abstract value, regardless of
+ the particular encoding used.
+7. Normative References
+
+ [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping
Information object specification
[11] ITU-T Recommendation X.682 (1997) | ISO/IEC 8824-3:1998
- Information Technology - Abstract Syntax Notation One (ASN.1):
- Constraint specification
- [12] ITU-T Recommendation X.683 (1997) | ISO/IEC 8824-4:1998
- Information Technology - Abstract Syntax Notation One (ASN.1):
- Parameterization of ASN.1 specifications
-9. Informative References
+Legg Expires 7 November 2003 [Page 14]
+\f
+INTERNET-DRAFT Generic String Encoding Rules May 7, 2003
- [13] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
- Protocol (v3)", RFC 2251, December 1997.
+ Information Technology - Abstract Syntax Notation One (ASN.1):
+ Constraint specification
+ [12] ITU-T Recommendation X.683 (1997) | ISO/IEC 8824-4:1998
+ Information Technology - Abstract Syntax Notation One (ASN.1):
+ Parameterization of ASN.1 specifications
+ [13] ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998
+ Information Technology - ASN.1 encoding rules: Specification of
+ Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and
+ Distinguished Encoding Rules (DER)
-Legg Expires 19 February 2002 [Page 14]
-\f
-INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
+8. Informative References
- [14] Legg, S., "Common Elements of GSER Encodings",
- draft-legg-ldap-gser-abnf-xx.txt, a work in progress, August
+ [14] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377, September
2002.
- [15] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
+ [15] Legg, S., "Common Elements of GSER Encodings",
+ draft-legg-ldap-gser-abnf-xx.txt, a work in progress, May 2003.
+
+ [16] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
Information Technology - Open Systems Interconnection - The
Directory: Overview of concepts, models and services
- [16] ITU-T Recommendation X.680 - Corrigendum 3 (02/2001)
-
- [17] ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998
- Information Technology - ASN.1 encoding rules: Specification of
- Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and
- Distinguished Encoding Rules (DER)
+ [17] ITU-T Recommendation X.680 - Corrigendum 3 (02/2001)
-10. Copyright Notice
+9. Copyright Notice
- Copyright (C) The Internet Society (2002). All Rights Reserved.
+ Copyright (C) The Internet Society (2003). 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
English.
The limited permissions granted above are perpetual and will not be
+
+
+
+Legg Expires 7 November 2003 [Page 15]
+\f
+INTERNET-DRAFT Generic String Encoding Rules May 7, 2003
+
+
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-11. Author's Address
+10. Author's Address
Steven Legg
-
-
-
-Legg Expires 19 February 2002 [Page 15]
-\f
-INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
-
-
Adacel Technologies Ltd.
- 405-409 Ferntree Gully Road
- Mount Waverley, Victoria 3149
+ 250 Bay Street
+ Brighton, Victoria 3186
AUSTRALIA
- Phone: +61 3 9451 2107
- Fax: +61 3 9541 2121
+ Phone: +61 3 8530 7710
+ Fax: +61 3 8530 7888
EMail: steven.legg@adacel.com.au
-
-
-
-
-
-
-
-
-
-
-
-
-
-Legg Expires 19 February 2002 [Page 16]
+Legg Expires 7 November 2003 [Page 16]
\f
INTERNET-DRAFT S. Legg
-draft-legg-ldapext-component-matching-08.txt Adacel Technologies
-Intended Category: Standard Track April 19, 2002
+draft-legg-ldapext-component-matching-10.txt Adacel Technologies
+Intended Category: Standard Track April 2, 2003
LDAP & X.500 Component Matching Rules
- Copyright (C) The Internet Society (2002). All Rights Reserved.
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
Status of this Memo
to the LDAPEXT working group mailing list <ietf-ldapext@netscape.com>
or to the author.
- This Internet-Draft expires on 19 October 2002.
+ This Internet-Draft expires on 2 October 2003.
-1. Abstract
+Abstract
The syntaxes of attributes in a Lightweight Directory Access Protocol
or X.500 directory range from simple data types, such as text string,
-Legg Expires 19 October 2002 [Page 1]
+Legg Expires 2 October 2003 [Page 1]
\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
complex attribute syntax.
-2. Table of Contents
-
- 1. Abstract ...................................................... 1
- 2. Table of Contents ............................................. 2
- 3. Introduction .................................................. 2
- 4. Conventions ................................................... 4
- 5. ComponentAssertion ............................................ 5
- 5.1 Component Reference ....................................... 5
- 5.1.1 Component Type Substitutions ......................... 7
- 5.1.2 Referencing SET, SEQUENCE and CHOICE Components ...... 8
- 5.1.3 Referencing SET OF and SEQUENCE OF Components ........ 9
- 5.1.4 Referencing Components of Parameterized Types ........ 10
- 5.1.5 Component Referencing Example ........................ 10
- 5.1.6 Referencing Components of Open Types ................. 11
- 5.1.6.1 Open Type Referencing Example ................... 12
- 5.1.7 Referencing Contained Types .......................... 13
- 5.1.7.1 Contained Type Referencing Example .............. 14
- 5.2 Matching of Components .................................... 15
- 5.2.1 Applicability of Existing Matching Rules ............. 16
- 5.2.1.1 String Matching ................................. 16
- 5.2.1.2 Telephone Number Matching ....................... 17
- 5.2.1.3 Distinguished Name Matching ..................... 17
- 5.2.2 Additional Useful Matching Rules ..................... 17
- 5.2.2.1 The rdnMatch Matching Rule ...................... 18
- 5.2.2.2 The presentMatch Matching Rule .................. 18
- 5.2.3 Summary of Useful Matching Rules ..................... 19
- 6. ComponentFilter ............................................... 21
- 7. The componentFilterMatch Matching Rule ........................ 22
- 8. Equality Matching of Complex Components ....................... 23
- 8.1 The OpenAssertionType Syntax .............................. 24
- 8.2 The allComponentsMatch Matching Rule ...................... 25
- 8.3 Deriving Component Equality Matching Rules ................ 27
- 8.4 The directoryComponentsMatch Matching Rule ................ 28
- 9. Component Matching Examples ................................... 29
- 10. Security Considerations ...................................... 36
- 11. Acknowledgements ............................................. 36
- 12. Normative References ......................................... 36
- 13. Informative References ....................................... 37
- 14. Intellectual Property Notice ................................. 38
- 15. Copyright Notice ............................................. 38
- 16. Author's Address ............................................. 39
-
-
-3. Introduction
-
-
-
-
-Legg Expires 19 October 2002 [Page 2]
+1. Table of Contents
+
+ 1. Table of Contents ............................................. 2
+ 2. Introduction .................................................. 2
+ 3. Conventions ................................................... 4
+ 4. ComponentAssertion ............................................ 5
+ 4.1 Component Reference ....................................... 5
+ 4.1.1 Component Type Substitutions ......................... 7
+ 4.1.2 Referencing SET, SEQUENCE and CHOICE Components ...... 8
+ 4.1.3 Referencing SET OF and SEQUENCE OF Components ........ 9
+ 4.1.4 Referencing Components of Parameterized Types ........ 10
+ 4.1.5 Component Referencing Example ........................ 10
+ 4.1.6 Referencing Components of Open Types ................. 11
+ 4.1.6.1 Open Type Referencing Example ................... 12
+ 4.1.7 Referencing Contained Types .......................... 13
+ 4.1.7.1 Contained Type Referencing Example .............. 14
+ 4.2 Matching of Components .................................... 15
+ 4.2.1 Applicability of Existing Matching Rules ............. 16
+ 4.2.1.1 String Matching ................................. 16
+ 4.2.1.2 Telephone Number Matching ....................... 17
+ 4.2.1.3 Distinguished Name Matching ..................... 17
+ 4.2.2 Additional Useful Matching Rules ..................... 17
+ 4.2.2.1 The rdnMatch Matching Rule ...................... 17
+ 4.2.2.2 The presentMatch Matching Rule .................. 18
+ 4.2.3 Summary of Useful Matching Rules ..................... 19
+ 5. ComponentFilter ............................................... 21
+ 6. The componentFilterMatch Matching Rule ........................ 22
+ 7. Equality Matching of Complex Components ....................... 23
+ 7.1 The OpenAssertionType Syntax .............................. 24
+ 7.2 The allComponentsMatch Matching Rule ...................... 25
+ 7.3 Deriving Component Equality Matching Rules ................ 27
+ 7.4 The directoryComponentsMatch Matching Rule ................ 28
+ 8. Component Matching Examples ................................... 29
+ 9. Security Considerations ....................................... 36
+ 10. Acknowledgements ............................................. 37
+ 11. Normative References ......................................... 37
+ 12. Informative References ....................................... 38
+ 13. Copyright Notice ............................................. 38
+ 14. Author's Address ............................................. 39
+
+
+2. Introduction
+
+ The structure or data type of data held in an attribute of an LDAP
+ [RFC3377] or X.500 [18] directory is described by the attribute's
+
+
+
+Legg Expires 2 October 2003 [Page 2]
\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
- The structure or data type of data held in an attribute of an LDAP
- [3] or X.500 [18] directory is described by the attribute's syntax.
- Attribute syntaxes range from simple data types, such as text string,
- integer, or boolean, to complex data types, for example, the syntaxes
- of the directory schema operational attributes.
+ syntax. Attribute syntaxes range from simple data types, such as
+ text string, integer, or boolean, to complex data types, for example,
+ the syntaxes of the directory schema operational attributes.
In X.500, the attribute syntaxes are explicitly described by ASN.1
[11] type definitions. ASN.1 type notation has a number of simple
using ASN.1 type notation. All of the type notations defined in [11]
are supported.
- Section 5 describes the ComponentAssertion, a testable assertion
+ Section 4 describes the ComponentAssertion, a testable assertion
about the value of a component of an attribute value of any complex
syntax.
- Section 6 introduces the ComponentFilter assertion, which is an
+ Section 5 introduces the ComponentFilter assertion, which is an
expression of ComponentAssertions. The ComponentFilter enables more
powerful filter matching of components in an attribute value.
- Section 7 defines the componentFilterMatch matching rule, which
+ Section 6 defines the componentFilterMatch matching rule, which
enables a ComponentFilter to be evaluated against attribute values.
- Section 8 defines matching rules for component-wise equality matching
+ Section 7 defines matching rules for component-wise equality matching
of attribute values of any syntax described by an ASN.1 type
definition.
- Examples showing the usage of componentFilterMatch are in Section 9.
+ Examples showing the usage of componentFilterMatch are in Section 8.
+
+ For a new attribute syntax, the Generic String Encoding Rules [7] and
-Legg Expires 19 October 2002 [Page 3]
+Legg Expires 2 October 2003 [Page 3]
\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
- For a new attribute syntax, the Generic String Encoding Rules [7] and
- the specifications in sections 5 to 8 of this document make it
+ the specifications in sections 4 to 7 of this document make it
possible to fully and precisely define, the LDAP-specific encoding,
the LDAP and X.500 binary encoding (and possibly other encodings in
the future, e.g. XML via XER), a suitable equality matching rule, and
semantically equivalent ASN.1 type definition is defined for them.
-4. Conventions
+3. Conventions
Throughout this document "type" shall be taken to mean an ASN.1 type
unless explicitly qualified as an attribute type, and "value" shall
be taken to mean an ASN.1 value unless explicitly qualified as an
attribute value.
- Note that "ASN.1 value" does not mean a BER [19] encoded value. The
+ Note that "ASN.1 value" does not mean a BER [16] encoded value. The
ASN.1 value is an abstract concept that is independent of any
particular encoding. BER is just one possible encoding of an ASN.1
value. The component matching rules operate at the abstract level
Attribute type and matching rule definitions in this document are
provided in both the X.500 [8] and LDAP [4] description formats. Note
that the LDAP descriptions have been rendered with additional
+ white-space and line breaks for the sake of readability.
-Legg Expires 19 October 2002 [Page 4]
+Legg Expires 2 October 2003 [Page 4]
\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
- white-space and line breaks for the sake of readability.
-
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
-5. ComponentAssertion
+4. ComponentAssertion
A ComponentAssertion is an assertion about the presence, or values
of, components within an ASN.1 value, i.e. an instance of an ASN.1
(assumed to be defined with "EXPLICIT TAGS" in force):
ComponentAssertion ::= SEQUENCE {
- component ComponentReference,
+ component ComponentReference (SIZE(1..MAX)) OPTIONAL,
useDefaultValues BOOLEAN DEFAULT TRUE,
rule MATCHING-RULE.&id,
value MATCHING-RULE.&AssertionType }
following sections.
-5.1 Component Reference
+4.1 Component Reference
The component field in a ComponentAssertion is a UTF8 character
string [6] whose textual content is a component reference,
+ identifying a component part of some ASN.1 type or value. A
+ component reference conforms to the following ABNF [2], which extends
-Legg Expires 19 October 2002 [Page 5]
+Legg Expires 2 October 2003 [Page 5]
\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
- identifying a component part of some ASN.1 type or value. A
- component reference conforms to the following ABNF [2], which extends
the notation defined in Clause 14 of [11]:
component-reference = ComponentId *( "." ComponentId )
an ASN.1 open type.
A component reference is always considered in the context of a
+ particular complex ASN.1 type. When applied to the ASN.1 type the
+ component reference identifies a specific component type. When
-Legg Expires 19 October 2002 [Page 6]
+Legg Expires 2 October 2003 [Page 6]
\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
- particular complex ASN.1 type. When applied to the ASN.1 type the
- component reference identifies a specific component type. When
applied to a value of the ASN.1 type a component reference identifies
zero, one or more component values of that component type. The
component values are potentially in a DEFAULT value if
the component reference determines what matching rules are capable of
being used to match the component values.
- An empty string for a component reference, which would identify the
- whole ASN.1 value, is NOT supported since assertions about a whole
- value are already possible by the direct application of a matching
- rule to an attribute value.
+ The component field in a ComponentAssertion may also be absent, in
+ which case the identified component type is the ASN.1 type to which
+ the ComponentAssertion is applied, and the identified component value
+ is the whole ASN.1 value.
A valid component reference for a particular complex ASN.1 type is
constructed by starting with the outermost combining type and
reference be a simple ASN.1 type.
-5.1.1 Component Type Substitutions
+4.1.1 Component Type Substitutions
ASN.1 type notation has a number of constructs for referencing other
defined types, and constructs that are irrelevant for matching
performed to eliminate them from further consideration. These
substitutions automatically occur prior to each ComponentId, whether
constructing or interpreting a component reference, but do not occur
- after the last ComponentId, except as allowed by Section 5.2.
+ after the last ComponentId, except as allowed by Section 4.2.
If the ASN.1 type is an ASN.1 type reference then the component type
is taken to be the actual definition on the right hand side of the
If the ASN.1 type is an ObjectClassFieldType (Clause 14 of [13]) that
denotes a specific ASN.1 type (e.g. MATCHING-RULE.&id denotes the
OBJECT IDENTIFIER type) then the component type is taken to be the
+ denoted type. Section 4.1.6 describes the case where the
+ ObjectClassFieldType denotes an open type.
-Legg Expires 19 October 2002 [Page 7]
+Legg Expires 2 October 2003 [Page 7]
\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
-
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
- denoted type. Section 5.1.6 describes the case where the
- ObjectClassFieldType denotes an open type.
If the ASN.1 type is a selection type other than one used in the list
of components for a SET or SEQUENCE type then the component type is
values.
-5.1.2 Referencing SET, SEQUENCE and CHOICE Components
+4.1.2 Referencing SET, SEQUENCE and CHOICE Components
If the ASN.1 type is a SET or SEQUENCE type then the <identifier>
form of ComponentId MAY be used to identify the component type within
directly by identifier as though it was defined in-line in the SET or
SEQUENCE type.
+ The REAL type is treated as though it is the SEQUENCE type defined in
+ Clause 20.5 of [11].
-Legg Expires 19 October 2002 [Page 8]
-\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+Legg Expires 2 October 2003 [Page 8]
+\f
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
- The REAL type is treated as though it is the SEQUENCE type defined in
- Clause 20.5 of [11].
The EMBEDDED PDV type is treated as though it is the SEQUENCE type
defined in Clause 32.5 of [11].
The EXTERNAL type is treated as though it is the SEQUENCE type
- defined in Clause 33.5 of [11].
+ defined in Clause 8.18.1 of [16].
The unrestricted CHARACTER STRING type is treated as though it is the
SEQUENCE type defined in Clause 39.5 of [11].
The <identifier> form MUST NOT be used on any other ASN.1 type.
-5.1.3 Referencing SET OF and SEQUENCE OF Components
+4.1.3 Referencing SET OF and SEQUENCE OF Components
If the ASN.1 type is a SET OF or SEQUENCE OF type then the
<from-beginning>, <from-end>, <count> and <all> forms of ComponentId
- can be used.
+ MAY be used.
The <from-beginning> form of ComponentId MAY be used to identify one
instance (i.e. value) of the component type of the SET OF or SEQUENCE
number of instances of the component type in a value of the SET OF or
SEQUENCE OF type. This count is not explicitly represented but for
matching purposes it has an assumed ASN.1 type of INTEGER (0..MAX).
- A ComponentId of the <count> form MUST be the last ComponentId in a
- component reference.
+ A ComponentId of the <count> form, if used, MUST be the last
+ ComponentId in a component reference.
The <all> form of ComponentId MAY be used to simultaneously identify
all instances of the component type of the SET OF or SEQUENCE OF
+ type. It is through the <all> form that a component reference can
+ identify more than one component value. However, if a particular
+ value of the SET OF or SEQUENCE OF type is an empty list there are no
-Legg Expires 19 October 2002 [Page 9]
+Legg Expires 2 October 2003 [Page 9]
\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
- type. It is through the <all> form that a component reference can
- identify more than one component value. However, if a particular
- value of the SET OF or SEQUENCE OF type is an empty list there are no
corresponding component values.
Where multiple component values are identified, the remaining
used on ASN.1 types other than SET OF or SEQUENCE OF.
-5.1.4 Referencing Components of Parameterized Types
+4.1.4 Referencing Components of Parameterized Types
A component reference cannot be formed for a parameterized type
unless the type has been used with actual parameters, in which case
substituted with the actual parameters.
-5.1.5 Component Referencing Example
+4.1.5 Component Referencing Example
Consider the following ASN.1 type definitions.
type ExampleType.
The component reference "part1" identifies a component of a value of
+ ExampleType having the ASN.1 tagged type [0] INTEGER.
+ The component reference "part2" identifies a component of a value of
-Legg Expires 19 October 2002 [Page 10]
-\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+Legg Expires 2 October 2003 [Page 10]
+\f
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
- ExampleType having the ASN.1 tagged type [0] INTEGER.
- The component reference "part2" identifies a component of a value of
ExampleType having the ASN.1 type of [1] ExampleSet
The component reference "part2.option" identifies a component of a
value of ExampleType having the ASN.1 type of OCTET STRING.
-5.1.6 Referencing Components of Open Types
+4.1.6 Referencing Components of Open Types
If a sequence of ComponentIds identifies an ObjectClassFieldType
denoting an open type (e.g. ATTRIBUTE.&Type denotes an open type)
The other components constraining the open type are termed the
referenced components (using the terminology in [14]). The <select>
+ form contains a list of one or more values which take the place of
+ the value(s) of the referenced component(s) to uniquely identify one
+ of the permissable types of the open type.
-Legg Expires 19 October 2002 [Page 11]
+Legg Expires 2 October 2003 [Page 11]
\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
- form contains a list of one or more values which take the place of
- the value(s) of the referenced component(s) to uniquely identify one
- of the permissable types of the open type.
-
Where the open type is constrained by a component relation
constraint, there is a <Value> in the <select> form for each of the
referenced components in the component relation constraint, appearing
the open type.
-5.1.6.1 Open Type Referencing Example
+4.1.6.1 Open Type Referencing Example
The ASN.1 type AttributeTypeAndValue from [8] describes a single
attribute value of a nominated attribute type.
to identify attribute values of specific attribute types it will
contain a single OBJECT IDENTIFIER value.
+ The component reference "value" on AttributeTypeAndValue refers to
+ the open type.
-Legg Expires 19 October 2002 [Page 12]
-\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
- The component reference "value" on AttributeTypeAndValue refers to
- the open type.
+Legg Expires 2 October 2003 [Page 12]
+\f
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
+
One of the X.500 standard attributes is facsimileTelephoneNumber
[10], which is identified with the OBJECT IDENTIFIER 2.5.4.23, and is
"value.(2.5.4.23).telephoneNumber".
-5.1.7 Referencing Contained Types
+4.1.7 Referencing Contained Types
Sometimes the contents of a BIT STRING or OCTET STRING value are
required to be the encodings of other ASN.1 values of specific ASN.1
some other component in an outer enclosing type (e.g. in a
certificate Extension, extnValue is constrained by the chosen
extnId). In these cases the next ComponentId, if any, MUST be of the
+ <select> form.
+ For the purpose of building component references, the content of the
-Legg Expires 19 October 2002 [Page 13]
-\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+Legg Expires 2 October 2003 [Page 13]
+\f
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
- <select> form.
- For the purpose of building component references, the content of the
extnValue OCTET STRING in the Extension type is assumed to be an open
type having a notional component relation constraint with the extnId
component as the single referenced component, i.e.
EXTENSION.&ExtnType ({ExtensionSet}{@extnId})
- The data-value component of the associated types for the EXTERNAL,
- EMBEDDED PDV and CHARACTER STRING types is an OCTET STRING containing
- the encoding of a data value described by the identification
- component. For the purpose of building component references, the
- content of the data-value OCTET STRING in these types is assumed to
- be an open type having a notional component relation constraint with
- the identification component as the single referenced component.
+ The data-value component of the associated types for the EMBEDDED PDV
+ and CHARACTER STRING types is an OCTET STRING containing the encoding
+ of a data value described by the identification component. For the
+ purpose of building component references, the content of the
+ data-value OCTET STRING in these types is assumed to be an open type
+ having a notional component relation constraint with the
+ identification component as the single referenced component.
-5.1.7.1 Contained Type Referencing Example
+4.1.7.1 Contained Type Referencing Example
The Extension ASN.1 type from [9] describes a single certificate
extension value of a nominated extension type.
cA BOOLEAN DEFAULT FALSE,
pathLenConstraint INTEGER (0..MAX) OPTIONAL }
+ The component reference "extnValue.content.(2.5.29.19)" on Extension
+ specifies a BasicConstraintsSyntax extension value and the component
+ reference "extnValue.content.(2.5.29.19).cA" identifies the cA
-Legg Expires 19 October 2002 [Page 14]
+Legg Expires 2 October 2003 [Page 14]
\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
- The component reference "extnValue.content.(2.5.29.19)" on Extension
- specifies a BasicConstraintsSyntax extension value and the component
- reference "extnValue.content.(2.5.29.19).cA" identifies the cA
component of a BasicConstraintsSyntax extension value.
-5.2 Matching of Components
+4.2 Matching of Components
The rule in a ComponentAssertion specifies how the zero, one or more
component values identified by the component reference are tested by
(typically one), defined as ASN.1 types, to which it may be applied.
When used in a ComponentAssertion these matching rules apply to the
same ASN.1 types, only in this context the corresponding ASN.1 values
- are not complete attribute values.
+ are not necessarily complete attribute values.
Note that the referenced component type may be a tagged and/or
constrained version of the expected attribute syntax (e.g. [0]
INTEGER, whereas integerMatch would expect simply INTEGER), or an
open type. Additional type substitutions of the kind described in
- Section 5.1.1 are performed as required to reduce the component type
+ Section 4.1.1 are performed as required to reduce the component type
to the same type as the attribute syntax expected by the matching
- rule. If an open type is encountered the actual ASN.1 type of the
- component value is substituted before continuing.
+ rule.
If a matching rule applies to more than one attribute syntax (e.g.
objectIdentifierFirstComponentMatch [10]) then the minimum number of
- substitutions required to conform to any one of those syntaxes are
+ substitutions required to conform to any one of those syntaxes is
performed. If a matching rule can apply to any attribute syntax
- (e.g. the allComponentsMatch rule defined in Section 8.2) then the
+ (e.g. the allComponentsMatch rule defined in Section 7.2) then the
referenced component type is used as is, with no additional
substitutions.
referenced component is used in place of an attribute syntax to
decide the required assertion syntax.
+ The ComponentAssertion is undefined if:
+ a) the matching rule in the ComponentAssertion is not known to the
+ evaluating procedure,
-Legg Expires 19 October 2002 [Page 15]
-\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
-
- The ComponentAssertion is undefined if:
+Legg Expires 2 October 2003 [Page 15]
+\f
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
- a) the matching rule in the ComponentAssertion is not known to the
- evaluating procedure,
- b) if no part of the component reference identifies an open type and
- the matching rule is not applicable to the referenced component
+ b) if the matching rule is not applicable to the referenced component
type, even with the additional type substitutions,
c) the value in the ComponentAssertion does not conform to the
assertion syntax defined for the matching rule,
- d) an open type in the tested value cannot be decoded, or
+ d) some part of the component reference identifies an open type in
+ the tested value that cannot be decoded, or
e) the implementation does not support the particular combination of
component reference and matching rule.
value returns TRUE, and evaluates to FALSE otherwise (which includes
the case where there are no component values).
- If some part of the component reference identifies an open type and
- the matching rule is not applicable to the referenced component type
- the ComponentAssertion evaluates to FALSE.
-
-5.2.1 Applicability of Existing Matching Rules
+4.2.1 Applicability of Existing Matching Rules
-5.2.1.1 String Matching
+4.2.1.1 String Matching
ASN.1 has a number of built in restricted character string types with
different character sets and/or different character encodings. A
The relevant string matching rules are: caseIgnoreMatch,
caseIgnoreOrderingMatch, caseIgnoreSubstringsMatch, caseExactMatch,
-
-
-
-Legg Expires 19 October 2002 [Page 16]
-\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
-
-
caseExactOrderingMatch and caseExactSubstringsMatch. The relevant
restricted character string types are: NumericString,
PrintableString, VisibleString, IA5String, UTF8String, BMPString,
use of the DirectoryString{} parameterized type to be a
ChoiceOfStrings type.
+
+
+
+Legg Expires 2 October 2003 [Page 16]
+\f
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
+
+
The assertion syntax of the string matching rules is still
DirectoryString regardless of the string syntax of the component
being matched. Thus an implementation will be called upon to compare
Otherwise matching returns FALSE.
-5.2.1.2 Telephone Number Matching
+4.2.1.2 Telephone Number Matching
Early editions of X.520 [10] gave the syntax of the telephoneNumber
attribute as a constrained PrintableString. The fourth edition of
TelephoneNumber values.
-5.2.1.3 Distinguished Name Matching
+4.2.1.3 Distinguished Name Matching
The DistinguishedName type is defined by assignment to be the same as
the RDNSequence type, however RDNSequence is sometimes directly used
the RDNSequence type.
-5.2.2 Additional Useful Matching Rules
+4.2.2 Additional Useful Matching Rules
This section defines additional matching rules that may prove useful
in ComponentAssertions. These rules MAY also be used in
extensibleMatch search filters [3].
-
-
-
-Legg Expires 19 October 2002 [Page 17]
-\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
-
-
-5.2.2.1 The rdnMatch Matching Rule
+4.2.2.1 The rdnMatch Matching Rule
The distinguishedNameMatch matching rule can match whole
distinguished names but it is sometimes useful to be able to match
The LDAP-style definitions for rdnMatch and its assertion syntax are:
+
+
+Legg Expires 2 October 2003 [Page 17]
+\f
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
+
+
( 1.2.36.79672281.1.13.3 NAME 'rdnMatch'
SYNTAX 1.2.36.79672281.1.5.0 )
component reference "3", or alternatively, "-1".
-5.2.2.2 The presentMatch Matching Rule
+4.2.2.2 The presentMatch Matching Rule
At times it would be useful to test not if a specific value of a
particular component is present, but whether any value of a
( 1.2.36.79672281.1.13.5 NAME 'presentMatch'
SYNTAX 1.2.36.79672281.1.5.1 )
-
-
-
-Legg Expires 19 October 2002 [Page 18]
-\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
-
-
( 1.2.36.79672281.1.5.1 DESC 'NULL' )
The LDAP-specific encoding for a value of the NULL syntax is given by
SYNTAX NULL
ID { 1 2 36 79672281 1 13 5 } }
+
+
+Legg Expires 2 October 2003 [Page 18]
+\f
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
+
+
When used in a extensible match filter item, presentMatch behaves
like the "present" case of a regular search filter. In a
ComponentAssertion, presentMatch evaluates to TRUE if and only if the
as present and equal to zero.
-5.2.3 Summary of Useful Matching Rules
+4.2.3 Summary of Useful Matching Rules
The following is a non-exhaustive list of useful matching rules and
the ASN.1 types to which they can be applied, taking account of all
- the extensions described in Section 5.2.1, and the new matching rules
- defined in Section 5.2.2.
+ the extensions described in Section 4.2.1, and the new matching rules
+ defined in Section 4.2.2.
+
+
+
+
+
-Legg Expires 19 October 2002 [Page 19]
+
+
+
+
+
+
+Legg Expires 2 October 2003 [Page 19]
\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
+================================+==============================+
-Legg Expires 19 October 2002 [Page 20]
+Legg Expires 2 October 2003 [Page 20]
\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
+--------------------------------+------------------------------+
| uTCTimeOrderingMatch | |
+--------------------------------+------------------------------+
- Note that the allComponentsMatch matching rule defined in Section 8.2
+ Note that the allComponentsMatch matching rule defined in Section 7.2
can be used for equality matching of values of the ENUMERATED, NULL,
REAL and RELATIVE-OID ASN.1 types, among other things.
-6. ComponentFilter
+5. ComponentFilter
The ComponentAssertion allows the value(s) of any one component type
in a complex ASN.1 type to be matched, but there is often a desire to
-Legg Expires 19 October 2002 [Page 21]
+Legg Expires 2 October 2003 [Page 21]
\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
The "not" of a component filter evaluates to TRUE if the component
and evaluates to undefined otherwise.
-7. The componentFilterMatch Matching Rule
+6. The componentFilterMatch Matching Rule
The componentFilterMatch matching rule allows a ComponentFilter to be
applied to an attribute value. The result of the matching rule is
SequenceOfComponentFilter = "{" [ sp ComponentFilter
*( "," sp ComponentFilter) ] sp "}"
- ComponentAssertion = "{" sp component ","
+ ComponentAssertion = "{" [ sp component "," ]
-Legg Expires 19 October 2002 [Page 22]
+Legg Expires 2 October 2003 [Page 22]
\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
- [ sp useDefaultValues "," ]
- sp rule ","
- sp assertion-value sp "}"
- component = component-label msp
- dquote component-reference dquote
+ [ sp useDefaultValues "," ]
+ sp rule ","
+ sp assertion-value sp "}"
+ component = component-label msp StringValue
useDefaultValues = use-defaults-label msp BooleanValue
rule = rule-label msp ObjectIdentifierValue
assertion-value = value-label msp Value
sp = *%x20 ; zero, one or more space characters
msp = 1*%x20 ; one or more space characters
- dquote = %x22 ; " (double quote)
- The ABNF for <Value>, <ObjectIdentifierValue> and <BooleanValue> is
- defined in [7].
+ The ABNF for <Value>, <StringValue>, <ObjectIdentifierValue> and
+ <BooleanValue> is defined in [7].
The ABNF descriptions of LDAP-specific encodings for attribute
syntaxes typically do not clearly or consistently delineate the
componentFilterMatch, so componentFilterMatch MAY be nested. The
component references in a nested componentFilterMatch are relative to
the component corresponding to the containing ComponentAssertion. In
- Section 9, an example search on the seeAlso attribute shows this
+ Section 8, an example search on the seeAlso attribute shows this
usage.
-8. Equality Matching of Complex Components
+7. Equality Matching of Complex Components
It is possible to test if an attribute value of a complex ASN.1
syntax is the same as some purported (i.e. assertion) value by using
+ a complicated ComponentFilter that tests if corresponding components
+ are the same. However, it would be more convenient to be able to
-Legg Expires 19 October 2002 [Page 23]
+Legg Expires 2 October 2003 [Page 23]
\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
- a complicated ComponentFilter that tests if corresponding components
- are the same. However, it would be more convenient to be able to
present a whole assertion value to a matching rule that could do the
component-wise comparison of an attribute value with the assertion
value for any arbitrary attribute syntax. Similarly, the ability to
semantics should be. For example, in some instances a case sensitive
comparison of string components may be preferable to a case
insensitive comparison. Therefore a basic equality matching rule,
- allComponentsMatch, is defined in Section 8.2, and the means to
+ allComponentsMatch, is defined in Section 7.2, and the means to
derive new matching rules from it with slightly different equality
- matching semantics are described in Section 8.3.
+ matching semantics are described in Section 7.3.
- The directoryComponentsMatch defined in Section 8.4 is a derivation
+ The directoryComponentsMatch defined in Section 7.4 is a derivation
of allComponentsMatch that suits typical uses of the directory.
Other specifications are free to derive new rules from
allComponentsMatch or directoryComponentsMatch, that suit their usage
component equality matching rules.
-8.1 The OpenAssertionType Syntax
+7.1 The OpenAssertionType Syntax
The component equality matching rules have a variable assertion
syntax. In X.500 this is indicated by omitting the optional SYNTAX
encoding defined for the syntax of the attribute type to which the
matching rule with the OpenAssertionType assertion syntax is applied.
+ The LDAP definition for the OpenAssertionType syntax is:
-Legg Expires 19 October 2002 [Page 24]
-\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+Legg Expires 2 October 2003 [Page 24]
+\f
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
- The LDAP definition for the OpenAssertionType syntax is:
( 1.2.36.79672281.1.5.3 DESC 'OpenAssertionType' )
-8.2 The allComponentsMatch Matching Rule
+7.2 The allComponentsMatch Matching Rule
The LDAP-style definition for allComponentsMatch is:
Values of an EMBEDDED PDV, EXTERNAL, unrestricted CHARACTER
STRING, or INSTANCE OF type are compared according to their
- respective SEQUENCE type (see Section 5.1.2).
+ respective associated SEQUENCE type (see Section 4.1.2).
b) Two values of a SEQUENCE OF type are the same if and only if, the
values have the same number of (possibly duplicated) instances and
corresponding instances are the same.
+ c) Two values of a SET OF type are the same if and only if, the
-Legg Expires 19 October 2002 [Page 25]
+
+Legg Expires 2 October 2003 [Page 25]
\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
- c) Two values of a SET OF type are the same if and only if, the
values have the same number of instances and each distinct
instance occurs in both values the same number of times, i.e. both
values have the same instances, including duplicates, but in any
m) Two REAL values are the same if and only if they are both the same
special value, or neither is a special value and they have the
same base and represent the same real number. The special values
+ for REAL are zero, PLUS-INFINITY and MINUS-INFINITY.
-Legg Expires 19 October 2002 [Page 26]
+Legg Expires 2 October 2003 [Page 26]
\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
- for REAL are zero, PLUS-INFINITY and MINUS-INFINITY.
-
n) Two RELATIVE-OID [12] values are the same if and only if the
values have the same number of arcs and corresponding arcs are the
same. The respective starting nodes for the RELATIVE-OID values
same.
o) Two values of an open type are the same if and only if both are of
- the same ASN.1 type and are the same according to that type.
+ the same ASN.1 type and are the same according to that type. If
+ the actual ASN.1 type of the values is unknown then the
+ allComponentsMatch rule evaluates to undefined.
Tags and constraints, being part of the type definition and not part
of the abstract values, are ignored for matching purposes.
matching rule for an attribute.
-8.3 Deriving Component Equality Matching Rules
+7.3 Deriving Component Equality Matching Rules
A new component equality matching rule with more refined matching
- semantics MAY be derived from allComponentsMatch, or any other
+ semantics may be derived from allComponentsMatch, or any other
component equality matching rule, using the convention described in
this section.
-Legg Expires 19 October 2002 [Page 27]
+Legg Expires 2 October 2003 [Page 27]
\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
type. Other component values that happen to be of the same ASN.1
type are not selected.
- Additional type substitutions as described in Section 5.2 are assumed
+ Additional type substitutions as described in Section 4.2 are assumed
to be performed to align the component type with the matching rule
assertion syntax.
component in the table for the base rule.
-8.4 The directoryComponentsMatch Matching Rule
+7.4 The directoryComponentsMatch Matching Rule
The directoryComponentsMatch matching rule is derived from the
allComponentsMatch matching rule.
ID { 1 2 36 79672281 1 13 7 } }
The matching semantics of directoryComponentsMatch are described by
- the following table, using the convention described in Section 8.3.
+ the following table, using the convention described in Section 7.3.
-Legg Expires 19 October 2002 [Page 28]
+Legg Expires 2 October 2003 [Page 28]
\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
ASN.1 Type | Matching Rule
matching rule for an attribute.
-9. Component Matching Examples
+8. Component Matching Examples
-Legg Expires 19 October 2002 [Page 29]
+Legg Expires 2 October 2003 [Page 29]
\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
This section contains examples of search filters using the
-Legg Expires 19 October 2002 [Page 30]
+Legg Expires 2 October 2003 [Page 30]
\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
item:{ component "identifier",
-Legg Expires 19 October 2002 [Page 31]
+Legg Expires 2 October 2003 [Page 31]
\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
word "bogus" in the description:
-Legg Expires 19 October 2002 [Page 32]
+Legg Expires 2 October 2003 [Page 32]
\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
match values of an ENUMERATED type. The following search filter
-Legg Expires 19 October 2002 [Page 33]
+Legg Expires 2 October 2003 [Page 33]
\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
(objectClasses:componentFilterMatch:=or:{
-Legg Expires 19 October 2002 [Page 34]
+Legg Expires 2 October 2003 [Page 34]
\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
RDN, "o=Adacel", anywhere in the DN:
-Legg Expires 19 October 2002 [Page 35]
+Legg Expires 2 October 2003 [Page 35]
\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
item:{ component "*.*.value.(2.5.4.11)",
ComponentAssertion evaluates to FALSE. Otherwise the substring
assertion is evaluated against the attribute value.
+ Absent component references in ComponentAssertions can be exploited
+ to avoid false positive matches on multi-valued attributes. For
+ example, suppose there is a multi-valued attribute named
+ productCodes, defined to have the Integer syntax
+ (1.3.6.1.4.1.1466.115.121.1.27). Consider the following search
+ filter:
+
+ (&(!(productCodes:integerOrderingMatch:=3))
+ (productCodes:integerOrderingMatch:=8))
+
+ An entry whose productCodes attribute contains only the values 1 and
+ 10 will match the above filter. The first subfilter is satisfied by
+ the value 10 (10 is not less than 3), and the second subfilter is
+ satisfied by the value 1 (1 is less than 8). The following search
+ filter can be used instead to only match entries that have a
+ productCodes value in the range 3 to 7, because the ComponentFilter
+ is evaluated against each productCodes value in isolation:
-10. Security Considerations
+ (productCodes:componentFilterMatch:= and:{
+ not:item:{ rule integerOrderingMatch, value 3 },
+ item:{ rule integerOrderingMatch, value 8 } })
+
+ An entry whose productCodes attribute contains only the values 1 and
+ 10 will not match the above filter.
+
+
+9. Security Considerations
The component matching rules described in this document allow for a
compact specification of matching capabilities that could otherwise
component matching rules are applicable to any attribute syntax,
support for them in a directory server may allow searching of
attributes that were previously unsearchable by virtue of there not
+
+
+
+Legg Expires 2 October 2003 [Page 36]
+\f
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
+
+
being a suitable matching rule. Such attribute types ought to be
properly protected with appropriate access controls.
-11. Acknowledgements
+10. Acknowledgements
The author would like to thank Tom Gindin for private email
discussions that clarified and refined the ideas presented in this
document.
-12. Normative References
+11. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
Directory Access Protocol (v3): Attribute Syntax Definitions",
RFC 2252, December 1997.
-
-
-Legg Expires 19 October 2002 [Page 36]
-\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
-
-
[5] Wahl, M., Kille S. and T. Howes. "Lightweight Directory Access
Protocol (v3): UTF-8 String Representation of Distinguished
Names", RFC 2253, December 1997.
[6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998.
+ [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377, September
+ 2002.
+
[7] Legg, S., "Generic String Encoding Rules for ASN.1 Types",
- draft-legg-ldap-gser-xx.txt, a work in progress, March 2002.
+ draft-legg-ldap-gser-xx.txt, a work in progress, October 2002.
[8] ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994,
Information Technology - Open Systems Interconnection - The
Information Technology - Open Systems Interconnection - The
Directory: Authentication Framework
+
+
+
+Legg Expires 2 October 2003 [Page 37]
+\f
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
+
+
[10] ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994,
Information Technology - Open Systems Interconnection - The
Directory: Selected attribute types
Information Technology - Abstract Syntax Notation One (ASN.1):
Parameterization of ASN.1 specifications
+ [16] ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998
+ Information Technology - ASN.1 encoding rules: Specification of
+ Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and
+ Distinguished Encoding Rules (DER)
-13. Informative References
- [16] Hovey, R. and S. Bradner, "The Organizations Involved in the
- IETF Standards Process", BCP 11, RFC 2028, October 1996.
+12. Informative References
[17] Howes, T., "The String Representation of LDAP Search Filters",
-
-
-
-Legg Expires 19 October 2002 [Page 37]
-\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
-
-
RFC 2254, December 1997.
[18] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
Information Technology - Open Systems Interconnection - The
Directory: Overview of concepts, models and services
- [19] ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998
- Information Technology - ASN.1 encoding rules: Specification of
- Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and
- Distinguished Encoding Rules (DER)
-
-
-14. Intellectual Property Notice
-
- The IETF takes no position regarding the validity or scope of any
- intellectual property 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; neither does it represent that it
- has made any effort to identify any such rights. Information on the
- IETF's procedures with respect to rights in standards-track and
- standards-related documentation can be found in BCP-11. [16] Copies
- of claims of rights made available for publication 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 implementors or users of this specification can
- be obtained from the IETF Secretariat.
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights which may cover technology that may be required to practice
- this standard. Please address the information to the IETF Executive
- Director.
+13. Copyright Notice
-
-15. Copyright Notice
-
- Copyright (C) The Internet Society (2002). All Rights Reserved.
+ Copyright (C) The Internet Society (2003). 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
-Legg Expires 19 October 2002 [Page 38]
+Legg Expires 2 October 2003 [Page 38]
\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
+ 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
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-16. Author's Address
+14. Author's Address
Steven Legg
Adacel Technologies Ltd.
- 405-409 Ferntree Gully Road
- Mount Waverley, Victoria 3149
+ 250 Bay Street
+ Brighton, Victoria 3186
AUSTRALIA
- Phone: +61 3 9451 2107
- Fax: +61 3 9541 2121
+ Phone: +61 3 8530 7710
+ Fax: +61 3 8530 7888
EMail: steven.legg@adacel.com.au
-17. Appendix A - Changes From Previous Drafts
+Appendix A - Changes From Previous Drafts
-17.1 Changes in Draft 01
+A.1 Changes in Draft 01
- Section 4.1.7 (now 5.1.7) was added to enable component matching of
- values embedded in encoded form into BIT STRINGs or OCTET STRINGs.
- In particular, this is to allow component matching of values in
+ Section 4.1.7 was added to enable component matching of values
+ embedded in encoded form into BIT STRINGs or OCTET STRINGs. In
+ particular, this is to allow component matching of values in
Certificate extensions. The <content> rule was added in Section 4.1
- (now 5.1) to allow the OCTET STRING contents to be treated as either
- raw octets or as an embedded value.
+ to allow the OCTET STRING contents to be treated as either raw octets
+ or as an embedded value.
References to a companion document summarizing the ASN.1 types of
LDAP syntaxes were removed to avoid holding up this document.
The OpenType syntax was renamed to OpenAssertionType.
- Object identifiers for the new syntax and matching rule definitions
- have been allocated from an arc belonging to Adacel Technologies Ltd.
-
-
-Legg Expires 19 October 2002 [Page 39]
+Legg Expires 2 October 2003 [Page 39]
\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
-17.2 Changes in Draft 02
+ Object identifiers for the new syntax and matching rule definitions
+ have been allocated from an arc belonging to Adacel Technologies Ltd.
+
+A.2 Changes in Draft 02
The context specific tagging in the ComponentAssertion ASN.1 type was
unnecessary and has been removed.
ComponentAssertions has been clarified, and the description of
OpenAssertionType has been promoted to its own section.
-17.3 Changes in Draft 03
+A.3 Changes in Draft 03
The default matching by allComponentsMatch of component values of BIT
STRING types with named bit lists has been changed to ignore trailing
Typographical errors in the <SafeUTF8Character> rule have been fixed.
-17.4 Changes in Draft 04
+A.4 Changes in Draft 04
When the matching rule in a ComponentAssertion has a variable
assertion syntax it is not possible to determine the syntax of the
The ASN.1 type of the notional iteration count associated with SET OF
and SEQUENCE OF values has been refined to INTEGER (0..MAX).
- The encoding rules in Section 8 (now draft-legg-ldap-gser-xx.txt)
- have been formally named the Generic String Encoding Rules (GSER) and
-
-Legg Expires 19 October 2002 [Page 40]
+Legg Expires 2 October 2003 [Page 40]
\f
-INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
+ The encoding rules in Section 8 (now draft-legg-ldap-gser-xx.txt)
+ have been formally named the Generic String Encoding Rules (GSER) and
a transfer syntax object identifier has been assigned.
The term "LDAP string encoding" has been replaced by the term "native
LDAP-specific encoding" to align with terminology anticipated to be
used in the revision of RFC 2252.
-17.5 Changes in Draft 05
+A.5 Changes in Draft 05
Reformatted the draft to conform to recent and proposed RFC editorial
policy.
Removed extraneous spaces from example DNs.
-17.6 Changes in Draft 06
+A.6 Changes in Draft 06
An ABNF syntax error in the <exponent> rule was fixed.
-17.7 Changes in Draft 07
+A.7 Changes in Draft 07
The term "native LDAP encoding" has been replaced by the term "LDAP-
specific encoding" to align with terminology anticipated to be used
editorial changes have been made to this draft to accommodate this
split.
-17.8 Changes in Draft 08
+A.8 Changes in Draft 08
The enumeratedMatch matching rule duplicates a subset of the
functionality of allComponentsMatch so it has been removed. The
enumeratedMatch rule has been replaced by allComponentsMatch in the
examples. The description of the OpenAssertionType syntax has been
- moved into Section 8.
+ moved into Section 7.
+
+
+
+Legg Expires 2 October 2003 [Page 41]
+\f
+INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 2, 2003
+
+
+A.9 Changes in Draft 09
+
+ The associated type for the EXTERNAL type has been changed from the
+ one defined in X.680 for ASN.1 value notation to the one defined in
+ X.690 for BER.
+
+A.10 Changes in Draft 10
+
+ The definition of ComponentAssertion has been changed to make the
+ "component" field optional, and non-empty when present. This change
+ allows the specification of search filters where all the assertions
+ must match the same value of an attribute. Normally each assertion is
+ free to match any of the values of a multi-valued attribute.
+ Corresponding changes have been made to the ABNF in Section 6. An
+ illustrative example has been added to Section 8.
+
+ Conditions on whether a ComponentAssertion returns FALSE or undefined
+ when some part of the component references identifies an open type
+ have been removed from Section 4.2. The changes in draft 04 that
+ introduced the <select> form of ComponentId made these conditions
+ unnecessary and inappropriate.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-Legg Expires 19 October 2002 [Page 41]
+Legg Expires 2 October 2003 [Page 42]
\f
-Individual Submission to ldapext Working Group Roger G. Harrison
-Internet Draft Novell, Inc.
-Intended Category: Standards Track
- Kurt D. Zeilenga
- OpenLDAP Foundation
-
- March 30, 2001
-
-
-
- LDAP Intermediate Response
- <draft-rharrison-ldap-intermediate-resp-00.txt>
-
-
-Status of this 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 Extensions Working
- Group (ldapext) mailing list <ietf-ldapext@netscape.com>. Please
- send editorial comments directly to the document editor
- <roger_harrison@novell.com>.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
+INTERNET-DRAFT R. Harrison
+draft-rharrison-ldap-intermediate-resp-01.txt Novell, Inc.
+Updates: 2251 K. Zeilenga
+Intended Category: Standards Track OpenLDAP Foundation
+ March 28, 2003
+
+
+ The Lightweight Directory Access Protocol (LDAP)
+ Intermediate Response Message
+
+
+Status of this 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 Extensions Working
+ Group (ldapext) mailing list <ietf-ldapext@netscape.com>. Please
+ send editorial comments directly to the document editor
+ <roger_harrison@novell.com>
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
- Drafts. Internet-Drafts are draft documents valid for a maximum of
- six months and may be updated, replaced, or obsoleted by other
- documents at any time. It is inappropriate to use Internet-Drafts as
- reference material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
-1. Abstract
-
- This document extends LDAPv3 to provide a general mechanism for
- defining single-request/multiple-response operations by defining and
- describing the IntermediateResponse message.
-
-
-2. Background and Intended Usage
-
- The Lightweight Directory Access Protocol, version 3 [LDAPv3] is an
- extensible protocol. Extended operations ([LDAPv3] Section 4.12) are
- defined to allow operations to be added to LDAP without requiring a
- new revision of the protocol. Similarly, controls ([LDAPv3] section
-
-Harrison & Zeilenga Expires September 30, 2001 [Page 1]
+ 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 Notice
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+Abstract
+
+ The Lightweight Directory Access Protocol (LDAP) version 3 is a
+ client-request/server-response based protocol. With the exception
+ of the search operation, the entire response to an operation request
+ is returned in a single LDAP message. While this single-
+ request/single-response paradigm is sufficient for many operations
+ (including all but one of those currently defined by LDAP), both
+ intuition and practical experience validate the notion that it is
+ insufficient for some operations. When multiple messages are sent
+
+
+Harrison & Zeilenga Expires September 28, 2003 [Page 1]
\f
- LDAPv3 Intermediate Response March 30, 2001
-
-
- 4.1.12) are defined to extend or modify the behavior of existing
- LDAP operations.
-
- LDAPv3 is a client-request/server-response based protocol. With the
- exception of the search operation, the entire response to an
- operation request is returned in a single protocol data unit (LDAP
- message). While this single-request/single-response paradigm is
- sufficient for many operations (including almost all but one of
- those currently defined by [LDAPv3]), both intuition and practical
- experience validate the notion that it is insufficient for some
- operations.
-
- For example, the LDAPv3 delete operation could be extended via a
- subtree control to mean that an entire subtree is to be deleted. A
- subtree delete operation needs to return continuation references
- based upon subordinate knowledge information contained in the server
- so that the client can complete the operation. Returning references
- as they are found instead of with the final result allows the client
- to progress the operation more efficiently because it does not have
- to wait for the final result to get this continuation reference
- information.
-
- Similarly, an engineer might choose to design the subtree delete
- operation as an extended operation of its own rather than using a
- subtree control in conjunction with the delete operation. Once
- again, the same continuation reference information is needed by the
- client to complete the operation, and sending the continuation
- references as they are found would allow the client progress the
- operation more efficiently.
-
- Operations that complete in stages or that progress through various
- states as they complete might want to send intermediate responses to
- the client apprising it of the status of the operation. For example,
- an LDAP implementation might define an extended operation to create
- a new replica of an administrative area on a server, and the
- operation completes in three stages: (1) begin creation of replica,
- (2) send replica data to server, (3) replica creation complete.
- Intermediate messages might be sent from the server to the client at
- the beginning of stages (1) and (2) with the final response for the
- extended operation being sent for stage (3).
-
- As LDAPv3 is currently defined, there is no general LDAP message
- type that can be used to return intermediate results. A single,
- reusable LDAP message for carrying intermediate response information
- is desired to avoid repeated modification of the protocol. Although
- the ExtendedResponse message is defined in LDAPv3, it is defined to
- be the one and only response message to an ExtendedRequest message
- ([LDAPv3] Section 4.12, also see Section 6 below), for unsolicited
- responses (LDAPv3 Section 4.4), and to return intermediate responses
- for the search operation ([LDAPv3] Section 4.5.2). The adaptation of
- ExpendedResponse as a general intermediate response mechanism would
- be problematic. In particular, existing APIs would likely have to
- be redesigned. It is believed (based upon operational experience)
-
-Harrison & Zeilenga Expires September 30, 2001 [Page 2]
+Internet-Draft LDAP Intermediate Response 28 March 2003
+
+
+ in response to a single request, all but the last of these response
+ messages are referred to as "intermediate responses".
+
+ This document defines and describes the IntermediateResponse
+ message, a general mechanism for defining single-request/multiple-
+ response operations in LDAP. The IntermediateResponse message is
+ defined in a way that maintains the protocol behavior of existing
+ LDAP operations. This message is intended to be used in conjunction
+ with the LDAP ExtendedRequest and ExtendedResponse 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.
+
+1. Introduction
+
+ The Lightweight Directory Access Protocol (LDAP), version 3
+ [RFC3377] is an extensible protocol. Extended operations ([RFC2251]
+ Section 4.12) are defined to allow operations to be added to LDAP
+ without requiring a new revision of the protocol. Similarly,
+ controls ([RFC2251] section 4.1.12) are defined to extend or modify
+ the behavior of existing LDAP operations.
+
+ LDAP is a client-request/server-response based protocol. With the
+ exception of the search operation, the entire response to an
+ operation request is returned in a single protocol data unit (i.e.
+ LDAP message). While this single-request/single-response paradigm
+ is sufficient for many operations (including all but one of those
+ currently defined by [RFC3377]), both intuition and practical
+ experience validate the notion that it is insufficient for some
+ operations.
+
+ For example, the LDAP delete operation could be extended via a
+ subtree control to mean that an entire subtree is to be deleted. A
+ subtree delete operation needs to return continuation references
+ based upon subordinate knowledge information contained in the server
+ so that the client can complete the operation. Returning references
+ as they are found instead of with the final result allows the client
+ to progress the operation more efficiently because it does not have
+ to wait for the final result to get this continuation reference
+ information.
+
+ Similarly, an engineer might choose to design the subtree delete
+ operation as an extended operation of its own rather than using a
+ subtree control in conjunction with the delete operation. Once
+ again, the same continuation reference information is needed by the
+ client to complete the operation, and sending the continuation
+ references as they are found would allow the client progress the
+ operation more efficiently.
+
+ Operations that complete in stages or that progress through various
+ states as they complete might want to send intermediate responses to
+ the client, thereby informing it of the status of the operation.
+ For example, an LDAP implementation might define an extended
+
+Harrison & Zeilenga Expires September 28, 2003 [Page 2]
\f
- LDAPv3 Intermediate Response March 30, 2001
-
-
- the addition of a new message to carry intermediate result
- information is easier to implement.
-
- This document defines the LDAPv3 IntermediateResponse message. This
- message is intended to be used (1) in conjunction with
+Internet-Draft LDAP Intermediate Response 28 March 2003
+
+
+ operation to create a new replica of an administrative area on a
+ server, and the operation completes in three stages: (1) begin
+ creation of replica, (2) send replica data to server, (3) replica
+ creation complete. Intermediate messages might be sent from the
+ server to the client at the beginning of each stage with the final
+ response for the extended operation being sent after stage (3) is
+ complete.
+
+ As LDAP [RFC3377] is currently defined, there is no general LDAP
+ message type that can be used to return intermediate results. A
+ single, reusable LDAP message for carrying intermediate response
+ information is desired to avoid repeated modification of the
+ protocol. Although the ExtendedResponse message is defined in LDAP,
+ it is defined to be the one and only response message to an
+ ExtendedRequest message ([RFC2251] Section 4.12), for unsolicited
+ responses (LDAP Section 4.4), and to return intermediate responses
+ for the search operation ([RFC3377] Section 4.5.2, also see Section
+ 5 below). The adaptation of ExtendedResponse as a general
+ intermediate response mechanism would be problematic. In
+ particular, existing APIs would likely have to be redesigned. It is
+ believed (based upon operational experience) that the addition of a
+ new message to carry intermediate result information is easier to
+ implement and is less likely to cause interoperability problems with
+ existing deployed implementations.
+
+ This document defines and describes the LDAP IntermediateResponse
+ message. This message is intended to be used in conjunction with
ExtendedRequest and ExtendedResponse to define new single-
- request/multiple-response operations and (2) in conjunction with a
- control when extending existing 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 a IntermediateResponse
- message can be sent by a server and the associated meaning of a
- IntermediateResponse message sent in a particular circumstance.
- Similarly, it is intended that clients will explicitly solicit
- IntermediateResponse messages by issuing operations that
- specifically call for their return.
-
-
-3. Conventions used in this document
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
- this document are to be interpreted as described in [ReqsKeywords].
-
- The term "request control" is used to describe a control that is
- included in an LDAPv3 request message sent from an LDAPv3 client to
- an LDAPv3 server.
-
-
-4. The IntermediateResponse PDU
-
- This document extends the protocolOp CHOICE of LDAPMessage ([LDAPv3]
- Section 4.1.1) to include the field:
-
- intermediateResponse IntermediateResponse
-
- where IntermediateResponse is defined as:
-
- 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.
-
- Although the responseName and responseValue are optional in some
- circumstances, generally speaking IntermediateResponse messages have
- a predefined responseName and a responseValue. The value of the
- responseName (if present), the syntax of the responseValue (if
-
-Harrison & Zeilenga Expires September 30, 2001 [Page 3]
+ 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.
+ Similarly, it is intended that clients will explicitly solicit
+ IntermediateResponse messages by issuing operations that
+ specifically call for their return.
+
+ The LDAP Content Sync Operation [draft-zeilenga-ldup-sync] (a work
+ in progress) demonstrates one use of LDAP Intermediate Response
+ messages.
+
+2. Conventions used in this document
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+
+
+
+Harrison & Zeilenga Expires September 28, 2003 [Page 3]
\f
- LDAPv3 Intermediate Response March 30, 2001
-
-
- present) and the semantics associated with a particular
- IntermediateResponse message MUST be specified in documents
- describing the extended operation or request control that uses them.
- Sections 4.1 and 4.2 describe additional requirements on the
- inclusion of responseName and responseValue in IntermediateResponse
- messages.
-
-
-4.1. Usage with LDAPv3 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.
-
- An extended operation that defines the return of multiple kinds of
- IntermediateResponse messages MUST provide and document a mechanism
- for the client to distinguish the kind of IntermediateResponse
- message being sent. This SHALL be accomplished by using different
- responseName values for each type of IntermediateResponse message
- associated with the extended operation or by including identifying
- information in the responseValue of each type of
- IntermediateResponse message associated with the extended operation.
-
-4.2. Usage with LDAPv3 Request Controls
-
- Any LDAPv3 operation may be extended by the addition of one or more
- 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
-
- (a) two or more controls using IntermediateResponse messages
- are included in a request for any LDAPv3 operation or
-
- (b) one or more controls using IntermediateResponse messages
- are included in a request with an LDAPv3 extended
- operation that uses IntermediateResponse messages.
-
- A request control that defines the return of multiple kinds of
- IntermediateResponse messages MUST provide and document a mechanism
- for the client to distinguish the kind of IntermediateResponse
- message being sent. This SHALL be accomplished by using different
- responseName values for each type of IntermediateResponse message
- associated with the request control or by including identifying
- information in the responseValue of each type of
- IntermediateResponse message associated with the request control.
-
-Harrison & Zeilenga Expires September 30, 2001 [Page 4]
+Internet-Draft LDAP Intermediate Response 28 March 2003
+
+
+ The term "request control" is used to describe a control that is
+ included in an LDAP request message sent from an LDAP client to an
+ LDAP server.
+
+3. The IntermediateResponse Message
+
+ This document extends the protocolOp CHOICE of LDAPMessage
+ ([RFC2251] Section 4.1.1) to include the field:
+
+ intermediateResponse IntermediateResponse
+
+ where IntermediateResponse is defined as:
+
+ 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.
+
+ Although the responseName and responseValue are optional in some
+ circumstances, generally speaking IntermediateResponse messages have
+ a predefined responseName and a responseValue. The value of the
+ responseName (if present), the syntax of the responseValue (if
+ present) and the semantics associated with a particular
+ IntermediateResponse message MUST be specified in documents
+ describing the extended operation or request control that uses them.
+ Sections 3.1 and 3.2 describe additional requirements on the
+ inclusion of responseName and responseValue in IntermediateResponse
+ messages.
+
+3.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.
+
+ An extended operation that defines the return of multiple kinds of
+ IntermediateResponse messages MUST provide and document a mechanism
+ for the client to distinguish the kind of IntermediateResponse
+ message being sent. This SHALL be accomplished by using different
+ responseName values for each type of IntermediateResponse message
+ associated with the extended operation or by including identifying
+ information in the responseValue of each type of
+ IntermediateResponse message associated with the extended operation.
+
+3.2. Usage with LDAP Request Controls
+
+ Any LDAP operation may be extended by the addition of one or more
+ controls ([RFC2251] Section 4.1.12). A control's semantics may
+
+Harrison & Zeilenga Expires September 28, 2003 [Page 4]
\f
- LDAPv3 Intermediate Response March 30, 2001
-
-
-
-5. Advertising Support for IntermediateResponse Messages
-
- Because IntermediateResponse messages are associated with extended
- operations or controls and LDAP provides a means for advertising the
- extended operations and controls supported by a server (using the
- supportedExtensions and supportedControls attributes of the root DSE
- attributes), no separate means for advertising support for
- IntermediateResponse messages is needed (or provided).
-
-6. Use of IntermediateResponse and ExtendedResponse with Search
-
- It is noted that ExtendedResponse messages may be sent in response
- to LDAPv3 search operations with controls ([LDAPv3] Section 4.5.1).
- This use of ExtendedResponse messages SHOULD be viewed as deprecated
- in favor of use of the IntermediateResponse messages.
-
-
-7. Security Considerations
-
- This document describes an enhancement to LDAPv3. All security
- considerations of [LDAPv3] apply to this document, however it does
- not introduce any new security considerations to the LDAPv3.
-
-8. References
-
- [LDAPv3]
- Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
- Access Protocol (v3)", RFC 2251, December 1997.
-
- [ReqsKeywords]
- Scott Bradner. "Key Words for use in RFCs to Indicate
- Requirement Levels". RFC 2119.
-
-
-9. Acknowledgments
-
- The authors would like to acknowledge the members of the IETF LDAP
- Extensions (ldapext) working group mail list who responded to the
- suggestion that a multiple-response paradigm might be useful for
- LDAP extended requests. Special thanks go to two individuals: David
- Wilbur who first introduced the idea on the working group list, and
- Thomas Salter, who succinctly summarized the group's discussion.
-
-10. Authors' Addresses
-
- Roger Harrison
- Novell, Inc.
- 1800 S. Novell Place
- Provo, UT 84606
- +1 801 861 2642
- roger_harrison@novell.com
-
-
-Harrison & Zeilenga Expires September 30, 2001 [Page 5]
+Internet-Draft LDAP Intermediate Response 28 March 2003
+
+
+ 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
+
+ (a) two or more controls using IntermediateResponse messages
+ are included in a request for any LDAP operation or
+
+ (b) one or more controls using IntermediateResponse messages
+ are included in a request with an LDAP extended
+ operation that uses IntermediateResponse messages.
+
+ A request control that defines the return of multiple kinds of
+ IntermediateResponse messages MUST provide and document a mechanism
+ for the client to distinguish the kind of IntermediateResponse
+ message being sent. This SHALL be accomplished by using different
+ responseName values for each type of IntermediateResponse message
+ associated with the request control or by including identifying
+ information in the responseValue of each type of
+ IntermediateResponse message associated with the request control.
+
+4. Advertising Support for IntermediateResponse Messages
+
+ Because IntermediateResponse messages are associated with extended
+ operations or controls and LDAP provides a means for advertising the
+ extended operations and controls supported by a server (using the
+ supportedExtensions and supportedControls attributes of the root DSE
+ attributes), no separate means for advertising support for
+ IntermediateResponse messages is needed (or provided).
+
+5. Use of IntermediateResponse and ExtendedResponse with Search
+
+ It is noted that ExtendedResponse messages may be sent in response
+ to LDAP search operations with controls ([RFC2251] Section 4.5.1).
+ This use of ExtendedResponse messages SHOULD be viewed as deprecated
+ in favor of use of the IntermediateResponse messages.
+
+6. Security Considerations
+
+ This document describes an enhancement to LDAP. All security
+ considerations of [RFC3377] apply to this document, however it does
+ not introduce any new security considerations to LDAP.
+
+ Security considerations specific to each extension using this
+ protocol mechanism shall be discussed in the technical specification
+ detailing the extension.
+
+7. IANA Considerations
+
+Harrison & Zeilenga Expires September 28, 2003 [Page 5]
\f
- LDAPv3 Intermediate Response March 30, 2001
-
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
- Kurt@OpenLDAP.org
-
-Appendix A - Document Revision History
- Editors' Note: this non-normative appendix should be removed prior
- to publication as an RFC. It is provided as an aid to reviewers of
- this "work in progress."
-
-A.1. draft-rharrison-ldap-extPartResp-00.txt
-
- Initial revision of draft.
-
-A.2. draft-rharrison-ldap-extPartResp-01.txt
-
- Changed responseName to be optional to align with [LDAPv3]
- definition of ExtendedResponse.
-
-A.3. draft-rharrison-ldap-extPartResp-02.txt
-
- Minor terminology corrections. Clarified use of
- ExtendedPartialResponse with LDAPv3 extended operations and other
- LDAPv3 operations with controls.
-
-A.4. draft-rharrison-ldap-intermediateResp-00.txt
+Internet-Draft LDAP Intermediate Response 28 March 2003
+
+
+
+ Registration of the following value is requested [RFC3383].
+
+7.1. LDAP Message Type
+
+ It is requested that IANA register upon Standards Action an LDAP
+ Message Type to identify the LDAP IntermediateResponse message as
+ defined in section 3 of this document.
+
+
+ The following registration template is suggested:
+
+ Subject: Request for LDAP Message Type Registration
+ Person & email address to contact for further information:
+ Roger Harrison <roger_harrison@novell.com>
+ Specification: RFCXXXX
+ Author/Change Controller: IESG
+ Comments: Identifies the LDAP IntermediateResponse Message
+
+Acknowledgments
+
+ The authors would like to acknowledge the members of the IETF LDAP
+ Extensions (ldapext) working group mail list who responded to the
+ suggestion that a multiple-response paradigm might be useful for
+ LDAP extended requests. Special thanks go to two individuals: David
+ Wilbur who first introduced the idea on the working group list, and
+ Thomas Salter, who succinctly summarized the group's discussion.
+
+Normative References
+
+ [RFC2119]
+ Bradner, S., "Key Words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2251]
+ Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
+ Access Protocol (v3)", RFC 2251, December 1997.
+
+ [RFC3377]
+ Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377, September
+ 2002.
+
+ [RFC3383]
+ Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access Protocol
+ (LDAP)", RFC 3383, September 2002.
+
+Informative References
+
+ [draft-zeilenga-ldup-sync]
+
+
+
+Harrison & Zeilenga Expires September 28, 2003 [Page 6]
+\f
+Internet-Draft LDAP Intermediate Response 28 March 2003
+
+
+ Zeilenga, K., "LDAP Content Synchronization Operation", Work in
+ Progress.
+
+Authors' Addresses
+
+ Roger Harrison
+ Novell, Inc.
+ 1800 S. Novell Place
+ Provo, UT 84606
+ +1 801 861 2642
+ roger_harrison@novell.com
+
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+ Kurt@OpenLDAP.org
+
+Full Copyright Statement
+
+ "Copyright (C) The Internet Society (date). All Rights Reserved.
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph
+ are included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 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.
+
+Appendix A - Document Revision History
+ Editors' Note: this appendix should be removed prior to publication
+ as an RFC. It is provided as an aid to reviewers of this "work in
+ progress."
+
+A.1. draft-rharrison-ldap-extPartResp-00.txt
+
+ Initial revision of draft.
+
+
+Harrison & Zeilenga Expires September 28, 2003 [Page 7]
+\f
+Internet-Draft LDAP Intermediate Response 28 March 2003
+
+
+A.2. draft-rharrison-ldap-extPartResp-01.txt
+
+ Changed responseName to be optional to align with [RFC3377]
+ definition of ExtendedResponse.
+
+A.3. draft-rharrison-ldap-extPartResp-02.txt
+
+ Minor terminology corrections. Clarified use of
+ ExtendedPartialResponse with LDAP extended operations and other LDAP
+ operations with controls.
+
+A.4. draft-rharrison-ldap-intermediateResp-00.txt
+
+ - Changed name of ExtendedPartialResponse to IntermediateResponse.
+
+ - Retitled "Motivation" section to "Background and Intended Usage"
+ and expanded its contents.
+
+ - Added detail surrounding the use of the IntermediateResponse with
+ extended operations and request controls.
+
+ - Generalized the way that Intermediate response fits into the ASN.1
+ definition of LDAP.
+
+ - Added information on advertising IntermediateResponse.
+
+ - Added information on the use of IntermediateResponse with the
+ search operation.
+
+A.5. draft-rharrison-ldap-intermediateResp-01.txt
+
+ This draft was oriented primarily to preparing the draft for
+ publication in accordance with established RFC formatting
+ guidelines. No substantial change in overall content was made.
+ Changes included the following:
+
+ - Retitled document
+
+ - Rewrote abstract
+
+ - Retitled "Background and Intended Usage" section to "Introduction"
+ and expanded its contents.
+
+ - Retitled Section 3 from "The Intermediate Response PDU" to "The
+ Intermediate Response Message".
+
+ - Renamed references to [RFCnnnn] format
+
+ - Added IANA Considerations section
+
+ - Retitled "References" section to "Normative References"
+
+ - Other small edits to bring draft in line with RFC formatting
+
+Harrison & Zeilenga Expires September 28, 2003 [Page 8]
+\f
+Internet-Draft LDAP Intermediate Response 28 March 2003
+
+
+ guidelines.
- - Changed name of ExtendedPartialResponse to IntermediateResponse.
- - Retitled "Motivation" section to "Background and Intended Usage"
- and expanded its contents.
- - Added detail surrounding the use of the IntermediateResponse with
- extended operations and request controls.
- - Generalized the way that Intermediate response fits into the ASN.1
- definition of LDAPv3.
- - Added information on advertising IntermediateResponse.
- - Added information on the use of IntermediateResponse with the
- search operation.
-Full Copyright Statement
- "Copyright (C) The Internet Society (date). 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
-Harrison & Zeilenga Expires September 30, 2001 [Page 6]
-\f
- LDAPv3 Intermediate Response March 30, 2001
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 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.
-Harrison & Zeilenga Expires September 30, 2001 [Page 7]
+
+Harrison & Zeilenga Expires September 28, 2003 [Page 9]
\f
+++ /dev/null
-Network Working Group M. Smith
-INTERNET-DRAFT Netscape Communications Corp.
-Intended Category: Standards Track
-Expires: 18 April 2000
-
- 18 October 1999
-
- LDAP C API Virtual List View Extension
- <draft-smith-ldap-c-api-ext-vlv-00.txt>
-
-1. Status of this Memo
-
-This document is an Internet-Draft and is in full conformance with all
-provisions of Section 10 of RFC2026. Internet-Drafts are working docu-
-ments 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 draft document will be submitted to the RFC Editor as a Standards
-Track document. Distribution of this memo is unlimited. Technical dis-
-cussion of this document will take place on the IETF LDAP Extension
-Working Group mailing list <ietf-ldapext@netscape.com>. Please send
-editorial comments directly to the author <mcs@netscape.com>.
-
-Copyright (C) The Internet Society (1998-1999). All Rights Reserved.
-
-Please see the Copyright section near the end of this document for more
-information.
-
-Expires: 18 April 2000 [Page 1]
-
-INTERNET-DRAFT LDAP C API Virtual List View Extension 18 October 1999
-
-2. Introduction
-
-This document defines a virtual list view extension for the LDAP C API
-to support the LDAP protocol extensions for scrolling view browsing of
-search results. More specifically, this document defines functions to
-create virtual list view request controls and to parse virtual list view
-response controls.
-
-The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-"SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are
-to be interpreted as described in RFC 2119 [KEYWORDS].
-
-3. Table of Contents
-
-1. Status of this Memo............................................1
-2. Introduction...................................................2
-3. Table of Contents..............................................2
-4. Background and Intended Usage..................................2
-5. Advertising the Virtual List View C LDAP API Extension.........3
-6. Creating a Virtual List View Request Control...................3
-7. Parsing a Virtual List View Response Control...................6
-8. Example Code...................................................8
-9. Security Considerations........................................8
-10. Copyright......................................................8
-11. Bibliography...................................................9
-12. Author's Address...............................................9
-13. Appendix A - Summary of Additions to the C LDAP API............9
-
-4. Background and Intended Usage
-
-The LDAP C API [CAPI] defines a C language application programming
-interface (API) to the Lightweight Directory Access Protocol [LDAP].
-This document defines an extension to that API to support an optional
-LDAP protocol extension for scrolling view browsing of search results,
-also known as Virtual List View [VLV].
-
-The scrolling view browsing LDAP extension itself is designed to allow a
-"virtual list box" feature to be supported efficiently by LDAP servers
-and clients. The protocol extension consists of two LDAP controls: a
-Virtual List View (VLV) Request control which is sent by a client to a
-server along with an LDAP search request and a Virtual List View
-Response control which is returned by the server to send back status
-information about the VLV request.
-
-LDAP clients that wish to use the "virtual list box" feature SHOULD
-first check the supportedControls attribute in a server's rootDSE to
-
-Expires: 18 April 2000 [Page 2]
-
-INTERNET-DRAFT LDAP C API Virtual List View Extension 18 October 1999
-
-determine if a value identical to the Virtual List View Request
-control's OID is present. If the OID is present and the client chooses
-to use the VLV feature, it MUST construct a Virtual List View Request
-control and a Server Side Sorting Control [SSS] and send both controls
-to the server within an LDAP searchRequest message. Both controls
-SHOULD be marked critical. Client applications MAY use the
-ldap_create_vlv_control() function described in this document to create
-a Virtual List View Request control.
-
-At the end of the search request processing, the server SHOULD return a
-Virtual List View Response control in the LDAP searchResultDone message.
-A Virtual List View Response control MAY be parsed to extract its con-
-tents by using the ldap_parse_vlv_control() function described in this
-document.
-
-5. Advertising the Virtual List View C LDAP API Extension
-
-To conform with the requirements defined in the C LDAP API specification
-[CAPI], implementations that support this extension SHOULD advertise the
-existence of this extension as follows:
-
- Define the macro LDAP_API_FEATURE_VIRTUAL_LIST_VIEW as a value that
- corresponds to the "level" or revision of this specification. When
- this document is published as an RFC, the value to use for
- LDAP_API_FEATURE_VIRTUAL_LIST_VIEW is the RFC number itself. While
- this document is an Internet Draft, the value to use is 1000 plus the
- revision number of this draft, i.e., 1000 for the -00 revision of
- this draft, 1001 for the -01 version, and so on.
-
- Return the text string VIRTUAL_LIST_VIEW in the ldapai_extensions
- array of the LDAPAPIInfo structure following a successful call to
- ldap_get_option() with an option parameter value of
- LDAP_OPT_API_INFO.
-
- Return information about the extension when the ldapaif_name field in
- the LDAPAPIFeatureInfo structure is set to the text string
- VIRTUAL_LIST_VIEW and a call to ldap_get_option() with an option
- parameter value of LDAP_OPT_API_FEATURE_INFO is made.
-
-6. Creating a Virtual List View Request Control
-
-The LDAPVLVInfo structure describes a Virtual List View Request control
-and is passed to the ldap_create_vlv_control() function to create a Vir-
-tualListViewRequest control. The resulting control SHOULD be passed to
-
-Expires: 18 April 2000 [Page 3]
-
-INTERNET-DRAFT LDAP C API Virtual List View Extension 18 October 1999
-
-the ldap_search_ext() or ldap_search_ext_s() functions described in
-[CAPI] to send them to the server. The ldap_create_sort_control() func-
-tion described in [SSSAPI] MAY be used to create a Sort control that is
-be passed to the server along with the VirtualListViewRequest control.
-
-The LDAPVLVInfo structure MAY also be used by applications to manage the
-state information associated with a series of virtual list view
-client/server interactions.
-
- /* LDAPVLVInfo structure: */
- typedef struct ldapvlvinfo {
- int ldvlv_version; /* version of this struct (1) */
- unsigned long ldvlv_before_count;
- unsigned long ldvlv_after_count;
- unsigned long ldvlv_offset; /* used if ldvlv_attrvalue is NULL
-*/
- unsigned long ldvlv_count; /* used if ldvlv_attrvalue is NULL
-*
- struct berval *ldvlv_attrvalue;
- struct berval *ldvlv_context;
- void *ldvlv_extradata; /* for use by application */
- } LDAPVLVInfo;
-
- /* value for the ldvlv_version field of the LDAPVLVInfo structure: */
- #define LDAP_VLVINFO_VERSION 1
-
- /* function used to create a VirtualListViewRequest control: */
- int ldap_create_vlv_control(
- LDAP *ld,
- LDAPVLVInfo *vlvinfop,
- LDAPControl **ctrlp
- );
-
- /* OID of the VirtualListViewRequest control: */
- #define LDAP_CONTROL_VLVREQUEST "2.16.840.1.113730.3.4.9"
-
-The parameters to the ldap_create_vlv_control() function are:
-
-ld An LDAP session handle, as obtained from a call to
- ldap_init().
-
-vlvinfop The address of an LDAPVLVInfo structure whose con-
- tents are used to construct the value of the control
- that is created.
-
-ctrlp A result parameter that will be assigned the address
- of an LDAPControl structure that contains the Virtu-
- alListViewRequest control created by this function.
- The memory occupied by the LDAPControl structure
- SHOULD be freed when it is no longer in use by
-
-Expires: 18 April 2000 [Page 4]
-
-INTERNET-DRAFT LDAP C API Virtual List View Extension 18 October 1999
-
- calling ldap_control_free().
-
-The ldap_create_vlv_control() function returns a C LDAP API error code
-to indicate success or failure (LDAP_SUCCESS if all goes well).
-
-The members of the LDAPVLVInfo structure are:
-
-ldvlv_version A number that identifies the version of the
- LDAPVLVInfo structure. This SHOULD always be set to
- the value LDAP_VLVINFO_VERSION (1).
-
-ldvlv_before_count A count of the number of entries before the target
- entry the client wants the server to send back.
- This field corresponds to the beforeCount element of
- the BER-encoded VirtualListViewRequest control value
- itself.
-
-ldvlv_after_count A count of the number of entries after the target
- entry the client wants the server to send back.
- This field corresponds to the afterCount element of
- the BER-encoded VirtualListViewRequest control value
- itself.
-
-ldvlv_offset This field is only used if ldvlv_attrvalue is NULL,
- i.e, if the byoffset choice within the VirtualList-
- ViewRequest control is to be used. ldvlv_offset is
- used along with the ldvlv_count value by the server
- to determine the target entry. This field
- corresponds to the offset element within the BER-
- encoded VirtualListViewRequest control value itself.
-
-ldvlv_count This field is only used if ldvlv_attrvalue is NULL,
- i.e., if the byIndex choice within the VirtualList-
- ViewRequest control is to be used. ldvlv_count is
- used along with the ldvlv_offset value by the server
- to determine the target entry. This field
- corresponds to the contentCount element within the
- BER-encoded VirtualListViewRequest control value
- itself.
-
-ldvlv_attrvalue If this is not NULL, it indicates that the
- greaterThanOrEqual choice within the VirtualList-
- ViewRequest is to be used. ldvlv_attrvalue
- corresponds to the assertionValue element of the
- BER-encoded VirtualListViewRequest control value
- itself. This value is compared by the server with
- the values of the attribute specified by the primary
- sort key to determine the target entry.
-
-Expires: 18 April 2000 [Page 5]
-
-INTERNET-DRAFT LDAP C API Virtual List View Extension 18 October 1999
-
-ldvlv_context If this is not NULL, it is included as the context
- identifier in the VirtualListViewRequest control;
- ldvlv_context corresponds to the contextID element
- within the BER-encoded VirtualListViewRequest con-
- trol value itself. If ldvlv_context is NULL, no
- context identifier is included in the VirtualList-
- ViewRequest control.
-
-ldvlv_extradata This field is reserved for application-specific use
- and is not used by the ldap_create_vlv_control()
- function; it has no effect on the control that is
- created.
-
-7. Parsing a Virtual List View Response Control
-
-When an application receives the result from a VLV search, it SHOULD use
-the ldap_parse_vlv_control() function to look for and parse the Virtual
-List View Response control returned by the server.
-
- /* function used to look for and parse a VirtualListViewResponse
-control: */
- int ldap_parse_vlv_control(
- LDAP *ld,
- LDAPControl **ctrls,
- unsigned long *target_posp,
- unsigned long *list_countp,
- struct berval **contextp,
- int *errcodep
- );
-
- /* OID of the VirtualListViewResponse control: */
- #define LDAP_CONTROL_VLVRESPONSE "2.16.840.1.113730.3.4.10"
-
- /* new error codes: */
- #define LDAP_SORT_CONTROL_MISSING 0x3C /* 60 */
- #define LDAP_INDEX_RANGE_ERROR 0x3D /* 61 */
-
-The parameters to the ldap_parse_vlv_control() function are:
-
-ld An LDAP session handle.
-
-ctrls The address of a NULL-terminated array of LDAPCon-
- trol structures, typically obtained by a call to
- ldap_parse_result().
-
-target_posp This result parameter is filled in with the list
- index of the target entry. If this parameter is
- NULL, the target position is not returned. The
-
-Expires: 18 April 2000 [Page 6]
-
-INTERNET-DRAFT LDAP C API Virtual List View Extension 18 October 1999
-
- value for this result parameter is pulled from the
- targetPosition element of the BER-encoded Virtual-
- ListViewResponse control value itself.
-
-list_countp This result parameter is filled in with the server's
- estimate of the size of the list. If this parameter
- is NULL, the size is not returned. The value for
- this result parameter is pulled from the con-
- tentCount element of the BER-encoded VirtualList-
- ViewResponse control value itself.
-
-contextp This result parameter is filled in with the address
- of a struct berval that contains the server-
- generated context identifier if one was returned by
- the server. If the server did not return a context
- identifier, this parameter will be set to NULL. The
- struct berval returned SHOULD be disposed of by cal-
- ling ber_bvfree() when it is no longer needed. If
- NULL is passed for contextp, the context identifier
- is not returned.
-
-errcodep This result parameter is filled in with the VLV
- result code. If this parameter is NULL, the result
- code is not returned. The value for this result
- parameter is pulled from the virtualListViewResult
- element of the BER-encoded VirtualListViewResponse
- control value itself. As specified in the VLV pro-
- tocol extension [VLV], it will have one of the fol-
- lowing values:
-
- LDAP_SUCCESS (0); defined in [CAPI]
- LDAP_OPERATIONS_ERROR (1); defined in [CAPI]
- LDAP_UNWILLING_TO_PERFORM (53); defined in [CAPI]
- LDAP_INSUFFICIENT_ACCESS (50); defined in [CAPI]
- LDAP_BUSY (51); defined in [CAPI]
- LDAP_TIMELIMIT_EXCEEDED (3); defined in [CAPI]
- LDAP_ADMINLIMIT_EXCEEDED (11); defined in [CAPI]
- LDAP_SORT_CONTROL_MISSING (60); defined above
- LDAP_INDEX_RANGE_ERROR (61); defined above
- LDAP_OTHER (80); defined in [CAPI]
-
-The ldap_parse_vlv_control() function returns an LDAP error code that
-indicates whether a VLV Result control was found and whether the parsing
-was successful. LDAP_SUCCESS is returned if all goes well,
-LDAP_CONTROL_NOT_FOUND is returned if the ctrls array does not include a
-VirtualListViewResponse control, and another LDAP error code that is
-defined in [CAPI] is returned if a parsing error or other problem
-occurs.
-
-Expires: 18 April 2000 [Page 7]
-
-INTERNET-DRAFT LDAP C API Virtual List View Extension 18 October 1999
-
-8. Example Code
-
-To be provided.
-
-9. Security Considerations
-
-Most servers will be configured to restrict access to the Virtual List
-View feature since poorly-behaved or malicious clients may cause many
-resources to be consumed on the server, or allow users to retrieve too
-many entries, or allow users to get an accurate count of the number of
-entries present in a portion of the DIT. Clients should take care to
-not abuse the VLV feature and should be prepared for servers to refuse
-to service a particular VLV request due to access control or other
-site-defined policies.
-
-Please see the protocol extension document [VLV] for a discussion of
-related security considerations.
-
-10. Copyright
-
-Copyright (C) The Internet Society (1998-1999). All Rights Reserved.
-
-This document and translations of it may be copied and furnished to oth-
-ers, and derivative works that comment on or otherwise explain it or
-assist in its implementation may be prepared, copied, published and dis-
-tributed, 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 Stan-
-dards process must be followed, or as required to translate it into
-languages other than English.
-
-The limited permissions granted above are perpetual and will not be
-revoked by the Internet Society or its successors or assigns.
-
-This document and the information contained herein is provided on an "AS
-IS" basis and THE INTERNET SOCIETY AND THE INTERNET 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 FIT-
-NESS FOR A PARTICULAR PURPOSE.
-
-Expires: 18 April 2000 [Page 8]
-
-INTERNET-DRAFT LDAP C API Virtual List View Extension 18 October 1999
-
-11. Bibliography
-
-[CAPI] M. Smith, T. Howes, A. Herron, M. Wahl, A. Anantha, "The C
- LDAP Application Program Interface", INTERNET-DRAFT,
- <draft-ietf-ldapext-ldap-c-api-04.txt>, 8 October 1999.
-
-[KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate Require-
- ment Levels", RFC 2119, March 1997.
-
-[LDAP] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
- Protocol (v3)", RFC 2251, December 1997.
-
-[SSS] A. Herron, T. Howes, M. Wahl, A. Anantha, "LDAP Control
- Extension for Server Side Sorting of Search Results",
- INTERNET-DRAFT, April 1999.
-
-[SSSAPI] C. Weider, A. Herron, T. Howes, M. Smith, M. Wahl, "LDAP API
- Extensions for Sort and Simple Paged Results", INTERNET-
- DRAFT, <draft-ietf-asid-ldapv3-api-ext-00.txt>, July 1997.
-
-[VLV] D. Boreham, J. Sermersheim, A. Anantha, M. Armijo, "LDAP
- Extensions for Scrolling View Browsing of Search Results",
- INTERNET-DRAFT <draft-ietf-ldapext-ldapv3-vlv-03.txt>, 11
- June 1999.
-
-12. Author's Address
-
- Mark Smith
- Netscape Communications Corp.
- 501 E. Middlefield Rd., Mailstop MV068
- Mountain View, CA 94043
- USA
- +1 650 937-3477
- mcs@netscape.com
-
-13. Appendix A - Summary of Additions to the C LDAP API
-
-This extension introduces the following macros:
-
- LDAP_API_FEATURE_VIRTUAL_LIST_VIEW
- LDAP_VLVINFO_VERSION
- LDAP_CONTROL_VLVREQUEST
- LDAP_CONTROL_VLVRESPONSE
- LDAP_SORT_CONTROL_MISSING
- LDAP_INDEX_RANGE_ERROR
-
-Expires: 18 April 2000 [Page 9]
-
-INTERNET-DRAFT LDAP C API Virtual List View Extension 18 October 1999
-
-This extension introduces the following structures and typedefs:
-
- ldapvlvinfo
- LDAPVLVInfo
-
-This extension introduces the following functions:
-
- ldap_create_vlv_control()
- ldap_parse_vlv_control()
-
-Expires: 18 April 2000 [Page 10]
INTERNET-DRAFT Rob Weltman
Intended Category: Standards Track Netscape Communications Corp.
- May 2002
+ April 2003
LDAP Proxied Authorization Control
- draft-weltman-ldapv3-proxy-11.txt
+ draft-weltman-ldapv3-proxy-12.txt
Status of this Memo
Abstract
This document defines the Lightweight Directory Access Protocol
- (LDAP) Proxied Authorization Control. The Proxied Authorization
- Control allows a client to request that an operation be processed
- under a provided authorization identity [AUTH] instead of as the
- current authorization identity associated with the connection.
+ (LDAP) Proxy Authorization Control. The Proxy Authorization Control
+ allows a client to request that an operation be processed under a
+ provided authorization identity instead of as the current
+ authorization identity associated with the connection.
1. Introduction
- This document defines support for proxied authorization using the
- Control mechanism. LDAP [LDAPV3] supports the use of SASL [SASL] for
- authentication and for supplying an authorization identity distinct
- from the authentication identity, where the authorization identity
- applies to the whole LDAP session. The proposed Proxied Authorization
- Control provides a mechanism for specifying an authorization identity
- on a per operation basis, benefiting clients that need to efficiently
- perform operations on behalf of multiple users.
-
- The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY", and
- "MAY NOT" used in this document are to be interpreted as described
- in [KEYWORDS].
-
+ Proxy authorization allows a client to request that an operation be
+ processed under a provided authorization identity instead of as the
+ current authorization identity associated with the connection. This
+ document defines support for proxy authorization using the Control
+ mechanism [RFC 2251]. The Lightweight Directory Access Protocol
+ [LDAPV3] supports the use of the Simple Authentication and Security
+ Layer [SASL] for authentication and for supplying an authorization
+ identity distinct from the authentication identity, where the
+ authorization identity applies to the whole LDAP session. The Proxy
+ Authorization Control provides a mechanism for specifying an
+ authorization identity on a per operation basis, benefiting clients
+ that need to efficiently perform operations on behalf of multiple
+ users.
-Expires November 2002 [Page 1]
+Expires October 2003 [Page 1]
\f
-PROXIED AUTHORIZATION CONTROL May 2002
+PROXIED AUTHORIZATION CONTROL April 2003
-2. Publishing support for the Proxied Authorization Control
+ The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
+ used in this document are to be interpreted as described in
+ [KEYWORDS].
+
- Support for the Proxied Authorization Control is indicated by the
- presence of the OID "2.16.840.1.113730.3.4.18" in the
- supportedControl attribute of a server's root DSE.
+2. Publishing support for the Proxy Authorization Control
+ Support for the Proxy Authorization Control is indicated by the
+ presence of the Object Identifier (OID) "2.16.840.1.113730.3.4.18" in
+ the supportedControl attribute [RFC 2252] of a server's root DSE.
-3. Proxied Authorization Control
- A single Proxied Authorization Control may be included in any search,
- compare, modify, add, delete, modDN or extended operation request
- message (with the exception of any extension that causes a change in
- authentication, authorization, or data confidentiality [RFC 2828],
- such as startTLS) as part of the controls field of the LDAPMessage,
- as defined in [LDAPV3].
+3. Proxy Authorization Control
- The controlType of the proxied authorization control is
+ A single Proxy Authorization Control may be included in any search,
+ compare, modify, add, delete, modify DN or extended operation request
+ message with the exception of any extension that causes a change in
+ authentication, authorization, or data confidentiality [RFC 2829],
+ such as Start TLS [LDAPTLS] as part of the controls field of the
+ LDAPMessage, as defined in [RFC 2251].
+
+ The controlType of the proxy authorization control is
"2.16.840.1.113730.3.4.18".
The criticality MUST be present and MUST be TRUE. This requirement
protects clients from submitting a request that is executed with an
unintended authorization identity.
- The controlValue is either an LDAPString [LDAPv3] containing an
- authzId as defined in section 9 of [AUTH] to use as the authorization
- identity for the request, or an empty value if the anonymous identity
- is to be used.
+ The controlValue SHALL be present and contain either an authzId
+ [AUTH] representing the authorization identity for the request or
+ empty if an anonymous association is to be used.
The mechanism for determining proxy access rights is specific to the
- server's access control policy.
+ server's proxy authorization policy.
If the requested authorization identity is recognized by the server,
and the client is authorized to adopt the requested authorization
- identity, the request will be executed as if submitted by the proxied
+ identity, the request will be executed as if submitted by the proxy
authorization identity, otherwise the result code TBD is returned.
[Note to the IESG/IANA/RFC Editor: the value TBD is to be replaced
- with an IANA assigned LDAP Result Code (see draft-ietf-ldapbis-iana-
- xx.txt, Section 3.5)]
+ with an IANA assigned LDAP Result Code (see RFC 3383 section 3.6]
4. Implementation Considerations
- The interaction of proxied authorization access control and normal
- access control is illustrated here for the case of search requests.
- During evaluation of a search request, an entry which would have been
- returned for the search if submitted by the proxied authorization
+ One possible interaction of proxy authorization and normal access
+ control is illustrated here for the case of search requests. During
+ evaluation of a search request, an entry which would have been
+ returned for the search if submitted by the proxy authorization
identity directly may not be returned if the server finds that the
requester does not have the right to assume the requested identity
for searching the entry, even if the entry is within the scope of a
search request under a base DN which does imply such rights. This
- means that fewer results, or no results, may be returned compared to
- the case where the proxied authorization identity issued the request
- directly. An example of such a case may be a system with fine-grained
-Expires November 2002 [Page 2]
+Expires October 2003 [Page 2]
\f
-PROXIED AUTHORIZATION CONTROL May 2002
+PROXIED AUTHORIZATION CONTROL April 2003
+ means that fewer results, or no results, may be returned compared to
+ the case where the proxy authorization identity issued the request
+ directly. An example of such a case may be a system with fine-grained
access control, where the proxy right requester has proxy rights at
the top of a search tree, but not at or below a point or points
within the tree.
5. Security Considerations
- The Proxied Authorization Control method is subject to general LDAP
- security considerations [LDAPV3] [AUTH] [LDAPTLS]. The control may be
- passed over a secure as well as over an insecure channel.
+ The Proxy Authorization Control method is subject to general LDAP
+ security considerations [RFC 2251] [AUTH] [LDAPTLS]. The control may
+ be passed over a secure as well as over an insecure channel.
The control allows for an additional authorization identity to be
passed. In some deployments, these identities may contain
confidential information which require privacy protection.
- Note that the server is responsible for determining if a proxied
+ Note that the server is responsible for determining if a proxy
authorization request is to be honored. "Anonymous" users SHOULD NOT
be allowed to assume the identity of others.
-6. Copyright
+6. IANA Considerations
+
+ The OID "2.16.840.1.113730.3.4.18" is reserved for the Proxy
+ Authorization Control. It is to be registered as an LDAP Protocol
+ Mechanism [RFC 3383].
+
+ A result code for the case where the server does not execute a
+ request using the proxy authorization identity is to be assigned by
+ the IANA.
+
+
+7. Copyright
Copyright (C) The Internet Society (date). All Rights Reserved.
English.
The limited permissions granted above are perpetual and will not be
+
+Expires October 2003 [Page 3]
+\f
+PROXIED AUTHORIZATION CONTROL April 2003
+
+
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-7. References
+8. Normative References
- [LDAPV3] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
- Protocol (v3)", RFC 2251, December 1997.
-
-Expires November 2002 [Page 3]
-\f
-PROXIED AUTHORIZATION CONTROL May 2002
-
-
[KEYWORDS] Bradner, Scott, "Key Words for use in RFCs to Indicate
Requirement Levels", draft-bradner-key-words-03.txt, January,
1997.
- [SASL] J. Myers, "Simple Authentication and Security Layer (SASL)",
+ [LDAPV3] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377, September
+ 2002.
+
+ [SASL] J. Myers, "Simple Authentication and Security Layer (SASL)",
RFC 2222, October 1997
[AUTH] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan, "Authentication
Access Protocol (v3): Extension for Transport Layer Security",
RFC 2830, May 2000
- [RFC 2828] R. Shirey, "Internet Security Glossary", RFC 2828, May
- 2000
+ [RFC 2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
+ Protocol (v3)", RFC 2251, December 1997.
+
+ [RFC 2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight
+ Directory Access Protocol (v3): Attribute Syntax Definitions",
+ RFC 2252, December 1997
+
+ [RFC 2829] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan,
+ "Authentication Methods for LDAP", RFC 2829, May 2000
+
+ [RFC 3383] K. Zeilenga, "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access Protocol
+ (LDAP)", RFC 3383, September 2002
-8. Author's Address
+9. Author's Address
Rob Weltman
Netscape Communications Corp.
- 466 Ellis Street
- Mountain View, CA 94043
+ 360 W. Caribbean Drive
+ Sunnyvale, CA 94089
USA
+
+
+Expires October 2003 [Page 4]
+\f
+PROXIED AUTHORIZATION CONTROL April 2003
+
+
+1 650 937-3194
rweltman@netscape.com
-9. Acknowledgements
+10. Acknowledgements
Mark Smith of Netscape Communications Corp., Mark Wahl of Sun
Microsystems, Inc, Kurt Zeilenga of OpenLDAP Foundation, Jim
Sermersheim of Novell, and Steven Legg of Adacel have contributed
- with reviews of this draft.
-
+ with reviews of this document.
-10. Revision History
-10.1 Changes from draft-weltman-ldapv3-proxy-10.txt
-
- Clarified the interaction of proxy access rights and normal access
- control evaluation.
-
-10.2 Changes from draft-weltman-ldapv3-proxy-09.txt
-
- Removed description of Control mechanism from Abstract.
-
- Added description of how this is different from SASL authz to the
- Introduction.
-
-Expires November 2002 [Page 4]
-\f
-PROXIED AUTHORIZATION CONTROL May 2002
-
-
- Reworded description of the value of the control (no semantic
- changes).
- Added new result code TBD for failure to acquire proxy rights.
-
- Added references to RFCs 2829 and 2830 in Security section.
-
-10.3 Changes from draft-weltman-ldapv3-proxy-08.txt
-
- Proxied Authorization Control
-
- Clarifications: the control may not be submitted with a startTLS
- request; an empty controlValue implies the anonymous identity; only
- one control may be included with a request.
-
- Permission to execute as proxy
-
- Replaced "proxy identity" with "proxied authorization identity".
-
-
- Security Considerations
-
- Added statement that anonymous users should not be allowed to assume
- the identity of others.
-
-10.4 Changes from draft-weltman-ldapv3-proxy-07.txt
-
- Proxied Authorization Control
-
- Clarification: the content of the control is an LDAPString.
-
-10.5 Changes from draft-weltman-ldapv3-proxy-06.txt
-
- None
-
-
-Expires November 2002 [Page 5]
-\f
-PROXIED AUTHORIZATION CONTROL May 2002
-
-
-10.6 Changes from draft-weltman-ldapv3-proxy-05.txt
-
- The control also applies to add and extended operations.
-
- The control value is an authorization ID, not necessarily a DN.
-
- Confidentiality concerns are mentioned.
-
-10.7 Changes from draft-weltman-ldapv3-proxy-04.txt
-
- The control does not apply to bind, unbind, or abandon operations.
-
- The proxy DN is represented as a string in the control, rather than
- embedded in a sequence.
-
- Support for the control is published in the supportedControl
- attribute of the root DSE, not in supportedExtensions.
-
- The security section mentions confidentiality issues with exposing an
- additional identity.
-
-10.8 Changes from draft-weltman-ldapv3-proxy-03.txt
-
- None
-
-
-10.9 Changes from draft-weltman-ldapv3-proxy-02.txt
-
- The Control is now called Proxied Authorization Control, rather than
- Proxied Authentication Control, to reflect that no authentication
- occurs as a consequence of processing the Control.
-
- Rather than containing an LDAPDN as the Control value, the Control
- contains a Sequence (which contains an LDAPDN). This is to provide
- for future extensions.
+
+
+
+
-Expires November 2002 [Page 6]
+Expires October 2003 [Page 5]
\f
\ No newline at end of file
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Informational OpenLDAP Foundation
-Expires in six months 17 May 2002
+Expires in six months 20 December 2002
- LDAPv3: Requesting Attributes by Object Class
- <draft-zeilenga-ldap-adlist-01.txt>
+ LDAP: Requesting Attributes by Object Class
+ <draft-zeilenga-ldap-adlist-04.txt>
Status of this Memo
revision, submitted to the RFC Editor as an Informational document.
Distribution of this memo is unlimited. Technical discussion of this
document will take place on the IETF LDAP Extensions Working Group
- mailing list <ietf-ldapext@netscape.com>. Please send editorial
- comments directly to the author <Kurt@OpenLDAP.org>.
+ 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
Zeilenga Requesting Attributes by Object Class [Page 1]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-adlist-01 17 May 2002
+INTERNET-DRAFT draft-zeilenga-ldap-adlist-04 20 December 2002
1. Overview
- LDAP [RFC2251] search operations support mechanisms for requesting
- sets of attributes. This set is determined by a list of attribute
- descriptions. Two special descriptors are defined to request all user
- attributes ("*") and all operational attributes ("+"). However, there
- is no convenient mechanism for requesting pre-defined sets of
- attributes. This document extends LDAP to allow an object class
- identifier to be specified in search request attributes list to
- request the return all attributes allowed by object class.
+ In the Lightweight Directory Access Protocol (LDAP) [RFC3377], the
+ search operation [RFC2251] support requesting a sets of attributes.
+ This set is determined by a list of attribute descriptions. Two
+ special descriptors are defined to request all user attributes ("*")
+ [RFC2251] and all operational attributes ("+") [OPATTRS]. However,
+ there is no convenient mechanism for requesting pre-defined sets of
+ attributes.
+
+ This document extends LDAP to allow an object class identifier to be
+ specified in search request attributes list to request the return all
+ attributes allowed by object class. A plus sign ("+", U+002B) is used
+ to distinguish an object class identifier from an attribute
+ descriptions.
+
+ For example, the attribute list of "+country" is equivalent to the
+ attribute list of 'c', 'searchGuide', 'description', and
+ 'objectClass'. This object class and its attributes are described in
+ [RFC2256].
+
+ This extension is intended to be used where the user is in direct
+ control of the parameters of the LDAP search operation.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
the attributes field of the LDAP SearchRequest [RFC2251]. For each
object class identified in the attributes field, the request is to be
treated as if each attribute allowed by that class (by "MUST" or
- "MAY", directly or by SUPerior) was itself listed. For example, a
- request for "country" [RFC2256] is treated as if "c", "searchGuide",
- "description", and "objectClass" were requested.
-
- As a special case, requesting extensibleObject [RFC2252] is treated as
- if "objectClass,*,+" was requested [RFC2251][OPATTRS].
+ "MAY", directly or by SUPerior) was itself listed.
If the object class identifier is unrecognized, it is be treated an an
unrecognized attribute description.
This extension redefines the attributes field of the SearchRequest to
- be a DescriptionList described by the following [ASN.1]:
+ be a DescriptionList described by the following ASN.1 [X.680] data
+ type:
DescriptionList ::= SEQUENCE OF Description
Description ::= LDAPString
- The Description is string conforming to the [ABNF]:
-
- Description ::= AttributeDescription | ObjectClassDescription.
- ObjectDescription ::= ObjectClass *( ";" options )
-
- where AttributeDescription and options productions are as defined in
- Section 4.1.5 of [RFC2251] and an ObjectClass is an objectIdentifier,
- in either numericoid or descr form [RFC 2252], of an object class.
-
- ObjectDescription options are provided for extensibility. This
+ The Description is string conforming to the ABNF [RFC2234]:
Zeilenga Requesting Attributes by Object Class [Page 2]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-adlist-01 17 May 2002
+INTERNET-DRAFT draft-zeilenga-ldap-adlist-04 20 December 2002
- document only defines semantics of ObjectDescriptions with zero
- options in the attributes field of a SearchRequest. Other uses may be
- defined in future specifications.
+ Description = AttributeDescription | ObjectClassDescription.
+ ObjectClassDescription = "+" ObjectClass *( ";" options )
+
+ where <AttributeDescription> and <options> productions are as defined
+ in Section 4.1.5 of [RFC2251] and an <ObjectClass> is an object
+ identifier, in either <numericoid> or <descr> form [RFC2252], of an
+ object class.
+
+ <ObjectClassDescription> <options> are provided for extensibility.
+ This document only defines semantics of <ObjectClassDescription>s with
+ zero options in the attributes field of a SearchRequest. Other uses
+ may be defined in future specifications.
Servers supporting this feature SHOULD publish the Object Identifier
- 1.3.6.1.4.1.4203.1.5.2 as a value of the supportedFeatures [FEATURES]
- attribute in the root DSE.
+ 1.3.6.1.4.1.4203.1.11.2 as a value of the 'supportedFeatures'
+ [FEATURES] attribute in the root DSE.
3. Security Considerations
This extension provides a shorthand for requesting all attributes of
an object class. As these attributes which could have been listed
- individually, this short hand is not believed to raises additional
+ individually, this short hand is not believed to raise additional
security considerations.
Implementors of this (or any) LDAP extension should be familiar with
- general LDAP general security considerations [LDAPTS].
+ general LDAP security considerations [RFC3377].
4. IANA Considerations
- No IANA assignments are requested.
+ This OID 1.3.6.1.4.1.4203.1.11.2 to identify the LDAP "OC AD List?
+ feature. This OID was assigned [ASSIGN] by OpenLDAP Foundation, under
+ its IANA-assigned private enterprise allocation [PRIVATE], for use in
+ this specification.
+
+ Registration of this protocol mechansism is requested per BCP 64
+ [RFC3383].
+
+ Subject: Request for LDAP Protocol Mechansism Registration
+ Object Identifier: 1.3.6.1.4.1.4203.1.5.2
+ Description: OC AD Lists
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@openldap.org>
+ Usage: Feature
+ Specification: RFCxxxx
+ Author/Change Controller: Kurt Zeilenga <kurt@openldap.org>
+ Comments: none
- This document uses the OID 1.3.6.1.4.1.4203.1.5.2 to identify the LDAP
- feature it details. This OID was assigned [ASSIGN] by OpenLDAP
- Foundation under its IANA assigned private enterprise allocation
- [PRIVATE] for use in this specification.
+
+
+Zeilenga Requesting Attributes by Object Class [Page 3]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-adlist-04 20 December 2002
5. Author's Address
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+ [RFC2234] D. Crocker, P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
[RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
Directory Access Protocol (v3): Attribute Syntax
Definitions", RFC 2252, December 1997.
-
-
-Zeilenga Requesting Attributes by Object Class [Page 3]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-adlist-01 17 May 2002
-
-
- [LDAPTS] J. Hodges, R. Morgan, "Lightweight Directory Access
- Protocol (v3): Technical Specification",
- draft-ietf-ldapbis-ldapv3-ts-xx.txt (a work in progress).
+ [RFC3377] J. Hodges, R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
[FEATURES] K. Zeilenga, "Feature Discovery in LDAP",
draft-zeilenga-ldap-features-xx.txt (a work in progress).
- [OPATTRS] K. Zeilenga, "LDAPv3: All Operational Attributes",
- draft-zeilenga-ldap-opattrs-xx.txt (a work in progress).
+ [X.680] ITU-T, "Abstract Syntax Notation One (ASN.1) -
+ Specification of Basic Notation", X.680, 1994.
7. Informative References
- [RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use
+ [RFC2256] M. Wahl, "A Summary of the X.500(96) User Schema for use
with LDAPv3", RFC 2256, December 1997.
- [X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts,
- Models and Service", 1993.
-
- [X.511] ITU-T Rec. X.511, "The Directory: Abstract Service
- Definition", 1993.
+ [RFC3383] K. Zeilenga, "IANA Considerations for LDAP", RFC 3383,
+ September 2002.
[ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
http://www.openldap.org/foundation/oid-delegate.txt.
+
+
+Zeilenga Requesting Attributes by Object Class [Page 4]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-adlist-04 20 December 2002
+
+
Copyright 2002, The Internet Society. All Rights Reserved.
This document and translations of it may be copied and furnished to
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
-
-
-
-Zeilenga Requesting Attributes by Object Class [Page 4]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-adlist-01 17 May 2002
-
-
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,
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
--- /dev/null
+
+
+
+
+
+
+INTERNET-DRAFT Kurt D. Zeilenga
+Intended Category: Standard Track OpenLDAP Foundation
+Expires in six months 11 May 2003
+
+
+ The LDAP Assertion Control
+ <draft-zeilenga-ldap-assert-00.txt>
+
+
+Status of this 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 IESG for consideration as a Standard Track
+ document. Distribution of this memo is unlimited. Technical
+ discussion of this document will take place on the IETF LDAP
+ Extensions 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 (C) The Internet Society (2003). All Rights Reserved.
+
+ Please see the Full Copyright section near the end of this document
+ for more information.
+
+
+Abstract
+
+ This document defines the Lightweight Directory Access Protocol (LDAP)
+ Assertion Control which allows a client to specify that a directory
+ operation should only be processed if the assertion when applied to
+ the target entry of the operation. It can be used to construct "test
+ and set" and "test and clear" operations.
+
+
+
+
+Zeilenga LDAP Assertion Control [Page 1]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-assert-00 11 May 2003
+
+
+1. Overview
+
+ This document defines the Lightweight Directory Access Protocol (LDAP)
+ [RFC3377] assertion control. The assertion control allows the client
+ to specify a condition which allows the operation to be processed
+ normally only when true. Otherwise the operation fails.
+
+ The control can be used with the Modify operation [RFC2251] to perform
+ atomic "test and set" and "test and clear" operations as the the
+ asserted condition is evaluated as an integral part the operation.
+ The control may be attached to other update operations to support
+ conditional add, delete, and renaming of objects.
+
+ The control may also be used with the search operation. Here the
+ assertion is applied to the base object of the search before searching
+ for objects matching the search scope and filter.
+
+ The control may also be used with the compare operation. Here it
+ extends the compare operation to allow a more complex assertion.
+
+
+2. Terminology
+
+ 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].
+
+ DN stands for Distinguished Name.
+ DSA stands for Directory System Agent (i.e., a directory server).
+ DSE stands for DSA-specific Entry.
+
+ 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].
+
+
+3. The Assertion Control
+
+ The assertion control is an LDAP Control [RFC2251] whose controlType
+ is IANA-ASSIGNED-OID and controlValue is a BER-encoded Filter
+ [RFC2251, Section 4.5.1]. The criticality may be TRUE or FALSE.
+ There is no corresponding response control.
+
+ Servers implementing this technical specification SHOULD publish
+ IANA-ASSIGNED-OID as a value of the 'supportedControl' attribute
+ [RFC2252] in their root DSE.
+
+
+
+
+Zeilenga LDAP Assertion Control [Page 2]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-assert-00 11 May 2003
+
+
+ The control is appropriate for both LDAP interrogation and update
+ operations [RFC2251] including Add, Compare, Delete, Modify, ModifyDN
+ (rename), and Search. It is not appropriate for Abandon, Bind nor
+ Unbind operations. Nor is it appropriate for the Start TLS [RFC2830]
+ operation.
+
+ When the control is attached to an LDAP request, the processing of the
+ request is conditional on the evaluation of the Filter as applied
+ against the target of the operation. If the Filter evaluates to TRUE,
+ then the request is processed normally. If the Filter evaluates to
+ FALSE, then assertionFailed (IANA-ASSIGNED-CODE) resultCode is
+ returned and no further processing is performed.
+
+ For Add, Compare, and ModifyDN the target is indicated by the entry
+ field in the request. For Modify, the target is indicated by the
+ object field. For Delete, the target is indicated by the DelRequest
+ type. For the Compare operation and all update operations, the
+ evaluation of the assertion MUST be performed as an integral part of
+ the operation. That is, the evaluation of the assertion and the
+ normal processing SHALL be done as one atomic action.
+
+ For search operation, the target is indicated by the baseObject field
+ and the evaluation is done after "finding" but before "searching"
+ [RFC2251]. Hence, if the evaluation fails, no entries or
+ continuations references are returned.
+
+ Other documents may specify how this control applies to other LDAP
+ operations. In doing so, they must how the target entry is
+ determined.
+
+
+3. Security Considerations
+
+ The filter may, like other values of the request, contain sensitive
+ information. When so, this information should be appropriately
+ protected.
+
+ As with any general assertion mechanism, the mechanism can be used to
+ determine directory content. Hence, the mechanism SHOULD be subject
+ to appropriate access controls.
+
+ Some assertions may be very complex, requiring significant time and
+ resources to evaluate. Hence, the mechanism SHOULD be subject to
+ appropriate administrative controls.
+
+ All security considerations for the base operations [RFC2251] to which
+ this control is attached to apply, as do general LDAP security
+ considerations [RFC3377].
+
+
+
+Zeilenga LDAP Assertion Control [Page 3]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-assert-00 11 May 2003
+
+
+4. IANA Considerations
+
+4.1. Object Identifier
+
+ It is requested that IANA register upon Standards Action an LDAP
+ Object Identifier [RFC3383] 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: IESG
+ Comments:
+ Identifies the LDAP Assertion Control
+
+4.2 LDAP Protocol Mechanism
+
+ Registration of this protocol mechanism [RFC3383] is requested.
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: IANA-ASSIGNED-OID
+ Description: Assertion Control
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@openldap.org>
+ Usage: Control
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+ Comments: none
+
+
+4.3 LDAP Result Code
+
+ Assignment of an LDAP Result Code [RFC3383] called 'assertionFailed'
+ is requested.
+
+ Subject: LDAP Result Code Registration
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@OpenLDAP.org>
+ Result Code Name: assertionFailed
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+ Comments: none
+
+
+5. Acknowledgments
+
+ The assertion control concept is attributed to Morteza Ansari.
+
+
+
+Zeilenga LDAP Assertion Control [Page 4]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-assert-00 11 May 2003
+
+
+6. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+ <Kurt@OpenLDAP.org>
+
+
+7. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+
+ [RFC2251] Wahl, M., T. Howes and S. Kille, "Lightweight Directory
+ Access Protocol (v3)", RFC 2251, December 1997.
+
+ [RFC2252] Wahl, M., A. Coulbeck, T. Howes, and S. Kille,
+ "Lightweight Directory Access Protocol (v3): Attribute
+ Syntax Definitions", RFC 2252, December 1997.
+
+ [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
+
+
+8. Informative References
+
+ [RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
+ (also RFC 3383), September 2002.
+
+
+
+Intellectual Property Rights
+
+ The IETF takes no position regarding the validity or scope of any
+ intellectual property 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; neither does it represent that it has made any
+ effort to identify any such rights. Information on the IETF's
+ procedures with respect to rights in standards-track and
+ standards-related documentation can be found in BCP-11. Copies of
+ claims of rights made available for publication 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 implementors or users of this specification can be obtained
+ from the IETF Secretariat.
+
+ The IETF invites any interested party to bring to its attention any
+
+
+
+Zeilenga LDAP Assertion Control [Page 5]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-assert-00 11 May 2003
+
+
+ copyrights, patents or patent applications, or other proprietary
+ rights which may cover technology that may be required to practice
+ this standard. Please address the information to the IETF Executive
+ Director.
+
+
+
+Full Copyright
+
+ Copyright (C) The Internet Society (2003). 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 implmentation 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga LDAP Assertion Control [Page 6]
+\f
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 17 May 2002
+Expires in six months 3 May 2003
LDAP Cancel Extended Operation
- <draft-zeilenga-ldap-cancel-05.txt>
+ <draft-zeilenga-ldap-cancel-08.txt>
1. Status of this Memo
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 <ietf-ldapext@netscape.com>. Please send editorial
- comments directly to the author <Kurt@OpenLDAP.org>.
+ 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
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
- Copyright 2002, The Internet Society. All Rights Reserved.
+ Copyright 2003, The Internet Society. All Rights Reserved.
Please see the Copyright section near the end of this document for
more information.
Abstract
- This specification describes an LDAP (Lightweight Directory Access
- Protocol) extended operation to cancel (or abandon) an outstanding
- operation. Unlike the LDAP Abandon operation but like the X.511 DAP
- Abandon operation, this operation has a response which provides an
- indication of its outcome.
+ This specification describes a Lightweight Directory Access Protocol
+ (LDAP) extended operation to cancel (or abandon) an outstanding
+ operation. Unlike the LDAP Abandon operation but like the X.511
+ Directory Access Protocol (DAP) Abandon operation, this operation has
+ a response which provides an indication of its outcome.
Zeilenga LDAP Cancel [Page 1]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-cancel-05 17 May 2002
+INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
Conventions
1. Background and Intent of Use
- LDAP [RFC2251] provides an Abandon operation which clients may use to
- cancel other operations. The Abandon operation does not have a
- response and also calls for there to be no response of the abandoned
- operation. These semantics provide the client with no clear
- indication of the outcome of the Abandon operation.
+ The Lightweight Directory Access Protocol (LDAP) [RFC3377] provides an
+ Abandon operation [RFC2251] which clients may use to cancel other
+ operations. The Abandon operation does not have a response and calls
+ for there to be no response of the abandoned operation. These
+ semantics provide the client with no clear indication of the outcome
+ of the Abandon operation.
- X.511 DAP [X.511] provides an Abandon operation which does have a
- response and also requires the abandoned operation to return a
- response with indicating it was canceled. The Cancel operation is
- modeled after the DAP Abandon operation.
+ X.511 Directory Access Protocol (DAP) [X.511] provides an Abandon
+ operation which does have a response and also requires the abandoned
+ operation to return a response indicating it was canceled. The Cancel
+ operation is modeled after the DAP Abandon operation.
The Cancel operation SHOULD be used instead of the LDAP Abandon
operation when the client needs an indication of the outcome. This
operations.
-4. Cancel Operation
+2. Cancel Operation
- The Cancel operation is defined as a LDAPv3 Extended Operation
- [RFC2251, Section 4.12] identified by the OBJECT IDENTIFIER cancelOID.
- This section details the syntax of the Cancel request and response
- messages and defines additional LDAP resultCodes.
-
- cancelOID OBJECT IDENTIFIER ::= IANA-ASSIGNED
+ The Cancel operation is defined as a LDAP Extended Operation [RFC2251,
+ Section 4.12] identified by the IANA-ASSIGNED-OID. This section
+ details the syntax of the Cancel request and response messages and
+ defines additional LDAP resultCodes.
cancelRequestValue ::= SEQUENCE {
cancelID MessageID
}
-4.1. Cancel Request
+2.1. Cancel Request
The Cancel request is an ExtendedRequest with the requestName field
+ containing the IANA-0IGNED-OID and a requestValue field which contains
Zeilenga LDAP Cancel [Page 2]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-cancel-05 17 May 2002
+INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
- containing cancelOID OID and a requestValue field which contains a
- cancelRequestValue value encoded per [RFC2251, Section 5.1]. The
- cancelID field contains the message id associated with the operation
- to be canceled.
+ a BER-encoded cancelRequestValue value. The cancelID field contains
+ the message id associated with the operation to be canceled.
-4.2. Cancel Response
+2.2. Cancel Response
A Cancel response is an ExtendedResponse where the responseName and
response fields are absent.
-4.3. Additional Result Codes
+2.3. Additional Result Codes
Implementations of this specification SHALL recognize the following
additional resultCode values:
cannotCancel (IANA-ASSIGNED-4)
-5. Operational Semantics
+3. Operational Semantics
The function of the Cancel Operation is to request that the server
cancel an outstanding operation issued within the same session.
a distinct message id. Clients SHOULD NOT request cancelation of an
operation multiple times.
- If the server is unable to parse the requestValue or the requestValue
- is absent, the server shall return protocolError.
-
If the server is willing and able to cancel the outstanding operation
identified by the cancelId, the server SHALL return a Cancel Response
with a success resultCode and the canceled operation SHALL fail with
non-success resultCode and SHALL NOT have impact upon the outstanding
operation (if it exists).
- The server SHALL return noSuchOperation if it has no knowledge of the
- operation requested to be canceled.
+ The protocolError resultCode is returned if the server is unable to
+ parse the requestValue or the requestValue is absent,
- The server SHALL return cannotCancel if the identified operation does
+ The noSuchOperation resultCode is returned if the server has no
+ knowledge of the operation requested to be canceled.
+
+ The cannotCancel resultCode is returned if the identified operation
+ does not support cancelation or the cancel operation could not be
+ performed. The following classes of operations are not cancelable:
Zeilenga LDAP Cancel [Page 3]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-cancel-05 17 May 2002
+INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
- not support cancelation or the cancel operation could not be
- performed. The following classes of operations are not cancelable:
-
- operations which have no response,
- operations which associate or disassociate authentication and/or
- operations which abandon or cancel other operations.
- Specifically, Abandon, Bind, Start TLS [RFC2830], Unbind and Cancel
- operations are not cancelable.
+ Specifically, the Abandon, Bind, Start TLS [RFC2830], Unbind and
+ Cancel operations are not cancelable.
- If the result of the outstanding operation has been determined by the
- server, the outstanding operation SHALL NOT be canceled and the cancel
- operation SHALL result in tooLate.
+ The tooLate resultCode is returned to indicate that it is too late to
+ cancel the outstanding operation. For example, the server may return
+ tooLate for a request to cancel an outstanding modify operation which
+ as already commited updates to the underlying datastore.
Servers SHOULD indicate their support for this extended operation by
- providing cancelOID as a value of the supportedExtension attribute
- type in their root DSE. A server MAY choose to advertise this
- extension only when the client is authorized and/or has established
- the necessary security protections to use this operation. Clients
- SHOULD verify the server implements this extended operation prior to
- attempting the operation by asserting the supportedExtension attribute
- contains a value of cancelOID.
+ providing IANA-ASSIGNED-OID as a value of the supportedExtension
+ attribute type in their root DSE. A server MAY choose to advertise
+ this extension only when the client is authorized to use this
+ operation.
-6. Security Considerations
+4. Security Considerations
This operation is intended to allow a user to cancel operations they
previously issued. No user should be allowed to cancel an operation
- issued by another user (within the same session or not). However, as
- this operation may only be used to cancel within the same session and
- LDAP requires operations to be abandoned upon bind requests, this is a
- non-issue.
+ issued by another user.
Some operations should not be cancelable for security reasons. This
specification disallows cancelation of Bind operation and Start TLS
extended operation so as to avoid adding complexity to authentication,
authorization, and security layer semantics. Designers of future
- extended operations and/or controls SHOULD disallow abandonment and
+ extended operations and/or controls should disallow abandonment and
cancelation when appropriate.
-7. IANA Considerations
+5. IANA Considerations
+
+ Registration of the following values [RFC3383] is requested.
+
+5.1. Object Identifier
+
+ It is requested that IANA register upon Standards Action an LDAP
+ Object Identifier to identify the LDAP Cancel Extended Operation as
+ defined in this document.
Zeilenga LDAP Cancel [Page 4]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-cancel-05 17 May 2002
-
+INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
-7.1. Object Identifiers
- It is requested that IANA register a Directory Number OID for use in
- this document upon Standards Action by the IESG. This OID will be
- used to identify the LDAP Cancel extended operation as indicated
- above. The following registration template is suggested:
+ The following registration template is suggested:
- Subject: Request for LDAP OID Registration
+ Subject: Request for LDAP Object Identifier Registration
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
- Specification: RFCXXX
+ Specification: RFCXXXX
Author/Change Controller: IESG
+ Comments:
+ Identifies the LDAP Cancel Extended Operation
-7.2. LDAP Result Codes
+5.2. LDAP Protocol Mechanism
- It is requested that IANA register the LDAP result codes:
+ It is requested that IANA register upon Standards Action the LDAP
+ Protocol Mechanism described in this document.
+
+ Subject: Request for LDAP Protocol Mechansism Registration
+ Object Identifier: IANA-ASSIGNED-OID
+ Description: LDAP Cancel Extended Operation
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@openldap.org>
+ Usage: Extended Operation
+ Specification: RFCXXXX
+ Author/Change Controller: IESG
+ Comments: none
+ in 2
- canceled (IANA-ASSIGNED-1)
- noSuchOperation (IANA-ASSIGNED-2)
- tooLate (IANA-ASSIGNED-3)
- cannotCancel (IANA-ASSIGNED-4)
- upon Standards Action by the IESG. The following registration
- template is suggested:
+5.3. LDAP Result Codes
+
+ It is requested that IANA register upon Standards Action the LDAP
+ Result Codes described in this document.
Subject: LDAP Result Code Registration
Person & email address to contact for further information:
Comments: request four consecutive result codes be assigned
-8. Acknowledgment
+6. Acknowledgment
- This document is based upon input from the IETF LDAPext working group.
+ The LDAP Cancel operation is modeled after the X.511 DAP Abandon
-9. Normative References
- [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+Zeilenga LDAP Cancel [Page 5]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
+ operation.
-Zeilenga LDAP Cancel [Page 5]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-cancel-05 17 May 2002
+7. 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, T. Howes, S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
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.
+
[X.680] ITU-T, "Abstract Syntax Notation One (ASN.1) - Specification
of Basic Notation", X.680, 1994.
Canonical, and Distinguished Encoding Rules", X.690, 1994.
-9. Informative References
+8. Informative References
- [X.511] ITU-T Rec. X.511, "The Directory: Abstract Service
- Definition", 1993.
+ [RFC3383] K. Zeilenga, "IANA Considerations for LDAP", RFC 3383,
+ September 2002.
+ [X.511] ITU-T, "The Directory: Abstract Service Definition", X.511,
+ 1993.
-11. Author's Address
+
+9. Author's Address
Kurt D. Zeilenga
OpenLDAP Foundation
<Kurt@OpenLDAP.org>
-Copyright 2002, The Internet Society. All Rights Reserved.
+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
+
+
+
+Zeilenga LDAP Cancel [Page 6]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
+
+
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
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,
-
-
-
-Zeilenga LDAP Cancel [Page 6]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-cancel-05 17 May 2002
-
-
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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
INTERNET-DRAFT Editor: Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 17 May 2002
+Expires in six months 18 August 2002
Collective Attributes in LDAP
- <draft-zeilenga-ldap-collective-07.txt>
+ <draft-zeilenga-ldap-collective-08.txt>
Status of this Memo
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 <ietf-ldapext@netscape.com>. Please send editorial
- comments directly to the author <Kurt@OpenLDAP.org>.
+ 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
-Zeilenga draft-zeilenga-ldap-collective-07 [Page 1]
+Zeilenga draft-zeilenga-ldap-collective-08 [Page 1]
\f
-INTERNET-DRAFT LDAP Collective Attributes 17 May 2002
+INTERNET-DRAFT LDAP Collective Attributes 18 August 2002
Conventions
-Zeilenga draft-zeilenga-ldap-collective-07 [Page 2]
+Zeilenga draft-zeilenga-ldap-collective-08 [Page 2]
\f
-INTERNET-DRAFT LDAP Collective Attributes 17 May 2002
+INTERNET-DRAFT LDAP Collective Attributes 18 August 2002
2. System Schema for Collective Attributes
-Zeilenga draft-zeilenga-ldap-collective-07 [Page 3]
+Zeilenga draft-zeilenga-ldap-collective-08 [Page 3]
\f
-INTERNET-DRAFT LDAP Collective Attributes 17 May 2002
+INTERNET-DRAFT LDAP Collective Attributes 18 August 2002
The descriptor excludeAllCollectiveAttributes is associated with the
-Zeilenga draft-zeilenga-ldap-collective-07 [Page 4]
+Zeilenga draft-zeilenga-ldap-collective-08 [Page 4]
\f
-INTERNET-DRAFT LDAP Collective Attributes 17 May 2002
+INTERNET-DRAFT LDAP Collective Attributes 18 August 2002
3.2. Collective State or Province Name
-Zeilenga draft-zeilenga-ldap-collective-07 [Page 5]
+Zeilenga draft-zeilenga-ldap-collective-08 [Page 5]
\f
-INTERNET-DRAFT LDAP Collective Attributes 17 May 2002
+INTERNET-DRAFT LDAP Collective Attributes 18 August 2002
collection of entries.
-Zeilenga draft-zeilenga-ldap-collective-07 [Page 6]
+Zeilenga draft-zeilenga-ldap-collective-08 [Page 6]
\f
-INTERNET-DRAFT LDAP Collective Attributes 17 May 2002
+INTERNET-DRAFT LDAP Collective Attributes 18 August 2002
SUP facsimileTelephoneNumber COLLECTIVE )
4. Security Considerations
- Collective attributes are not believed to introduce any additional
- security considerations to LDAP [LDAPTS].
+ Collective attributes, like other attributes, are subject to access
+ control restrictions and other administrative policy. Generally
+ speaking, collective attributes accessed via an entry in a collection
+ are governed by rules restricting access to attributes of that entry.
+ And collective attributes access via a subentry are governed by rules
+ restricting access to attributes of that subentry. However, as LDAP
+ does not have a standard access model, the particulars of each
+ server's access control system may differ.
+
+ General LDAP security considerations [LDAPTS] also apply.
5. IANA Considerations
- It is requested that IANA register the LDAP descriptors used in this
- document per the following registration template:
+ It is requested that IANA register upon Standards Action the LDAP
+ descriptors [LDAPIANA] defined in this technical specification. The
+ following registration template is suggested:
Subject: Request for LDAP Descriptor Registration
- Descriptor (short name): see comment
+ Descriptor see comments
Object Identifier: see comment
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
c-InternationalISDNNumber A 2.5.4.25.1
c-PhysicalDeliveryOffice A 2.5.4.19.1
c-PostOfficeBox A 2.5.4.18.1
+
+
+
+Zeilenga draft-zeilenga-ldap-collective-08 [Page 7]
+\f
+INTERNET-DRAFT LDAP Collective Attributes 18 August 2002
+
+
c-PostalAddress A 2.5.4.16.1
c-PostalCode A 2.5.4.17.1
c-TelephoneNumber A 2.5.4.20.1
c-ou A 2.5.4.11.1
c-st A 2.5.4.8.1
c-street A 2.5.4.9.1
-
-
-
-Zeilenga draft-zeilenga-ldap-collective-07 [Page 7]
-\f
-INTERNET-DRAFT LDAP Collective Attributes 17 May 2002
-
-
collectiveAttributeSubentries A 2.5.18.12
collectiveAttributeSubentry O 2.5.20.2
collectiveExclusions A 2.5.18.7
where Type A is Attribute and Type O is ObjectClass.
- This document uses in this document were assigned by the ISO/IEC Joint
- Technical Committee 1 - Subcommitte 6 to identify elements of X.500
- schema. This document make no OID assignments, it only associates
- LDAP schema descriptions with existing elements of X.500 schema.
+ The Object Identifiers used in this document were assigned by the
+ ISO/IEC Joint Technical Committee 1 - Subcommitte 6 to identify
+ elements of X.500 schema [X.520]. This document make no OID
+ assignments, it only provides LDAP schema descriptions with existing
+ elements of X.500 schema.
6. Acknowledgments
Directory Access Protocol (v3): Attribute Syntax
Definitions", RFC 2252, December 1997.
+
+
+
+Zeilenga draft-zeilenga-ldap-collective-08 [Page 8]
+\f
+INTERNET-DRAFT LDAP Collective Attributes 18 August 2002
+
+
[RFC2256] M. Wahl, "A Summary of the X.500(96) User Schema for use
with LDAPv3", RFC 2256, December 1997.
[SUBENTRY] K. Zeilenga, S. Legg, "Subentries in LDAP",
draft-zeilenga-ldap-subentry-xx.txt, a work in progress.
-
-
-
-Zeilenga draft-zeilenga-ldap-collective-07 [Page 8]
-\f
-INTERNET-DRAFT LDAP Collective Attributes 17 May 2002
-
-
[X.501] "The Directory: Models", ITU-T Recommendation X.501, 1993.
-
-
-
-
-
-
-
-
-
-
-Zeilenga draft-zeilenga-ldap-collective-07 [Page 9]
+Zeilenga draft-zeilenga-ldap-collective-08 [Page 9]
\f
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 17 May 2002
+Expires in six months 26 May 2003
Feature Discovery in LDAP
- <draft-zeilenga-ldap-features-03.txt>
+ <draft-zeilenga-ldap-features-05.txt>
Status of this Memo
revision, submitted to the RFC Editor as an 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 <ietf-ldapext@netscape.com>. Please send editorial
- comments directly to the author <Kurt@OpenLDAP.org>.
+ 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
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
- Copyright 2002, The Internet Society. All Rights Reserved.
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
- Please see the Copyright section near the end of this document for
- more information.
+ Please see the Full Copyright section near the end of this document
+ for more information.
Abstract
-Zeilenga draft-zeilenga-ldap-features-03 [Page 1]
+Zeilenga draft-zeilenga-ldap-features-05 [Page 1]
\f
-INTERNET-DRAFT LDAP supportedFeatures 17 May 2002
+INTERNET-DRAFT LDAP supportedFeatures 26 May 2003
1. Background and Intended Use
- LDAP [RFC2251] is an extensible protocol with numerous elective
- features. LDAP provides mechanisms for a client to discover supported
- protocol versions, controls, extended operations, SASL mechanisms, and
- subschema information. However, these mechanisms are not designed to
- support general feature discovery.
+ The Lightweight Directory Access Protocol (LDAP) [RFC3377] is an
+ extensible protocol with numerous elective features. LDAP provides
+ mechanisms for a client to discover supported protocol versions,
+ controls, extended operations, Simple Authentication and Security
+ Layer (SASL) mechanisms, and subschema information. However, these
+ mechanisms are not designed to support general feature discovery.
This document describes a simple, general-purpose mechanism which
- clients may use to discover the set of features supported by a server.
-
- Schema definitions are provided using LDAPv3 description formats
+ clients may use to discover the set of elective features supported by
+ a server. For example, this mechanism could be used by a client to
+ discover whether or not the server supports requests for all
+ operational attributes, e.g. "+" [OPATTRS]. As another example, this
+ mechanism could be used to discover absolute true, e.g. "(&)" and
+ false, e.g. "(|)", search filters [T-F] support.
+
+ This document extends the LDAP Protocol Mechanism registry [RFC3383]
+ to support registration of values of the supportedFeatures attribute.
+ This registry is managed by the Internet Assigned Numbers Authority
+ (IANA).
+
+ Schema definitions are provided using LDAP description formats
[RFC2252]. Definitions provided here are formatted (line wrapped) for
readability.
2. Discovery of supported features
- Each feature whose support may be discovered SHALL be identified by an
- Object Identifier (OID). A server advertises its support for a given
- feature by providing the OID associated with the feature as a value of
- the supportedFeatures attribute held in the root DSE. A client may
- examine the values of this attribute to determine if a particular
- feature is supported by the server.
+ Each elective feature whose support may be discovered SHALL be
+ identified by an Object Identifier (OID). A server advertises its
+ support for a given feature by providing the OID associated with the
+ feature as a value of the 'supportedFeatures' attribute held in the
+ root DSE. A client may examine the values of this attribute to
+ determine if a particular feature is supported by the server. A
+ client MUST ignore values it doesn't recognize as they refer to
+ elective features it doesn't implement.
+
+ Features associated with Standard Track protocol mechanisms MUST be
+ registered. Features associated with other protocol mechanisms SHOULD
+ be registered. Procedures for registering protocol mechanisms are are
+ described in [RFC3383]. "Feature" should be placed in the usage field
+ of the submitted LDAP Protocol Mechanism template.
+
- The supportedFeatures attribute type is described as follows:
+
+
+Zeilenga draft-zeilenga-ldap-features-05 [Page 2]
+\f
+INTERNET-DRAFT LDAP supportedFeatures 26 May 2003
+
+
+ The 'supportedFeatures' attribute type is described as follows:
( 1.3.6.1.4.1.4203.1.3.5
NAME 'supportedFeatures'
other names.
-3. Security Considerations
+4. Security Considerations
As rogue clients can discover features of a server by other means
(such as by trial and error), this feature discovery mechanism is not
believed to introduce any new security risk to LDAP.
+5. IANA Considerations
-Zeilenga draft-zeilenga-ldap-features-03 [Page 2]
-\f
-INTERNET-DRAFT LDAP supportedFeatures 17 May 2002
+5.1. Registration of Features as Protocol Mechanisms
+ Future specifications detailing LDAP features are to register each
+ feature as a LDAP Protocol Mechanism per guidance given in BCP 64
+ [RFC3383]. A usage of "Feature" in a Protocol Mechanism registration
+ template indicates that the value to be registered is associated with
+ an LDAP feature.
-4. IANA Considerations
- It is requested that IANA register the LDAP 'supportedFeatures'
- descriptor used in this document per the following registration
- template:
+5.2. Registration of the supportedFeatures descriptor
+
+ It is requested that IANA register upon Standards Action the LDAP
+ 'supportedFeatures' descriptor. The following registration template
+ is suggested:
Subject: Request for LDAP Descriptor Registration
Descriptor (short name): supportedFeatures
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Usage: Attribute Type
- Specification: RFCXXXX
+ Specification: RFC XXXX
Author/Change Controller: IESG
-
This OID was assigned [ASSIGN] by OpenLDAP Foundation under its IANA
+
+
+
+Zeilenga draft-zeilenga-ldap-features-05 [Page 3]
+\f
+INTERNET-DRAFT LDAP supportedFeatures 26 May 2003
+
+
assigned private enterprise allocation [PRIVATE] for use in this
specification.
-5. Acknowledgment
+6. Acknowledgment
- This document is based upon input from the IETF LDAPext working group.
+ This document is based upon input from the IETF LDAPEXT working group.
-6. Author's Address
+7. Author's Address
Kurt D. Zeilenga
OpenLDAP Foundation
<Kurt@OpenLDAP.org>
-7. Normative References
+8. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+
+ [RFC2252] Wahl, M., A. Coulbeck, T. Howes, and S. Kille,
+ "Lightweight Directory Access Protocol (v3): Attribute
+ Syntax Definitions", RFC 2252, December 1997.
+
+ [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
+
+ [RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
+ (also RFC 3383), September 2002.
+
- [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+9. Informative References
- [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
- Protocol (v3)", RFC 2251, December 1997.
+ [OPATTRS] Zeilenga, K., "LDAPv3: All Operational Attributes",
+ draft-zeilenga-ldap-opattrs-xx.txt, a work in progress.
- [RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight
- Directory Access Protocol (v3): Attribute Syntax
- Definitions", RFC 2252, December 1997.
+ [T-F] Zeilenga, K., "LDAP True/False Filters",
+ draft-zeilenga-ldap-t-f-xx.txt, a work in progress.
+ [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
+ http://www.openldap.org/foundation/oid-delegate.txt.
-8. Informative References
+ [PRIVATE] IANA, "Private Enterprise Numbers",
+ http://www.iana.org/assignments/enterprise-numbers.
-Zeilenga draft-zeilenga-ldap-features-03 [Page 3]
+
+Zeilenga draft-zeilenga-ldap-features-05 [Page 4]
\f
-INTERNET-DRAFT LDAP supportedFeatures 17 May 2002
+INTERNET-DRAFT LDAP supportedFeatures 26 May 2003
+
+
+Intellectual Property Rights
+
+ The IETF takes no position regarding the validity or scope of any
+ intellectual property 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; neither does it represent that it has made any
+ effort to identify any such rights. Information on the IETF's
+ procedures with respect to rights in standards-track and
+ standards-related documentation can be found in BCP-11. Copies of
+ claims of rights made available for publication 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 implementors or users of this specification can be obtained
+ from the IETF Secretariat.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights which may cover technology that may be required to practice
+ this standard. Please address the information to the IETF Executive
+ Director.
+
Full Copyright
- Copyright 2002, The Internet Society. All Rights Reserved.
+ Copyright (C) The Internet Society (2003). 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
+ or assist in its implmentation 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
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 draft-zeilenga-ldap-features-03 [Page 4]
+Zeilenga draft-zeilenga-ldap-features-05 [Page 5]
\f
--- /dev/null
+
+
+
+
+
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 17 May 2002
+Expires in six months 1 November 2002
LDAPv3: All Operational Attributes
- <draft-zeilenga-ldap-opattrs-03.txt>
+ <draft-zeilenga-ldap-opattrs-05.txt>
Status of this Memo
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 Extensions Working Group
- mailing list <ietf-ldapext@netscape.com>. Please send editorial
- comments directly to the author <Kurt@OpenLDAP.org>.
+ 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
Abstract
The Lightweight Directory Access Protocol (LDAP) supports a mechanism
- for requesting the return of all user attributes but does not all
+ for requesting the return of all user attributes but not all
operational attributes. This document describes an LDAP extension
which clients may use to request the return of all operational
attributes.
Zeilenga LDAP All Op Attrs [Page 1]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-opattrs-03 17 May 2002
+INTERNET-DRAFT draft-zeilenga-ldap-opattrs-05 1 November 2002
1. Overview
to a search operation. This mechanism is often used by clients to
discover which operational attributes are present in an entry.
- This documents extends LDAP [RFC2251] to provide a simple mechanism
- which clients may use to request the return of all operation
- attributes. The mechanism is designed for use with existing general
- purpose LDAP clients (including web browsers which support LDAP URLs)
- and existing LDAP API.
+ This documents extends the Lightweight Directory Access Protocol
+ (LDAP) [RFC3377] to provide a simple mechanism which clients may use
+ to request the return of all operational attributes. The mechanism is
+ designed for use with existing general purpose LDAP clients (including
+ web browsers which support LDAP URLs) and existing LDAP APIs.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
2. All Operational Attributes
The presence of the attribute description "+" (ASCII 43) in the list
- of attributes in a Search Request SHALL signify a request for the
- return of all operational attributes.
+ of attributes in a Search Request [RFC2251] SHALL signify a request
+ for the return of all operational attributes.
As with all search requests, client implementors should note that
results may not include all requested attributes due to access
- controls or other restrictions. Clients implementors should also note
+ controls or other restrictions. Client implementors should also note
that certain operational attributes may be returned only if requested
by name even when "+" is present. This is because some operational
attributes are very expensive to return.
Servers supporting this feature SHOULD publish the Object Identifier
- 1.3.6.1.4.1.4203.1.5.1 as a value of the supportedFeatures [FEATURES]
- attribute in the root DSE.
+ 1.3.6.1.4.1.4203.1.5.1 as a value of the 'supportedFeatures'
+ [FEATURES] attribute in the root DSE.
3. Interoperability Considerations
This mechanism is specifically designed to allow users to request all
operational attributes using existing LDAP clients. In particular,
the mechanism is designed to be compatible with existing general
- purpose LDAP clients includes web browsers which support LDAP URLs
- [RFC2255].
+ purpose LDAP clients including those supporting LDAP URLs [RFC2255].
- The addition of this mechanism to LDAPv3 is believed not to cause any
+ The addition of this mechanism to LDAP is not believed to cause any
significant interoperability issues (this has been confirmed through
- testing). Servers which have yet to implement this specification
+ testing). Servers which have yet to implement this specification
should ignore the "+" as an unrecognized attribute description per
+ [RFC2251, Section 4.5.1]. From the client's perspective, a server
Zeilenga LDAP All Op Attrs [Page 2]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-opattrs-03 17 May 2002
+INTERNET-DRAFT draft-zeilenga-ldap-opattrs-05 1 November 2002
- [RFC2251, Section 4.5.1]. From the client's perspective, a server
which does not return all operational attributes when "+" is requested
should be viewed as having other restrictions.
4. Security Considerations
- This document provides a mechanism which clients may use to discover
- operational attributes. Those relying on security by obscurity SHOULD
- implement appropriate access controls to restricts access to
- operational attributes per local policy.
+ This document provides a general mechanism which clients may use to
+ discover operational attributes. Prior to the introduction of this
+ mechanism, operational attributes where only returned when requested
+ by name. Some might have viewed this as obscurity" feature. However,
+ this sense of security as the attributes were still transferable.
+ Implementations SHOULD implement appropriate access controls
+ mechanisms to restricts access to operational attributes.
-5. IANA Considerations
- No IANA assignments are requested.
+5. IANA Considerations
This document uses the OID 1.3.6.1.4.1.4203.1.5.1 to identify the
feature described above. This OID was assigned [ASSIGN] by OpenLDAP
- Foundation under its IANA assigned private enterprise allocation
- [PRIVATE] for use in this specification.
+ Foundation, under its IANA-assigned private enterprise allocation
+ [PRIVATE], for use in this specification.
+
+ Registration of this feature is requested [FEATURES][RFC3383].
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+
+ Object Identifier: 1.3.6.1.4.1.4203.1.5.1
+
+ Description: All Op Attrs
+
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@openldap.org>
+
+ Usage: Feature
+
+ Specification: RFCxxxx
+
+ Author/Change Controller: IESG
+
+ Comments: none
6. Acknowledgment
+
+
+
+Zeilenga LDAP All Op Attrs [Page 3]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-opattrs-05 1 November 2002
+
+
The "+" mechanism is believed to have been first suggested by Bruce
Greenblatt in a November 1998 post to the IETF LDAPext Working Group
mailing list.
[RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
-
-
-
-Zeilenga LDAP All Op Attrs [Page 3]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-opattrs-03 17 May 2002
-
+ [RFC3377] J. Hodges, R. Morgan, "Lightweight Directory Access Protocol
+ (v3): Technical Specification", RFC 3377, September 2002.
[FEATURES] K. Zeilenga, "Feature Discovery in LDAP", draft-zeilenga-
ldap-features-xx.txt (a work in progress).
[RFC2255] T. Howes and M. Smith, "The LDAP URL Format", RFC 2255,
December 1997.
+ [RFC3383] K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also
+ RFC 3383), September 2002.
+
[X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts,
Models and Service", 1993.
Copyright 2002, The Internet Society. All Rights Reserved.
This document and translations of it may be copied and furnished to
+
+
+
+Zeilenga LDAP All Op Attrs [Page 4]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-opattrs-05 1 November 2002
+
+
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,
-Zeilenga LDAP All Op Attrs [Page 4]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga LDAP All Op Attrs [Page 5]
\f
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
-Date: 17 May 2002 Steven Legg
+Date: 18 August 2002 Steven Legg
Expires in six months Adacel Technologies
Subentries in LDAP
- <draft-zeilenga-ldap-subentry-05.txt>
+ <draft-zeilenga-ldap-subentry-07.txt>
Status of this Memo
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 <ietf-ldapext@netscape.com>. Please send editorial
- comments directly to the author <Kurt@OpenLDAP.org>.
+ 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
-Zeilenga draft-zeilenga-ldap-subentry-05 [Page 1]
+Zeilenga draft-zeilenga-ldap-subentry-07 [Page 1]
\f
-INTERNET-DRAFT Subentries in LDAP 17 May 2002
+INTERNET-DRAFT Subentries in LDAP 18 August 2002
Conventions
-Zeilenga draft-zeilenga-ldap-subentry-05 [Page 2]
+Zeilenga draft-zeilenga-ldap-subentry-07 [Page 2]
\f
-INTERNET-DRAFT Subentries in LDAP 17 May 2002
+INTERNET-DRAFT Subentries in LDAP 18 August 2002
lower boundary, possibly extending to the leaf entries. A subtree
-Zeilenga draft-zeilenga-ldap-subentry-05 [Page 3]
+Zeilenga draft-zeilenga-ldap-subentry-07 [Page 3]
\f
-INTERNET-DRAFT Subentries in LDAP 17 May 2002
+INTERNET-DRAFT Subentries in LDAP 18 August 2002
constraints on the components of SubtreeSpecification.
-Zeilenga draft-zeilenga-ldap-subentry-05 [Page 4]
+Zeilenga draft-zeilenga-ldap-subentry-07 [Page 4]
\f
-INTERNET-DRAFT Subentries in LDAP 17 May 2002
+INTERNET-DRAFT Subentries in LDAP 18 August 2002
Entries that are more than the maximum number of RDN arcs below the
-Zeilenga draft-zeilenga-ldap-subentry-05 [Page 5]
+Zeilenga draft-zeilenga-ldap-subentry-07 [Page 5]
\f
-INTERNET-DRAFT Subentries in LDAP 17 May 2002
+INTERNET-DRAFT Subentries in LDAP 18 August 2002
The administrativeRole operational attribute is also used to regulate
-Zeilenga draft-zeilenga-ldap-subentry-05 [Page 6]
+Zeilenga draft-zeilenga-ldap-subentry-07 [Page 6]
\f
-INTERNET-DRAFT Subentries in LDAP 17 May 2002
+INTERNET-DRAFT Subentries in LDAP 18 August 2002
The controlValue SHALL NOT be absent.
5.1 Descriptors
- It is requested that IANA register the LDAP descriptors used in this
- document per the following registration template:
+ It is requested that IANA register upon Standards Action the LDAP
+ descriptors detailed in this technical specification. The following
+ registration template is suggested:
Subject: Request for LDAP Descriptor Registration
Descriptor (short name): see comment
collectiveAttributeSpecificArea R 2.5.23.5
subentry O 2.5.20.0
subschemaAdminSpecificArea R 2.5.23.4
- subtreeSpecification A 2.5.18.6
-Zeilenga draft-zeilenga-ldap-subentry-05 [Page 7]
+Zeilenga draft-zeilenga-ldap-subentry-07 [Page 7]
\f
-INTERNET-DRAFT Subentries in LDAP 17 May 2002
+INTERNET-DRAFT Subentries in LDAP 18 August 2002
+
+ subtreeSpecification A 2.5.18.6
where Type A is Attribute, Type O is ObjectClass, and Type R is
Administrative Role.
5.2 Object Identifiers
- No IANA assignment of object identifiers is requested.
-
This document uses the OID 1.3.6.1.4.1.4203.1.10.1 to identify an LDAP
protocol element defined herein. This OID was assigned [ASSIGN] by
- OpenLDAP Foundation under its IANA assigned private enterprise
- allocation [PRIVATE] for use in this specification.
+ OpenLDAP Foundation, under its IANA-assigned private enterprise
+ allocation [PRIVATE], for use in this specification.
Other OIDs which appear in this document were either assigned by the
ISO/IEC Joint Technical Committee 1 - Subcommitte 6 to identify
here.
+5.3 Protocol Mechanisms
+
+ Registration of the protocol mechanisms defined in this document is
+ requested [LDAPIANA].
+
+ Subject: Request for LDAP Protocol Mechansism Registration
+
+ Object Identifier: 1.3.6.1.4.1.4203.1.10.1
+
+ Description: Subentries
+
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@openldap.org>
+
+ Usage: Control
+
+ Specification: RFCxxxx
+
+ Author/Change Controller: IESG
+
+ Comments: none
+
+
6. Acknowledgment
This document is based on engineering done by IETF LDUP and LDAPext
document also borrows from a number of ITU documents including X.501.
+
+
+Zeilenga draft-zeilenga-ldap-subentry-07 [Page 8]
+\f
+INTERNET-DRAFT Subentries in LDAP 18 August 2002
+
+
7. Authors' Addresses
Kurt D. Zeilenga
[X.501] ITU-T, "The Directory -- Models," X.501, 1993.
-
-
-
-Zeilenga draft-zeilenga-ldap-subentry-05 [Page 8]
-\f
-INTERNET-DRAFT Subentries in LDAP 17 May 2002
-
-
[X.680] ITU-T, "Abstract Syntax Notation One (ASN.1) -
Specification of Basic Notation", X.680, 1994.
Protocol (v3): Technical Specification",
draft-ietf-ldapbis-ldapv3-ts-xx.txt, a work in progress.
+
+
+Zeilenga draft-zeilenga-ldap-subentry-07 [Page 9]
+\f
+INTERNET-DRAFT Subentries in LDAP 18 August 2002
+
+
[GSER] S. Legg, "Generic String Encoding Rules for ASN.1 Types",
draft-legg-ldapext-gser--xx.txt, a work in progress.
http://www.iana.org/assignments/enterprise-numbers.
-
-
-Zeilenga draft-zeilenga-ldap-subentry-05 [Page 9]
-\f
-INTERNET-DRAFT Subentries in LDAP 17 May 2002
-
-
A. Subtree Specification ABNF
This appendix is non-normative.
In the event that there is a discrepancy between this ABNF and the
encoding determined by [GSER], [GSER] is to be taken as definitive.
- SubtreeSpecification = "{" [ sp base ]
- [ sep sp specificExclusions ]
- [ sep sp minimum ]
- [ sep sp maximum ]
- [ sep sp specificationFilter ]
+ SubtreeSpecification = "{" [ sp ss-base ]
+ [ sep sp ss-specificExclusions ]
+ [ sep sp ss-minimum ]
+ [ sep sp ss-maximum ]
+ [ sep sp ss-specificationFilter ]
sp "}"
- base = id-base msp LocalName
- specificExclusions = id-specificExclusions msp SpecificExclusions
- minimum = id-minimum msp BaseDistance
- maximum = id-maximum msp BaseDistance
- specificationFilter = id-specificationFilter msp Refinement
+ ss-base = id-base msp LocalName
+ ss-specificExclusions = id-specificExclusions msp SpecificExclusions
+
+
+
+Zeilenga draft-zeilenga-ldap-subentry-07 [Page 10]
+\f
+INTERNET-DRAFT Subentries in LDAP 18 August 2002
+
+
+ ss-minimum = id-minimum msp BaseDistance
+ ss-maximum = id-maximum msp BaseDistance
+ ss-specificationFilter = id-specificationFilter msp Refinement
id-base = %x62.61.73.65 ; "base"
id-specificExclusions = %x73.70.65.63.69.66.69.63.45.78.63.6C.75.73
Refinement = item / and / or / not
item = id-item ":" OBJECT-IDENTIFIER
-
-
-
-Zeilenga draft-zeilenga-ldap-subentry-05 [Page 10]
-\f
-INTERNET-DRAFT Subentries in LDAP 17 May 2002
-
-
and = id-and ":" Refinements
or = id-or ":" Refinements
not = id-not ":" Refinement
id-or = %x6F.72 ; "or"
id-not = %x6E.6F.74 ; "not"
- BaseDistance = INTEGER
+ BaseDistance = INTEGER-0-MAX
The <sp>, <msp>, <sep>, <INTEGER>, <OBJECT-IDENTIFIER> and <LocalName>
rules are defined in [GCE].
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
+
+
+
+Zeilenga draft-zeilenga-ldap-subentry-07 [Page 11]
+\f
+INTERNET-DRAFT Subentries in LDAP 18 August 2002
+
+
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,
-Zeilenga draft-zeilenga-ldap-subentry-05 [Page 11]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga draft-zeilenga-ldap-subentry-07 [Page 12]
\f
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 17 May 2002
+Expires in six months 3 May 2003
- LDAP True/False Filters
- <draft-zeilenga-ldap-t-f-02.txt>
+ LDAP Absolute True and False Filters
+ <draft-zeilenga-ldap-t-f-05.txt>
Status of this Memo
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 Extensions Working Group
- mailing list <ietf-ldapext@netscape.com>. Please send editorial
- comments directly to the author <Kurt@OpenLDAP.org>.
+ 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
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
- Copyright 2002, The Internet Society. All Rights Reserved.
+ Copyright 2003, The Internet Society. All Rights Reserved.
Please see the Copyright section near the end of this document for
more information.
-Zeilenga LDAP True/False Filters [Page 1]
+Zeilenga LDAP True & False Filters [Page 1]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-t-f-02.txt 17 May 2002
+INTERNET-DRAFT draft-zeilenga-ldap-t-f-05.txt 3 May 2003
1. Background and Intended Use
True and False assertions. An 'and' filter with zero elements always
evaluates to True. An 'or' filter with zero elements always evaluates
to False. These filters are commonly used when requesting DSA-
- specific Entries (DSEs) which do not necessarily have objectClass
+ specific Entries (DSEs) which do not necessarily have 'objectClass'
attributes. That is, where "(objectClass=*)" may evaluate to False.
While LDAPv2 [RFC1777] placed no restriction on the number of elements
in 'and' and 'or' filter sets, the LDAPv2 string representation
[RFC1960] could not represent empty 'and' and 'or' filter sets. Due
- to this, LDAPv3 [RFC2251] required 'and' and 'or' filter sets to have
- at least one element. Hence, LDAPv3 does not provide absolute True or
- False filters.
+ to this, absolute True or False filters were (unfortunately)
+ eliminated from LDAPv3 [RFC3377].
- This documents extends LDAPv3 [RFC2251] to support absolute True and
- False matches by allowing empty 'and' and 'or' and extends the filter
- string representation [RFC2254] to allow empty filter lists.
+ This documents extends LDAPv3 to support absolute True and False
+ matches by allowing empty 'and' and 'or' in Search filters [RFC2251]
+ and extends the filter string representation [RFC2254] to allow empty
+ filter lists.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
Implementations of this extension SHALL allow 'and' and 'or' choices
with zero filter elements.
- An 'and' Filter consisting of an empty set of filters SHALL evaluate
- to True. This filter is to represented by the string "(&)".
+ An 'and' filter consisting of an empty set of filters SHALL evaluate
+ to True. This filter is represented by the string "(&)".
- An 'or' Filter consisting of an empty set of filters SHALL evaluate to
- False. This filter is to represented by the string "(|)".
+ An 'or' filter consisting of an empty set of filters SHALL evaluate to
+ False. This filter is represented by the string "(|)".
Servers supporting this feature SHOULD publish the Object Identifier
1.3.6.1.4.1.4203.1.5.3 as a value of the supportedFeatures [FEATURES]
3. Security Considerations
- The (re)introduction of absolute True and False filters does not raise
- any new security considerations.
+ The (re)introduction of absolute True and False filters is not
+ believed to raise any new security considerations.
-Zeilenga LDAP True/False Filters [Page 2]
+Zeilenga LDAP True & False Filters [Page 2]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-t-f-02.txt 17 May 2002
+INTERNET-DRAFT draft-zeilenga-ldap-t-f-05.txt 3 May 2003
- Implementors of this (or any) LDAP extension should be familiar with
- general LDAP general security considerations [LDAPTS].
+ Implementors of this (or any) LDAPv3 extension should be familiar with
+ general LDAPv3 security considerations [RFC3377].
4. IANA Considerations
- No IANA assignments are requested.
+ The OID 1.3.6.1.4.1.4203.1.5.3 identifies the feature described above.
+ This OID was assigned [ASSIGN] by OpenLDAP Foundation, under its
+ IANA-assigned private enterprise allocation [PRIVATE], for use in this
+ specification.
- This document uses the OID 1.3.6.1.4.1.4203.1.5.3 to identify the
- feature described above. This OID was assigned [ASSIGN] by OpenLDAP
- Foundation under its IANA assigned private enterprise allocation
- [PRIVATE] for use in this specification.
+ Registration of this feature is requested [FEATURES][RFC3383].
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: 1.3.6.1.4.1.4203.1.5.3
+ Description: T/F Filters
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@openldap.org>
+ Usage: Feature
+ Specification: RFCxxxx
+ Author/Change Controller: IESG
+ Comments: none
5. Author's Address
[RFC2254] T. Howes, "A String Representation of LDAP Search Filters",
RFC 2254, December 1997.
- [LDAPTS] J. Hodges, R. Morgan, "Lightweight Directory Access
- Protocol (v3): Technical Specification",
- draft-ietf-ldapbis-ldapv3-ts-xx.txt (a work in progress).
+ [RFC3377] J. Hodges, R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
[FEATURES] K. Zeilenga, "Feature Discovery in LDAP",
draft-zeilenga-ldap-features-xx.txt (a work in progress).
+
+Zeilenga LDAP True & False Filters [Page 3]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-t-f-05.txt 3 May 2003
+
+
7. Informative References
[RFC1777] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory
[RFC1960] T. Howes, "A String Representation of LDAP Search Filters",
RFC 1960, June 1996.
-
-
-
-Zeilenga LDAP True/False Filters [Page 3]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-t-f-02.txt 17 May 2002
-
+ [RFC3383] K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also
+ RFC 3383), September 2002.
[X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts,
Models and Service", 1993.
http://www.iana.org/assignments/enterprise-numbers.
-
-Copyright 2002, The Internet Society. All Rights Reserved.
+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
-
-
-
-
-
-
-
-
-
-
-Zeilenga LDAP True/False Filters [Page 4]
+Zeilenga LDAP True & False Filters [Page 4]
\f
--- /dev/null
+
+
+
+
+
+
+INTERNET-DRAFT Kurt D. Zeilenga
+Intended Category: Experimental OpenLDAP Foundation
+Expires in six months 3 May 2003
+
+
+ LDAP Transactions
+ <draft-zeilenga-ldap-txn-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 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>.
+
+ 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
+
+ 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
+
+
+
+Zeilenga LDAP Transactions [Page 1]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-txn-06 3 May 2003
+
+
+ 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].
+
+
+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
+ 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.
+
+
+2. Specification of a Transaction
+
+ Servers implementing this specification SHOULD publish the
+ transactionGroupingType as a value of the 'supportedGroupingTypes'
+ attribute contained within the Root DSE.
+
+ transactionGroupingType ::= IANA-ASSIGNED-OID
+
+ 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]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-txn-06 3 May 2003
+
+
+ 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.
+
+ 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 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.
+
+
+3. Settling of the Transaction
+
+ Upon receipt of a request to abort the transaction, the server is to
+ abort the transaction and then return an endGroupingResponse
+ indicating success.
+
+ 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
+
+
+
+Zeilenga LDAP Transactions [Page 3]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-txn-06 3 May 2003
+
+
+ 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.
+
+
+4. Distributed Directory Considerations
+
+ 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
+ are part of a transaction. However, if a server does allow such
+ chaining, it MUST ensure that transaction semantics detailed above 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
+ 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.
+
+ The LDAP/X.500 models do not currently support a multi-master
+ replication architecture and, hence, not considered by this
+ specification.
+
+
+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.
+
+
+6. IANA Considerations
+
+ In accordance with [RFC3383], it is requested that Internet Assigned
+ Numbers Authority (IANA) make the following assignments.
+
+
+
+
+Zeilenga LDAP Transactions [Page 4]
+\f
+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:
+
+ Subject: Request for LDAP Object Identifier Registration
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@OpenLDAP.org>
+ Specification: RFCXXXX
+ Author/Change Controller: IESG
+ Comments:
+ Identifies the LDAP Transactions Grouping Type
+
+
+6.2. LDAP Protocol Mechanism
+
+ Registration of the protocol mechanisms defined in this document is
+ requested.
+
+ Subject: Request for LDAP Protocol Mechansism Registration
+
+ Object Identifier: IANA-ASSIGNED-OID
+ Description: LDAP Transaction Grouping Type
+ 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.
+
+
+8. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+ <Kurt@OpenLDAP.org>
+
+
+9. Normative References
+
+
+
+
+Zeilenga LDAP Transactions [Page 5]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-txn-06 3 May 2003
+
+
+ [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.
+
+ [RFC3377] J. Hodges, R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377, September 2002.
+
+ [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.
+
+ [X.690] ITU-T, "Specification of ASN.1 encoding rules: Basic,
+ Canonical, and Distinguished Encoding Rules", X.690, 1994.
+
+
+10. Informative References
+
+ [ACID] Section 4 of ISO/IEC 10026-1:1992.
+
+ [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.
+
+
+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
+
+
+
+Zeilenga LDAP Transactions [Page 6]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-txn-06 3 May 2003
+
+
+ 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 Transactions [Page 7]
+\f
--- /dev/null
+
+
+
+
+
+
+INTERNET-DRAFT Kurt D. Zeilenga
+Intended Category: Standard Track OpenLDAP Foundation
+Expires in six months 11 May 2003
+
+
+ The LDAP entryUUID operational attribute
+ <draft-zeilenga-ldap-uuid-00.txt>
+
+
+Status of this 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 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 (C) The Internet Society (2003). All Rights Reserved.
+
+ Please see the Full Copyright section near the end of this document
+ for more information.
+
+
+Abstract
+
+ This document describes the LDAP/X.500 'entryUUID' operational
+ attribute and associated matching rules and syntax. The attribute
+ holds a server-assigned Universally Unique Identifier (UUID) for the
+ object. Directory clients may use this attribute to distinguish
+ objects identified by a distinguished name or to locate an object
+ after renaming.
+
+
+
+Zeilenga draft-zeilenga-ldap-uuid-00 [Page 1]
+\f
+INTERNET-DRAFT LDAP entryUUID 11 May 2003
+
+
+1. Background and Intended Use
+
+ In X.500 Directory Services [X.501], such as those accessible using
+ the the Lightweight Directory Access Protocol (LDAP) [RFC3377], an
+ object is identified by its distinguished name (DN). However, DNs are
+ not stable identifiers. That is, a new object may be identified by a
+ DN which previously identified another (now renamed or deleted)
+ object.
+
+ This document describes the 'entryUUID' operational attribute holds
+ the Universally Unique Identifier (UUID) [ISO11578] assigned to the
+ object by the server. Clients may use this attribute to distinguish
+ objects identified by a distinguished name or to locate an object
+ after renaming.
+
+ This document defines the UUID syntax, the 'uuidMatch' and
+ 'uuidOrderingMatch' matching rules, the 'entryUUID' attribute type.
+
+ 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].
+
+ Schema definitions are provided using LDAP description formats
+ [RFC2252]. Definitions provided here are formatted (line wrapped) for
+ readability.
+
+
+2. UUID Schema Elements
+
+2.1 UUID Syntax
+
+ A Universally Unique Identifier (UUID) [ISO11578] is a 16-octet value
+ which identifies object. The ASN.1 [X.690] type UUID is defined to
+ represent UUIDs.
+
+ UUID ::= OCTET STRING{16} -- constrained to an UUID [ISO 11578]
+
+ In LDAP, values of the UUID are encoded using the string
+ representation described in [ISO11578]. For example,
+ 597ae2f6-16a6-1027-98f4-d28b5365dc14.
+
+ ( IANA-ASSIGNED-OID.1 DESC 'UUID' )
+
+
+2.2 'uuidMatch' Matching Rule
+
+ The 'uuidMatch' matching rule compares an asserted UUID with a stored
+ UUID for equality. Its semantics are same as octetStringMatch
+
+
+
+Zeilenga draft-zeilenga-ldap-uuid-00 [Page 2]
+\f
+INTERNET-DRAFT LDAP entryUUID 11 May 2003
+
+
+ [X.520][RFC2252].
+
+ ( IANA-ASSIGNED-OID.2 NAME 'uuidMatch'
+ SYNTAX IANA-ASSIGNED-OID.1 )
+
+
+2.3 'uuidOrderingMatch' Matching Rule
+
+ The 'uuidOrderingMatch' matching rule compares an asserted UUID
+ with a stored UUID for ordering. Its semantics are the same as
+ octetStringOrderingMatch [X.520][RFC2252].
+
+ ( IANA-ASSIGNED-OID.3 NAME 'uuidMatch'
+ SYNTAX IANA-ASSIGNED-OID.1 )
+
+
+2.4. 'entryUUID' attribute
+
+ The 'entryUUID' operational attribute provides the Universally Unique
+ Identifier (UUID) [ISO11578] assigned to the entry.
+
+ ( IANA-ASSIGNED-OID.4 NAME 'entryUUID'
+ DESC 'UUID of the entry'
+ EQUALITY uuidMatch
+ ORDERING uuidOrderingMatch
+ SYNTAX IANA-ASSIGNED-OID.1
+ SINGLE-VALUE
+ NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+ Servers SHALL assign a UUID to each entry upon its addition to the
+ directory and provide the entry's UUID as the value of the
+ 'entryUUID' operational attribute. An entry's UUID is immutable.
+
+
+3. Security Considerations
+
+ Servers should ensure that components of UUID values are publicly
+ disclosable.
+
+ General LDAP security considerations [RFC3377] apply.
+
+
+4. IANA Considerations
+
+4.1. Object Identifier Registration
+
+ It is requested that IANA register upon Standards Action an LDAP
+
+
+
+Zeilenga draft-zeilenga-ldap-uuid-00 [Page 3]
+\f
+INTERNET-DRAFT LDAP entryUUID 11 May 2003
+
+
+ Object Identifier for use in this technical specification.
+
+ Subject: Request for LDAP OID Registration
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@OpenLDAP.org>
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+ Comments:
+ Identifies the UUID schema elements
+
+
+4.2. Registration of the uuidMatch descriptor
+
+ It is requested that IANA register upon Standards Action the LDAP
+ 'uuidMatch' descriptor.
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): uuidMatch
+ Object Identifier: IANA-ASSIGNED-OID.2
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@OpenLDAP.org>
+ Usage: Matching Rule
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+
+
+4.3. Registration of the uuidOrderingMatch descriptor
+
+ It is requested that IANA register upon Standards Action the LDAP
+ 'uuidOrderingMatch' descriptor.
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): uuidOrderingMatch
+ Object Identifier: IANA-ASSIGNED-OID.3
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@OpenLDAP.org>
+ Usage: Matching Rule
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+
+
+4.4. Registration of the entryUUID descriptor
+
+ It is requested that IANA register upon Standards Action the LDAP
+ 'entryUUID' descriptor.
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): entryUUID
+
+
+
+Zeilenga draft-zeilenga-ldap-uuid-00 [Page 4]
+\f
+INTERNET-DRAFT LDAP entryUUID 11 May 2003
+
+
+ Object Identifier: IANA-ASSIGNED-OID.4
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@OpenLDAP.org>
+ Usage: Attribute Type
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+
+
+5. Acknowledgments
+
+ This document is based upon discussions in the LDAP Update and
+ Duplication Protocols (LDUP) WG.
+
+
+6. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+ <Kurt@OpenLDAP.org>
+
+
+7. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+
+ [RFC2252] Wahl, M., A. Coulbeck, T. Howes, and S. Kille,
+ "Lightweight Directory Access Protocol (v3): Attribute
+ Syntax Definitions", RFC 2252, December 1997.
+
+ [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
+
+ [ISO11578] International Organization for Standardization,
+ "Information technology - Open Systems Interconnection -
+ Remote Procedure Call", ISO/IEC 11578:1996.
+
+ [X.501] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The Directory
+ -- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
+
+ [X.520] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory: Selected Attribute Types", X.520(1993) (also
+ ISO/IEC 9594-6:1994).
+
+ [X.680] International Telecommunication Union -
+
+
+
+Zeilenga draft-zeilenga-ldap-uuid-00 [Page 5]
+\f
+INTERNET-DRAFT LDAP entryUUID 11 May 2003
+
+
+ Telecommunication Standardization Sector, "Abstract
+ Syntax Notation One (ASN.1) - Specification of Basic
+ Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
+
+
+8. Informative References
+
+ [RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
+ (also RFC 3383), September 2002.
+
+ [UUIDinfo] The Open Group, "Universally Unique Identifier" section
+ of "CDE 1.1: Remote Procedure Calls",
+ <http://www.opengroup.org/onlinepubs/9629399/apdxa.htm>,
+ April 1997.
+
+
+
+Intellectual Property Rights
+
+ The IETF takes no position regarding the validity or scope of any
+ intellectual property 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; neither does it represent that it has made any
+ effort to identify any such rights. Information on the IETF's
+ procedures with respect to rights in standards-track and
+ standards-related documentation can be found in BCP-11. Copies of
+ claims of rights made available for publication 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 implementors or users of this specification can be obtained
+ from the IETF Secretariat.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights which may cover technology that may be required to practice
+ this standard. Please address the information to the IETF Executive
+ Director.
+
+
+
+Full Copyright
+
+ Copyright (C) The Internet Society (2003). 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 implmentation may be prepared, copied, published and
+
+
+
+Zeilenga draft-zeilenga-ldap-uuid-00 [Page 6]
+\f
+INTERNET-DRAFT LDAP entryUUID 11 May 2003
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga draft-zeilenga-ldap-uuid-00 [Page 7]
+\f
--- /dev/null
+
+
+
+
+
+
+INTERNET-DRAFT Kurt D. Zeilenga
+ OpenLDAP Foundation
+Expires in six months 1 October 2002
+
+
+
+ LDAP (Alternative) Virtual List View Operation
+ <draft-zeilenga-ldapext-vlv-00.txt>
+
+
+
+1. Status of this Memo
+
+ This document is an Internet-Draft and is in full conformance with all
+ provisions of Section 10 of RFC2026.
+
+ This document is offered to IETF LDAPEXT WG as an alternative to
+ draft-ietf-ldapext-ldapv3-vlv-xx.txt.
+
+ 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 LDAPEXT 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 2002, The Internet Society. All Rights Reserved.
+
+ Please see the Copyright section near the end of this document for
+ more information.
+
+
+
+
+
+
+
+
+Zeilenga LDAP Virtual List View [Page 1]
+\f
+INTERNET-DRAFT draft-zeilenga-ldapext-vlv-00 1 October 2002
+
+
+Abstract
+
+ This document describes an LDAP (Lightweight Directory Access
+ Protocol) Virtual List View (VLV) operation. The operation allows the
+ client to obtain portion (the view) of an ordered set (the list) of
+ entries visible through a virtual window. The client can reissue the
+ operation with different criteria to obtain a different view of the
+ list. Clients may use this operation to page, scroll, or browse
+ directory content.
+
+ The VLV operation is defined as a set of LDAP controls which extend
+ the Search operation. The VLV controls may be used in conjunction
+ with a number of other search controls, such as the Server Side
+ Sorting of Search Results (RFC 2891) control.
+
+
+1. Overview
+
+ A "virtual list" is a graphical user interface (GUI) technique
+ employed where a list containing a large number of entries need to be
+ displayed. A window containing a small number of list entries are
+ visible. This window can be relocated such that another set of list
+ entries are visible. The set of entries visible through the window is
+ the view.
+
+ The Lightweight Directory Access Protocol (LDAP) [RFC3377] Virtual
+ List View (VLV) operation allows a client to obtain the set of entries
+ of an ordered list visible through a window from a server. The set of
+ entries are selected based on search criteria. In absence of a
+ control specifying a particular order, the order is determined by the
+ server. The position and size of the window is determined by
+ parameters of the VLV request control.
+
+ The VLV operation is defined as an extended Search operation. The VLV
+ operation is state-less.
+
+ Appendix A. discusses how a client can use VLV operations to provide a
+ GUI to page, scroll, and browse directory content.
+
+
+1.1. Relationship to other LDAP extensions
+
+ The VLV operation may be used with
+
+ - Duplicate Entry Control [DUPENT],
+ - ManageDsaIT Control [RFC3296],
+ - Matched Values Control [MATCHED],
+ - Server-Side Sorting Control [RFC2891], and
+
+
+
+Zeilenga LDAP Virtual List View [Page 2]
+\f
+INTERNET-DRAFT draft-zeilenga-ldapext-vlv-00 1 October 2002
+
+
+ - Subentries Control [SUBENTRY].
+
+ as described in Section 5. The VLV operation may be used with other
+ LDAP extensions as detailed in other documents.
+
+ This document provides a standardized mechanism for scrolling, paging,
+ and browsing DIT content. It is intended to replace Scrolling View
+ Browsing [SVB] and the the Simple Paged Results Manipulation [RFC2696]
+ control extensions.
+
+
+1.2. Comparison to Scrolling View Browsing
+
+ This document was originally offered as an alternative to the
+ Scrolling View Browsing (SVB) [SVB] approach. While both SVB and VLV
+ are upon a Virtual View List metaphor, they differ in many ways. This
+ section highlights a few of the differences.
+
+ SVB was designed to work in static environments. Small DIT changes
+ between related SVB operations can yield astonishing results. For
+ example, an SVB operation intended to page the view down, may jump
+ over entries or an SVB operation intended to scroll a view up can
+ actually return entries which are below the current view. This is
+ because SVB relies on the ordinal position of entries in the list to
+ be stable.
+
+ VLV addresses this problem by selecting the target entry which the
+ view is centered about by DN. An VLV intended to page down the view,
+ selects the next page based upon the position of a particular entry.
+ Likewise for scrolling. Even where the target entry is modified (and
+ hence now appears next to other entries in the list), the client can,
+ by requesting overlapping entries, determine whether the returned view
+ is adjacent to the previous view or not. Based upon intended result,
+ the client can choose to display this view to the user or request
+ another view centered about other entries in the previous view.
+
+ SVB provides a mechanism allowing selection of the target entry by its
+ offset from the head of the list, but not the tail of the list. VLV
+ provides selection by offsets from the head or the tail.
+
+ SVB provides a "type down" selection mechanism limited to the list
+ primary sort key. VLV provides a "type down" selection mechanism
+ which allows selection by all of the sort keys.
+
+ SVB requires that entries be sorted using the Server-Side Sorting
+ Control [RFC2891]. VLV only requires that the list be ordered by a
+ deterministic algorithm. VLV allows, but does not require, a
+ particular ordering algorithm to be requested.
+
+
+
+Zeilenga LDAP Virtual List View [Page 3]
+\f
+INTERNET-DRAFT draft-zeilenga-ldapext-vlv-00 1 October 2002
+
+
+1.3. Terminology and Conventions
+
+ The term "list" (of entries) refers to an ordered set of entries by a
+ deterministic algorithm. The list may contain both returnable and
+ non-returnable entries.
+
+ The term "returnable entry" refers to an entry which the server is
+ willing and able to return. A "non-returnable entry" refers to an
+ entry which the server is unwilling or unable to return.
+
+ The term "target" refers to the entry used to position the window.
+
+ The term "view" refers to the portion of a list of entries visible
+ through a window.
+
+ The term "window" refers to the criteria for selecting the portion of
+ the list to be viewed.
+
+ 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].
+
+
+2. Protocol Elements
+
+ 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] per Section 5.1 of [RFC2251].
+
+
+2.1. VLV Request Control
+
+ The VLV Request Control is an LDAPControl [RFC2251] whose controlType
+ is the "IANA-ASSIGNED-OID.1", criticality is True or False (the
+ DEFAULT), and the controlValue, an OCTET STRING, contains a
+ BER-encoded value of the vlvRequestValue data type:
+
+ target ::= SEQUENCE {
+ tSelect CHOICE {
+ tName [0] LDAPDN,
+ tFraction [1] SEQUENCE {
+ tNumerator INTEGER,
+ -- constrained to (0..tDenominator))
+ tDenominator INTEGER (1..maxint)
+ },
+ tOffset [2] INTEGER (0..maxint),
+ tTypeDown [3] SEQUENCE OF AssertionValue
+ -- contains at least one AssertionValue
+
+
+
+Zeilenga LDAP Virtual List View [Page 4]
+\f
+INTERNET-DRAFT draft-zeilenga-ldapext-vlv-00 1 October 2002
+
+
+ ...
+ },
+ tReverse BOOLEAN DEFAULT False
+ -- for tTypeDown, tReverse is constrained to False
+ }
+
+ window ::= SEQUENCE {
+ wOffset INTEGER,
+ wCount INTEGER (0..maxInt)
+ wReverse BOOLEAN DEFAULT False
+ }
+
+ vlvRequestValue ::= SEQUENCE {
+ COMPONENTS OF target
+ COMPONENTS OF window
+ }
+
+ The VLV Request Control is applicable to the SearchRequest message.
+
+
+2.2. VLV Target Response Control
+
+ The VLV Target Response Control is an LDAPControl [RFC2251] whose
+ controlType is the "IANA-ASSIGNED-OID.2", criticality is False (the
+ DEFAULT), and the controlValue is absent.
+
+ The VLV Target Response Control is applicable to the SearchResultEntry
+ message.
+
+
+2.3. VLV Done Response Control
+
+ The VLV Done Response Control is an LDAPControl [RFC2251] whose
+ controlType is the "IANA-ASSIGNED-OID.3", criticality is False (the
+ DEFAULT), and the controlValue is absent.
+
+ The VLV Done Response Control is applicable to the SearchResultDone
+ message.
+
+
+2.4. VLV Result Codes
+
+ Implementations of this specification SHALL recognize the following
+ additional resultCode [RFC2251] values:
+
+ vlvTargetInvalid (IANA-ASSIGNED-1)
+ vlvTargetNotFound (IANA-ASSIGNED-2)
+ vlvWindowInvalid (IANA-ASSIGNED-3)
+
+
+
+Zeilenga LDAP Virtual List View [Page 5]
+\f
+INTERNET-DRAFT draft-zeilenga-ldapext-vlv-00 1 October 2002
+
+
+3. The VLV Operation
+
+ The VLV operation is defined as an extension to the Search operation.
+ The operation is initiated by the client sending a VLV request
+ message, a SearchRequest which includes a VLV Request Control. In
+ response to this request, the server returns zero or more
+ SearchResultEntry messages, one of which may include the VLV Target
+ Control. The operation is completed by the server returning a VLV
+ done response message, a SearchResultDone message which includes VLV
+ Response Done Control.
+
+ No searchResultReference messages are returned in response to a VLV
+ Request. Continuation references are discussed further in Section
+ 4.1.
+
+ In the VLV request message, fields of searchRequest structure specify
+ the list of entries. The searchRequest fields have the same semantics
+ as defined in Section 4.5.1 of [RFC2251]. The fields of the VLV
+ Request Control specify the desired target as well as the window.
+
+
+3.1. Target Selection
+
+ The target may be select from the list by multiple means.
+
+
+3.1.1. Target Selection by DN
+
+ The target tName choice allows selection of the target by
+ distinguished name (DN). If the provided LDAPDN is not a valid string
+ representation [RFC2253] of a DN, vlvTargetInvalid is returned. If
+ the entry named cannot be found, is not in the list, or is not
+ returnable, vlvTargetNotFound is returned.
+
+ When the request is accompanied by a Duplicate Entry control [DUPENT],
+ tReverse=False indicates that first duplicate of the entry in the list
+ is the target and tReverse=True indicates that last duplicate of the
+ entry in the list is the target. If a Duplicate Entry control was not
+ provided, tReverse is ignored.
+
+
+3.1.2. Target Selection by Offset
+
+ The target tOffset choice selects the target based on ordinal position
+ in the list. When tReverse is False (DEFAULT), a tOffset value of N
+ selects the first returnable entry whose ordinal position is greater
+ than N. When tReverse is True, a tOffset value of N selects the last
+ returnable entry in a list of size M whose ordinal position is less
+
+
+
+Zeilenga LDAP Virtual List View [Page 6]
+\f
+INTERNET-DRAFT draft-zeilenga-ldapext-vlv-00 1 October 2002
+
+
+ than or equal to the value M-N. For example, in a list of 100
+ entries:
+
+ <tOffset=0,tReverse=False> selects the first returnable entry;
+
+ <tOffset=0,tReverse=True> selects the first returnable entry;
+
+ <tOffset=10,tReverse=True> selects the first returnable entry
+ whose ordinal position is greater than 10;
+
+ <tOffset=5,tReverse=True> selects the last returnable entry whose
+ ordinal position is less than or equal to 95 (100-5).
+
+ If the value of tOffset is greater than or equal to the size of the
+ list, vlvTargetInvalid is returned. If no entry meets the criteria,
+ vlvTargetNotFound is returned.
+
+
+3.1.2. Target Selection by Fraction
+
+ The target tFraction choice selects the target based on proportional
+ position of entries on the list. The target is the first returnable
+ entry whose ordinal position is closest to quantity 0.5 plus product
+ of the size of the list, less one, and the quotient of the value
+ tNumerator divided by the value of tDenominator. That is, the target
+ is the returnable entry of whose ordinal position in a list of N
+ entries is closest to
+
+ (0.5 + (N - 1) * (tNumerator / tDenominator))).
+
+ Where the two closest returnable entries are equally close, the entry
+ which appears later in the list is targeted.
+
+ For a list of any size:
+
+ <tNumerator=0,tDenominator=1> selects the first returnable entry;
+ and
+ <tNumerator=1,tDenominator=1> selects the last returnable entry;
+
+ For a list of size 100:
+ <tNumerator=1,tDenominator=2> selects the returnable entry closest
+ to 51 (e.g., the returnable entry closest to the middle);
+ <tNumerator=2,tDenominator=3> selects the returnable entry closest
+ to 65.49.
+
+ For a list of size 101:
+ <tNumerator=1,tDenominator=2> selects the returnable entry closest
+ to 50.5 (e.g., the returnable entry closest to the middle);
+
+
+
+Zeilenga LDAP Virtual List View [Page 7]
+\f
+INTERNET-DRAFT draft-zeilenga-ldapext-vlv-00 1 October 2002
+
+
+ <tNumerator=2,tDenominator=3> selects the returnable entry closest
+ to 67.2.
+
+ If the list is empty or contains no returnable entries,
+ vlvTargetNotFound is returned. If tReverse is True, protocolError is
+ returned.
+
+
+3.1.3. Target Selection by Type Down
+
+ The target tTypeDown choice selects the target whose based upon "type
+ down" criteria.
+
+ The first tTypeDown AssertionValue is associated with the first sort
+ key. The second AssertionValue is associated with the second key.
+ And so on.
+
+ If there are more AssertionValues than keys, protocolError is
+ returned. If there are more keys than AssertionValues, only the keys
+ which have associated AssertionValues are used.
+
+ If tReverse is True, protocolError is returned.
+
+ To select the target, the set of returnable entries whose least
+ attribute value for the first key is equal to the first AssertionValue
+ is determined. If the set contains one entry, that entry is the
+ target. If this set is empty, the first returnable greater than the
+ AssertionValue is the target. If none, vlvTargetNotFound is returned.
+ If the set contains multiple entries, additional key and
+ AssertionValue pairs are used in turn as detailed in the next
+ paragraph. If there are no additional pairs, the target is the first
+ entry in the set.
+
+ Using the next key and AssertionValue, a subset of the set (from the
+ preceding step) whose least attribute value for the key is equal to
+ the AssertionValue is determined. If the set contains one entry, that
+ entry is the target. If this subset is empty, first entry in the set
+ greater than the AssertionValue is the target. If none, the first
+ returnable entry entry greater than the first AssertionValue is the
+ target. In none, vlvTargetNotFound is returned. If the set contains
+ multiple entries, then this step is repeated with the next key and
+ AssertionValue pair. If there are no additional pairs, the target is
+ the first entry in the subset.
+
+ For example, consider a list sorted by list sorted first by 'sn', then
+ by 'givenName', and then by 'initials' and a target criteria of
+ <tTypeDown={"James", "J"}>. First, the set of returnable entries
+ whose least value of 'sn' is "James" is determined. Second, assuming
+
+
+
+Zeilenga LDAP Virtual List View [Page 8]
+\f
+INTERNET-DRAFT draft-zeilenga-ldapext-vlv-00 1 October 2002
+
+
+ the set is non-empty, the subset of this set whose least value of
+ 'givenName' is "J" is determined. If the subset is non-empty, the
+ first entry of the subset is the target (as there are no further key /
+ AssertionValue pairs). If this subset is empty then, the target is
+ the first entry in the set which has a 'givenName' greater than "J".
+ If none, then the target is the first entry in the list which contains
+ a 'sn' value greater than 'James'.
+
+
+3.2. View Selection and Return
+
+ If wCount is 0, the view is empty and no entries are returned.
+ Otherwise, the window is positioned relative to the target entry to
+ determine the view.
+
+ The positioning index is the value of wOffset plus the ordinal
+ position of the target entry. If this index is less than 1, the first
+ entry of the list is first entry of the view. If the index is greater
+ than the size of the list, the last entry in the list is the first
+ entry in the view. Otherwise, the entry whose ordinal position in the
+ list is equal to this index is the first entry of the view.
+
+ If the entry at the positioning index is returnable, it is returned
+ first and wCount is reduced by one.
+
+ If wReverse=False, the next wCount returnable entries from the
+ position index towards the tail of the list are in the view and are
+ returned in increase ordinal order.
+
+ If wReverse=True, the next wCount returnable entries from the position
+ index towards the head of the list are in the view and are returned in
+ decreasing ordinal order.
+
+ If the target entry is within view, it is returned with a Virtual
+ Target Response control.
+
+
+3.3. Done Response Message
+
+ The VLV Done Response message is returned on completion of the VLV
+ operation.
+
+
+4. Other considerations
+
+4.1. Continuation References
+
+ As indicated above, no searchResultReference messages are returned in
+
+
+
+Zeilenga LDAP Virtual List View [Page 9]
+\f
+INTERNET-DRAFT draft-zeilenga-ldapext-vlv-00 1 October 2002
+
+
+ response to a VLV Request.
+
+ Where the content contains references to other servers, the server MAY
+ obtain entries from these others in order to fulfill the VLV request.
+ Otherwise, the server SHALL ignore these references.
+
+
+4.2. Changes to content between VLV operations
+
+ While individual entries tend to change infrequently, changes to a
+ list of entries is likely change frequently. For example, if the
+ average entry changes once per (8 hour) work day, a list of 28,800
+ entries will change approximately once per second during the work day.
+
+ The client SHOULD NOT assume the directory content is static.
+
+
+4.3. Changes to content during a VLV operation
+
+ Server implementations which allows directory content to change (due
+ to other operations) during processing of the VLV operation, need to
+ take special care to ensure the operation behaves in a consistent
+ manner.
+
+ During the processing of the VLV operation, an entry is modified in a
+ manner which changes in a manner which affects it position in the
+ list. If only the old position is in the view, the server MUST either
+ return the old entry in the old position or not return the entry. If
+ only the new position is in the view, the server MUST either return
+ new entry in the new position or not return the entry. If both
+ positions are in the view, the server MUST either return the old entry
+ in the old position, the new entry in the new position, or not return
+ the entry.
+
+ If the target entry is modified, then the server MUST select all
+ returned entries based upon the old position of the target entry or
+ select all returned entries based upon the new entry.
+
+
+5. Interaction with Other Controls
+
+ The VLV operation may be used with
+
+ - Duplicate Entry Control [DUPENT],
+ - ManageDsaIT Control [RFC3296],
+ - Matched Values Control [MATCHED],
+ - Server-Side Sorting Control [RFC2891], and
+ - Subentries Control [SUBENTRY].
+
+
+
+Zeilenga LDAP Virtual List View [Page 10]
+\f
+INTERNET-DRAFT draft-zeilenga-ldapext-vlv-00 1 October 2002
+
+
+ as described below. The VLV operation may be used with other LDAP
+ extensions as detailed in other documents.
+
+
+5.1. Server-Side Sorting Control
+
+ VLV operations provide a view into an ordered list. When the Server-
+ Side Sorting Control (SSS) [RFC2891] indicates the particular sorting
+ algorithm to be used to determining the order of entries in the list.
+ Where the sorting algorithm allows for two or more entries to be
+ presented in any order, the server MUST choose the order which these
+ entries appear in the list by a deterministic algorithm.
+
+ That is, if the Sort Control indicates the list is to sorted by their
+ CN values and two or more entries have the same CN value, the server
+ is not free to return the entries in randomly selected order.
+
+
+5.2. Duplicate Entry Control
+
+ It is often desirable to include an entry which has multiple values
+ for the sort key(s) in the list multiple times, once for each value of
+ a sort key. For example, when constructing a list of entries by
+ ordered by common name (CN), it is often desirable for the entry to
+ appear in the list under each CN value. The Duplicate Entry Control
+ provides a mechanism by which the "client requests that the server
+ return separate entries for each value held in the specified
+ attribute(s)" [DUPENT].
+
+ When used with the VLV Operation, the Duplicate Entry Control
+ logically applies to entries before list ordering. That is, each
+ duplicate entry is ordered independently in respect to other entries
+ (duplicates or not) in the list.
+
+ A particular ordering algorithm may be specified by use of a sorting
+ control.
+
+
+5.3. Matched Values Control
+
+ The Matched Values control is "used to return a subset of attribute
+ values from an entry, specifically, only those values that match a
+ "values return" filter" [MATCHED].
+
+ When used with the VLV Operation, the Matched Values control logically
+ applies to entries before list ordering. That is, entries are to
+ ordered based only upon a subset of attribute values selected by the
+ Matched Values control. Other values are eliminated.
+
+
+
+Zeilenga LDAP Virtual List View [Page 11]
+\f
+INTERNET-DRAFT draft-zeilenga-ldapext-vlv-00 1 October 2002
+
+
+ Matched Values control SHOULD precede other controls are specified
+ which affect the number and ordering entries in the list.
+
+
+5.4. ManageDsaIT control
+
+ As when used with other operations, the ManageDsaIT control [RFC3296]
+ causes referral and other special objects to be treated as normal
+ objects with respect to the VLV Operation and other controls. That
+ is, the referral and other special objects appear in the list if they
+ were normal objects.
+
+
+5.5. Subentries control
+
+ The Subentries control is used with the search operation "to control
+ the visibility of entries and subentries which are within scope"
+ [SUBENTRY]. When used with the VLV Operation, the subentries control
+ and other factors (search scope, filter, etc.) is used to determining
+ whether an entry or subentry in the list is returnable or not.
+
+
+6. Security Considerations
+
+ Significant resources (CPU, memory, etc.) may be required at the
+ server to process a VLV Operation, especially where the VLV Operation
+ has been extended by Server-Side Sorting, Duplicate Entry, and other
+ controls. Servers SHOULD provide administrative controls to limit the
+ rate and/or kinds of VLV operations which can be submitted by
+ authorized users.
+
+ A single VLV operation does not directly disclose the size of the
+ list. However, by issuing multiple VLV operations, an authorized
+ client can determine the size of the list.
+
+
+7. IANA Considerations
+
+ Registration of the following values is requested [RFC3383].
+
+
+7.1. Object Identifiers
+
+ It is requested that IANA register upon Standards Action an LDAP
+ Object Identifier in identifying the protocol elements defined in this
+ technical specification. The following registration template is
+ suggested:
+
+
+
+
+Zeilenga LDAP Virtual List View [Page 12]
+\f
+INTERNET-DRAFT draft-zeilenga-ldapext-vlv-00 1 October 2002
+
+
+ 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:
+ Three delegations will be made under the assigned OID:
+
+ IANA-ASSIGNED-OID.1 VLV Request Control
+ IANA-ASSIGNED-OID.2 VLV Target Response Control
+ IANA-ASSIGNED-OID.3 VLV Done Response Control
+
+
+7.2. 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 Mechanism Registration
+ Object Identifier: IANA-ASSIGNED-OID.1
+ Description: VLV Request Control
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@openldap.org>
+ Usage: Control
+ Specification: RFCxxxx
+ Author/Change Controller: IESG
+ Comments: none
+ in 2
+
+
+7.3. LDAP Result Codes
+
+ It is requested that IANA register upon Standards Action the LDAP
+ result codes:
+
+ vlvTargetInvalid (IANA-ASSIGNED-1)
+ vlvTargetNotFound (IANA-ASSIGNED-2)
+ vlvWindowInvalid (IANA-ASSIGNED-3)
+
+ The following registration template is suggested:
+
+ Subject: LDAP Result Code Registration
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@OpenLDAP.org>
+ Result Code Name: vlvTargetInvalid
+ Result Code Name: vlvTargetNotFound
+ Result Code Name: vlvWindowInvalid
+
+
+
+Zeilenga LDAP Virtual List View [Page 13]
+\f
+INTERNET-DRAFT draft-zeilenga-ldapext-vlv-00 1 October 2002
+
+
+ Specification: RFCXXXX
+ Author/Change Controller: IESG
+ Comments: request consecutive result codes be assigned
+
+
+8. 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, T. Howes, S. Kille, "Lightweight Directory Access
+ Protocol (v3)", RFC 2251, December 1997.
+
+ [RFC2253] M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access
+ Protocol (v3): UTF-8 String Representation of Distinguished
+ Names", RFC 2253, December 1997.
+
+ [RFC2830] J. Hodges, R. Morgan, and M. Wahl, "Lightweight Directory
+ Access Protocol (v3): Extension for Transport Layer
+ Security", RFC 2830, May 2000.
+
+ [RFC2891] T. Howes, M. Wahl, A. Anantha, "LDAP Control Extension for
+ Server Side Sorting of Search Results", RFC 2891, August
+ 2000
+
+ [RFC3296] K. Zeilenga, "Named Subordinate References in Lightweight
+ Directory Access Protocol (LDAP) Directories", RFC 3296,
+ July 2002.
+
+ [RFC3377] J. Hodges, R. Morgan, "Lightweight Directory Access Protocol
+ (v3): Technical Specification", RFC 3377, September 2002.
+
+ [DUPENT] J. Sermersheim. "LDAP Control for a Duplicate Entry
+ Representation of Search Results",
+ draft-ietf-ldapext-ldapv3-dupent-xx.txt (a work in
+ progress).
+
+ [MATCHED] D. Chadwick, "Returning Matched Values with LDAPv3",
+ draft-ietf-ldapext-matchedval-xx.txt (a work in progress).
+
+ [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.
+
+
+9. Informative References
+
+
+
+Zeilenga LDAP Virtual List View [Page 14]
+\f
+INTERNET-DRAFT draft-zeilenga-ldapext-vlv-00 1 October 2002
+
+
+ [RFC3383] K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also
+ RFC 3383), September 2002.
+
+ [SVB] D. Bozeman, J. Sermersheim, A. Kashi, "LDAP Extensions for
+ Scrolling View Browsing of Search Results", draft-ietf-
+ ldapext-ldapv3-vlv-08.txt (a work in progress).
+
+
+10. Acknowledgment
+
+ This work benefited from prior work in this area, especially the
+ paging and scrolling work done in IETF ASID and LDAPEXT working
+ groups.
+
+ This borrows significantly (both concepts and text) from the "LDAP
+ Extensions for Scrolling View Browsing of Search Results" [SVB]
+ Internet-Draft written by Dave Boreham, Jim Sermersheim, and Asaf
+ Kashi.
+
+
+11. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+ <Kurt@OpenLDAP.org>
+
+Appendix A. Using the VLV Operation
+
+ This informative appendix discusses how the VLV operation can be used
+ to page, scroll, and browse directory content.
+
+ For the purposes of this discussion, let's assume we want to implement
+ an address book application which allows the user to page, scroll, and
+ browse address information held in an LDAP-accessible directory system
+ using inetOrgPerson [RFC2798] schema.
+
+ Say this application has a widget which is capable of displaying 10
+ rows of information. In each row, we'll display the values of
+ 'displayName' and 'mail' attributes of an entry.
+
+ Aside from the usual search parameters (baseObject, scope, filter), we
+ likely also want to sort the entries. So, initially, we'll provide a
+ sort control which requests values be sorted by displayName.
+
+A.1. Widget Initialization
+
+ There are multiple VLV operations which might be used to initialize
+ the widget. To initialize the widget with the first 10 entries of the
+
+
+
+Zeilenga LDAP Virtual List View [Page 15]
+\f
+INTERNET-DRAFT draft-zeilenga-ldapext-vlv-00 1 October 2002
+
+
+ list, the VLV request <tOffset=0, tReverse=False, wOffset=0,
+ wCount=10, wReverse=False> can be used. To initialize the widget with
+ the middle 10 entries, the VLV request <tNumerator=1, tDenominator=2,
+ tReverse=False, wOffset=-5, wCount=10, wReverse=False> can be used.
+ To initialize the widget to the last 10 entries, the VLV request
+ <tNumerator=1, tDenominator=1, tReverse=False, wOffset=-9, wCount=10,
+ wReverse=False> can be used.
+
+ However, as the last 10 entries of in the list may not be returnable,
+ it may be more appropriate to request <tNumerator=1, tDenominator=1,
+ tReverse=False, wOffset=0, wCount=10, wReverse=True> instead. Note
+ that since wReverse is selected, the last entry is returned first.
+
+ The widget can also be initialized to the entries surrounding a known
+ DN by sending the request <tName="cn=kdz,dc=example,dc=com",
+ tReverse=False, wOffset=-5, wCount=10, wReverse=False>.
+
+ The widget can also be initialized based upon "typedown" criteria.
+ Typedown is discussed in A.4.
+
+
+A.2. Slider navigation
+
+ Most list widgets allow based upon proportional positioning of a
+ slider. Our widget reports the slider's position as the percentage
+ the area above the slider position to the total slider area. When it
+ is repositioned, the application can request <tNumerator=percent,
+ tDenominator=100, tReverse=False, wOffset=-5, wCount=10,
+ wReverse=False> when percent is less than or equal to 50 and
+ <tNumerator=percent, tDenominator=100, tReverse=False, wOffset=5,
+ wCount=10, wReverse=True> when percent is less than or equal to 50.
+ Because the list may contain non-returnable entries, we reverse the
+ window as we approach the tail of the list. When wReverse is True,
+ the last entry is returned first.
+
+
+A.3. Page navigation
+
+ Most list widgets provide page up/down controls.
+
+ When page down is selected, the application can request <tName=last,
+ tReverse=False, wOffset=0, wCount=10, wReverse=False> where last is
+ the name of the entry presently at the bottom of the current widget
+ view. The server will then return a new view in forward order. When
+ inserted into the widget, the target will appear at the top of the
+ current widget view.
+
+ When page up is selected, the application can request <tName=first,
+
+
+
+Zeilenga LDAP Virtual List View [Page 16]
+\f
+INTERNET-DRAFT draft-zeilenga-ldapext-vlv-00 1 October 2002
+
+
+ tReverse=False, wOffset=0, wCount=10, wReverse=Reverse> where first is
+ the name of the entry presently at the top of the current view. The
+ server will then return a new view in reverse order with the named
+ entry returned first. When inserted into the widget, the target will
+ appear at the bottom the current widget view.
+
+ If the page up/down VLV operation returns vlvTargetNotFound, the
+ application can reissue the page up/down VLV operation with the name
+ of the entry nearest the top/bottom of the present widget view.
+
+ It is noted that when named entry is modified prior to issuing of the
+ VLV operation in a manner which affects its position in the list, the
+ view will follow the named entry.
+
+
+A.4. Type down navigation
+
+ Type down navigation can be used to navigate the list.
+
+ The list is sorted by 'displayName'. When the user types in a partial
+ or complete value, the application can use this value to present the
+ 10 values at are below the value.
+
+ So, for example, the user inputs "K", the application can request
+ <tTypeDown="K", tReverse=False, wOffset=0, wCount=10, wReverse>.
+ Desiring further typedown, the user inputs "Kurt" and the application
+ requests <tTypeDown="Kurt", tReverse=False, wOffset=0, wCount=10,
+ wReverse>. Etc.
+
+
+Copyright 2002, 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.
+
+
+
+
+Zeilenga LDAP Virtual List View [Page 17]
+\f
+INTERNET-DRAFT draft-zeilenga-ldapext-vlv-00 1 October 2002
+
+
+ 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 Virtual List View [Page 18]
+\f
--- /dev/null
+
+
+
+
+
+
+INTERNET-DRAFT Kurt D. Zeilenga
+Intended Category: Standard Track OpenLDAP Foundation
+Expires in six months Jonghyuk Choi
+ IBM Corporation
+
+ 5 May 2003
+
+
+
+
+ LDAP Content Synchronization Operation
+ <draft-zeilenga-ldup-sync-02.txt>
+
+
+
+
+1. Status of this Memo
+
+ This document is an Internet-Draft and is in full conformance with all
+ provisions of Section 10 of RFC2026.
+
+ Distribution of this memo is unlimited. Technical discussion of this
+ document will take place on the IETF LDUP Working Group mailing list
+ at <ietf-ldup@imc.org>. Please send editorial comments directly to
+ the document editor at <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.
+
+
+
+
+
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 1]
+\f
+INTERNET-DRAFT draft-zeilenga-ldup-sync-02 5 May 2003
+
+
+Abstract
+
+ This specification describes the LDAP (Lightweight Directory Access
+ Protocol) Content Synchronization operation. The operation allows a
+ client to maintain a shadow copy of a fragment of directory
+ information tree. It supports both polling for changes and listening
+ for changes. The operation is defined as an extension of the LDAP
+ Search operation.
+
+
+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].
+
+
+1. Introduction
+
+ The Lightweight Directory Access Protocol (LDAP) [RFC3377] provides a
+ mechanism, the search operation [RFC2251], to allow a client to
+ request the return of content matching a complex set of assertions and
+ for the server to return this content, subject to access control and
+ other restrictions, to the client. However, short of repeating a
+ search operation each time a new copy needed, LDAP does not provide an
+ effective and efficient mechanism for maintaining synchronized copies
+ of directory content.
+
+ This document defines the LDAP Content Synchronization operation, or
+ Sync operation for short, which allows a client to maintain a
+ synchronized shadow copy of a fragment of a Directory Information Tree
+ (DIT). The Sync operation is defined as a set of controls and other
+ protocol elements which extend the Search operation.
+
+
+1.1. Background
+
+ Over the years, a number of directory synchronization approaches have
+ been suggested. These approaches are inadequate for one or more of
+ the following reasons:
+
+ 1) do not ensure a reasonable level of convergence;
+ 2) fail to detect that convergence cannot be achieved (without
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 2]
+\f
+INTERNET-DRAFT draft-zeilenga-ldup-sync-02 5 May 2003
+
+
+ reload);
+ 3) require pre-arranged synchronization agreements;
+ 4) require the server to maintain synchronization state on a per
+ client basis;
+ 5) require the server to maintain histories of past changes to DIT
+ content and/or meta information; and/or
+ 6) are overly chatty.
+
+ The Sync operation provides eventual convergence of synchronized
+ content when possible and, when not, notification that content reload
+ is required.
+
+ The Sync operation does not require pre-arranged synchronization
+ agreements.
+
+ The Sync operation does not require servers to maintain
+ synchronization state on a per user basis.
+
+ The Sync operation does not require servers to maintain any history of
+ past changes to the DIT or to meta information. While histories
+ (e.g., change logs, tombstones, DIT snapshots) may be used in the
+ implementation of the Sync operation, the operation may be implemented
+ using purely state-based approaches.
+
+ As the Sync operation does not require servers to maintain any
+ histories of past changes, it can be implemented in environments where
+ it is not feasible to maintain such histories. Histories, if
+ available, may be used by the server to reduce the number of messages
+ generated and reduce their size.
+
+ The Sync operation chattiness is reasonably bound.
+
+
+1.2. Intended Usage
+
+ The Sync operation is intended to be used in applications requiring
+ eventual-convergent content synchronization. Upon completion of each
+ synchronization phase of the operation, all information to construct
+ an synchronized shadow copy of the content has been provided to the
+ client or the client has been notified that a complete content reload
+ is necessary. Excepting for transient inconsistencies due to
+ concurrent operation (or other) processing at the server, the shadow
+ copy is an accurate reflection of the content held by the server.
+ Each inconsistency is transient in that it will be corrected during
+ subsequent synchronization requests.
+
+ Possible uses include:
+ - White page service applications may use the Sync operation to
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 3]
+\f
+INTERNET-DRAFT draft-zeilenga-ldup-sync-02 5 May 2003
+
+
+ maintain current shadow copy of a DIT fragment. For example, an
+ mail user agent which use the sync operation to maintain a local
+ copy of an enterprise address book.
+
+ - Meta-information engines may use the Sync operation to maintain a
+ shadow copy of a DIT fragment.
+
+ - Caching proxy services may use the Sync operation to maintain a
+ coherent content cache.
+
+ - Lightweight master-slave replication between heterogeneous
+ directory servers. For example, the Sync operation can be used by
+ a slave server to maintain a shadow copy of a DIT fragment.
+
+ Note: The International Telephone Union (ITU) has defined the X.500
+ Directory Synchronization Protocol [X.525] which may be used for
+ master-slave replication between LDAP servers. Other
+ experimental LDAP replication protocols exist. The Sync
+ operation should be viewed as complementary to these replication
+ protocols.
+
+ This protocol is not intended to be used in applications requiring
+ transactional data consistency.
+
+ As this protocol transfers all visible values of entries upon change
+ instead of change deltas, this protocol is not appropriate for
+ bandwidth-challenged applications or deployments.
+
+
+1.3. Overview
+
+ This section provides an overview of basis ways the Sync operation can
+ be used to maintain a synchronized shadow copy of a DIT fragment.
+
+ - Polling for Changes: refreshOnly mode
+ - Listening for Changes: refreshAndPersist mode
+
+
+1.3.1. Polling for Changes (refreshOnly)
+
+ To obtain its initial shadow copy, the client issues a Sync request: a
+ search request with the Sync Request Control with mode set to
+ refreshOnly. The server, much like it would with a normal search
+ operation, returns (subject to access controls and other restrictions)
+ the content matching the search criteria (baseObject, scope, filter).
+ Additionally, with each entry returned, the server provides a Sync
+ State control indicating state add. This control contains the
+ Universally Unique Identifier (UUID) [UUID] of the entry. Unlike
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 4]
+\f
+INTERNET-DRAFT draft-zeilenga-ldup-sync-02 5 May 2003
+
+
+ Distinguished Names (DNs), which may change over time, an entry's
+ UUIDs are stable. The initial content is followed by a
+ searchResultDone with a Sync Done control. The Sync Done control
+ provides a syncCookie. The syncCookie represents session state.
+
+ To poll for updates to the shadow copy, the client reissues the Sync
+ operation with the syncCookie previously returned. The server, much
+ as it would with a normal search operation, determines which content
+ would be returned as if the operation was a normal search operation.
+ However, using the syncCookie as an indicator of what content the
+ client was sent previously, the server sends copies of entries which
+ have changed with a Sync State control indicating state add. For each
+ unchanged entry, the server sends an empty entry (e.g., no attributes)
+ with a Sync State control indicating state present. The set of
+ updates is followed by a searchResultDone with a Sync Done control.
+
+ If the server can reliably determine which entries in the prior shadow
+ copy are no longer present in the content and the number of such
+ entries is less than or equal to the number of unchanged entries, the
+ server may, instead of returning an empty entry with state present for
+ each present entry, send an empty entry with state delete for each
+ entry which is no longer in the content. Also, the Sync Done control
+ refreshDeletes is set to TRUE to indicate to the client that this
+ method was used. This field is FALSE otherwise.
+
+ The synchronized shadow copy of the DIT fragment is constructed by the
+ client.
+
+ If refreshDeletes is FALSE, the new copy includes all changed entries
+ returned by the reissued Sync operation as well as all unchanged
+ entries identified as being present by the reissued Sync operation,
+ but whose content is provided by the previous Sync operation. The
+ unchanged entries not identified as being present are deleted from the
+ shadow content. They had been either deleted, moved, or otherwise
+ scoped-out from the content.
+
+ If refreshDeletes is TRUE, the new copy includes all changed entries
+ returned by the reissued Sync operation as well as all other entries
+ of the previous copy except those which were identified as having been
+ deleted from the content.
+
+ The client can, at some later time, re-poll for changes to this
+ synchronized shadow copy.
+
+
+1.3.2. Listening for Changes (refreshAndPersist)
+
+ Polling for changes can be expensive in terms of server, client, and
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 5]
+\f
+INTERNET-DRAFT draft-zeilenga-ldup-sync-02 5 May 2003
+
+
+ network resources. The refreshAndPersist mode allows for active
+ updates of changed entries in the content.
+
+ By selecting the refreshAndPersist mode, the client requests the
+ server to send updates of entries that are changed after the the
+ initial refresh content is determined. Instead of sending a
+ searchResultDone message as described above, the server sends a Sync
+ Info message to the client indicating that refresh phase is complete
+ and then enters persist phase. After receipt of this Sync Info
+ message, the client will have a synchronized shadow copy as described
+ above.
+
+ The server may then send change notifications. For entries to be
+ added to the returned content, the server sends a searchResultEntry
+ (with attributes) with a Sync State control indicating state add. For
+ entries to be deleted from the content, the server sends a
+ searchResultEntry containing with no attributes and a Sync State
+ control indicating state delete. To modify entries in the return
+ content, the server sends a searchResultEntry (with attributes) with a
+ Sync State control indicating state modify. Upon modification of an
+ entry, all (modified or unmodified) attributes belonging to the
+ content are sent.
+
+ Note that renaming an entry of the DIT may cause an add state change
+ where the entry is renamed into the content, a delete state change
+ where the entry is renamed out of the content, and a modify state
+ change where the entry remains in the content. Also note that a
+ modification of an entry of the DIT may cause a add, delete, or modify
+ state change to the content.
+
+ Upon receipt of a change notification, the client updates its copy of
+ the content.
+
+ If the server desires to update the syncCookie during the persist
+ stage, it may include the syncCookie any Sync State control or Sync
+ Info message returned.
+
+ The operation persists until canceled [CANCEL] by the client or
+ terminated by the server. A Sync Done control may be attached to
+ searchResultDone message to provide a new syncCookie.
+
+
+2. Elements of the Sync Operation
+
+ The Sync Operation is defined as an extension to the LDAP Search
+ Operation [RFC2251] where the directory user agent (DUA or client)
+ submits a SearchRequest message with a Sync Request control and the
+ directory system agent (DSA or server) responses with zero or more
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 6]
+\f
+INTERNET-DRAFT draft-zeilenga-ldup-sync-02 5 May 2003
+
+
+ SearchResultEntry messages, each with a Sync State control; zero or
+ more SearchResultReference messages, each with a Sync State control;
+ zero or more Sync Intermediate Response messages; and a
+ searchResultDone message with a Sync Done control.
+
+ To allow clients to discover support for this operation, servers
+ implementing this operation SHOULD publish the IANA-ASSIGNED-OID.1 as
+ a value of supportedControl root DSE attribute.
+
+
+2.1 Common ASN.1 elements
+
+2.1.1 syncUUID
+
+ The syncUUID is a notational convenience to indicate that, while the
+ syncUUID type is encoded as an OCTET STRING, its value is restricted
+ to the string representation of an Universally Unique Identifier
+ (UUID) defined in [UUID].
+
+ syncUUID ::= OCTET STRING
+
+
+ 2.1.2 syncCookie
+
+ The syncCookie is a notational convenience to indicate that, while the
+ syncCookie type is encoded as an OCTET STRING, its value is an opaque
+ value containing information about the synchronization session and its
+ state. Generally, the session information would include a hash of the
+ operation parameters which the server requires not be changed; the
+ synchronization state information includes a commit (log) sequence
+ number, a change sequence number, or a time stamp; and a digital
+ signature for detection of tampering.
+
+ syncCookie ::= OCTET STRING
+
+
+2.2 Sync Request Control
+
+ The Sync Request Control is an LDAP Control [RFC2251, Section 4.1.2]
+ where the controlType is the object identifier IANA-ASSIGNED-OID.1 and
+ the controlValue, an OCTET STRING, contains a BER-encoded
+ syncRequestValue. The criticality field is either TRUE or FALSE.
+
+ syncRequestValue ::= SEQUENCE {
+ mode ENUMERATED {
+ -- 0 unused
+ refreshOnly (1),
+ -- 2 reserved
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 7]
+\f
+INTERNET-DRAFT draft-zeilenga-ldup-sync-02 5 May 2003
+
+
+ refreshAndPersist (3)
+ },
+ cookie syncCookie OPTIONAL
+ }
+
+ The Sync Request Control is only applicable to the searchRequest
+ message.
+
+
+2.3 Sync State Control
+
+ The Sync State Control is an LDAP Control [RFC2251, Section 4.1.2]
+ where the controlType is the object identifier IANA-ASSIGNED-OID.2 and
+ the controlValue, an OCTET STRING, contains a BER-encoded
+ syncStateValue. The criticality is FALSE.
+
+ syncStateValue ::= SEQUENCE {
+ state ENUMERATED {
+ present (0),
+ add (1),
+ modify (2),
+ delete (3)
+ },
+ entryUUID syncUUID,
+ cookie syncCookie OPTIONAL
+ }
+
+ The Sync State Control is only applicable to SearchResultEntry and
+ SearchResultReference messages.
+
+
+2.4 Sync Done Control
+
+ The Sync Done Control is an LDAP Control [RFC2251, Section 4.1.2]
+ where the controlType is the object identifier IANA-ASSIGNED-OID.3 and
+ the controlValue contains a BER-encoded syncDoneValue. The
+ criticality is FALSE (and hence absent).
+
+ syncDoneValue ::= SEQUENCE {
+ cookie syncCookie OPTIONAL,
+ refreshDeletes BOOLEAN DEFAULT FALSE,
+ }
+
+ The Sync Done Control is only applicable to SearchResultDone message.
+
+
+2.5 Sync Info Message
+
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 8]
+\f
+INTERNET-DRAFT draft-zeilenga-ldup-sync-02 5 May 2003
+
+
+ The Sync Info Message is an LDAP Intermediate Response Message
+ [LDAPIRM] where responseName is the object identifier
+ IANA-ASSIGNED-OID.4 and responseValue contains a BER-encoded
+ syncInfoValue. The criticality is FALSE (and hence absent).
+
+ syncInfoValue ::= CHOICE {
+ newcookie [0] syncCookie,
+ refreshDone [1] SEQUENCE {
+ cookie syncCookie OPTIONAL,
+ refreshDeletes BOOLEAN DEFAULT FALSE
+ }
+ }
+
+
+2.6 Sync Result Codes
+
+ The following LDAP resultCodes [RFC2251] are defined:
+
+ syncRefreshRequired (IANA-ASSIGNED-CODE-0)
+
+
+3. Content Synchronization
+
+ The Sync Operation is invoked by the client sending a searchRequest
+ message with a Sync Request Control.
+
+ The absence of a cookie indicates a request for initial content while
+ the presence of a cookie indicates a request for content update.
+ Synchronization Sessions are discussed in Section 3.1. Content
+ Determination is discussed in Section 3.2.
+
+ The mode is either refreshOnly or refreshAndPersist. The refreshOnly
+ and refreshAndPersist modes are discussed in Section 3.3 and 3.4,
+ respectively. The refreshOnly mode consists only of a refresh stage,
+ while the refreshAndPersist mode consists of a refresh stage and a
+ subsequent persist stage.
+
+
+3.1. Synchronization Session
+
+ A sequence of Sync Operations where the last cookie returned by a
+ operation is provided by the client in the next operation are said to
+ belong to the same Synchronization Session.
+
+ The client MUST specify the same content controlling parameters (see
+ Section 3.5) in each Search Request of the session. The client SHOULD
+ also issue each Sync request of a session under the same
+ authentication and authorization associations with equivalent
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 9]
+\f
+INTERNET-DRAFT draft-zeilenga-ldup-sync-02 5 May 2003
+
+
+ integrity and confidential protections. If the server does not
+ recognize the request cookie or the request is made under different
+ associations or inequivalent protections, the server SHALL process the
+ request as if no cookie had been provided.
+
+ A Synchronization Session may span multiple LDAP sessions between the
+ client and the server. The client SHOULD issue each Sync request of a
+ session to the same server.
+
+
+3.2. Content Determination
+
+ The content to be provided is determined by parameters of the Search
+ Request, as described in [RFC2251], and possibly other controls. The
+ same content SHOULD be used in each Sync request of a session. If
+ different content is requested and the server is unwilling or unable
+ to process the request, the server SHALL process the request as if no
+ cookie had been provided.
+
+ The content may not necessarily include all entries or references
+ which would be returned by a normal search operation nor, for those
+ entries included, not all attributes returned by a normal search.
+ Where the server is unwilling or unable to provide synchronization for
+ an attribute for a set of entries, the server MUST treat all filter
+ components matching against these attribute as Undefined and MUST NOT
+ return the attribute in searchResultEntry responses.
+
+ Servers SHOULD support synchronization for all non-collective
+ user-applications attributes for all entries.
+
+ The server may also return continuation references to other servers or
+ to itself. The latter is allowed as the server may partition the
+ entries it holds into separate synchronization contexts.
+
+ The client may chase all or some of these continuations, each in a
+ separate LDAP session.
+
+
+3.3. refreshOnly mode
+
+ A Sync request with mode refreshOnly and no cookie is a poll for
+ initial content. A Sync request with mode refreshOnly and cookie is a
+ poll for content update.
+
+
+3.3.1. Initial Content Poll
+
+ Upon receipt of the request, the server provides the initial content
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 10]
+\f
+INTERNET-DRAFT draft-zeilenga-ldup-sync-02 5 May 2003
+
+
+ using a set of zero or more searchResultEntry and
+ searchResultReference messages followed by a searchResultDone message.
+
+ Each searchResultEntry message SHALL include a Sync State control of
+ state add, entryUUID containing the entry's UUID, and no cookie. Each
+ searchResultReference message SHALL include a Sync State control of
+ state add, entryUUID containing the UUID associated with the reference
+ (normally the referral [RFC3296] object's entryUUID), and no cookie.
+ The searchResultDone message SHALL include a Sync Done control. The
+ refreshDeletes SHALL be FALSE.
+
+ A resultCode value of success indicates the operation successfully
+ completed. Otherwise, the result code indicates the nature of
+ failure.
+
+ If the operation is successful, a cookie SHOULD be returned for use in
+ subsequent Sync operations.
+
+
+3.3.2. Content Update Poll
+
+ Upon receipt of the request the server provides the content refresh
+ using a set of zero or more searchResultEntry and
+ searchResultReference messages followed by a searchResultDone message.
+
+ The server is REQUIRED to either:
+ a) provide the sequence of messages necessary for eventual
+ convergence of the client's copy of the content to the server's
+ copy,
+
+ b) treat the request as an initial content request (e.g., ignore
+ the cookie),
+
+ c) indicate that convergence is not possible by returning
+ syncRefreshRequired,
+
+ d) return a resultCode other than success or syncRefreshRequired.
+
+ For each entry or reference added to the content or was changed since
+ the previous Sync operation indicated by the cookie, the server
+ returns a searchResultEntry or searchResultReference message,
+ respectively, each with a Sync State cookie of state add, entryUUID
+ containing the UUID of the entry or reference, and no cookie. Each
+ searchResultEntry message represents the current state of a changed
+ entry. Each SearchResultReference message represents the current
+ state of a changed reference.
+
+ For each entry which has not been changed since the previous Sync
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 11]
+\f
+INTERNET-DRAFT draft-zeilenga-ldup-sync-02 5 May 2003
+
+
+ operation, a searchResultEntry is returned whose objectName reflects
+ the entry's current DN, the attributes field is empty, and a Sync
+ State control of state present, entryUUID containing the UUID of the
+ entry, and no cookie. For each reference which has not been changed
+ since the previous Sync operation, a searchResultReference containing
+ an empty SEQUENCE OF LDAPURL is returned with a Sync State control of
+ state present, entryUUID containing the UUID of the entry, and no
+ cookie. No messages are sent for entries or references which are no
+ longer in content.
+
+ As an alternative to sending messages for each entry and reference
+ which has not been changed, the server may instead return the
+ following. For each entry no longer in content, return a
+ searchResultEntry whose objectName reflects a past DN of the entry or
+ is empty, the attributes field is empty, and a Sync State control of
+ state delete, entryUUID containing the UUID of the deleted entry, and
+ no cookie. For each reference no longer in content, a
+ searchResultReference containing an empty SEQUENCE OF LDAPURL is
+ returned with a a Sync State control of state delete, entryUUID
+ containing the UUID of the deleted reference, and no cookie.
+
+ A resultCode value of success indicates the operation successfully
+ completed. Otherwise, the result code indicates the nature of
+ failure.
+
+ If the operation is successful, a cookie SHOULD be returned for use in
+ subsequent Sync operations.
+
+
+3.4. refreshAndPersist mode
+
+ A Sync request with mode refreshAndPersist asks for initial content or
+ content update (during the refresh stage) followed by change
+ notifications (during the persist stage).
+
+
+3.4.1. refresh stage
+
+ The content refresh is provided as described in Section 3.3 excepting
+ that successful completion of content refresh is indicated by sending
+ a Sync Info with state refreshDone message instead of a
+ SearchResultDone message with resultCode success. A cookie SHOULD be
+ returned for use in subsequent Sync operations.
+
+
+3.4.2. persist stage
+
+ Change notifications are provided during the persist stage.
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 12]
+\f
+INTERNET-DRAFT draft-zeilenga-ldup-sync-02 5 May 2003
+
+
+ As updates are made to the DIT the server notifies the client of
+ changes to the content. DIT updates may cause entries references to
+ be added to the content, deleted from the content, or modify entries
+ in the content. DIT updates may also cause references to be added,
+ deleted, or modified within the content.
+
+ Where DIT updates cause an entry to be added to the content, the
+ server provides a searchResultEntry message which represents the entry
+ as it appears in the content. The message SHALL include a Sync State
+ control with state of add, entryUUID containing the entry's UUID, and
+ an optional cookie.
+
+ Where DIT updates cause a reference to be added to the content, the
+ server provides a searchResultReference message which represents the
+ reference in the content. The message SHALL include a Sync State
+ control with state of add, entryUUID containing the UUID associated
+ with the reference, and an optional cookie.
+
+ Where DIT updates cause an entry to be modified in the content, the
+ server provides a searchResultEntry message which represents the entry
+ as it appears in the content. The message SHALL include a Sync State
+ control with state of modify, entryUUID containing the entry's UUID,
+ and an optional cookie.
+
+ Where DIT updates cause a reference to be modified in the content, the
+ server provides a searchResultEntry message which represents the
+ reference in the content. The message SHALL include a Sync State
+ control with state of modify, entryUUID containing the UUID associated
+ with the reference, and an optional cookie.
+
+ Where DIT updates cause an entry to be deleted from the content, the
+ server provides a searchResultReference message with an empty SEQUENCE
+ OF LDAPURL. The message SHALL include a Sync State control with state
+ of delete, entryUUID containing the UUID associated with the
+ reference, and an optional cookie.
+
+ Where DIT updates cause a reference to be deleted from the content,
+ the server provides a searchResultEntry message with no attributes.
+ The message SHALL include a Sync State control with state of delete,
+ entryUUID containing the entry's UUID, and an optional cookie.
+
+ With each of these messages, the server may provide a new cookie to be
+ used in subsequent Sync operations. Additionally, the server may also
+ return Sync Info messages of choice newCookie to provide a new cookie.
+ The client SHOULD use newest (last) cookie it received from the server
+ in subsequent Sync operations.
+
+
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 13]
+\f
+INTERNET-DRAFT draft-zeilenga-ldup-sync-02 5 May 2003
+
+
+3.5. Search Request Parameters
+
+ As stated in Section 3.1, the client SHOULD specify the same content
+ controlling parameters (see Section 3.5) in each Search Request of the
+ session. All fields of the SearchRequest message are considered
+ content controlling parameters except for sizeLimit and timeLimit.
+
+
+3.5.1. baseObject Issues
+
+ As with the normal search operation, the refresh and persist phases
+ are not isolated from DIT changes. It is possible that the entry
+ referred to be the baseObject be deleted, renamed, or moved. It is
+ also possible that alias object used in finding the entry referred to
+ by the baseObject is changed such that the baseObject refers to a
+ different entry.
+
+ If the DIT is updated during processing of the Sync Operation in a
+ manner that causes the baseObject to no longer refers to any entry or
+ changes which entry the baseObject refers to, the server SHALL return
+ an appropriate non-success result code such as noSuchObject,
+ aliasProblem, aliasDereferencingProblem, referral, or
+ syncRefreshRequired.
+
+
+3.5.2. derefAliases Issues
+
+ This operation does not support alias dereferencing during searching.
+ The client SHALL specify neverDerefAliases or derefFindingBaseObj for
+ the searchRequest derefAliases parameter. The server SHALL treat
+ other values (e.g., derefInSearching, derefAlways) as protocol errors.
+
+
+3.5.3. sizeLimit Issues
+
+ The sizeLimit applies only to entries (regardless of their syncState)
+ returned during refreshOnly processing or the refresh stage of the
+ refreshAndPersist processing.
+
+
+3.5.4. timeLimit Issues
+
+ For a refreshOnly Sync operation, the timeLimit applies to the whole
+ operation. For a refreshAndPersist operation, the timeLimit applies
+ to processing up to and including generating the Sync Info with state
+ refreshDone message.
+
+
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 14]
+\f
+INTERNET-DRAFT draft-zeilenga-ldup-sync-02 5 May 2003
+
+
+3.5.5. filter Issues
+
+ The client SHOULD avoid filter assertions which apply to values of
+ attributes likely to be considered by the server as holding meta-
+ information. See section 4.
+
+
+3.6. objectName Issues
+
+ The Sync operation uses entryUUID values provided in the Sync State
+ control as the primary keys to entries. The client MUST use these
+ entryUUIDs to correlate synchronization messages.
+
+ In some circumstances the DN returned may not reflect the entry's
+ current DN. In particular, when the entry is being deleted from the
+ content, the server MAY provide an empty DN if the server does not
+ wish to disclose the entry's current DN (or, if deleted from the DIT,
+ the entry's last DN).
+
+ It should also be noted that the entry's DN may be viewed as meta
+ information (see section 4.1).
+
+
+3.7. Canceling the Sync Operation
+
+ Servers SHOULD implement the LDAP Cancel [CANCEL] operation and
+ support cancellation of outstanding Sync operations as described here.
+
+ To cancel an outstanding Sync Operation, the client SHOULD issue a
+ Cancel operation [CANCEL]....
+
+
+3.7. Refresh Required
+
+ In order to achieve the eventual-convergent synchronization, the
+ server may terminate the Sync operation in refresh or persist stage by
+ returning a syncRefreshRequired resultCode to the client. The client
+ may then request a full reload (e.g., no cookie) instead of
+ incremental synchronization in order to obtain a new copy of the
+ content. In case that the client issues incremental synchronization
+ requests between the issue of a syncRefreshRequired and that of a full
+ reload, the server should send a syncRefreshRequired response again,
+ but the client may receive one or more searchResultEntry responses
+ before it receives the syncRefreshRequired response.
+
+ The server may also choose to provide a full copy in the refresh stage
+ (e.g., ignore the cookie) instead of providing an incremental refresh
+ in order to achieve the eventual convergence.
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 15]
+\f
+INTERNET-DRAFT draft-zeilenga-ldup-sync-02 5 May 2003
+
+
+ In the case of persist stage Sync, the server returns the resultCode
+ of syncRefreshRequired to the client to indicate that the client needs
+ to issue a full reload operation (e.g., no cookie) in order to obtain
+ a synchronized copy of the content.
+
+ The server may also return syncRefreshRequired if it determines that a
+ refresh would be more efficient than sending all the messages required
+ for convergence.
+
+
+3.8. Chattiness Considerations
+
+ The server MUST ensure that the number of entry messages generated to
+ refresh the client content does not exceed the number of entries
+ presently in the content. While there is no requirement for servers
+ to maintain historical information, if the server has sufficient
+ history to allow it to reliably determine which entries in the prior
+ shadow copy are no longer present in the content and the number of
+ such entries is less than equal the number of unchanged entries, the
+ server SHOULD generate delete entry messages instead of present entry
+ messages (see Section 3.3.2).
+
+ The server SHOULD maintain enough (current or historical) state
+ information (such as a context-wide last modify time stamp), to
+ determine that no changes were made in the context since the content
+ to refresh was provided and, and when no changes were made, generate
+ zero delete entry messages instead of present messages.
+
+ The server implementor should also consider chattiness issues which
+ span multiple Sync operations of a session. As noted in Section 3.7,
+ the server may return syncRefreshRequired if it determines that a
+ refresh would be more efficient than continuing under the current
+ operation.
+
+ The server SHOULD transfer a new cookie frequently to avoid having to
+ transfer information already provided to the client. Even where DIT
+ changes do not cause content synchronization changes to be
+ transferred, it may be advantageous to provide a new cookie using a
+ Sync Info message. However, the server SHOULD avoid overloading the
+ client or network with Sync Info messages.
+
+ During persist mode, the server SHOULD coalesce multiple outstanding
+ messages updating the same entry. The server MAY delay generation of
+ an entry update in anticipation of subsequent changes to that entry
+ which could be coalesced. The length of the delay should be long
+ enough to allow coalescing of update requests issued back to back but
+ short enough that the transient inconsistency induced by the delay is
+ corrected in a timely manner.
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 16]
+\f
+INTERNET-DRAFT draft-zeilenga-ldup-sync-02 5 May 2003
+
+
+4. Meta Information Considerations
+
+4.1. Entry DN
+
+ As an entry's DN is constructed from its relative DN (RDN) and the
+ entry's parent's DN, it is often viewed as meta information.
+
+ While renaming or moving a superior to an entry causes the entry's DN
+ to change, that change SHOULD NOT, by itself, cause synchronization
+ message to be sent for that entry. However, if renaming or moving of
+ a superior could cause the entry to added or deleted from the content
+ and, if so, appropriate synchronization messages should be generated
+ to indicate this to the client.
+
+ Where a server treats the entry's DN as meta information, the server
+ SHALL either
+ - evaluate all MatchingRuleAssertions to TRUE if matching a value
+ of an attribute of the entry and otherwise Undefined, or
+ - evaluate all MatchingRuleAssertion with dnAttributes of TRUE
+ as Undefined.
+
+ The latter choice is offered for ease of server implementation.
+
+
+4.2. Operational Attributes
+
+ Where values of an operational attribute is determined by values not
+ held as part of the entry it appears in, the operational attribute
+ SHOULD NOT support synchronization of that operational attribute.
+
+ For example, in servers which implement X.501 subschema model [X.501],
+ servers should not support synchronization of the subschemaSubentry
+ attribute as its value is determined by values held and administrated
+ in subschema subentries.
+
+ For a counter example, servers which implement aliases
+ [RFC2256][X.501] can support synchronization of the aliasedObjectName
+ attribute as its values are held and administrated as part of the
+ alias entries.
+
+ Servers SHOULD support synchronization of the following operational
+ attributes: createTimestamp, modifyTimestamp, creatorsName,
+ modifiersName [RFC2252]. Servers MAY support synchronization of other
+ operational attributes. Synchronization of operational attributes is
+ discussed in Section 4.1.
+
+
+4.3. Collective Attributes
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 17]
+\f
+INTERNET-DRAFT draft-zeilenga-ldup-sync-02 5 May 2003
+
+
+ A collective attribute is "a user attribute whose values are the same
+ for each member of an entry collection" [X.501]. Use of collective
+ attributes in LDAP is detailed in [COLLECTIVE].
+
+ Modification of a collective attribute generally affects the content
+ of multiple entries, each a member of the collection. It is
+ inefficient to include values of collective attributes visible in
+ entries of the collection, as a single modification of a collective
+ attribute require transmission of multiple SearchResultEntry (one of
+ each entry of the collection which the modification affected) to be
+ transmitted.
+
+ Servers SHOULD NOT synchronize collective attributes appearing in
+ entries of any collection. Servers MAY support synchronization of
+ collective attributes appearing in collective attribute subentries.
+
+
+4.4. Access and other administrative controls
+
+ Entries are commonly subject to access and other administrative
+ controls. While portions of the policy information governing a
+ particular entry may be held in the entry, policy information is often
+ held elsewhere (in superior entries, in subentries, in the root DSE,
+ in configuration files, ...). Because of this, changes to policy
+ information make it difficult to ensure eventual convergence during
+ incremental synchronization.
+
+ Where it is impractical or infeasible to generate content changes
+ resulting from a change to policy information, servers may opt to
+ return syncRefreshRequired or treat the Sync Operation as an initial
+ content request (e.g., ignore the cookie).
+
+
+5. Interaction with other controls
+
+ The Sync Operation may be used with:
+
+ - ManageDsaIT Control [RFC3296]
+ - Subentries Control [SUBENTRY]
+
+ as described below. The Sync operation may be used with other LDAP
+ extensions as detailed in other documents.
+
+
+5.1. ManageDsaIT control
+
+ The ManageDsaIT control [RFC3296] indicates that the operation acts
+ upon the DSA Information Tree and causes referral and other special
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 18]
+\f
+INTERNET-DRAFT draft-zeilenga-ldup-sync-02 5 May 2003
+
+
+ objects to be treated as normal objects with respect to the operation.
+
+
+5.2. Subentries control
+
+ The Subentries control is used with the search operation "to control
+ the visibility of entries and subentries which are within scope"
+ [SUBENTRY]. When used with the Sync Operation, the subentries control
+ and other factors (search scope, filter, etc.) are used to determining
+ whether an entry or subentry appear in the content or not.
+
+
+6. Security Considerations
+
+ In order to maintain a synchronized copy of the content, a client is
+ to delete information from its copy of the content as described above.
+ However, the client may maintain knowledge of information disclosed to
+ it by the server separate from its copy of the content used for
+ synchronization. Management of this knowledge is beyond the scope of
+ this document.
+
+ While the information provided by a series of refreshOnly Sync
+ operations is similar to that provided by a series of Search
+ operations, persist stage may disclose additional information. A
+ client may be able to discern information about the particular
+ sequence of update operations which caused content change.
+
+ Implementors should take precautions against malicious cookie content,
+ including malformed cookies or valid cookies used with different
+ security associations and/or protections in attempt to obtain
+ unauthorized access to information.
+
+ The Sync operation may be the target of denial of service attacks.
+ Implementors should provide safeguards to ensure these mechanisms are
+ not abused. Servers may place access control or other restrictions
+ upon the use of this operation.
+
+ Implementors of this (or any) LDAP extension should be familiar with
+ general LDAP security considerations [RFC3377].
+
+
+7. IANA Considerations
+
+ Registration of the following values is requested.
+
+
+7.1. Object Identifier
+
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 19]
+\f
+INTERNET-DRAFT draft-zeilenga-ldup-sync-02 5 May 2003
+
+
+ It is requested that IANA register upon Standards Action an LDAP
+ Object Identifier to identify elements of the LDAP Content
+ Synchronization Operation as 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: RFCXXXX
+ Author/Change Controller: IESG
+ Comments:
+ Identifies elements of the LDAP Content Synchronization Operation
+
+
+7.2. LDAP Protocol Mechanism
+
+ It is requested that IANA register upon Standards Action the LDAP
+ Protocol Mechanism described in this document.
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: IANA-ASSIGNED-OID
+ Description: LDAP Content Synchronization Control
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@openldap.org>
+ Usage: Control
+ Specification: RFCXXXX
+ Author/Change Controller: IESG
+ Comments: none
+
+
+7.3. LDAP Result Codes
+
+ It is requested that IANA register upon Standards Action the LDAP
+ Result Codes described in this document.
+
+ Subject: LDAP Result Code Registration
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@OpenLDAP.org>
+ Result Code Name: syncRefreshRequired (IANA-ASSIGNED-CODE-0)
+ Specification: RFCXXXX
+ Author/Change Controller: IESG
+ Comments: none
+
+
+8. Acknowledgment
+
+ This work borrows significantly from the LDAP Client Update Protocol
+ [LCUP]. This work also benefited Persistent Search [PSEARCH],
+ Triggered Search [TSEARCH], and Directory Synchronization [DIRSYNC]
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 20]
+\f
+INTERNET-DRAFT draft-zeilenga-ldup-sync-02 5 May 2003
+
+
+ efforts. This work also borrows from "Lightweight Directory Access
+ Protocol (v3)" [RFC2251].
+
+
+9. 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, T. Howes, S. Kille, "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.
+
+ [RFC2256] M. Wahl, "A Summary of the X.500(96) User Schema for use
+ with LDAPv3", RFC 2256, December 1997.
+
+ [RFC2830] J. Hodges, R. Morgan, and M. Wahl, "Lightweight Directory
+ Access Protocol (v3): Extension for Transport Layer
+ Security", RFC 2830, May 2000.
+
+ [RFC3296] K. Zeilenga, "Named Subordinate References in Lightweight
+ Directory Access Protocol (LDAP) Directories", RFC 3296,
+ July 2002.
+
+ [RFC3377] J. Hodges, R.L. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
+
+ [LDAPIRM] R. Harrison, K. Zeilenga, "LDAP Intermediate Response
+ Message", draft-rharrison-ldap-intermediate-resp-xx.txt
+ (a work in progress).
+
+ [SUBENTRY] K. Zeilenga, S. Legg, "Subentries in LDAP",
+ draft-zeilenga-ldap-subentry-xx.txt, a work in progress.
+
+ [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.
+
+ [CANCEL] K. Zeilenga, "LDAP Cancel Extended Operation",
+ draft-zeilenga-ldap-cancel-xx.txt, a work in progress.
+
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 21]
+\f
+INTERNET-DRAFT draft-zeilenga-ldup-sync-02 5 May 2003
+
+
+ [UUID] International Organization for Standardization (ISO),
+ "Information technology - Open Systems Interconnection -
+ Remote Procedure Call", ISO/IEC 11578:1996.
+
+
+10. Informative References
+
+ [RFC3383] K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also
+ RFC 3383), September 2002.
+
+ [X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts,
+ Models and Service", 1993.
+
+ [X.511] ITU, "The Directory: Abstract Service Definition", ITU-T
+ Rec. X.511, 1993.
+
+ [X.525] ITU, "The Directory: Replication", ITU-T Rec. X.525,
+ 1993.
+
+ [COLLECTIVE] K. Zeilenga, "Collective Attributes in LDAP",
+ draft-zeilenga-ldap-collective-xx.txt, a work in
+ progress.
+
+ [DIRSYNC] M. Armijo, "Microsoft LDAP Control for Directory
+ Synchronization", draft-armijo-ldap-dirsync-xx.txt, a
+ work in progress.
+
+ [LCUP] R. Megginson, et. al., "LDAP Client Update Protocol",
+ draft-ietf-ldup-lcup-xx.txt, a work in progress.
+
+ [PSEARCH] M. Smith, et. al., "Persistent Search: A Simple LDAP
+ Change Notification Mechanism",
+ draft-ietf-ldapext-psearch-xx.txt, a work in progress.
+
+ [TSEARCH] M. Wahl, "LDAPv3 Triggered Search Control",
+ draft-ietf-ldapext-trigger-xx.txt, a work in progress.
+
+ [UUID-CSN] K. Zeilenga, J. Choi, "LDAP UUID and CSN Operational
+ Attributes", draft-zeilenga-ldap-uuid-csn-xx.txt, a work
+ (not yet) in progress.
+
+
+10. Authors' Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+ <Kurt@OpenLDAP.org>
+
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 22]
+\f
+INTERNET-DRAFT draft-zeilenga-ldup-sync-02 5 May 2003
+
+
+ Jonghyuk Choi
+ IBM Corporation
+ <jongchoi@us.ibm.com>
+
+
+Full Copyright
+
+ 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.
+
+
+Appendix - CSN-based Implementation Considerations
+
+ This appendix is provided for informational purposes only, it is not a
+ normative part of the LDAP Content Synchronization Operation's
+ technical specification.
+
+ This appendix discusses some of the implementation considerations
+ associated with a Change Sequence Number [UUID-CSN] based approaches
+ to supporting the LDAP Content Synchronization Operation.
+
+ Change Sequence Number-based approaches are targetted for use in
+ servers which do not maintain historical information (e.g., change
+ logs, state snapshots, etc.) about changes made to the Directory and
+ hence, must rely on current directory state and minimal
+ synchronization state information embedded in Sync Cookie. Servers
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 23]
+\f
+INTERNET-DRAFT draft-zeilenga-ldup-sync-02 5 May 2003
+
+
+ which maintain historical information should consider an other
+ approaches which exploit the historical information.
+
+ A Change Sequence Number is, effectively a time stamp has sufficient
+ granularity to ensure that relationship in time of two updates to the
+ same object can be determined. Change Sequence Numbers are not to be
+ confused with Commit Sequence Numbers or Commit Log Record Numbers. A
+ Commit Sequence Number allow one to determine how to two commits (to
+ the same object or different objects) relate to each other in time.
+ Change Sequence Number associated with different entries may be
+ committed out of order. In the remainder of this Appendix, the term
+ CSN refers to a Change Sequence Number.
+
+ In these approaches, the server not only maintains an entry CSN
+ operational attribute for each directory entry (as discussed in [UUID-
+ CSN], but maintains a value which we will call the context CSN. The
+ context CSN is the greatest committed entry CSN which is not greater
+ than any outstanding entry CSNs for all entries in a directory
+ context. The values of context CSN are used in syncCookie values as
+ synchronization state indicators.
+
+ As search operations are not isolated from individual directory update
+ operations and individual update operations cannot be assumed to be
+ serialized, one cannot assume that the returned content incorporates
+ all relevant changes whose change sequence number is less than or
+ equal to the greatest entry CSN in the content. The content
+ incorporates all the relevant changes whose change sequence number is
+ less than or equal to context CSN before search processing. The
+ content may also incorporate any subset of the the changes whose
+ change sequence number is greater than context CSN before search
+ processing but less than or equal to the context CSN after search
+ processing. The content does not incorporate any of the changes whose
+ CSN is greater than the context CSN after search processing.
+
+ A simple server implementation could use value of the context CSN
+ before search processing to indicate state. Such an implementation
+ would embed this value into each SyncCookie returned. We'll call this
+ the cookie CSN. When a refresh was requested, the server would simply
+ entry "update" messages for all entries in the content whose CSN is
+ greater than the cookie CSN and entry "present" messages for all other
+ entries in the content. However, if the current context CSN is same
+ as the cookie CSN, the server should instead generate zero "updates",
+ zero "delete" messages and indicate refreshDeletes of TRUE as the
+ directory has not changed.
+
+ The implementation should also consider the impact of changes to meta
+ information, such as access controls, which affects content
+ determination. One approach is for the server to maintain a context
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 24]
+\f
+INTERNET-DRAFT draft-zeilenga-ldup-sync-02 5 May 2003
+
+
+ wide meta information CSN or meta CSN. This meta CSN would be updated
+ whenever meta information affecting content determination was changed.
+ If the value of the meta CSN is greater than cookie CSN, the server
+ should ignore the cookie and treat the request as an initial request
+ for content.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 25]
+\f
projects / openldap / commitdiff