--- /dev/null
+
+
+Internet Draft R. Megginson, Editor
+Document: <draft-ietf-ldup-lcup-02.txt> M. Smith
+Category: Proposed Standard Netscape
+ Communications Corp.
+ O. Natkovich
+ Yahoo
+ J. Parham
+ Microsoft Corporation
+ November 2001
+
+
+ LDAP Client Update Protocol
+
+
+Status of this Memo
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC2026 [1].
+
+ 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 defines the LDAP Client Update Protocol (LCUP). The
+ protocol is intended to allow an LDAP client to synchronize with the
+ content of a directory information tree (DIT) stored by an LDAP
+ server and to be notified about the changes to that content.
+
+
+2. Conventions used in this document
+
+ In the protocol flow definition, the notation C->S and S->C
+ specifies the direction of the data flow from the client to the
+ server and from the server to the client respectively.
+
+ 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
+ [KEYWORDS].
+
+
+3. Overview
+
+\f
+
+
+ The LCUP protocol is intended to allow LDAP clients to synchronize
+ with the content stored by LDAP servers.
+
+ The problem areas addressed by the protocol include:
+
+ - mobile clients that maintain a local read-only copy of the
+ directory data. While off-line, the client uses the local copy of
+ the data. When the client connects to the network, it
+ synchronizes with the current directory content and can be
+ optionally notified about the changes that occur while it is on-
+ line. For example, a mail client can maintain a local copy of the
+ corporate address book that it synchronizes with the master copy
+ whenever the client gets connected to the corporate network.
+
+ - applications intending to synchronize heterogeneous data stores.
+ A meta directory application, for instance, would periodically
+ retrieve a list of modified entries from the directory, construct
+ the changes and apply them to a foreign data store.
+
+ - clients that need to take certain actions when a directory entry
+ is modified. For instance, an electronic mail repository may want
+ to perform a "create mailbox" task when a new person entry is
+ added to an LDAP directory and a "delete mailbox" task when a
+ person entry is removed.
+
+ The problem areas not being considered:
+
+ - directory server to directory server synchronization. The
+ replication protocol that is being defined by the LDUP IETF
+ working group should be used for this purpose.
+
+ Several features of the protocol distinguish it from LDUP
+ replication. First, the server does not maintain any state
+ information on behalf of its clients. The clients are responsible
+ for storing the information about how up to date they are with
+ respect to the server's content. Second, no predefined agreements
+ exist between the clients and the servers. The client decides when
+ and from where to retrieve the changes. Finally, the server never
+ pushes the data to the client; the client always initiates the
+ update session during which it pulls the changes from the server.
+
+ The set of clients that are allowed to synchronize with an LDAP
+ server is determined by the server defined policy.
+
+ There are currently several protocols in use for LDAP client server
+ synchronization. While each protocol addresses the needs of a
+ particular group of clients (e.g., on-line clients or off-line
+ clients) none satisfies the requirements of all clients in the
+ target group. For instance, a mobile client that was off-line and
+ wants to become up to date with the server and stay up to date while
+ connected can't be easily supported by any of the existing
+ protocols.
+
+
+
+Megginson, et. al. Proposed Standard - Expires: May 2002 2
+\f
+
+
+ A server can define a naming context or some part thereof to
+ participate in LCUP. This document will refer to this as an LCUP
+ Context. For example, LDUP defines a replica, a part of the DIT
+ which may participate in replication. The LCUP context may be
+ coincident with the replicated area, depending on the server's
+ implementation. It is assumed that most server implementations of
+ LCUP will make use of the server's underlying replication mechanism,
+ but this does not have to be LDUP compliant.
+
+4. Protocol Specification
+
+ This section describes the protocol elements and the protocol flow.
+
+4.1 Unique Identifiers
+
+ Distinguished names can change, so are therefore unreliable
+ as identifiers. The server SHOULD assign a Unique Identifier to each
+ entry as it is created. This identifier will be stored as an
+ operational attribute of the entry, named `entryUUID'. The entryUUID
+ attribute is single valued. If the client wants to use entryUUID, it
+ should supply entryUUID in the list of attributes to return in the
+ LCUP search (described below).
+ A consistent algorithm for generating such unique
+ identifiers may be standardized at some point in the future.
+ The definition of the entryUUID attribute type, written using the
+ BNF form of AttributeDescription described in RFC 2252 [RFC2252] is:
+
+ ( OID-To-Be-Specified
+ NAME `entryUUID'
+ DESC `unique entry identifier'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+4.2 LCUP Cookie Value
+
+ The LCUP protocol uses a cookie to hold the state of the client's
+ data with respect to the server's data. The LCUP Cookie is a value
+ of the following ASN.1 type:
+
+ LCUPCookie ::= SEQUENCE {
+ scheme LDAPOID,
+ value OCTET STRING OPTIONAL
+ }
+
+ scheme - this is the OID which identifies the format of the value.
+ The scheme OID, like all object identifiers, MUST be unique for a
+ given cookie scheme. The cookie value may be opaque or it may be
+ exposed to LCUP clients. For cookie schemes that expose their
+ value, the preferred form of documentation is an RFC. It is
+ expected that there will be one or more standards track cookie
+ schemes where the value format is exposed and described in detail.
+
+Megginson, et. al. Proposed Standard - Expires: May 2002 3
+\f
+
+
+
+
+ value - this is the actual data describing the state of the
+ client's data. This value may be opaque, or its value may have
+ some well known format, depending on the scheme. The cookie value
+ MUST be included except when a client has no stored state; i.e.,
+ when the client is requesting a full synchronization. When the
+ server sends back a cookie, the cookie value MUST be present.
+
+ Further uses of the LCUP Cookie value are described below.
+
+4.3 LCUP Cookie Schemes Operational Attribute
+
+ The OIDs of the supported LCUP cookie schemes SHOULD be published
+ using the following operational attribute:
+
+ ( OID-TBD
+ NAME 'lcupCookieScheme'
+ EQUALITY objectIdentifierMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
+ NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+ The lcupCookieScheme operational attribute MUST be present in the
+ root DSE. The lcupCookieScheme operational attribute MAY be present
+ in every directory entry that may be used as the baseObject for a
+ search request that contains an LCUP clientUpdate control. If a
+ client wants to determine what LCUP cookie schemes are supported, it
+ MAY use a base object search to read the lcupCookieScheme attribute
+ from the entry that will be used as the baseObject in subsequent
+ LCUP sessions, then query the root DSE if the lcupCookieScheme was
+ not found in the base entry. Clients SHOULD NOT search for entries
+ that contain lcupCookieScheme values; rather, it is RECOMMENDED that
+ servers support LCUP sessions based at as many different entries as
+ possible.
+ Each value of the attribute will be a list of OIDs of the cookie
+ schemes followed by the DN of the LCUP context which supports the
+ schemes. The delimiter will be a single space character. For
+ example:
+ lcupCookieScheme: 1.2.3.4 5.6.7.8 dc=mycorp, dc=com
+ Everything after the last space after the last OID will be the LCUP
+ Context DN. If the attribute is present in a regular directory
+ entry in an LCUP Context, the values corresponding to DNs other than
+ the LCUP Context containing the entry MAY be omitted.
+
+4.4 Client Update Control Value
+
+ A client initiates a synchronization session with a server by
+ attaching a clientUpdate control to a search operation. The search
+ specification determines the part of the directory information tree
+ (DIT) the client wishes to synchronize with, the set of attributes
+ it is interested in and the amount of data the client is willing to
+ receive. The clientUpdate control contains the client's
+ synchronization specification. The controlType field for the
+
+Megginson, et. al. Proposed Standard - Expires: May 2002 4
+\f
+
+
+ clientUpdate control is ClientUpdateControlOID (to be assigned).
+ The controlValue is an OCTET STRING, whose contents are the bytes of
+ the BER encoding of the following:
+
+ ClientUpdateControlValue ::= SEQUENCE {
+ updateType ENUMERATED {
+ synchronizeOnly (0),
+ synchronizeAndPersist (1),
+ persistOnly (2) },
+ cookie LCUPCookie OPTIONAL
+ }
+
+ updateType - specifies the type of update requested by the client
+
+ synchronizeOnly - the server sends all the data needed to
+ synchronize the client with the server, then closes the
+ connection
+
+ synchronizeAndPersist - the server sends all the data needed to
+ synchronize the client with the server, then leaves open the
+ connection, sending to the client any new added, modified, or
+ deleted entries which satisfy the search criteria.
+
+ persistOnly - the server does not synchronize the data with the
+ client but leaves open the connection and sends over any new
+ added, modified, or deleted entries which satisfy the search
+ criteria.
+
+ cookie - a value that represents the current state of the client's
+ data. If a cookie is provided, the server MUST use the enclosed
+ scheme throughout the duration of the LCUP session or until an
+ LCUP context boundary is crossed, since a new cookie may be
+ required in that case. If the value or scheme part of the cookie
+ is invalid, the server MUST return immediately with a
+ SearchResultDone message with the clientUpdateDone control
+ attached with the reason set to the value of lcupInvalidCookie
+ (see below). Also, the LDAP result code MUST be
+ unwillingToPerform. If the scheme part of the cookie is a valid
+ OID, but is not supported, the server MUST return immediately
+ with a SearchResultDone message with the clientUpdateDone control
+ attached with the reason set to the value of
+ lcupUnsupportedScheme (see below). Also, the LDAP result code
+ MUST be unwillingToPerform.
+
+ If the cookie is omitted, the server MAY use any scheme it
+ supports.
+
+4.5 Entry Update Control Value
+
+ In response to the client's synchronization request, the server
+ returns one or more SearchResultEntry PDU that fits the client's
+ specification. Each SearchResultEntry PDU also contains an
+ entryUpdateControl which describes the LCUP state of the returned
+ entry. To represent a deleted entry, the server attaches an
+
+Megginson, et. al. Proposed Standard - Expires: May 2002 5
+\f
+
+
+ entryUpdate control to the corresponding SearchResultEntry. The
+ SearchResultEntry corresponding to a deleted entry MUST contain a
+ valid DN and MAY contain a valid Unique Identifier but, to reduce
+ the amount of data sent to the client, it SHOULD not contain any
+ other attributes. Distinguished names can change, so are therefore
+ unreliable as identifiers. A Unique Identifier MAY therefore be
+ assigned to each entry as it is created. The Unique Identifier
+ allows the client to uniquely identify entries even in the presence
+ of modifyDN operations. The Unique Identifier is carried in the
+ entryUUID attribute.
+ For returned SearchResultEntry PDUs other than deleted entries, the
+ client MAY request that the Unique Identifier attribute be returned
+ by specifying it in the attribute list to be returned by the search
+ request. If the Unique Identifier is not returned, the client MAY
+ use the entry DN to keep track of returned entries.
+
+ Furthermore, the server may elect to periodically return to the
+ client the cookie that represents the state of the client's data.
+ This information is useful in case the client crashes or gets
+ disconnected. The cookie SHOULD be present in every entryUpdate
+ control sent to the client to insure ease of synchronization. The
+ cookie is also provided in the entryUpdate control. The controlType
+ field for the entryUpdate control is EntryUpdateControlOID (to be
+ assigned). The controlValue is an OCTET STRING, whose contents are
+ the bytes of the BER encoding of the following:
+
+ EntryUpdateControlValue ::= SEQUENCE {
+ stateUpdate BOOLEAN,
+ entryDeleted BOOLEAN,
+ cookie LCUPCookie OPTIONAL
+
+ }
+
+ stateUpdate - if set to TRUE, indicates that the entry to which the
+ control is attached contains no changes and it is sent only to
+ communicate to the client the new cookie. In this case, the
+ entryDeleted field MUST be ignored and the cookie field MUST
+ contain the updated cookie. This feature allows updating the
+ client's cookie when there are no changes that effect the
+ client's data store. Note that the control MUST be attached to a
+ valid SearchResultEntry, i.e. the entry should contain a valid
+ dn. The server MAY send the entry named by the baseObject from
+ the client's search request.
+
+ entryDeleted - if set to TRUE, indicates that the entry to which
+ the control is attached was deleted. The server MAY also set
+ this to TRUE if the entry has left the client's search result
+ set. As far as the client is concerned, a deleted entry is no
+ different than an entry which has left the result set.
+
+ cookie - the LCUP cookie value that represents the current state of
+ the client's data.
+
+4.6 Client Update Done Control Value
+
+Megginson, et. al. Proposed Standard - Expires: May 2002 6
+\f
+
+
+
+ When the server has finished processing the client's request, it
+ attaches a clientUpdateDone control to the SearchResultDone message
+ and sends it to the client. However, if the SearchResultDone message
+ contains a resultCode which is not success, the clientUpdateDone
+ control MAY be omitted. The controlType field for the
+ clientUpdateDone control is ClientUpdateDoneControlOID (to be
+ assigned). The controlValue is an OCTET STRING, whose contents are
+ the bytes of the BER encoding of the following:
+
+ ClientUpdateDoneControlValue ::= SEQUENCE {
+ reason INTEGER,
+ reasonText LDAPString,
+ cookie LCUPCookie OPTIONAL
+ }
+
+ reason - reason for terminating the operation. The following values
+ are defined:
+
+ lcupSuccess (0) the operation was successfully
+ processed
+ lcupResourcesExhausted (1) the server is running out of resource
+ lcupSecurityViolation (2) the client is suspected of malicious
+ actions
+ lcupInvalidCookie (3) invalid cookie was supplied by the
+ client - both/either the scheme
+ and/or the value part was invalid
+ lcupUnsupportedScheme (4) The scheme part of the cookie is a
+ valid OID but is not supported by
+ this server
+ lcupClientDisconnect (5) client requested search termination
+ using the stopClientUpdate request
+ (defined below)
+ lcupReloadRequired (6) indicates that client data needs to
+ be reinitialized. This reason is
+ returned if the server does not
+ contain sufficient information to
+ synchronize the client or that the
+ server's data was reloaded since the
+ last synchronization session
+
+ reasonText - The reasonText 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) error diagnostic. As this error diagnostic is
+ not standardized, implementations MUST NOT rely on the values
+ returned. If the server chooses not to return a textual
+ diagnostic, the reasonText field of the
+ ClientUpdateDoneControlValue MUST contain a zero length string.
+ The reasonText should be limited to characters in the range 0x00 to
+ 0x7F.
+
+ cookie - the LCUP cookie value that represents the current state of
+ the client's data. Although this value is OPTIONAL, it MUST be set
+
+Megginson, et. al. Proposed Standard - Expires: May 2002 7
+\f
+
+
+ in the ClientUpdateDoneControlValue if the reason is lcupSuccess or
+ lcupClientDisconnect and the LDAP search result code is success.
+ This provides a good "checksum" of what the server thinks the state
+ of the client is. If some error occurred, either an LDAP search
+ error (e.g. insufficientAccessRights) or an LCUP error (e.g.
+ lcupUnsupportedScheme), the cookie MAY be omitted.
+
+ If server resources become tight, the server can terminate one or
+ more search operations by sending a SearchResultDone message to the
+ client(s). Unless the client sets the updateType field to
+ persistOnly, the server attaches a clientUpdateDone control that
+ contains the cookie that corresponds to the current state of the
+ client's data and the value of the reason field is set to
+ lcupResourcesExhausted. A server set policy is used to decide which
+ searches to terminate. This can also be used as a security mechanism
+ to disconnect clients that are suspected of malicious actions, but
+ if the server can infer that the client is malicious, the server
+ should return lcupSecurityViolation in the reason field of the
+ response.
+
+4.7 Stop Client Update Request and Response
+
+ The Stop Client Update operation is an LDAPv3 Extended Operation
+ [RFC2251, Section 4.12] and is identified by the OBJECT IDENTIFIER
+ stopClientUpdateRequestOID (to be assigned). This section details
+ the syntax of the protocol.
+
+ An LDAPv3 Extended Request is defined in [LDAPv3] as follows:
+
+ ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
+ requestName [0] LDAPOID,
+ requestValue [1] OCTET STRING OPTIONAL
+ }
+
+ If the client needs to terminate the synchronization process and it
+ wishes to obtain the cookie that represents the current state of its
+ data, it issues a stopClientUpdateRequest extended operation. The
+ operation carries the following data. The extended operation
+ requestValue is an OCTET STRING, whose contents are the bytes of the
+ BER encoding of the following:
+
+ StopClientUpdateRequestValue ::= MessageID
+
+ StopClientUpdateRequestValue - the message ID of the search that
+ included the original clientUpdate control
+
+ The server responds immediately with a stopClientUpdateResponse
+ extended operation that carries no data, and an OBJECT IDENTIFIER of
+ stopClientUpdateResponseOID (to be assigned). The server MAY send
+ any pending SearchResultEntry PDUs if the server cannot easily abort
+ or remove those search results from its outgoing queue. The server
+ SHOULD send as few of these remaining SearchResultEntry PDUs as
+ possible. Finally, the server sends the message SearchResultDone
+ with the clientUpdateDone control attached. The value of the reason
+
+Megginson, et. al. Proposed Standard - Expires: May 2002 8
+\f
+
+
+ in the clientUpdateDone control value MUST be either an error code
+ (some value other than lcupSuccess) or lcupClientDisconnect. The
+ stopClientUpdateResponse is sent only to satisfy LDAP requirement
+ that every server must issue an extended response for each extended
+ request it receives.
+
+ If the client is not interested in the state information, it can
+ simply abandon the search operation or disconnect from the server.
+
+ The requestName portion of the stopClientUpdate must be the
+ OID stopClientUpdateOID (to be assigned). The requestValue is the
+ message ID corresponding to the client's search request. If the
+ message ID is not valid, the server MUST send back to the client an
+ LDAP error code of unwillingToPerform.
+
+4.8 Protocol Flow
+
+ The client server interaction can proceed in three different ways
+ depending on the client's requirements. Protocol flows beginning
+ with an asterisk (*) are optional or conditional.
+
+ If the client's intent is not to synchronize data but to trigger
+ actions in response to directory modifications, the protocol
+ proceeds as follows:
+
+ C->S Sends a search operation with a clientUpdate control attached.
+ The search specification determines the part of the DIT the
+ client wishes to synchronize with and the set of attributes it
+ is interested in. The updateType field of the control value
+ should be set to persistOnly.
+ *S->C If there is an error (invalid search scope, invalid cookie)
+ the server returns the appropriate error codes and terminates
+ the request (SearchResultDone message with optional
+ clientUpdateDone control)
+ S->C Sends change notification to the client for each change to the
+ data within the client's search specification. Each
+ SearchResultEntry may have an entryUpdate control attached.
+ *S->C If the server starts to run out of resources or the client is
+ suspected of malicious actions, the server SHOULD terminate
+ the search operation by sending to the client a
+ SearchResultDone message with clientUpdateDone control
+ attached. The control contains the reason field set to
+ lcupResourcesExhausted or lcupSecurityViolation depending on
+ the reason for termination. The server MAY provide more
+ details to the client via the reasonText field of the control.
+ *C->S If the client receives lcupResourcesExhausted error from the
+ server, it MUST wait for a while before attempting another
+ synchronization session with the server. It is RECOMMENDED
+ that clients use an exponential backoff strategy.
+ C->S The client terminates the search. The client can do this by
+ abandoning the search operation, disconnecting from the
+ server, or by sending the stopClientUpdate extended operation.
+ *S->C If the server receives the stopClientUpdate extended op, it
+ will immediately send back the stopClientUpdate extended op
+
+Megginson, et. al. Proposed Standard - Expires: May 2002 9
+\f
+
+
+ response
+ *S->C If the client sent the stopClientUpdate extended op, the
+ server MAY send any pending SearchResultEntry PDUs in its
+ outgoing queue
+ *S->C If the client sent the stopClientUpdate extended op, after the
+ server sends the response and any pending SearchResultEntry
+ PDUs, the server sends the SearchResultDone message with the
+ clientUpdateDone control attached. The value of the reason
+ field of the clientUpdateDone control value will be either
+ lcupClientDisconnect or some lcup error code (not
+ lcupSuccess).
+ S->C Stops sending changes to the client and closes the connection.
+
+ If the client's intent is to synchronize with the server and then
+ disconnect, the protocol proceeds as follows:
+
+ C->S Sends a search operation with the clientUpdate control
+ attached. The search specification determines the part of the
+ DIT the client wishes to synchronize with, the set of
+ attributes it is interested in and the amount of data the
+ client is willing to receive. If this is the initial
+ synchronization session, the client either does not provide a
+ cookie or provides a cookie with no value; otherwise, the
+ cookie field of the control is set to the cookie received from
+ the server at the end of the last synchronization session. If
+ the scheme field of the cookie was provided, the server MUST
+ use that scheme throughout the duration of the LCUP session or
+ until an LCUP boundary is crossed, since the server will
+ usually require a different cookie in that case anyway. (Note
+ that the client can synchronize with different servers during
+ different synchronization sessions.) The updateType field of
+ the control value is set to synchronizeOnly.
+ *S->C If there is an error (invalid search scope, invalid cookie)
+ the server returns the appropriate error codes and terminates
+ the request (SearchResultDone message with optional
+ clientUpdateDone control)
+ *S->C If no cookie is specified in the clientUpdate control, or if
+ the value field of the cookie is empty, the server sends all
+ data that matches the client's search specification followed
+ by the SearchResultDone message with a clientUpdateDone
+ control attached. The control contains the cookie that
+ corresponds to the current state of the client's data and the
+ reason flag set to lcupSuccess.
+ *S->C If an invalid cookie is specified, the server sends the
+ SearchResultDone message with clientUpdateDone control
+ attached. The reason field of the control is set to
+ lcupInvalidCookie and the reasonText field MAY contain
+ explanation of the error.
+ *S->C If a valid cookie is specified and the data that matches the
+ search specification has been reloaded or the server does not
+ contain enough state information to synchronize the client,
+ the server sends a SearchResultDone message with
+ clientUpdateDone control attached. The reason field of the
+ control is set to lcupReloadRequired and the reasonText field
+
+Megginson, et. al. Proposed Standard - Expires: May 2002 10
+\f
+
+
+ MAY contain explanation of the error.
+ *S->C If the cookie is valid and the client is up to date, the
+ server sends a success response to the client.
+ S->C If the cookie is valid and there is data to be sent, the
+ server sends the modified entries to the client. Each
+ SearchResultEntry contains the attributes requested by the
+ client in the search specification regardless of whether they
+ were modified. An entryUpdate control with the entryDeleted
+ field set to TRUE MUST be attached to every deleted entry. The
+ server may also periodically attach an entryUpdate control to
+ the entries sent to the client to indicate the current state
+ of the client's data. In that case, the cookie field of the
+ control represents the state of the client's data including
+ the entry to which the control is attached. Once all the
+ changes are sent, the server sends a SearchResultDone with the
+ clientUpdateDone control attached. The control contains the
+ cookie that represents the current state of the client's data.
+ The reason field of the control is set to lcupSuccess.
+ The client stores the cookie received from the server until
+ the next synchronization session.
+ *C->S If the reason field of the control is set lcupReloadRequired,
+ the client clears its data store and repeats the
+ synchronization process by sending the search operation with
+ clientUpdate control that contains no cookie, or that contains
+ a cookie with no value field.
+
+ If the client's intent is to be synchronized with the server and
+ stay notified about data modifications, the protocol proceeds as
+ follows:
+
+ C->S The client behaves exactly as in the previous case except it
+ sets the updateType field in the control value to
+ synchronizeAndPersist.
+ S->C The server behaves exactly as in the previous case except the
+ connection is kept open after the initial set of changes is
+ sent to the client. A SearchResultDone message is not sent to
+ the client; instead, the server keeps sending changes to the
+ client.
+ *S->C If the server starts to run out of resources or the client is
+ suspected of malicious actions, the server SHOULD terminate
+ the search operation by sending to the client a
+ SearchResultDone message with clientUpdateDone control
+ attached. The control contains the reason field set to
+ lcupResourcesExhausted or lcupSecurityViolation depending on
+ the reason for termination. The server MAY provide more
+ details to the client via the reasonText field of the control.
+ *C->S If the client receives lcupResourcesExhausted error from the
+ server, it MUST wait for a while before attempting another
+ synchronization session with the server. We recommend
+ exponential backoff strategy.
+ C->S Sends a stopClientUpdateRequest extended operation to the
+ server to terminate the synchronization session.
+ S->C Responds with a stopClientUpdateResponse extended operation
+ followed by a SearchResultDone with the clientUpdateDone
+
+Megginson, et. al. Proposed Standard - Expires: May 2002 11
+\f
+
+
+ control optionally attached. If present, the control contains
+ the cookie that represents the current state of the client's
+ data. The value of the reason field of the clientUpdateDone
+ control value will be either lcupClientDisconnect or some lcup
+ error code (not lcupSuccess). The control may not be present
+ if some error occurred.
+
+4.9 Size and Time Limits
+
+ The search request size or the time limits can only be imposed for
+ non-persistent operations, those that set the updateType field of
+ the ClientUpdateControlValue to synchronizeOnly (for the entire
+ operation) or synchronizeAndPersist (for the initial synchronization
+ phase only). All other operations MUST set both limits to 0. The
+ server SHOULD ignore the limits set for persistent operations.
+
+4.10 Changes vs. Operations
+
+ The server sends to the client modified entries rather than
+ operations. Given this model, the server communicates a modifyDN
+ operation in one of two ways: by sending the client the current form
+ of the entry (with its new DN) along with an entryUUID attribute, or
+ by sending the client a deletion for the previous DN and an entry
+ for the new DN. The latter method must be used if the server does
+ not support the entryUUID attribute. In either case, if the client
+ state shows that the object that underwent the modifyDN operation
+ was the root of a subtree, the client MUST infer that the DNs of all
+ objects in the subtree have changed such that they reflect the new
+ DN of the subtree root.
+
+4.11 Operations on the Same Connection
+
+ It is permissible for the client to issue other LDAP operations on
+ the connection used by the protocol. Since each LDAP
+ request/response carries a message id there will be no ambiguity
+ about which PDU belongs to which operation. By sharing the
+ connection among multiple operations, the server will be able to
+ conserve its resources.
+
+4.12 Interactions with Other LDAP Search and Response Controls
+
+ LCUP defines neither restrictions nor guarantees about the ability
+ to use the LDAP client update control defined in this document in
+ conjunction with other LDAP controls, except for the following: A
+ server MAY ignore non-critical controls supplied with the LCUP
+ control. A server MAY ignore the LCUP control if it is non-critical
+ and it is supplied with other critical controls. If a server
+ receives a critical LCUP control with another critical control, and
+ the server does not support both controls at the same time, the
+ server SHOULD return unavailableCriticalExtension.
+
+5. Additional Features
+
+
+
+Megginson, et. al. Proposed Standard - Expires: May 2002 12
+\f
+
+
+ There are several features present in other protocols or considered
+ useful by clients that are currently not included in the protocol
+ primarily because they are difficult to implement on the server.
+ These features are briefly discussed in this section. This section
+ is intended to open a discussion on the merits of including and
+ approaches to implementing these features.
+
+5.1 Triggered Search Change Type
+
+ This feature is present in the Triggered Search specification. A
+ flag is attached to each entry returned to the client indicating the
+ reason why this entry is returned. The possible reasons from the
+ draft are
+ "- notChange: the entry existed in the directory and matched the
+ search at the time the operation is being performed,
+ - enteredSet: the entry entered the result,
+ - leftSet: the entry left the result,
+ - modified: the entry was part of the result set, was modified or
+ renamed, and still is in the result set."
+
+ The leftSet feature is particularly useful because it indicates to
+ the client that an entry is no longer within the client's search
+ specification and the client can remove the associated data from its
+ data store. Ironically, this feature is the hardest to implement on
+ the server because the server does not keep track of the client's
+ state and has no easy way of telling which entries moved out of
+ scope between synchronization sessions with the client.
+
+ A compromise could be reached by only providing this feature for the
+ operations that occur while the client is connected to the server.
+ This is easier to accomplish because the decision about the change
+ type can be made based only on the change without need for any
+ historical information. This, however, would add complexity to the
+ protocol.
+
+5.2 Persistent Search Change Type
+
+ This feature is present in the Persistent Search specification.
+ Persistent search has the notion of changeTypes. The client
+ specifies which type of updates will cause entries to be returned,
+ and optionally whether the server tags each returned entry with the
+ type of change that caused that entry to be returned.
+
+ For LCUP, the intention is full synchronization, not partial. Each
+ entry returned by an LCUP search will have some change associated
+ with it that may concern the client. The client may have to have a
+ local index of entries by DN or unique identifier to determine if
+ the entry has been added or just modified. It is easy for clients
+ to determine if the entry has been deleted because the entryDeleted
+ value of the entryUpdateControl will be TRUE.
+
+5.3 Sending Changes
+
+
+
+Megginson, et. al. Proposed Standard - Expires: May 2002 13
+\f
+
+
+ Some earlier synchronization protocols sent the client(s) only the
+ modified attributes of the entry rather than the entire entry. While
+ this approach can significantly reduce the amount of data returned
+ to the client, it has several disadvantages. First, unless a
+ separate mechanism (like the change type described above) is used to
+ notify the client about entries moving into the search scope,
+ sending only the changes can result in the client having an
+ incomplete version of the data. Let's consider an example. An
+ attribute of an entry is modified. As a result of the change, the
+ entry enters the scope of the client's search. If only the changes
+ are sent, the client would never see the initial data of the entry.
+ Second, this feature is hard to implement since the server might not
+ contain sufficient information to construct the changes based solely
+ on the server's state and the client's cookie. On the other hand,
+ this feature can be easily implemented by the client assuming that
+ the client has the previous version of the data and can perform
+ value by value comparisons.
+
+5.4 Data Size Limits
+
+ Some earlier synchronization protocols allowed clients to control
+ the amount of data sent to them in the search response. This feature
+ was intended to allow clients with limited resources to process
+ synchronization data in batches. However, an LDAP search operation
+ already provides the means for the client to specify the size limit
+ by setting the sizeLimit field in the SearchRequest to the maximum
+ number of entries the client is willing to receive. While the
+ granularity is not the same, the assumption is that LCUP protocol
+ will be implemented by regular LDAP clients that can deal with the
+ limitations of the LDAP protocol.
+
+5.5 Data Ordering
+
+ Some earlier synchronization protocols allowed a client to specify
+ that parent entries should be sent before the children for add
+ operations and children entries sent before their parents during
+ delete operations. This ordering helps clients to maintain a
+ hierarchical view of the data in their data store. While possibly
+ useful, this feature is relatively hard to implement and is
+ expensive to perform.
+
+6. Client Side Considerations
+
+ There are several issues that the implementors of a synchronization
+ client need to consider:
+
+ - The cookie received from the server after a synchronization
+ session can only be used with the same or more restrictive search
+ specification than the search that generated the cookie. The
+ server will reject the search operation with a cookie that does
+ not satisfy this condition. This is because the client can end up
+ with an incomplete data store otherwise. A more restrictive
+ search specification is the one that generates a subset of the
+ data produced by the original search specification.
+
+Megginson, et. al. Proposed Standard - Expires: May 2002 14
+\f
+
+
+
+ - Because an LCUP client specifies the area of the tree with which
+ it wishes to synchronize through the standard LDAP search
+ specification, the client can be returned noSuchObject error if
+ the root of the synchronization area was renamed between the
+ synchronization sessions or during a synchronization session. If
+ this condition occurs, the client can attempt to locate the root
+ by using the root's Unique Identifier saved in client's local
+ data store. It then can repeat the synchronization request using
+ the new search base. In general, a client can detect that an
+ entry was renamed and apply the changes received to the right
+ entry by using the Unique Identifier rather then DN based
+ addressing.
+
+ - Each active persistent operation requires that an open TCP
+ connection be maintained between an LDAP client and an LDAP
+ server that might not otherwise be kept open. Therefore, client
+ implementors are encouraged to avoid using persistent operations
+ for non-essential tasks and to close idle LDAP connections as
+ soon as practical. The server may close connections if server
+ resources become tight.
+
+ - The client MAY receive a continuation reference
+ (SearchResultReference [RFC2251 SECTION 4.5.3]) if the search
+ request spans multiple parts of the DIT, some of which may
+ require a different LCUP cookie, some of which may not even be
+ managed by LCUP. The client SHOULD maintain a cache of the LDAP
+ URLs returned in the continuation references and the cookies
+ associated with them. The client is responsible for performing
+ another LCUP search to follow the references, and SHOULD use the
+ cookie corresponding to the LDAP URL for that reference (if it
+ has a cookie).
+
+ - For alias dereferencing, the server will behave as if the client
+ had requested neverDerefAliases or derefFindingBaseObj as the
+ derefAliases field in the search request [RFC2251, Section
+ 4.5.1]. If the client specifies a value other than
+ neverDerefAliases or derefFindingBaseObj, the server will return
+ protocolError to the client.
+
+ - Changes to data (e.g., that might affect the LCUP client's
+ filter or scope) or meta-data (e.g., that might affect the
+ client's read access) may affect the presence of entries in the
+ search set. Servers MAY notify LCUP clients of changes to the
+ search set that result from such changes, but an LCUP client MUST
+ NOT assume that such notification will occur. Therefore, in the
+ case where a client is maintaining a cache of entries using LCUP,
+ the data held by the client may be a superset or a subset of the
+ entries that would be returned by a new search request. For
+ example, if access control meta information is changed to deny
+ access to particular entries in the search result set, and the
+ access control information is outside of the search scope (e.g.,
+ in a parent entry), the client may have entries stored locally
+ which are no longer part of its desired search set. Similarly,
+
+Megginson, et. al. Proposed Standard - Expires: May 2002 15
+\f
+
+
+ if entries are added to the search result set due to changes in
+ meta-data, the client's cache of entries may not include these
+ entries.
+
+7. Server Implementation Considerations
+
+ By design, the protocol supports multiple cookie schemes. This is
+ to allow different implementations the flexibility of storing any
+ information applicable to their environment. A reasonable
+ implementation for an LDUP compliant server would be to use the
+ Replica Update Vector (RUV). For each master, RUV contains the
+ largest CSN seen from this master. In addition, the RUV implemented
+ by some directory servers (not yet in LDUP) contains replica
+ generation - an opaque string that identifies the replica's data
+ store. The replica generation value changes whenever the replica's
+ data is reloaded. Replica generation is intended to signal the
+ replication/synchronization peers that the replica's data was
+ reloaded and that all other replicas need to be reinitialized. RUV
+ satisfies the three most important properties of the cookie: (1) it
+ uniquely identifies the state of client's data, (2) it can be used
+ to synchronize with multiple servers, and (3) it can be used to
+ detect that the server's data was reloaded.
+
+ A server may support one or more LCUP cookie schemes. It is
+ expected that schemes will be published along with their OIDs as
+ RFCs. If a client initiates an LCUP session with a particular
+ scheme, the server MUST use that same scheme throughout the LCUP
+ session, or until an LCUP context boundary is crossed, in which case
+ the server will usually require a different cookie anyway.
+
+ In addition, the cookie must contain enough information to allow the
+ server to determine whether the cookie can be safely used with the
+ search specification it is attached to. As discussed earlier in the
+ document, the cookie can only be used with the search specification
+ that is equally or more restrictive than the one for which the
+ cookie was generated.
+
+ An implementation must make sure that it can correctly update the
+ client's cookie when there is a size limit imposed on the search
+ results by either the client's request or by the server's
+ configuration. If RUV is used as the cookie, entries last modified
+ by a particular master must be sent to the client in the order of
+ their last modified CSN. This ordering guarantees that the RUV can
+ be updated after each entry is sent.
+
+ The server's DIT may be partitioned into different sections which
+ may have different cookies associated with them. For example, some
+ servers may use some sort of replication mechanism to support LCUP.
+ If so, the DIT may be partitioned into multiple replicas. A client
+ may send an LCUP search request that spans multiple replicas. Some
+ parts of the DIT spanned by the search request scope may be managed
+ by LCUP and some may not. A part of the DIT which is enabled for
+ LCUP is referred to as an LCUP Context. The server SHOULD send a
+ SearchResultReference [RFC2251, SECTION 4.5.3] when the LCUP Context
+
+Megginson, et. al. Proposed Standard - Expires: May 2002 16
+\f
+
+
+ for a returned entry changes. The server SHOULD return all entries
+ for a particular LCUP Context before returning a reference to other
+ LCUP Contexts or non LCUP enabled parts of the DIT, in order to
+ minimize the processing burden on the clients. The LDAP URL(s)
+ returned MUST contain the DN(s) of the base of another section of
+ the DIT (however the server implementation has partitioned the DIT).
+ The client will then issue another LCUP search using the LDAP URL
+ returned. Each section of the DIT MAY require a different cookie
+ value, so the client SHOULD maintain a cache, mapping the different
+ LDAP URL values to different cookies. If the cookie changes, the
+ scheme may change as well, but the cookie scheme MUST be the same
+ within a given LCUP Context.
+
+ An implementation SHOULD notify the client about all entries deleted
+ from the search set since the client's last session, but an LCUP
+ client MUST NOT assume that such notification will occur. For
+ example, the server might not notify the client of the deletion of
+ an object if the object left the search set following the client's
+ last synchronization and prior to the object's deletion. An LDUP
+ compliant implementation can achieve this through the use of entry
+ tombstones. The implementation should avoid aggressive tombstone
+ purging since lack of tombstones would cause client's data to be
+ reloaded. We suggest that only the tombstone content be removed
+ during the regular trimming cycle while tombstones themselves are
+ discarded much less frequently.
+
+ The specification makes no guarantees about how soon a server should
+ send notification of a changed entry to the client when the
+ connection between the client and the server is kept open. This is
+ intentional as any specific maximum delay would be impossible to
+ meet in a distributed directory service implementation. Server
+ implementors are encouraged to minimize the delay before sending
+ notifications to ensure that clients' needs for timeliness of change
+ notification are met.
+
+ Implementors of servers that support the mechanism described in this
+ document should ensure that their implementation scales well as the
+ number of active persistent operations and the number of changes
+ made in the directory increases. Server implementors are also
+ encouraged to support a large number of client connections if they
+ need to support large numbers of persistent operations.
+
+8. Synchronizing Heterogeneous Data Stores
+
+ Clients, like a meta directory join engine, synchronizing multiple
+ writable data stores will only work correctly if each piece of
+ information is single mastered (for instance, only by an LDUP
+ compliant directory). This is because different systems have
+ different notions of time and different update resolution
+ procedures. As a result, a change applied on one system can be
+ discarded by the other, thus preventing the data stores from
+ converging.
+
+9. Security Considerations
+
+Megginson, et. al. Proposed Standard - Expires: May 2002 17
+\f
+
+
+
+ In some situations, it may be important to prevent general exposure
+ of information about changes that occur in an LDAP server.
+ Therefore, servers that implement the mechanism described in this
+ document SHOULD provide a means to enforce access control on the
+ entries returned and MAY also provide specific access control
+ mechanisms to control the use of the controls and extended
+ operations defined in this document.
+
+ As with normal LDAP search requests, a malicious client can initiate
+ a large number of persistent search requests in an attempt to
+ consume all available server resources and deny service to
+ legitimate clients. The protocol provides the means to stop
+ malicious clients by disconnecting them from the server. The servers
+ that implement the mechanism SHOULD provide the means to detect the
+ malicious clients. In addition, the servers SHOULD provide the means
+ to limit the number of resources that can be consumed by a single
+ client.
+
+ Access control on the data can be modified in such a way that the
+ data is no longer visible to the client. The specification does not
+ specify how the server should handle this condition. Moreover, data
+ consistency is not guaranteed if access control is changed from a
+ more restrictive to a less restrictive one. This is because access
+ control can be considered as an additional filter on the search
+ specification and the protocol does not support going from a more to
+ a less restrictive search specification. See Client Side
+ Considerations Section for more detailed explanation of the problem.
+
+10. References
+
+ [KEYWORDS] S. Bradner, "Keywords for use in RFCs to Indicate
+ Requirement Levels", RFC 2119, March 1997.
+
+ [RFC2251] M. Wahl, T. Howes, S. Kille "Lightweight Directory
+ Access Protocol", RFC 2251, December 1997.
+
+ [RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight
+ Directory Access Protocol (v3): Attribute Syntax
+ Definitions", RFC 2252, December 1997.
+
+11. Acknowledgements
+
+ The LCUP protocol is based in part on the Persistent Search Change
+ Notification Mechanism defined by Mark Smith, Gordon Good, Tim
+ Howes, and Rob Weltman, the LDAPv3 Triggered Search Control defined
+ by Mark Wahl, and the LDAP Control for Directory Synchronization
+ defined by Michael Armijo.
+
+12. Author's Addresses
+
+ Rich Megginson
+ Netscape Communications Corp.
+ 901 San Antonio Rd.
+
+Megginson, et. al. Proposed Standard - Expires: May 2002 18
+\f
+
+
+ Palo Alto, CA 94303-4900
+ Mail Stop SCA17 - 201
+ Phone: +1 505 797-7762
+ Email: richm@netscape.com
+
+ Olga Natkovich
+ Yahoo, Inc.
+ 701 First Ave.
+ Sunnyvale, CA 94089
+ Phone: +1 408 349-6153
+ Email: olgan@yahoo-inc.com
+
+ Mark Smith
+ Netscape Communications Corp.
+ 901 San Antonio Rd.
+ Palo Alto, CA 94303-4900
+ Mail Stop SCA17 - 201
+ Phone: +1 650 937-3477
+ Email: mcs@netscape.com
+
+ Jeff Parham
+ Microsoft Corporation
+ One Microsoft Way
+ Redmond, WA 98052-6399
+ Phone: +1 425 882-8080
+ Email: jeffparh@microsoft.com
+
+13. 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.
+
+14. Appendix A - Summary of Changes
+
+Megginson, et. al. Proposed Standard - Expires: May 2002 19
+\f
+
+
+
+ Changes new to version 02:
+
+ Section 4.2: The lcupCookieScheme operational attribute MUST be
+ present in the root DSE, and MAY be present in entries. Each
+ value of the attribute in the root DSE will be a list of OIDs of
+ cookie schemes followed by the DN of the LCUP context which
+ supports the schemes. The attribute value in the DIT entries will
+ be the list of OIDs followed by the DN of the LCUP context.
+
+ section 4.5 - the entry uuid is now MAY instead of MUST - if
+ implementers do not wish to identify entries by a unique ID other
+ than DN (which may not be unique), then so be it. For returned
+ SearchResultEntry PDUs other than deleted entries, the client MAY
+ request that the Unique Identifier attribute be returned by
+ specifying it in the attribute list to be returned by the search
+ request.
+
+ section 4.5 - added "or the base DN of the client's search
+ request." to the phrase. "The server MAY send the entry at the
+ root of the client's tree, or the base DN of the client's search
+ request." I think this clarifies which entry the client may
+ search for.
+
+ section 4.6 - the clientUpdateDone control is now optional for
+ error conditions. Also, the cookie value of the control is now
+ optional for lcup error conditions (e.g. not lcupSuccess or
+ lcupClientDisconnect).
+
+ Added section 4.12 - Interactions with Other LDAP Search and
+ Response Controls
+
+ Added blurb about alias dereferencing back to section 6:
+ "For alias dereferencing, the server will behave as if the client
+ had requested neverDerefAliases or derefFindingBaseObj as the
+ derefAliases field in the search request [RFC2251, Section 4.5.1].
+ If the client specifies a value other than neverDerefAliases or
+ derefFindingBaseObj, the server will return protocolError to the
+ client."
+
+ Changed this in section 6:
+ Because an LCUP client specifies the area of the tree with which
+ it wishes to synchronize through the standard LDAP search
+ specification, the client can be returned noSuchObject error if
+ the root of the synchronization area was renamed between the
+ synchronization sessions "or during a synchronization session"
+
+ Changes new to version 01:
+
+ The opaque cookie has been split into two parts - a scheme which
+ is an OID, and a value. The value may or may not have a format
+ known to the client, depending on the specified scheme. Section
+ 4.2 describes the new cookie format and defines the LCUP Cookie
+ Value.
+
+Megginson, et. al. Proposed Standard - Expires: May 2002 20
+\f
+
+
+
+ Added new section 4.3 - the lcupCookieScheme operational
+ attribute.
+
+ Changes new to version 00:
+
+ Added the definition for Unique Identifier (basically copied from
+ the LDUP model doc http://search.ietf.org/internet-drafts/draft-
+ ietf-ldup-model-06.txt. I needed to add the definition here
+ because LCUP needs a Unique Identifier but should not be dependent
+ on LDUP.
+
+ Removed all normative references to LDUP. I've left the
+ implementation suggestions that refer to LDUP, but LCUP should not
+ be dependent on LDUP.
+
+ Cleaned up the protocol flows.
+
+ Removed this text from section 4.8: "Clients MUST NOT issue
+ multiple synchronization requests on the same connection. This is
+ because the protocol includes an extended operation and it would
+ be impossible to decide which synchronization session it belongs
+ to." - This is no longer true, since the extended operation now
+ includes the message ID of the search request.
+
+ "Client Side Consideration" section - the client will never
+ receive a referral or continuation reference
+
+ Added section 12. Acknowledgements
+
+ Removed normative references to documents not depended on.
+
+ Removed explicit references to software vendors.
+
+ Section 4.1 - Changed ClientUpdateControlValue to remove the
+ keepConnection and changesOnly fields and replace them with
+ updateType which is an ENUMERATED with three values:
+ synchronizeOnly, synchronizeAndPersist, and persistOnly.
+
+ Section 4.2 - The EntryUpdateControlValue fields stateUpdate and
+ entryDeleted no longer have DEFAULT values, they must be specified
+ - this eliminates any potential ambiguity.
+
+ Added this text to the description of the entryDeleted field
+ (section 4.2): "The server SHOULD also set this to TRUE if the
+ entry has left the clients search result set. As far as the client
+ is concerned, a deleted entry is no different than an entry which
+ has left the result set."
+ Section 4.2 - Added an explanation of the concept and requirement
+ for the Unique Identifier.
+
+ Section 4.4 - Added to the extended operation a request value
+ containing the message id of the operation to stop.
+
+
+Megginson, et. al. Proposed Standard - Expires: May 2002 21
+\f
+
+
+ Updated contact information for Olga.
+
+ Removed Michael Armijo and added Jeff Parham as an author.
+
+ Changes new to previous version:
+
+ "Authors" section - added Rich Megginson as the new editor.
+
+ "Client Side Consideration" section - added a note and a question
+ concerning referral and continuation reference handling.
+
+ "Client Update Control Value" section (4.1) - clarified the meaning
+ of keepConnection and added a table summarizing the effects of
+ different values of keepConnection and changesOnly.
+
+ "Stop Client Update Request and Response" - added section 4.4
+ describing this extended operation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Megginson, et. al. Proposed Standard - Expires: May 2002 22
+\f
\ No newline at end of file
--- /dev/null
+
+
+
+
+
+
+INTERNET-DRAFT Kurt D. Zeilenga
+Intended Category: Informational OpenLDAP Foundation
+Expires in six months 17 May 2002
+
+
+ LDAPv3: Requesting Attributes by Object Class
+ <draft-zeilenga-ldap-adlist-01.txt>
+
+
+Status of this Memo
+
+ This document is an Internet-Draft and is in full conformance with all
+ provisions of Section 10 of RFC2026.
+
+ This document is intended to be, after appropriate review and
+ 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>.
+
+ 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.
+
+
+Abstract
+
+ The Lightweight Directory Access Protocol (LDAP) search operation
+ provides mechanisms for clients to request all user application
+ attributes, all operational attributes, or attributes selected by
+ their description. This document extends LDAP to provide a mechanism
+ for LDAP clients to request the return of all attributes of an object
+ class.
+
+
+
+Zeilenga Requesting Attributes by Object Class [Page 1]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-adlist-01 17 May 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.
+
+ 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. Return of all Attributes of an Object Class
+
+ This extension allows object class identifiers is to be provided in
+ 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].
+
+ 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]:
+
+ 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
+
+
+
+Zeilenga Requesting Attributes by Object Class [Page 2]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-adlist-01 17 May 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.
+
+ 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.
+
+
+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
+ security considerations.
+
+ Implementors of this (or any) LDAP extension should be familiar with
+ general LDAP general security considerations [LDAPTS].
+
+
+4. IANA Considerations
+
+ No IANA assignments are requested.
+
+ 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.
+
+
+5. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+ <Kurt@OpenLDAP.org>
+
+
+6. 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.
+
+
+
+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).
+
+ [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).
+
+
+7. Informative References
+
+ [RFC2256] Wahl, M., "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.
+
+ [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
+ http://www.openldap.org/foundation/oid-delegate.txt.
+
+ [PRIVATE] IANA, "Private Enterprise Numbers",
+ http://www.iana.org/assignments/enterprise-numbers.
+
+
+
+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 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,
+ 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 Requesting Attributes by Object Class [Page 5]
+\f
--- /dev/null
+
+
+
+
+
+
+INTERNET-DRAFT Kurt D. Zeilenga
+Intended Category: Standard Track OpenLDAP Foundation
+Expires in six months 17 May 2002
+
+
+
+ LDAP "Who am I?" Operation
+ <draft-zeilenga-ldap-authzid-06.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 Extension Working Group
+ mailing list <ietf-ldapext@netscape.com>. 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.
+
+
+Abstract
+
+ This specification provides a mechanism for Lightweight Directory
+ Access Protocol (LDAP) clients to obtain the authorization identity
+ which the server has associated with the user or application entity.
+ This mechanism is specified as an LDAP extended operation called the
+ LDAP "Who am I?" operation.
+
+
+
+Zeilenga LDAP "Who am I?" [Page 1]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-authzid-06 17 May 2002
+
+
+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 Intent of Use
+
+ This specification describes a Lightweight Directory Access Protocol
+ (LDAP) [RFC2251] extended operation which clients can use to obtain
+ the primary authorization identity in its primary form which the
+ server has associated with the user or application entity.
+
+ Servers often associate multiple authorization identities with the
+ client and each authorization identity may be represented by multiple
+ authzId [RFC2829] strings. This operation requests and returns the
+ authzId the server considers to be primary. In the specification, the
+ term "the authorization identity" and "the authzid" are to generally
+ read as "the primary authorization identity" and the "the primary
+ authzid", respectively.
+
+ This specification is intended to replace the existing [AUTHCTL]
+ mechanism which uses Bind request and response controls to request and
+ return the authorization identity. Bind controls are not protected by
+ the security layers established by the Bind operation which they are
+ transferred as part of. While it is possible to establish security
+ layers prior to the Bind operation, it is often desirable to only use
+ security layers established by the Bind operation. An extended
+ operation sent after a Bind operation is protected by the security
+ layers established by the Bind operation.
+
+ There are other cases where it is desirable to request the
+ authorization identity which the server associated with the client
+ separately from the Bind operation. For example, the "Who am I?"
+ operation can be augmented with a Proxied Authorization Control
+ [PROXYCTL] to determine the authorization identity which the server
+ associates with the identity asserted in the Proxied Authorization
+ Control. The "Who am I?" operation can also be used prior to the Bind
+ operation.
+
+ The LDAP "Who am I?" operation is named after the UNIX whoami(1)
+ command. The whoami(1) command displays the effective user id.
+
+
+2. The "Who am I?" Operation
+
+ The "Who am I?" operation is defined as an LDAP Extended Operation
+
+
+
+Zeilenga LDAP "Who am I?" [Page 2]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-authzid-06 17 May 2002
+
+
+ [RFC2251, Section 4.12] identified by the whoamiOID Object Identifier
+ (OID). This section details the syntax of the operation's whoami
+ request and response messages.
+
+ whoamiOID ::= "1.3.6.1.4.1.4203.1.11.3"
+
+
+2.1. The whoami Request
+
+ The whoami request is an ExtendedRequest with the requestName field
+ containing the whoamiOID OID and an absent requestValue field. For
+ example, a whoami request could be encoded as the sequence of octets
+ (in hex):
+
+
+2.2. The whoami Response
+
+ The whoami response is an ExtendedResponse where the responseName
+ field is absent and, if present, the response field is empty or an
+ authzId [RFC2829]. For example, a whoami response returning the
+ authzid "u:kurt@OPENLDAP.ORG" (in response to the example request)
+ would be encoded as the sequence of octets (in hex):
+
+
+
+3. Operational Semantics
+
+ The function of the "Who am I?" operation is to request that the
+ server returns the authorization identity it currently associates with
+ the client. The client requests this authorization identity by
+ issuing a whoami Request. The server responds to this request with a
+ whoami Response.
+
+ If the server is willing and able to provide the authorization
+ identity it associates with the client, the server SHALL return a
+ whoami Response with a success resultCode. If the server is treating
+ the client as an anonymous entity, the response field is empty.
+ Otherwise the server is to provide the authzId [RFC2829] representing
+ the authorization identity it currently associates with the client in
+ the response field.
+
+ If the server is unwilling or unable to provide the authorization
+ identity it associates with the client, the server SHALL return a
+ whoami Response with an appropriate non-success resultCode (such as
+ operationsError, protocolError, confidentialityRequired,
+ insufficientAccessRights, busy, unavailable, unwillingToPerform, or
+ other) and an absent response field.
+
+
+
+
+Zeilenga LDAP "Who am I?" [Page 3]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-authzid-06 17 May 2002
+
+
+ As described in [RFC2251] and [RFC2829], an LDAP session has an
+ "anonymous" association until the client has been successfully
+ authenticated using the Bind operation. Clients MUST NOT invoke the
+ "Who Am I?" operation while any Bind operation is in progress,
+ including between two Bind requests made as part of a multi-stage Bind
+ operation.
+
+
+4. Extending the "Who am I?" operation with controls
+
+ Future specifications may extend the "Who am I?" operation using the
+ control mechanism. When extended by controls, the "Who am I?"
+ operation requests and returns the authorization identity the server
+ associates with the client in a particular context indicated by the
+ controls.
+
+
+4.1. Proxied Authorization Control
+
+ The Proxied Authorization Control [PROXYCTL] is used by clients to
+ request that the operation it is attached to operates under the
+ authorization of an assumed identity. The client provides the
+ identity to assume in the Proxied Authorization request control. If
+ the client is authorized to assume the requested identity, the server
+ executes the operation as if the requested identity had issued the
+ operation.
+
+ As servers often map the asserted authzId to another identity
+ [RFC2829], it is desirable to request the server provide the authzId
+ it associates with the assumed identity.
+
+ When a Proxied Authorization Control is be attached to the "Who Am I?"
+ operation, the operation requests the return of the authzid the server
+ associates with the identity asserted in the Proxied Authorization
+ Control. The TBD result code is used to indicate that the server does
+ not allow the client to assume the asserted identity. [[Note to RFC
+ Editor: TBD is to be replaced with the name/code assigned by IANA for
+ [PROXYCTL] use.]]
+
+
+5. Security Considerations
+
+ Identities associated with users may be sensitive information. When
+ so, security layers [RFC2829][RFC2830] should be established to
+ protect this information. This mechanism is specifically designed to
+ allow security layers established by a Bind operation to protect the
+ integrity and/or confidentiality of the authorization identity.
+
+
+
+
+Zeilenga LDAP "Who am I?" [Page 4]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-authzid-06 17 May 2002
+
+
+ Servers may place access control or other restrictions upon the use of
+ this operation.
+
+ As with any other extended operations, general LDAP considerations
+ apply. These are detailed in [RFC2251], [RFC2829], and [RFC2830].
+
+
+6. IANA Considerations
+
+ No IANA assignments are requested.
+
+ This document uses the OID 1.3.6.1.4.1.4203.1.11.3 to identify the
+ LDAP "Who Am I? extended operation. This OID was assigned [ASSIGN] by
+ OpenLDAP Foundation under its IANA assigned private enterprise
+ allocation [PRIVATE] for use in this specification.
+
+
+7. Acknowledgment
+
+ This document borrows from prior work in this area including
+ "Authentication Response Control" [AUTHCTL] by Rob Weltman, Mark Smith
+ and Mark Wahl.
+
+
+8. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+ <Kurt@OpenLDAP.org>
+
+
+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.
+
+ [RFC2829] M. Wahl, H. Alvestrand, J. Hodges, RL "Bob" Morgan,
+ "Authentication Methods for LDAP", RFC 2829, June 2000.
+
+ [RFC2830] J. Hodges, R. Morgan, and M. Wahl, "Lightweight Directory
+ Access Protocol (v3): Extension for Transport Layer
+ Security", RFC 2830, May 2000.
+
+ [PROXYCTL] R. Weltman, "LDAP Proxied Authentication Control", draft-
+ weltman-ldapv3-proxy-xx.txt (a work in progress).
+
+
+
+Zeilenga LDAP "Who am I?" [Page 5]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-authzid-06 17 May 2002
+
+
+10. Informative References
+
+ [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
+ http://www.openldap.org/foundation/oid-delegate.txt.
+
+ [AUTHCTL] R. Weltman, M. Smith, M. Wahl, "LDAP Authentication
+ Response Control", draft-weltman-ldapv3-auth-response-
+ xx.txt (a work in progress).
+
+ [PRIVATE] IANA, "Private Enterprise Numbers",
+ http://www.iana.org/assignments/enterprise-numbers.
+
+
+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.
+
+ 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 "Who am I?" [Page 6]
+\f
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
-Expires: 1 October 2001 1 April 2001
+Expires in six months 17 May 2002
LDAP Cancel Extended Operation
- <draft-zeilenga-ldap-cancel-03.txt>
+ <draft-zeilenga-ldap-cancel-05.txt>
1. Status of this Memo
material or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft
- Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
+ <http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
+ Internet-Draft Shadow Directories can be accessed at
+ <http://www.ietf.org/shadow.html>.
- Copyright 2001, The Internet Society. All Rights Reserved.
+ Copyright 2002, The Internet Society. All Rights Reserved.
Please see the Copyright section near the end of this document for
more information.
-2. Abstract
+Abstract
- This specification describes an extended operation to cancel (or
- abandon) an outstanding operation. Unlike the LDAP Abandon operation
- [RFC2251] but like the DAP Abandon operation [X.511], this operation
- has a response which provides an indication of its outcome.
+ 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.
- The key words ``MUST'', ``MUST NOT'', ``REQUIRED'', ``SHALL'', ``SHALL
- NOT'', ``SHOULD'', ``SHOULD NOT'', ``RECOMMENDED'', and ``MAY'' in
Zeilenga LDAP Cancel [Page 1]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-cancel-03 1 April 2001
+INTERNET-DRAFT draft-zeilenga-ldap-cancel-05 17 May 2002
- this document are to be interpreted as described in RFC 2119
- [RFC2119].
+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].
-3. Background and Intent of Use
+ 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].
- LDAP 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.
- DAP 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.
+1. Background and Intent of Use
- The Cancel operation is intended to be used instead of the LDAP
- Abandon operation. This operation may be used to cancel both
- interrogation and update operations.
+ 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.
+ 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.
-4. Cancel Operation
+ The Cancel operation SHOULD be used instead of the LDAP Abandon
+ operation when the client needs an indication of the outcome. This
+ operation may be used to cancel both interrogation and update
+ operations.
+
+
+4. 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 ::= 1.3.6.1.4.1.4203.1.11.2
+ cancelOID OBJECT IDENTIFIER ::= IANA-ASSIGNED
cancelRequestValue ::= SEQUENCE {
cancelID MessageID
}
-4.1. Cancel Request
+4.1. Cancel Request
The Cancel request is an ExtendedRequest with the requestName field
- 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.
-4.2. Cancel Response
- A Cancel response is an ExtendedResponse where the responseName and
+Zeilenga LDAP Cancel [Page 2]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-cancel-05 17 May 2002
+ 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.
-Zeilenga LDAP Cancel [Page 2]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-cancel-03 1 April 2001
+4.2. Cancel Response
+ A Cancel response is an ExtendedResponse where the responseName and
response fields are absent.
-4.3. Additional Result Codes
+4.3. Additional Result Codes
Implementations of this specification SHALL recognize the following
additional resultCode values:
- canceled (72)
- noSuchOperation (73)
- tooLate (74)
- cannotCancel (75)
+ canceled (IANA-ASSIGNED-1)
+ noSuchOperation (IANA-ASSIGNED-2)
+ tooLate (IANA-ASSIGNED-3)
+ cannotCancel (IANA-ASSIGNED-4)
-5. Operational Semantics
+5. Operational Semantics
The function of the Cancel Operation is to request that the server
cancel an outstanding operation issued within the same session.
operation requested to be canceled.
The server SHALL return cannotCancel if the identified operation does
+
+
+
+Zeilenga LDAP Cancel [Page 3]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-cancel-05 17 May 2002
+
+
not support cancelation or the cancel operation could not be
performed. The following classes of operations are not cancelable:
- operations which establish or tear-down security services, and
-
-
-Zeilenga LDAP Cancel [Page 3]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-cancel-03 1 April 2001
-
-
- operations which abandon or cancel other operations.
Specifically, Abandon, Bind, Start TLS [RFC2830], Unbind and Cancel
contains a value of cancelOID.
-6. Security Considerations
+6. 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
cancelation when appropriate.
-7. Copyright
+7. IANA Considerations
+
+
+
+
+Zeilenga LDAP Cancel [Page 4]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-cancel-05 17 May 2002
+
+
+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:
+
+ Subject: Request for LDAP OID Registration
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@OpenLDAP.org>
+ Specification: RFCXXX
+ Author/Change Controller: IESG
+
+
+7.2. LDAP Result Codes
+
+ It is requested that IANA register the LDAP result codes:
+
+ 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:
+
+ Subject: LDAP Result Code Registration
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@OpenLDAP.org>
+ Result Code Name: canceled
+ Result Code Name: noSuchOperation
+ Result Code Name: tooLate
+ Result Code Name: cannotCancel
+ Specification: RFCXXXX
+ Author/Change Controller: IESG
+ Comments: request four consecutive result codes be assigned
+
+
+8. Acknowledgment
+
+ This document is based upon input from the IETF LDAPext working group.
+
+
+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-05 17 May 2002
+
+
+ [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
+ Protocol (v3)", RFC 2251, December 1997.
+
+ [RFC2830] J. Hodges, R. Morgan, and M. Wahl, "Lightweight Directory
+ Access Protocol (v3): Extension for Transport Layer
+ Security", RFC 2830, May 2000.
+
+ [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.
- Copyright 2001, The Internet Society. All Rights Reserved.
+
+9. Informative References
+
+ [X.511] ITU-T Rec. X.511, "The Directory: Abstract Service
+ Definition", 1993.
+
+
+11. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+ <Kurt@OpenLDAP.org>
+
+
+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
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 LDAP Cancel [Page 4]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-cancel-03 1 April 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,
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.
-8. Bibliography
- [RFC2219] S. Bradner, "Key words for use in RFCs to Indicate
- Requirement Levels", RFC 2119, March 1997.
- [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
- Protocol (v3)", RFC 2251, December 1997.
- [RFC2830] J. Hodges, R. Morgan, and M. Wahl, "Lightweight Directory
- Access Protocol (v3): Extension for Transport Layer
- Security", RFC 2830, May 2000.
- [X.511] ITU-T Rec. X.511, "The Directory: Abstract Service
- Definition", 1993. (not normative)
-9. Acknowledgment
- This document is based upon input from the IETF LDAPext working group.
-10. Author's Address
- Kurt D. Zeilenga
- OpenLDAP Foundation
- <Kurt@OpenLDAP.org>
-Zeilenga LDAP Cancel [Page 5]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga LDAP Cancel [Page 7]
\f
--- /dev/null
+
+
+
+
+
+
+INTERNET-DRAFT Editor: Kurt D. Zeilenga
+Intended Category: Standard Track OpenLDAP Foundation
+Expires in six months 17 May 2002
+
+
+ Collective Attributes in LDAP
+ <draft-zeilenga-ldap-collective-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, 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-ldapext@netscape.com>. 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.
+
+
+Abstract
+
+ X.500 collective attributes allow common characteristics to be shared
+ between collections of entries. This document summarizes the X.500
+ information model for collective attributes and describes use of
+ collective attributes in LDAP (Lightweight Directory Access Protocol).
+ This document provides schema definitions for collective attributes
+ for use in LDAP.
+
+
+
+Zeilenga draft-zeilenga-ldap-collective-07 [Page 1]
+\f
+INTERNET-DRAFT LDAP Collective Attributes 17 May 2002
+
+
+Conventions
+
+ Schema definitions are provided using LDAPv3 description formats
+ [RFC2252]. Definitions provided here are formatted (line wrapped) for
+ 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 BCP 14 [RFC2119].
+
+
+1. Introduction
+
+ In X.500, a collective attribute is "a user attribute whose values are
+ the same for each member of an entry collection" [X.501]. This
+ document details their use in the Lightweight Directory Access
+ Protocol (LDAP) [LDAPTS].
+
+
+1.1. Entry Collections
+
+ A collection of entries is a grouping of object and alias entries
+ based upon common properties or shared relationship between the
+ corresponding entries which share certain attributes. An entry
+ collection consists of all entries within scope of a collective
+ attributes subentry [SUBENTRY]. An entry can belong to several entry
+ collections.
+
+
+1.2. Collective Attributes
+
+ Attributes shared by the entries comprising an entry collection are
+ called collective attributes. Values of collective attributes are
+ visible but not updateable to clients accessing entries within the
+ collection. Collective attributes are updated (i.e. modified) via
+ their associated collective attributes subentry.
+
+ When an entry belongs to multiple entry collections, the entry's
+ values of each collective attribute are combined such that independent
+ sources of these values are not manifested to clients.
+
+ Entries can specifically exclude a particular collective attribute by
+ listing the attribute as a value of the collectiveExclusions
+ attribute. Like other user attributes, collective attributes are
+ subject to a variety of controls including access, administrative, and
+ content controls.
+
+
+
+
+
+Zeilenga draft-zeilenga-ldap-collective-07 [Page 2]
+\f
+INTERNET-DRAFT LDAP Collective Attributes 17 May 2002
+
+
+2. System Schema for Collective Attributes
+
+ The following operational attributes are used to manage Collective
+ Attributes. LDAP servers [LDAPTS] MUST act in accordance with the
+ X.500 Directory Models [X.501] when providing this service.
+
+
+2.1. collectiveAttributeSubentry
+
+ Subentries of this object class are used to administer collective
+ attributes and are referred to as collective attribute subentries.
+
+ ( 2.5.20.2 NAME 'collectiveAttributeSubentry' AUXILIARY )
+
+ A collective attribute subentry SHOULD contain at least one collective
+ attribute. The collective attributes contained within a collective
+ attribute subentry are available for finding, searching, and
+ comparison at every entry within the scope of the subentry. The
+ collective attributes, however, are administered (e.g. modified) via
+ the subentry.
+
+ Implementations of this specification SHOULD support collective
+ attribute subentries in both collectiveAttributeSpecificArea
+ (2.5.23.5) and collectiveAttributeInnerArea (2.5.23.6) administrative
+ areas [SUBENTRY][X.501].
+
+
+2.2. collectiveAttributeSubentries
+
+ The collectiveAttributeSubentries operational attribute identifies all
+ collective attribute subentries that affect the entry.
+
+ ( 2.5.18.12 NAME 'collectiveAttributeSubentries'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ USAGE directoryOperation NO-USER-MODIFICATION )
+
+
+2.3. collectiveExclusions
+
+ The collectiveExclusions operational attribute allows particular
+ collective attributes to be excluded from an entry. It MAY appear in
+ any entry and MAY have multiple values.
+
+ ( 2.5.18.7 NAME 'collectiveExclusions'
+ EQUALITY objectIdentifierMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
+ USAGE directoryOperation )
+
+
+
+Zeilenga draft-zeilenga-ldap-collective-07 [Page 3]
+\f
+INTERNET-DRAFT LDAP Collective Attributes 17 May 2002
+
+
+ The descriptor excludeAllCollectiveAttributes is associated with the
+ OID 2.5.18.0. When this descriptor or OID is present as a value of
+ the collectiveExclusions attribute, all collective attributes are
+ excluded from an entry.
+
+
+3. Collective Attribute Types
+
+ A userApplications attribute type can be defined to be COLLECTIVE
+ [RFC2252]. This indicates that the same attribute values will appear
+ in the entries of an entry collection subject to the use of the
+ collectiveExclusions attribute and other administrative controls.
+ These administrative controls MAY include DIT Content Rules, if
+ implemented.
+
+ Collective attribute types are commonly defined as subtypes of non-
+ collective attribute types. By convention, collective attributes are
+ named by prefixing the name of their non-collective supertype with
+ "c-". For example, the collective telephone attribute is named
+ c-TelephoneNumber after its non-collective supertype telephoneNumber.
+
+ Non-collective attributes types SHALL NOT subtype collective
+ attributes.
+
+ Collective attributes SHALL NOT be SINGLE-VALUED. Collective
+ attribute types SHALL NOT appear in the attribute types of an object
+ class definition.
+
+ Operational attributes SHALL NOT be defined to be collective.
+
+ The remainder of section provides a summary of collective attributes
+ derived from those defined in [X.520]. The SUPerior attribute types
+ are described in [RFC 2256] for use with LDAP.
+
+ Implementations of this specification SHOULD support the following
+ collective attributes and MAY support additional collective
+ attributes.
+
+
+3.1. Collective Locality Name
+
+ The c-l attribute type specifies a locality name for a collection of
+ entries.
+
+ ( 2.5.4.7.1 NAME 'c-l'
+ SUP l COLLECTIVE )
+
+
+
+
+
+Zeilenga draft-zeilenga-ldap-collective-07 [Page 4]
+\f
+INTERNET-DRAFT LDAP Collective Attributes 17 May 2002
+
+
+3.2. Collective State or Province Name
+
+ The c-st attribute type specifies a state or province name for a
+ collection of entries.
+
+ ( 2.5.4.8.1 NAME 'c-st'
+ SUP st COLLECTIVE )
+
+
+3.3. Collective Street Address
+
+ The c-street attribute type specifies a street address for a
+ collection of entries.
+
+ ( 2.5.4.9.1 NAME 'c-street'
+ SUP street COLLECTIVE )
+
+
+3.4. Collective Organization Name
+
+ The c-o attribute type specifies an organization name for a collection
+ of entries.
+
+ ( 2.5.4.10.1 NAME 'c-o'
+ SUP o COLLECTIVE )
+
+
+3.5. Collective Organizational Unit Name
+
+ The c-ou attribute type specifies an organizational unit name for a
+ collection of entries.
+
+ ( 2.5.4.11.1 NAME 'c-ou'
+ SUP ou COLLECTIVE )
+
+
+3.6. Collective Postal Address
+
+ The c-PostalAddress attribute type specifies a postal address for a
+ collection of entries.
+
+ ( 2.5.4.16.1 NAME 'c-PostalAddress'
+ SUP postalAddress COLLECTIVE )
+
+
+3.7. Collective Postal Code
+
+ The c-PostalCode attribute type specifies a postal code for a
+
+
+
+Zeilenga draft-zeilenga-ldap-collective-07 [Page 5]
+\f
+INTERNET-DRAFT LDAP Collective Attributes 17 May 2002
+
+
+ collection of entries.
+
+ ( 2.5.4.17.1 NAME 'c-PostalCode'
+ SUP postalCode COLLECTIVE )
+
+
+3.8. Collective Post Office Box
+
+ The c-PostOfficeBox attribute type specifies a post office box for a
+ collection of entries.
+
+ ( 2.5.4.18.1 NAME 'c-PostOfficeBox'
+ SUP postOfficeBox COLLECTIVE )
+
+
+3.9. Collective Physical Delivery Office Name
+
+ The c-PhysicalDeliveryOfficeName attribute type specifies a physical
+ delivery office name for a collection of entries.
+
+ ( 2.5.4.19.1 NAME 'c-PhysicalDeliveryOfficeName'
+ SUP physicalDeliveryOfficeName COLLECTIVE )
+
+
+3.10. Collective Telephone Number
+
+ The c-TelephoneNumber attribute type specifies a telephone number for
+ a collection of entries.
+
+ ( 2.5.4.20.1 NAME 'c-TelephoneNumber'
+ SUP telephoneNumber COLLECTIVE )
+
+
+3.11. Collective Telex Number
+
+ The c-TelexNumber attribute type specifies a telex number for a
+ collection of entries.
+
+ ( 2.5.4.21.1 NAME 'c-TelexNumber'
+ SUP telexNumber COLLECTIVE )
+
+
+3.13. Collective Facsimile Telephone Number
+
+ The c-FacsimileTelephoneNumber attribute type specifies a facsimile
+ telephone number for a collection of entries.
+
+ ( 2.5.4.23.1 NAME 'c-FacsimileTelephoneNumber'
+
+
+
+Zeilenga draft-zeilenga-ldap-collective-07 [Page 6]
+\f
+INTERNET-DRAFT LDAP Collective Attributes 17 May 2002
+
+
+ SUP facsimileTelephoneNumber COLLECTIVE )
+
+
+3.14. Collective International ISDN Number
+
+ The c-InternationalISDNNumber attribute type specifies an
+ international ISDN number for a collection of entries.
+
+ ( 2.5.4.25.1 NAME 'c-InternationalISDNNumber'
+ SUP internationalISDNNumber COLLECTIVE )
+
+
+4. Security Considerations
+
+ Collective attributes are not believed to introduce any additional
+ security considerations to LDAP [LDAPTS].
+
+
+5. IANA Considerations
+
+ It is requested that IANA register the LDAP descriptors used in this
+ document per the following registration template:
+
+ Subject: Request for LDAP Descriptor Registration
+ 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: RFCXXXX
+ Author/Change Controller: IESG
+ Comments:
+
+ NAME Type OID
+ ------------------------ ---- -----------------
+ c-FacsimileTelephoneNumber A 2.5.4.23.1
+ c-InternationalISDNNumber A 2.5.4.25.1
+ c-PhysicalDeliveryOffice A 2.5.4.19.1
+ c-PostOfficeBox A 2.5.4.18.1
+ 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-TelexNumber A 2.5.4.21.1
+ c-l A 2.5.4.7.1
+ c-o A 2.5.4.10.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.
+
+
+6. Acknowledgments
+
+ This document is based upon the ITU Recommendations for the Directory
+ [X.501][X.520].
+
+
+7. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+ <Kurt@OpenLDAP.org>
+
+
+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.
+
+ [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.
+
+ [LDAPTS] J. Hodges, R.L. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification",
+ draft-ietf-ldapbis-ldapv3-ts-xx.txt.
+
+ [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.
+
+
+9. Informative References
+
+ [X.500] "The Directory: Overview of Concepts, Models", ITU-T
+ Recommendation X.500, 1993.
+
+ [X.520] "The Directory: Selected Attribute Types", ITU-T
+ Recommendation X.520, 1993.
+
+
+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.
+
+ 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-collective-07 [Page 9]
+\f
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
-Expires: 26 December 2001 26 June 2001
+Expires in six months 17 May 2002
Feature Discovery in LDAP
- <draft-zeilenga-ldap-features-01.txt>
+ <draft-zeilenga-ldap-features-03.txt>
Status of this Memo
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
- Copyright 2001, The Internet Society. All Rights Reserved.
+ Copyright 2002, The Internet Society. All Rights Reserved.
Please see the Copyright section near the end of this document for
more information.
-1. Overview
+Abstract
+
+ The Lightweight Directory Access Protocol (LDAP) is an extensible
+ protocol with numerous elective features. This document introduces a
+ general mechanism for discovery of elective features and extensions
+ which cannot be discovered using existing mechanisms.
- 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.
-Zeilenga draft-zeilenga-ldap-features-01 [Page 1]
+Zeilenga draft-zeilenga-ldap-features-03 [Page 1]
\f
-INTERNET-DRAFT LDAP supportedFeatures 26 June 2001
+INTERNET-DRAFT LDAP supportedFeatures 17 May 2002
+
+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.
This document describes a simple, general-purpose mechanism which
- clients may use to discovery the set of features supported by a
- server.
+ clients may use to discover the set of features supported by a server.
- 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
- [RFC2119].
+ Schema definitions are provided using LDAPv3 description formats
+ [RFC2252]. Definitions provided here are formatted (line wrapped) for
+ 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 BCP 14 [RFC2119].
2. Discovery of supported features
examine the values of this attribute to determine if a particular
feature is supported by the server.
- The supportedFeatures attribute type is described [RFC2252] as
- follows:
+ The supportedFeatures attribute type is described as follows:
( 1.3.6.1.4.1.4203.1.3.5
NAME 'supportedFeatures'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
USAGE dSAOperation )
+ Servers MUST be capable of recognizing this attribute type by the name
+ 'supportedFeatures'. Servers MAY recognize the attribute type by
+ other names.
+
3. Security Considerations
believed to introduce any new security risk to LDAP.
-4. Acknowledgment
- This document is based upon input from the IETF LDAPext working group.
+Zeilenga draft-zeilenga-ldap-features-03 [Page 2]
+\f
+INTERNET-DRAFT LDAP supportedFeatures 17 May 2002
-5. Author's Address
+4. IANA Considerations
- Kurt D. Zeilenga
- OpenLDAP Foundation
- <Kurt@OpenLDAP.org>
+ It is requested that IANA register the LDAP 'supportedFeatures'
+ descriptor used in this document per the following registration
+ template:
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): supportedFeatures
+ Object Identifier: 1.3.6.1.4.1.4203.1.3.5
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@OpenLDAP.org>
+ Usage: Attribute Type
+ Specification: RFCXXXX
+ Author/Change Controller: IESG
+ This OID was assigned [ASSIGN] by OpenLDAP Foundation under its IANA
+ assigned private enterprise allocation [PRIVATE] for use in this
+ specification.
+
+
+5. Acknowledgment
+
+ This document is based upon input from the IETF LDAPext working group.
-Zeilenga draft-zeilenga-ldap-features-01 [Page 2]
-\f
-INTERNET-DRAFT LDAP supportedFeatures 26 June 2001
+6. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+ <Kurt@OpenLDAP.org>
-References
- [RFC2219] S. Bradner, "Key words for use in RFCs to Indicate
- Requirement Levels", RFC 2119, March 1997.
+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.
Definitions", RFC 2252, December 1997.
+8. Informative References
+
+
+
+
+Zeilenga draft-zeilenga-ldap-features-03 [Page 3]
+\f
+INTERNET-DRAFT LDAP supportedFeatures 17 May 2002
+
+
Full Copyright
- Copyright 2001, The Internet Society. All Rights Reserved.
+ 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
-Zeilenga draft-zeilenga-ldap-features-01 [Page 3]
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga draft-zeilenga-ldap-features-03 [Page 4]
\f
INTERNET-DRAFT Editor: Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
-Expires: 20 January 2002 20 July 2001
+Expires: 20 May 2002 20 November 2001
+
Named Subordinate References in LDAP Directories
- <draft-zeilenga-ldap-namedref-04.txt>
+ <draft-zeilenga-ldap-namedref-05.txt>
Status of this Memo
Abstract
This document details schema and protocol elements for representing
- and manipulating named subordinate references in LDAP [RFC2251]
- directories. A referral object is used to hold subordinate reference
- information in the directory. These referral objects hold one or more
- URIs [RFC2396] contained in values of the ref attribute type and are
- used to generate protocol referrals and continuations. A control,
+ and managing named subordinate references in LDAP directories.
+
+
+Conventions
Zeilenga LDAP NamedRef [Page 1]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-namedref-04 20 July 2001
+INTERNET-DRAFT draft-zeilenga-ldap-namedref-05 20 November 2001
- ManageDsaIT, is defined to allow manipulation of referral objects as
- normal objects.
+ Schema definitions are provided using LDAPv3 description formats
+ [RFC2252]. Definitions provided here are formatted (line wrapped) for
+ readability.
+
+ The key words "SHALL", "SHALL NOT", "MUST", "MUST NOT", "SHOULD",
+ "SHOULD NOT", "MAY" and "MAY NOT" used in this document are to be
+ interpreted as described in BCP 14 [RFC2119].
1. Background and Intended Usage
- The broadening of interest in LDAP directories beyond their use as
- front ends to X.500 [X.500] directories has created a need to
- represent knowledge information in a more general way. Knowledge
- information is information about one or more servers maintained in
- another server, used to link servers and services together.
+ The broadening of interest in LDAP (Lightweight Directory Access
+ Protocol) [RFC2251] directories beyond their use as front ends to
+ X.500 [X.500] directories has created a need to represent knowledge
+ information in a more general way. Knowledge information is
+ information about one or more servers maintained in another server,
+ used to link servers and services together.
+
+ This document details schema and protocol elements for representing
+ and manipulating named subordinate references in LDAP directories. A
+ referral object is used to hold subordinate reference information in
+ the directory. These referral objects hold one or more URIs [RFC2396]
+ contained in values of the ref attribute type and are used to generate
+ protocol referrals and continuations.
+
+ A control, ManageDsaIT, is defined to allow manipulation of referral
+ and other special objects as normal objects. As the name of control
+ implies, it is intended to be analogous to the ManageDsaIT service
+ option described in X.511(97) [X.511].
- This document defines a specific method of representing subordinate
- knowledge references in LDAP directories. Other forms of knowledge
- information are not detailed by this document. These forms may be
- described in subsequent documents.
+ Other forms of knowledge information are not detailed by this
+ document. These forms may be described in subsequent documents.
This document details subordinate referral processing requirements for
servers. This document does not describe protocol syntax and
to support replicated environments nor distributed operations (e.g.,
chaining of operations from one server to other servers).
- The key words "SHALL", "SHALL NOT", "MUST", "MUST NOT", "SHOULD",
- "SHOULD NOT", "MAY" and "MAY NOT" used in this document are to be
- interpreted as described in BCP 14 [RFC2119].
-
2. Schema
- The schema definitions are defined in terms of RFC 2252 [RFC2252].
-
-
2.1. The referral Object Class
A referral object is a directory entry whose structural object class
is (or is derived from) the referral object class.
+
+
+Zeilenga LDAP NamedRef [Page 2]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-namedref-05 20 November 2001
+
+
( 2.16.840.1.113730.3.2.6
NAME 'referral'
DESC 'named subordinate reference object'
The referral object class is a structural object class used to
represent a subordinate reference in the directory. The referral
-
-
-
-Zeilenga LDAP NamedRef [Page 2]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-namedref-04 20 July 2001
-
-
object class SHOULD be used in conjunction with the extensibleObject
object class to support the naming attributes used in the entry's
Distinguished Name (DN) [RFC2253]. Referral objects are directory
entries whose structural object class is (or is derived from)
referral.
- Referral objects MUST only be instantiated at DSEs immediately
- subordinate to leaf object entries within a naming context held by the
- DSA. Referral objects correspond to X.500 subordinate knowledge
- (subr) DSEs [X.501].
+ Referral objects are normally instantiated at DSEs immediately
+ subordinate to object entries within a naming context held by the DSA.
+ Referral objects are analogous to X.500 subordinate knowledge (subr)
+ DSEs [X.501].
In the presence of a ManageDsaIT control, referral objects are treated
as normal entries as described in section 3. Note that the ref
structure on the label portion of the syntax as it appears in the ref
attribute.
+
+
+Zeilenga LDAP NamedRef [Page 3]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-namedref-05 20 November 2001
+
+
If the URI contained in a ref attribute value refers to a LDAP
[RFC2251] server, it MUST be in the form of a LDAP URL [RFC2255]. The
LDAP URL SHOULD NOT contain an explicit scope specifier, filter,
empty DN parts or with explicit scope specifier is not defined by this
specification.
-
-
-Zeilenga LDAP NamedRef [Page 3]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-namedref-04 20 July 2001
-
-
Other URI schemes MAY be used so long as all operations returning
referrals based upon the value could be performed. This document does
not detail use of non-LDAP URIs. This is left to future
specifications.
- All values of a ref attribute MUST point to services which are equally
- capable of handling operations referred to these services.
-
The referential integrity of the URI SHOULD NOT be validated by the
- server holding or returning the URI (whether as part of the value of
- the attribute or as part of a referral result or search reference
+ server holding or returning the URI (whether as a value of the
+ attribute or as part of a referral result or search reference
response).
When returning a referral result or search continuation, the server
DSA (server) Information Tree. The control causes Directory-specific
entries (DSEs), regardless of type, to be treated as normal entries
allowing clients to interrogate and update these entries using LDAP
- operations. This control is analogous to the ManageDsaIT option
- described in X.511 [X.511].
+ operations.
A client MAY specify the following control when issuing an add,
compare, delete, modify, modifyDN, search request or an extended
The control type is 2.16.840.1.113730.3.4.2. The control criticality
may be TRUE or, if FALSE, absent. The control value is absent.
- When the control is present in the request, the server SHALL NOT
- generate a referral or continuation reference for any referral object
- and instead treat the referral object as a normal entry. When not
- present, referral objects SHALL be handled as described above.
Zeilenga LDAP NamedRef [Page 4]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-namedref-04 20 July 2001
+INTERNET-DRAFT draft-zeilenga-ldap-namedref-05 20 November 2001
+ When the control is present in the request, the server SHALL NOT
+ generate a referral or continuation reference based upon information
+ held in referral objects and instead SHALL treat the referral object
+ as a normal entry. The server, however, is still free to return
+ referrals for other reasons. When not present, referral objects SHALL
+ be handled as described above.
+
The control MAY cause other objects to be treated as normal entries as
defined by subsequent documents.
objectClass: referral
objectClass: extensibleObject
- While typically the DN of the referral object and the DN of the object
- in the referenced server are the same, they need not be the same.
+ Typically the DN of the referral object and the DN of the object in
+ the referenced server are the same.
If the ref attribute has multiple values, all the DNs contained within
the LDAP URLs SHOULD be equivalent. Administrators SHOULD avoid
The following sections contain specifications of how referral objects
should be used in different scenarios followed by examples that
- illustrate that usage. The scenarios described consist of referral
- operation when finding target of a non-search operation, when finding
- the base of a search operation, and when generating search references.
- Lastly, other operation processing considerations are presented.
-
- It is to be noted that, in this document, a search operation is
- conceptually divided into two distinct, sequential phases: (1) finding
- the base object where the search is to begin, and (2) performing the
- search itself. The first phase is similar to, but not the same as,
+ illustrate that usage. The scenarios described here consist of
+ referral object handling when finding target of a non-search
Zeilenga LDAP NamedRef [Page 5]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-namedref-04 20 July 2001
+INTERNET-DRAFT draft-zeilenga-ldap-namedref-05 20 November 2001
+ operation, when finding the base of a search operation, and when
+ generating search references. Lastly, other operation processing
+ considerations are presented.
+
+ It is to be noted that, in this document, a search operation is
+ conceptually divided into two distinct, sequential phases: (1) finding
+ the base object where the search is to begin, and (2) performing the
+ search itself. The first phase is similar to, but not the same as,
finding the target of a non-search operation.
It should also be noted that the ref attribute may have multiple
Also, in the context of this document, the "nearest naming context"
means the deepest context which the object is within. That is, if the
- object is within multiple naming contexts, the nearest naming context
- is the one which is subordinate to all other naming contexts the
- object is within.
-5.2. Target object considerations
- This section details referral handling for add, compare, delete,
+Zeilenga LDAP NamedRef [Page 6]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-namedref-05 20 November 2001
+ object is within multiple naming contexts, the nearest naming context
+ is the one which is subordinate to all other naming contexts the
+ object is within.
-Zeilenga LDAP NamedRef [Page 6]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-namedref-04 20 July 2001
+5.2. Target object considerations
+ This section details referral handling for add, compare, delete,
modify, and modify DN operations. If the client requests any of these
operations, there are four cases that the server must handle with
respect to the target object.
object.
The server SHOULD return the URI value contained in the ref
- attribute of the referral object.
+ attribute of the referral object appropriately modified as
+ described above.
Example: If the client issues a modify request for the target object
of "OU=People,O=MNN,c=WW", the server will return:
}
+
+
+
+Zeilenga LDAP NamedRef [Page 7]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-namedref-05 20 November 2001
+
+
Case 3: The target object is not held by the server, but the nearest
naming context contains no referral object which the target object
is subordinate to.
request as appropriate for a nonexistent target (generally return
noSuchObject).
-
-
-
-Zeilenga LDAP NamedRef [Page 7]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-namedref-04 20 July 2001
-
-
Case 4: The target object is not held by the server, but the nearest
naming context contains a referral object which the target object
is subordinate to.
modified by the alias dereferencing such that the return URL refers to
the new target object per [RFC2251, 4.1.11].
+
+
+
+Zeilenga LDAP NamedRef [Page 8]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-namedref-05 20 November 2001
+
+
Critical extensions MUST NOT be trimmed nor modified.
Case 1: The base object is not held by the server and is not within
a non-existent base which not within any naming context of the
server (generally return a superior referral or noSuchObject).
This document does not detail management or processing of superior
-
-
-
-Zeilenga LDAP NamedRef [Page 8]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-namedref-04 20 July 2001
-
-
knowledge references.
Case 2: The base object is held by the server and is a referral
object.
The server SHOULD return the URI value contained in the ref
- attribute of the referral object.
+ attribute of the referral object appropriately modified as
+ described above.
+
Example: If the client issues a subtree search in which the base
object is "OU=Roles,O=MNN,C=WW", the server will return
server SHOULD return a referral response which is constructed from
the URI portion of the ref value of the referral object.
+
+
+Zeilenga LDAP NamedRef [Page 9]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-namedref-05 20 November 2001
+
+
Example: If the client issues a base search request for
"CN=Manager,OU=Roles,O=MNN,C=WW", the server will return
of subtree, the returned LDAP URL would explicitly specify "sub"
or "one", respectively, instead of "base".
-
-
-Zeilenga LDAP NamedRef [Page 9]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-namedref-04 20 July 2001
-
-
Note that the DN part of the LDAP URL is modified such that it
refers to the appropriate entry in the referenced server.
SearchResultReference {
ldap://hostd/OU=Roles,O=MNN,C=WW??sub
}
+
+
+
+Zeilenga LDAP NamedRef [Page 10]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-namedref-05 20 November 2001
+
+
SearchResultDone (success)
One Level Example:
possible sequence is shown:
SearchResultReference {
-
-
-
-Zeilenga LDAP NamedRef [Page 10]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-namedref-04 20 July 2001
-
-
ldap://hostb/OU=People,O=MNN,C=WW??base
ldap://hostc/OU=People,O=MNN,C=WW??base
}
5.6.1 Bind
Servers SHOULD NOT return referral result code if the bind name (or
- other identity in the DN form) is (or is subordinate to) a referral
- object but MAY use the knowledge information to process the bind
- request (such as in support a future distributed operation
- specification). Where the server makes no use of the knowledge
- information, the server processes the request normally as appropriate
- for a non-existent authentication or authorization identity (e.g.
- return invalidCredentials).
+ authentication identity or authorization identity) is (or is
+ subordinate to) a referral object but MAY use the knowledge
+ information to process the bind request (such as in support a future
+ distributed operation specification). Where the server makes no use
+ of the knowledge information, the server processes the request
+ normally as appropriate for a non-existent authentication or
+ authorization identity (e.g., return invalidCredentials).
5.6.2 Modify DN
return affectsMultipleDSAs instead of entryAlreadyExists.
+
+Zeilenga LDAP NamedRef [Page 11]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-namedref-05 20 November 2001
+
+
6. Security Considerations
This document defines mechanisms that can be used to tie LDAP (and
protected from unauthorized disclosure as well.
-
-
-
-Zeilenga LDAP NamedRef [Page 11]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-namedref-04 20 July 2001
-
-
7. Acknowledgments
This document borrows heavily from previous work by IETF LDAPext
<Kurt@OpenLDAP.org>
-References
+9. Normative References
[RFC2079] M. Smith, "Definition of an X.500 Attribute Type and an
Object Class to Hold Uniform Resource Identifiers (URIs)",
RFC 2079, January 1997.
[RFC2119] S. Bradner, "Key Words for use in RFCs to Indicate
- Requirement Levels", RFC 2119 (Also BCP 14), March 1997.
+ 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.
[RFC2255] T. Howes, M. Smith, "The LDAP URL Format", RFC 2255,
December, 1997.
- [RFC2396] Berners-Lee, T., R. Fielding, L. Masinter, "Uniform Resource
- Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
- [X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts,
- Models, and Services", 1993.
- [X.501] ITU-T Rec. X.501, "The Directory: Models", 1993.
- [X.511] ITU-T Rec. X.511, "The Directory: Abstract Service
+Zeilenga LDAP NamedRef [Page 12]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-namedref-05 20 November 2001
+ [RFC2396] Berners-Lee, T., R. Fielding, L. Masinter, "Uniform Resource
+ Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
-Zeilenga LDAP NamedRef [Page 12]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-namedref-04 20 July 2001
+ [X.501] ITU-T, "The Directory: Models", X.501, 1993.
- Definition", 1993.
+10. Informative References
+
+ [X.500] ITU-T, "The Directory: Overview of Concepts, Models, and
+ Services", X.500, 1993.
+
+ [X.511] ITU-T, "The Directory: Abstract Service Definition", X.500,
+ 1993.
Copyright 2001, The Internet Society. All Rights Reserved.
-
-
-
-
-
-
-
-
-
-
-
-
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
-Expires: 26 December 2001 26 June 2001
+Expires in six months 17 May 2002
LDAPv3: All Operational Attributes
- <draft-zeilenga-ldap-opattrs-01.txt>
+ <draft-zeilenga-ldap-opattrs-03.txt>
Status of this Memo
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
- Copyright 2001, The Internet Society. All Rights Reserved.
+ Copyright 2002, The Internet Society. All Rights Reserved.
Please see the Copyright section near the end of this document for
more information.
-1. Overview
-
- X.500 [X.500] provides a mechanism for clients to request all
- operational attributes be returned with entries provided in response
- to a search operation. This mechanism is often used by clients to
- discover which operational attributes are present in an entry.
+Abstract
+ The Lightweight Directory Access Protocol (LDAP) supports a mechanism
+ for requesting the return of all user attributes but does 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-01 26 June 2001
+INTERNET-DRAFT draft-zeilenga-ldap-opattrs-03 17 May 2002
+
+
+1. Overview
+ X.500 [X.500] provides a mechanism for clients to request all
+ operational attributes be returned with entries provided in response
+ to a search operation. This mechanism is often used by clients to
+ discover which operational attributes are present in an entry.
- This documents updates LDAP [RFC2251] to provide a simple mechanism
+ 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.
- 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
- [RFC2119].
+ 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. All Operational Attributes
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 supportedFeatures [FEATURES]
+ 1.3.6.1.4.1.4203.1.5.1 as a value of the supportedFeatures [FEATURES]
attribute in the root DSE.
significant interoperability issues (this has been confirmed through
testing). Servers which have yet to implement this specification
should ignore the "+" as an unrecognized attribute description per
+
+
+
+Zeilenga LDAP All Op Attrs [Page 2]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-opattrs-03 17 May 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.
modification of existing LDAP APIs.
-
-Zeilenga LDAP All Op Attrs [Page 2]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-opattrs-01 26 June 2001
-
-
4. Security Considerations
This document provides a mechanism which clients may use to discover
operational attributes per local policy.
-5. Acknowledgment
+5. IANA Considerations
+
+ No IANA assignments are requested.
+
+ 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.
+
+
+6. Acknowledgment
The "+" mechanism is believed to have been first suggested by Bruce
Greenblatt in a November 1998 post to the IETF LDAPext Working Group
<Kurt@OpenLDAP.org>
-References
+8. Normative References
- [RFC2219] S. Bradner, "Key words for use in RFCs to Indicate
- Requirement Levels", RFC 2119, March 1997.
+ [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.
- [RFC2255] T. Howes and M. Smith, "The LDAP URL Format", RFC 2255,
- December 1997.
-
- [FEATURES] K. Zeilenga, "Feature Discovery in LDAP", draft-zeilenga-
- ldap-features-xx.txt (a work in progress).
-
- [X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts,
- Models and Service", 1993.
-
-
-Copyright 2001, 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
Zeilenga LDAP All Op Attrs [Page 3]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-opattrs-01 26 June 2001
-
-
- 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+INTERNET-DRAFT draft-zeilenga-ldap-opattrs-03 17 May 2002
+ [FEATURES] K. Zeilenga, "Feature Discovery in LDAP", draft-zeilenga-
+ ldap-features-xx.txt (a work in progress).
+9. Informative References
+ [RFC2255] T. Howes and M. Smith, "The LDAP URL Format", RFC 2255,
+ December 1997.
+ [X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts,
+ Models and Service", 1993.
+
+ [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
+ http://www.openldap.org/foundation/oid-delegate.txt.
+
+ [PRIVATE] IANA, "Private Enterprise Numbers",
+ http://www.iana.org/assignments/enterprise-numbers.
+
+
+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.
+
+ 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.
INTERNET-DRAFT Editor: Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
-Expires: 13 May 2002 13 November 2001
+Expires in six months 1 March 2002
Obsoletes: RFC 2596
Language Tags and Ranges in LDAP
- draft-zeilenga-ldap-rfc2596-00.txt
+ draft-zeilenga-ldap-rfc2596-01.txt
Status of Memo
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
- Copyright 2001, The Internet Society. All Rights Reserved.
+ Copyright 2002, The Internet Society. All Rights Reserved.
Please see the Copyright section near the end of this document for
more information.
Abstract
- This document details the use of Language Tags and Ranges in LDAP.
- This document replaces RFC 2596.
-
-
-
+ It is often desirable to to be able to indicate the natural language
+ associated with values held in a directory and to be able to query the
+ directory for values which fulfill the user's language needs. This
+ document details the use of Language Tags and Ranges in the
+ Lightweight Directory Access Protocol (LDAP).
Zeilenga Language Tags and Ranges in LDAP [Page 1]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
+INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119].
1. Background and Intended Use
- The Lightweight Directory Access Protocol (LDAP) [LDAPTS] provides a
+ The Lightweight Directory Access Protocol (LDAP) [Roadmap] provides a
means for clients to interrogate and modify information stored in a
distributed directory system. The information in the directory is
maintained as attributes of entries. Most of these attributes have
This document replaces RFC 2596. Appendix A summaries changes made
since RFC 2596.
- The remainder of this section provides a summary of Langauge Tags,
+ Appendix B discusses differences from X.500(1997) "contexts"
+ mechanism.
+
+ Appendix A and B are provided for information purposes and are not a
+ normative part of this specification.
+
+ The remainder of this section provides a summary of Language Tags,
Language Ranges, and Attribute Descriptions.
1.2. Language Ranges
- Section 2.5 of BCP 47 [RFC3066] describes the language ranges.
- Language ranges are used to specify sets of language tags.
-
- A language range matches a language tag if it exactly equals the tag,
- or if it exactly equals a prefix of the tag such that the first
- character following the prefix is "-". The special tag "*" matches
Zeilenga Language Tags and Ranges in LDAP [Page 2]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
+INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
+ Section 2.5 of BCP 47 [RFC3066] describes the language ranges.
+ Language ranges are used to specify sets of language tags.
+
+ A language range matches a language tag if it exactly equals the tag,
+ or if it exactly equals a prefix of the tag such that the first
+ character following the prefix is "-". The special tag "*" matches
all tags.
Due to restrictions upon option naming in LDAP, this document uses a
1.3. Attribute Descriptions
- An attribute consists of a type, a list of "subtyping" (or "tag")
- options for that type, and a set of one or more values. The type and
- the options are combined into the AttributeDescription, defined in
- section 4.1.5 of RFC 2251 [RFC2251]. AttributeDescription may also
- contain options which are not part of the attribute, but indicate some
- function such as the transfer encoding.
+ This section provides an overview of attributes in LDAP. LDAP
+ attributes are defined in [Models].
- In summary, an attribute with "subtyping" (or "tag") options is
- treated as a subtype of the attribute without the options. If a
- server does not support any of the options, the attribute is treated
- as an unrecognized attribute.
+ An attribute consists of a type, a set of zero or more associated
+ tagging options, and a set of one or more values. The type and the
+ options are combined into the AttributeDescription.
+ AttributeDescriptions can also contain options which are not part of
+ the attribute, but indicate some other function such as the transfer
+ encoding.
+
+ An attribute with one or more tagging options is a direct subtype of
+ each attribute of the same with all but one of the tagging options.
+ If the attribute's type is a direct subtype of some other type, then
+ the attribute is also a direct subtype of the attribute whose
+ description consists of the the supertype and all of the tagging
+ options. That is, CN;x-bar;x-foo is a direct subtype of CN;x-bar,
+ CN;x-foo, and name;x-bar;x-foo. Note that CN is a subtype of name.
+
+ If the attribute description contains an unrecognized option, the
+ attribute description is treated as an unrecognized attribute type.
As language tags are intended to stored with the attribute, they are
- to treated as "subtyping" (or "tag") options. Language range are used
- only to match against language ranges and are not stored with the
- attribute, they are not treated "subtyping" (or "tag") options but as
- detailed in Section 3 of this document.
+ to treated as tagging options as described in Section 2. Language
+ range are used only to match against language ranges and are not
+ stored with the attribute. They are not treated tagging options (nor
+ as transfer options), but as described in Section 3.
2. Use of Language Tags in LDAP
This section describes how LDAP implementations MUST interpret
+
+
+
+Zeilenga Language Tags and Ranges in LDAP [Page 3]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
+
+
language tags in performing operations.
- Servers which support storing attributes with language tag in the DIT
- SHOULD allow any attribute type it recognizes that has the Directory
- String syntax to have language tag options associated with it.
+ Servers which support storing attributes with language tag options in
+ the Directory Information Tree (DIT) SHOULD allow any attribute type
+ it recognizes that has the Directory String, IA5 String, or other
+ textual string syntax to have language tag options associated with it.
Servers MAY allow language options to be associated with other
attributes types.
with language tags in the directory.
Implementations MUST NOT otherwise interpret the structure of the tag
- when comparing two tag, and MUST treat them as simply strings of
+ when comparing two tag, and MUST treat them simply as strings of
characters. Implementations MUST allow any arbitrary string which
- conforms to the syntax defined in BCP 47 to be used as a language tag.
-
-
-
-Zeilenga Language Tags and Ranges in LDAP [Page 3]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
+ conforms to the syntax defined in BCP 47 [RFC3066] to be used as a
+ language tag.
2.1. Language Tag Options
- A language tag option associates a natural language with values for
- that attribute. An attribute description may contain multiple
- language tag options. An entry may contain multiple attributes with
- same attribute type but different language tag (and other) options.
+ A language tag option associates a natural language with values of an
+ attribute. An attribute description MAY contain multiple language tag
+ options. An entry MAY contain multiple attributes with same attribute
+ type but different combinations of language tag (and other) options.
A language tag option conforms to the following ABNF [RFC2234]:
language-tag-option = "lang-" Language-Tag
where the Language-Tag production is as defined in BCP 47 [RFC3066].
+ This production and those it imports from [RFC2234] are provided here
+ for convenience:
+
+ Language-Tag = Primary-subtag *( "-" Subtag )
+
+ Primary-subtag = 1*8ALPHA
+
+ Subtag = 1*8(ALPHA / DIGIT)
+
+ ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
+
+ DIGIT = %x30-39 ; 0-9
+
+ A language tag option is a tagging option [Models]. A language tag
+ option has no effect on the syntax of the attribute's values nor their
+ transfer encoding.
+
+
+
+
+Zeilenga Language Tags and Ranges in LDAP [Page 4]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
- A language tag option is a "subtyping" (or "tag") option [RFC2251bis].
- A language tag option has no effect on the tranfer encoding nor on the
- syntax of the attribute values.
Examples of valid AttributeDescription:
2.2. Search Filter
- If langugage tag options are present in an AttributeDescription in an
+ If language tag options are present in an AttributeDescription in an
assertion, then for each entry within scope, the values of each
attribute whose AttributeDescription consists of the same attribute
type or its subtypes and contains each of the presented (and possibly
name;lang-en-US: Billy Ray MATCHES
name;lang-en-US: Billy Bob DOES NOT MATCH (wrong value)
CN;lang-en-US: Billy Ray MATCHES
-
-
-
-Zeilenga Language Tags and Ranges in LDAP [Page 4]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
-
-
CN;lang-en-US;x-foobar: Billy Ray MATCHES
CN;lang-en;x-foobar: Billy Ray DOES NOT MATCH (differing lang-)
CN;x-foobar: Billy Ray DOES NOT MATCH (no lang-)
name: Billy Ray DOES NOT MATCH (no lang-)
SN;lang-en-GB;lang-en-US: Billy Ray MATCHES
- SN: Ray DOES NOT MATCH (wrong value)
+ SN: Ray DOES NOT MATCH (no lang-,
+ wrong value)
(Note that "CN" and "SN" are subtypes of "name".)
- Client implementors should however note that providing a language tag
- option in a search filter AttributeDescription will often filter out
- desirable values where the tag does not match exactly. For example,
- the filter (name;lang-en=Billy Ray) does NOT match the attribute
- "name;lang-en-US: Billy Ray".
+ It is noted that providing a language tag option in a search filter
+ AttributeDescription will filter out desirable values where the tag
+ does not match exactly. For example, the filter (name;lang-en=Billy
+ Ray) does NOT match the attribute "name;lang-en-US: Billy Ray".
If the server does not support storing attributes with language tag
options in the DIT, then any assertion which includes a language tag
- option will not match as it is an unrecognized attribute type. No
- error would be returned because of this; a presence filter would
+
+
+
+Zeilenga Language Tags and Ranges in LDAP [Page 5]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
+
+
+ option will not match as such it is an unrecognized attribute type.
+ No error would be returned because of this; a presence assertion would
evaluate to FALSE and all other assertions to Undefined.
If no options are specified in the assertion, then only the base
If language tag options are provided in an attribute description, then
only attributes in a directory entry whose attribute descriptions have
-
-
-
-Zeilenga Language Tags and Ranges in LDAP [Page 5]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
-
-
the same attribute type or its subtype and the provided language tags
options are to be returned. Thus if a client requests just the
attribute "name;lang-en", the server would return "name;lang-en" and
include language tag options are to be ignored, just as if they were
unknown attribute types.
+
+
+Zeilenga Language Tags and Ranges in LDAP [Page 6]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
+
+
If a request is made specifying all attributes or an attribute is
requested without providing a language tag option, then all attribute
values regardless of their language tag option are returned.
Language tag options can be present in an AttributeDescription used in
a compare request AttributeValueAssertion. This is to be treated by
servers the same as the use of language tag options in a search filter
- with an equality match, as described in section 2.2. If there is no
+ with an equality match, as described in Section 2.2. If there is no
attribute in the entry with the same subtype and language tag options,
-
-
-
-Zeilenga Language Tags and Ranges in LDAP [Page 6]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
-
-
the noSuchAttributeType error will be returned.
Thus for example a compare request of type "name" and assertion value
would fail with the noSuchAttributeType error.
If the server does not support storing attributes with language tag
+
+
+
+Zeilenga Language Tags and Ranges in LDAP [Page 7]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
+
+
options in the DIT, then any comparison which includes a language tag
option will always fail to locate an attribute, and
noSuchAttributeType will be returned.
streetAddress;lang-fr: 1 rue Universite
houseIdentifier;lang-fr: 9e etage
-
-
-
-Zeilenga Language Tags and Ranges in LDAP [Page 7]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
-
-
If a server does not support storing language tag options with
attribute values in the DIT, then it MUST treat an
AttributeDescription with a language tag option as an unrecognized
"delete", then if the stored values to be deleted have language tag
options, then those language tag options MUST be provided in the
modify operation, and if the stored values to be deleted do not have
+
+
+
+Zeilenga Language Tags and Ranges in LDAP [Page 8]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
+
+
any language tag option, then no language tag option is to be
provided.
Since the publication of RFC 2596, it has become apparent that there
is a need to provide a mechanism for a client to request attributes
based upon set of language tag options whose tags all begin with the
- same sequence of subtags.
+ same sequence of language sub-tags.
AttributeDescriptions containing language range options are intended
to be used in attribute value assertions, search attribute lists, and
description matching of a range of language tags associated with
attributes.
- A language range option conforms to the following ABNF [RFC 2234]:
+ A language range option conforms to the following ABNF [RFC2234]:
language-range-option = "lang-" [ Language-Tag "-" ]
where the Language-Tag production is as defined in BCP 47 [RFC3066].
+ This production and those it imports from [RFC2234] are provided here
+ for convenience:
- A language range option matches a langugage tag option if language
- range option less the trailing "-" matches exactly the language tag or
+ Language-Tag = Primary-subtag *( "-" Subtag )
+ Primary-subtag = 1*8ALPHA
+ Subtag = 1*8(ALPHA / DIGIT)
-Zeilenga Language Tags and Ranges in LDAP [Page 8]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
+ ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
+ DIGIT = %x30-39 ; 0-9
+ A language range option matches a language tag option if language
+ range option less the trailing "-" matches exactly the language tag or
if the language range option (including the trailing "-") matches a
prefix of the language tag option. Note that the language range
option "lang-" matches all language tag options.
Examples of valid AttributeDescription containing language range
options:
+
+
+Zeilenga Language Tags and Ranges in LDAP [Page 9]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
+
+
givenName;lang-en-
CN;lang-
O;lang-x-;x-foobar
- A language range option is not a "subtyping" (or "tag") option
- [RFC2251bis]. Attributes cannot be stored with language range
- options. Any attempt to add or update an attribute description with a
- languague range option SHALL be treated as an undefined attribute type
- and result in an error.
+ A language range option is not a tagging option. Attributes cannot be
+ stored with language range options. Any attempt to add or update an
+ attribute description with a language range option SHALL be treated as
+ an undefined attribute type and result in an error.
- A language range option has no effect on the tranfer encoding nor on
+ A language range option has no effect on the transfer encoding nor on
the syntax of the attribute values.
Servers SHOULD support assertion of language ranges for any attribute
3.1. Search Filter
- If a langugage range option is present in an AttributeDescription in
- an assertion, then for each entry within scope, the values of each
+ If a language range option is present in an AttributeDescription in an
+ assertion, then for each entry within scope, the values of each
attribute whose AttributeDescription consists of the same attribute
type or its subtypes and contains a language tag option matching the
language range option are to be returned.
CN;x-foobar: Billy Ray DOES NOT MATCH (no lang-)
name: Billy Ray DOES NOT MATCH (no lang-)
SN;lang-en-GB;lang-en-US: Billy Ray MATCHES
- SN: Ray DOES NOT MATCH (wrong value)
-
-
-
-
-Zeilenga Language Tags and Ranges in LDAP [Page 9]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
-
+ SN: Ray DOES NOT MATCH (no lang-,
+ wrong value)
(Note that "CN" and "SN" are subtypes of "name".)
evaluate to FALSE and all other assertions to Undefined.
+
+Zeilenga Language Tags and Ranges in LDAP [Page 10]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
+
+
3.2. Requested Attributes in Search
Clients can provide language range options in AttributeDescription in
Language range options can be present in an AttributeDescription used
in a compare request AttributeValueAssertion. This is to be treated
by servers the same as the use of language range options in a search
- filter with an equality match, as described in section 3.1. If there
+ filter with an equality match, as described in Section 3.1. If there
is no attribute in the entry with the same subtype and a matching
language tag option, the noSuchAttributeType error will be returned.
value "Johann", against the entry with the following attributes:
objectclass: top
-
-
-
-Zeilenga Language Tags and Ranges in LDAP [Page 10]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
-
-
objectclass: person
givenName;lang-de-DE: Johann
CN: Johann Sibelius
range option "lang-" matches any language tag option.)
However, if the client issued a compare request of type "name;lang-de"
+
+
+
+Zeilenga Language Tags and Ranges in LDAP [Page 11]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
+
+
and assertion value "Sibelius" against the above entry, the request
would fail with the noSuchAttributeType error.
the root DSE.
A server MAY restrict use of language tag options to a subset of the
- attribute types it recongizes. This document does not define a
+ attribute types it recognizes. This document does not define a
mechanism for determining which subset of attribute types can be used
with language tag options.
5. Security Considerations
- There are no known security considerations for this document. See the
- security considerations sections of [LDAPTS] for security
- considerations of LDAP in general.
+ Language tags and range options are used solely to indicate the native
+ language of values and in querying the directory for values which
+ fulfill the user's language needed. These options are not known to
+ raise specific security considerations. However, the reader should
+ consider general directory security issues detailed in the LDAP
+ technical specification [Roadmap].
-6. Acknowledgements
+6. Acknowledgments
This document is a revision of RFC 2596 by Mark Wahl and Tim Howes.
RFC 2596 was a product of the IETF ASID and LDAPEXT working groups.
This document borrows from a number of IETF documents including BCP
+ 47.
+7. Normative References
-Zeilenga Language Tags and Ranges in LDAP [Page 11]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- 47.
+Zeilenga Language Tags and Ranges in LDAP [Page 12]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
-7. References
- [RFC2119] Bradner, S., "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] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
- Access Protocol (v3)", RFC 2251, December 1997.
-
- [RFC2251bis] Sermersheim, J., "Lightweight Directory Access Protocol
- (v3)", draft-ietf-ldapbis-protocol-xx.txt (a work in
- progress).
-
[RFC3066] Alvestrand, H., "Tags for the Identification of Languages",
BCP 47 (also RFC 3066), January 2001.
- [LDAPTS] J. Hodges, R.L. Morgan, "Lightweight Directory Access
- Protocol (v3): Technical Specification",
- draft-ietf-ldapbis-ldapv3-ts-00.txt (a work in progress).
+ [Roadmap] K. Zeilenga (editor), "LDAP: Technical Specification Road
+ Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
+ progress.
+
+ [Models] K. Zeilenga (editor), "LDAP: Directory Information Models",
+ draft-ietf-ldapbis-models-xx.txt, a work in progress.
[FEATURES] K. Zeilenga, "Feature Discovery in LDAP",
draft-zeilenga-ldap-features-xx.txt (a work in progress).
-A. Differences from RFC 2596
+8. Informative References
+
+ [X.501] "The Directory: Models", ITU-T Recommendation X.501, 1997.
- This document adds support for language ranges, provides a mechansism
+
+Appendix A. Differences from RFC 2596
+
+ This document adds support for language ranges, provides a mechanism
that a client can use to discover whether a server supports language
- tags, and clarifies how attributes with multiple language tags are to
- be treated. This document is a significant rewrite of RFC 2596.
+ tags and ranges, and clarifies how attributes with multiple language
+ tags are to be treated. This document is a significant rewrite of RFC
+ 2596.
-B. Differences from X.500(1997)
+Appendix B. Differences from X.500(1997)
- X.500(1997) defines a different mechanism, contexts, as the means of
- representing language tags (codes). This section summarizes the major
- differences in approach.
+ X.500(1997) [X.501] defines a different mechanism, contexts, as the
+ means of representing language tags (codes). This section summarizes
+ the major differences in approach.
a) An X.500 operation which has specified a language code on a value
matches a value in the directory without a language code.
b) LDAP references BCP 47 [RFC3066], which allows for IANA
registration of new tags as well as unregistered tags.
c) LDAP supports language ranges.
-
-
-
-Zeilenga Language Tags and Ranges in LDAP [Page 12]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
-
-
d) LDAP does not allow language tags (and ranges) in distinguished
names.
e) X.500 describes subschema administration procedures to allow
language codes to be associated with particular attributes types.
-Copyright 2001, The Internet Society. All Rights Reserved.
+
+Zeilenga Language Tags and Ranges in LDAP [Page 13]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
+
+
+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
-Zeilenga Language Tags and Ranges in LDAP [Page 13]
+
+
+
+
+
+
+Zeilenga Language Tags and Ranges in LDAP [Page 14]
\f
--- /dev/null
+
+
+
+
+
+
+INTERNET-DRAFT Kurt D. Zeilenga
+Intended Category: Standard Track OpenLDAP Foundation
+Date: 17 May 2002 Steven Legg
+Expires in six months Adacel Technologies
+
+
+ Subentries in LDAP
+ <draft-zeilenga-ldap-subentry-05.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 Extension Working Group
+ mailing list <ietf-ldapext@netscape.com>. 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.
+
+
+Abstract
+
+ In X.500 directories, subentries are special entries used to hold
+ information associated with a subtree or subtree refinement. This
+ document adapts X.500 subentries mechanisms for use with Lightweight
+ Directory Access Protocol (LDAP).
+
+
+
+
+Zeilenga draft-zeilenga-ldap-subentry-05 [Page 1]
+\f
+INTERNET-DRAFT Subentries in LDAP 17 May 2002
+
+
+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. Overview
+
+ From [X.501]:
+ A subentry is a special kind of entry immediately subordinate to
+ an administrative point. It contains attributes that pertain to a
+ subtree (or subtree refinement) associated with its administrative
+ point. The subentries and their administrative point are part of
+ the same naming context.
+
+ A single subentry may serve all or several aspects of
+ administrative authority. Alternatively, a specific aspect of
+ administrative authority may be handled through one or more of its
+ own subentries.
+
+ Subentries in Lightweight Directory Access Protocol (LDAP) [LDAPTS]
+ SHALL behave in accordance with X.501 unless noted otherwise in this
+ specification.
+
+ In absence of the subentries control (detailed in Section 3),
+ subentries SHALL NOT be considered in one-level and subtree scope
+ search operations. For all other operations, including base scope
+ search operations, subentries SHALL be considered.
+
+
+2. Subentry Schema
+
+2.1. Subtree Specification Syntax
+
+ The Subtree Specification syntax provides a general purpose mechanism
+ for the specification of a subset of entries in a subtree of the
+ Directory Information Tree (DIT). A subtree begins at some base entry
+ and includes the subordinates of that entry down to some identified
+
+
+
+Zeilenga draft-zeilenga-ldap-subentry-05 [Page 2]
+\f
+INTERNET-DRAFT Subentries in LDAP 17 May 2002
+
+
+ lower boundary, possibly extending to the leaf entries. A subtree
+ specification is always used within a context or scope which
+ implicitly determines the bounds of the subtree. For example, the
+ scope of a subtree specification for a subschema administrative area
+ does not include the subtrees of any subordinate administrative point
+ entries for subschema administration. Where a subtree specification
+ does not identify a contiguous subset of the entries within a single
+ subtree the collection is termed a subtree refinement.
+
+ This syntax corresponds to the SubtreeSpecification ASN.1 type
+ described in [X.501], Section 11.3. This ASN.1 data type definition
+ is reproduced here for completeness.
+
+ SubtreeSpecification ::= SEQUENCE {
+ base [0] LocalName DEFAULT { },
+ COMPONENTS OF ChopSpecification,
+ specificationFilter [4] Refinement OPTIONAL }
+
+
+ LocalName ::= RDNSequence
+
+ ChopSpecification ::= SEQUENCE {
+ specificExclusions [1] SET OF CHOICE {
+ chopBefore [0] LocalName,
+ chopAfter [1] LocalName } OPTIONAL,
+ minimum [2] BaseDistance DEFAULT 0,
+ maximum [3] BaseDistance OPTIONAL}
+
+ BaseDistance ::= INTEGER (0 .. MAX)
+
+ Refinement ::= CHOICE {
+ item [0] OBJECT-CLASS.&id,
+ and [1] SET OF Refinement,
+ or [2] SET OF Refinement,
+ not [3] Refinement }
+
+ The components of SubtreeSpecification are: base, which identifies the
+ base entry of the subtree or subtree refinement, and
+ specificExclusions, minimum, maximum and specificationFilter, which
+ then reduce the set of subordinate entries of the base entry. The
+ subtree or subtree refinement contains all the entries within scope
+ that are not excluded by any of the components of the subtree
+ specification. When all of the components of SubtreeSpecification are
+ absent (i.e. when a value of the Subtree Specification syntax is the
+ empty sequence, {}), the subtree so specified implicitly includes all
+ the entries within scope.
+
+ Any particular use of this mechanism MAY impose limitations or
+
+
+
+Zeilenga draft-zeilenga-ldap-subentry-05 [Page 3]
+\f
+INTERNET-DRAFT Subentries in LDAP 17 May 2002
+
+
+ constraints on the components of SubtreeSpecification.
+
+ The LDAP syntax specification is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.45 DESC 'SubtreeSpecification' )
+
+ The native LDAP encoding of values of this syntax is defined by the
+ Generic String Encoding Rules [GSER]. Appendix A provides an
+ equivalent ABNF for this syntax.
+
+
+2.1.1. Base
+
+ The base component of SubtreeSpecification nominates the base entry of
+ the subtree or subtree refinement. The base entry may be an entry
+ which is subordinate to the root entry of the scope in which the
+ subtree specification is used, in which case the base component
+ contains a sequence of RDNs relative to the root entry of the scope,
+ or may be the root entry of the scope itself (the default), in which
+ case the base component is absent or contains an empty sequence of
+ RDNs.
+
+ Entries that are not subordinates of the base entry are excluded from
+ the subtree or subtree refinement.
+
+
+2.1.2. Specific Exclusions
+
+ The specificExclusions component of a ChopSpecification is a list of
+ exclusions that specify entries and their subordinates to be excluded
+ from the the subtree or subtree refinement. The entry is specified by
+ a sequence of RDNs relative to the base entry (i.e. a LocalName).
+ Each exclusion is of either the chopBefore or chopAfter form. If the
+ chopBefore form is used then the specified entry and its subordinates
+ are excluded from the subtree or subtree refinement. If the chopAfter
+ form is used then only the subordinates of the specified entry are
+ excluded from the subtree or subtree refinement.
+
+
+2.1.3. Minimum and Maximum
+
+ The minimum and maximum components of a ChopSpecification allow the
+ exclusion of entries based on their depth in the DIT.
+
+ Entries that are less than the minimum number of RDN arcs below the
+ base entry are excluded from the subtree or subtree refinement. A
+ minimum value of zero (the default) corresponds to the base entry.
+
+
+
+
+Zeilenga draft-zeilenga-ldap-subentry-05 [Page 4]
+\f
+INTERNET-DRAFT Subentries in LDAP 17 May 2002
+
+
+ Entries that are more than the maximum number of RDN arcs below the
+ base entry are excluded from the subtree or subtree refinement. An
+ absent maximum component indicates that there is no upper limit on the
+ number of RDN arcs below the base entry for entries in the subtree or
+ subtree refinement.
+
+2.1.4. Specification Filter
+
+ The specificationFilter component is a boolean expression of
+ assertions about the values of the objectClass attribute of the base
+ entry and its subordinates. A Refinement assertion item evaluates to
+ true for an entry if that entry's objectClass attribute contains the
+ OID nominated in the assertion. Entries for which the overall filter
+ evaluates to false are excluded from the subtree refinement. If the
+ specificationFilter is absent then no entries are excluded from the
+ subtree or subtree refinement because of their objectClass attribute
+ values.
+
+
+2.2. Administrative Role Attribute Type
+
+ The Administrative Model defined in [X.501], clause 10 requires that
+ administrative entries contain an administrativeRole attribute to
+ indicate that the associated administrative area is concerned with one
+ or more administrative roles.
+
+ The administrativeRole operational attribute is specified as follows:
+
+ ( 2.5.18.5 NAME 'administrativeRole'
+ EQUALITY objectIdentifierMatch
+ USAGE directoryOperation
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
+
+ The possible values of this attribute defined in X.501 are:
+
+ OID NAME
+ -------- -------------------------------
+ 2.5.23.1 autonomousArea
+ 2.5.23.2 accessControlSpecificArea
+ 2.5.23.3 accessControlInnerArea
+ 2.5.23.4 subschemaAdminSpecificArea
+ 2.5.23.5 collectiveAttributeSpecificArea
+ 2.5.23.6 collectiveAttributeInnerArea
+
+ Other values may be defined in other specifications. Names associated
+ with each administrative role are Object Identifier Descriptors
+ [LDAPIANA].
+
+
+
+
+Zeilenga draft-zeilenga-ldap-subentry-05 [Page 5]
+\f
+INTERNET-DRAFT Subentries in LDAP 17 May 2002
+
+
+ The administrativeRole operational attribute is also used to regulate
+ the subentries permitted to be subordinate to an administrative entry.
+ A subentry not of a class permitted by the administrativeRole
+ attribute cannot be subordinate to the administrative entry.
+
+
+2.3. Subtree Specification Attribute Type
+
+ The subtreeSpecification operational attribute is defined as follows:
+
+ ( 2.5.18.6 NAME 'subtreeSpecification'
+ SINGLE-VALUE
+ USAGE directoryOperation
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.45 )
+
+ This attribute is present in all subentries. See [X.501], clause 10.
+ Values of the subtreeSpecification attribute nominate collections of
+ entries within the DIT for one or more aspects of administrative
+ authority.
+
+
+2.4. Subentry Object Class
+
+ The subentry object class is a structural object class.
+
+ ( 2.5.20.0 NAME 'subentry'
+ SUP top STRUCTURAL
+ MUST ( cn $ subtreeSpecification ) )
+
+
+3. Subentries Control
+
+ The subentries control MAY be sent with a searchRequest to control the
+ visibility of entries and subentries which are within scope.
+ Non-visible entries or subentries are not returned in response to the
+ request.
+
+ The subentries control is an LDAP Control whose controlType is
+ 1.3.6.1.4.1.4203.1.10.1, criticality is TRUE or FALSE (hence absent),
+ and controlValue contains a BER-encoded BOOLEAN indicating visibility.
+ A controlValue containing the value TRUE indicates that subentries are
+ visible and normal entries are not. A controlValue containing the
+ value FALSE indicates that normal entries are visible and subentries
+ are not.
+
+ Note that TRUE visibility has the three octet encoding { 01 01 FF }
+ and FALSE visibility has the three octet encoding { 01 01 00 }.
+
+
+
+
+Zeilenga draft-zeilenga-ldap-subentry-05 [Page 6]
+\f
+INTERNET-DRAFT Subentries in LDAP 17 May 2002
+
+
+ The controlValue SHALL NOT be absent.
+
+ In absence of this control, subentries are not visible to singleLevel
+ and wholeSubtree scope Search requests but are visible to baseObject
+ scope Search requests.
+
+ There is no corresponding response control.
+
+ This control is not appropriate for non-Search operations.
+
+
+4. Security Considerations
+
+ Subentries often hold administrative information or other sensitive
+ information and should be protected from unauthorized access and
+ disclosure as described in [RFC2829][RFC2830].
+
+ General LDAP [LDAPTS] security considerations also apply.
+
+
+5. IANA Considerations
+
+5.1 Descriptors
+
+ It is requested that IANA register the LDAP descriptors used in this
+ document per the following registration template:
+
+ Subject: Request for LDAP Descriptor Registration
+ 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: RFCXXXX
+ Author/Change Controller: IESG
+ Comments:
+
+ NAME Type OID
+ ------------------------ ---- --------
+ accessControlInnerArea R 2.5.23.3
+ accessControlSpecificArea R 2.5.23.2
+ administrativeRole A 2.5.18.5
+ autonomousArea R 2.5.23.1
+ collectiveAttributeInnerArea R 2.5.23.6
+ 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]
+\f
+INTERNET-DRAFT Subentries in LDAP 17 May 2002
+
+
+ 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.
+
+ Other OIDs which appear in this document were either assigned by the
+ ISO/IEC Joint Technical Committee 1 - Subcommitte 6 to identify
+ elements of X.500 schema or assigned in RFC 2252 for the use described
+ here.
+
+
+6. Acknowledgment
+
+ This document is based on engineering done by IETF LDUP and LDAPext
+ Working Groups including "LDAP Subentry Schema" by Ed Reed. This
+ document also borrows from a number of ITU documents including X.501.
+
+
+7. Authors' Addresses
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ Email: Kurt@OpenLDAP.org
+
+ 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
+
+
+8. Normative References
+
+ [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.
+
+ [X.690] ITU-T, "Specification of ASN.1 encoding rules: Basic,
+ Canonical, and Distinguished Encoding Rules", X.690, 1994.
+
+ [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14 (was 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.
+
+ [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.
+
+ [LDAPTS] J. Hodges, R.L. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification",
+ draft-ietf-ldapbis-ldapv3-ts-xx.txt, a work in progress.
+
+ [GSER] S. Legg, "Generic String Encoding Rules for ASN.1 Types",
+ draft-legg-ldapext-gser--xx.txt, a work in progress.
+
+ [LDAPIANA] K. Zeilenga, "IANA Considerations for LDAP", draft-ietf-
+ ldapbis-iana-xx.txt, a work in progress.
+
+
+9. Informative References
+
+ [RFC2234] D. Crocker, P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [GCE] S. Legg, "Common Elements of GSER Encodings",
+ draft-legg-ldap-gser-abnf-xx.txt, a work in progress.
+
+ [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
+ http://www.openldap.org/foundation/oid-delegate.txt.
+
+ [PRIVATE] IANA, "Private Enterprise Numbers",
+ 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.
+
+ The LDAP-specific native string encoding for the Subtree Specification
+ syntax is specified by the Generic String Encoding Rules [GSER]. The
+ ABNF [RFC2234] in 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 SubtreeSpecification ASN.1 type may
+ be extended in future editions of [X.501], the provided ABNF should be
+ regarded as a snapshot in time. The native LDAP encoding for any
+ extension to the SubtreeSpecification 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.
+
+ SubtreeSpecification = "{" [ sp base ]
+ [ sep sp specificExclusions ]
+ [ sep sp minimum ]
+ [ sep sp maximum ]
+ [ sep sp 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
+
+ id-base = %x62.61.73.65 ; "base"
+ id-specificExclusions = %x73.70.65.63.69.66.69.63.45.78.63.6C.75.73
+ %x69.6F.6E.73 ; "specificExclusions"
+ id-minimum = %x6D.69.6E.69.6D.75.6D ; "minimum"
+ id-maximum = %x6D.61.78.69.6D.75.6D ; "maximum"
+ id-specificationFilter = %x73.70.65.63.69.66.69.63.61.74.69.6F.6E.46
+ %x69.6C.74.65.72 ; "specificationFilter"
+
+ SpecificExclusions = "{" sp SpecificExclusion
+ *( "," sp SpecificExclusion ) sp "}"
+ SpecificExclusion = chopBefore / chopAfter
+ chopBefore = id-chopBefore ":" LocalName
+ chopAfter = id-chopAfter ":" LocalName
+ id-chopBefore = %x63.68.6F.70.42.65.66.6F.72.65 ; "chopBefore"
+ id-chopAfter = %x63.68.6F.70.41.66.74.65.72 ; "chopAfter"
+
+ 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
+ Refinements = "{" [ sp Refinement
+ *( "," sp Refinement ) ] sp "}"
+ id-item = %x69.74.65.6D ; "item"
+ id-and = %x61.6E.64 ; "and"
+ id-or = %x6F.72 ; "or"
+ id-not = %x6E.6F.74 ; "not"
+
+ BaseDistance = INTEGER
+
+ The <sp>, <msp>, <sep>, <INTEGER>, <OBJECT-IDENTIFIER> and <LocalName>
+ rules are defined in [GCE].
+
+
+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.
+
+ 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-subentry-05 [Page 11]
+\f
--- /dev/null
+
+
+
+
+
+
+INTERNET-DRAFT Kurt D. Zeilenga
+Intended Category: Standard Track OpenLDAP Foundation
+Expires in six months 17 May 2002
+
+
+
+ LDAP True/False Filters
+ <draft-zeilenga-ldap-t-f-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, 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
+ mailing list <ietf-ldapext@netscape.com>. 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.
+
+
+Abstract
+
+ This document extends the Lightweight Directory Access Protocol (LDAP)
+ to support absolute True and False filters based upon similar
+ capabilities found in X.500 directory systems. The document also
+ extends the String Representation of LDAP Search Filters to support
+ these filters.
+
+
+
+Zeilenga LDAP True/False Filters [Page 1]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-t-f-02.txt 17 May 2002
+
+
+1. Background and Intended Use
+
+ The X.500 Directory Access Protocol (DAP) [X.511] supports absolute
+ 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
+ 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.
+
+ 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.
+
+ 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. Absolute True and False Filters
+
+ 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 'or' Filter consisting of an empty set of filters SHALL evaluate to
+ False. This filter is to 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]
+ attribute in the root DSE.
+
+ Clients supporting this feature SHOULD NOT use the feature unless they
+ have knowledge the server supports it.
+
+
+3. Security Considerations
+
+ The (re)introduction of absolute True and False filters does not raise
+ any new security considerations.
+
+
+
+Zeilenga LDAP True/False Filters [Page 2]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-t-f-02.txt 17 May 2002
+
+
+ Implementors of this (or any) LDAP extension should be familiar with
+ general LDAP general security considerations [LDAPTS].
+
+
+4. IANA Considerations
+
+ No IANA assignments are requested.
+
+ 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.
+
+
+5. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+ <Kurt@OpenLDAP.org>
+
+
+6. 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.
+
+ [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).
+
+ [FEATURES] K. Zeilenga, "Feature Discovery in LDAP",
+ draft-zeilenga-ldap-features-xx.txt (a work in progress).
+
+
+7. Informative References
+
+ [RFC1777] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory
+ Access Protocol", RFC 1777, March 1995.
+
+ [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
+
+
+ [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.
+
+ [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
+ http://www.openldap.org/foundation/oid-delegate.txt.
+
+ [PRIVATE] IANA, "Private Enterprise Numbers",
+ http://www.iana.org/assignments/enterprise-numbers.
+
+
+
+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.
+
+ 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 True/False Filters [Page 4]
+\f
INTERNET-DRAFT Editor: Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
-Expires: 22 April 2002 22 October 2001
+Expires in six months 17 May 2002
Obsoletes: RFC 1274
Updates: RFC 2798
-
LDAPv3: A Collection of User Schema
- <draft-zeilenga-ldap-user-schema-03.txt>
+ <draft-zeilenga-ldap-user-schema-06.txt>
Status of this Memo
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
- Copyright 2001, The Internet Society. All Rights Reserved.
+ Copyright 2002, 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 collection of user schema elements for use
- with LDAP collected from numerous sources including RFC 1274, X.501,
- and X.520.
+ with LDAP (Lightweight Directory Access Protocol) from both ITU-T
+ Recommendations for the X.500 Directory and COSINE and Internet X.500
+ pilot projects.
-Zeilenga draft-zeilenga-ldap-user-schema-03 [Page 1]
+Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 1]
\f
-INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
Conventions
[RFC2252]. Definitions provided here are formatted (line wrapped) for
readability.
- The key words "SHALL", "SHALL NOT", "MUST", "MUST NOT", "SHOULD",
- "SHOULD NOT", "MAY" and "MAY NOT" used in this document are to be
- interpreted as described in [RFC2119].
+ 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].
Table of Contents (to be expanded by editor)
2.5. caseIgnoreListSubstringsMatch
2.6. directoryStringFirstComponentMatch 5
2.7. integerOrderingMatch
- 2.7. keywordMatch
+ 2.8. keywordMatch
2.9. numericStringOrderingMatch 6
2.10. octetStringOrderingMatch
2.11. storedPrefixMatch
- 2.12. wordMatch 7
+ 2.12. wordMatch 7
3. Attribute Types
3.1. associatedDomain
3.2. associatedName
3.3. buildingName
3.3. co 8
- 3.4. destinationIndicator
3.5. documentAuthor
- 3.6. documentIdentifier 9
+ 3.6. documentIdentifier
3.7. documentLocation
- 3.8. documentPublisher
+ 3.8. documentPublisher 9
3.9. documentTitle
3.10. documentVersion
- 3.11. drink 10
- 3.12. houseIdentifier
- 3.13. homePhone
- 3.14. homePostalAddress
- 3.15. host 11
+ 3.11. drink
+ 3.12. homePhone 10
+ 3.13. homePostalAddress
+ 3.14. host
+ 3.16. info
+ 3.17. mail 11
-Zeilenga draft-zeilenga-ldap-user-schema-03 [Page 2]
+Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 2]
\f
-INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
- 3.16. info
- 3.17. mail
- 3.18. manager 12
+ 3.18. manager
3.19. mobile
3.20. organizationalStatus
- 3.21. otherMailbox
- 3.22. pager 13
+ 3.21. otherMailbox 12
+ 3.22. pager
3.23. personalTitle
- 3.24. roomNumber
+ 3.24. roomNumber 13
3.25. secretary
- 3.26. uid 14
+ 3.26. uid
3.27. uniqueIdentifier
- 3.28. userClass
- 4. Object Classes 15
+ 3.28. userClass 14
+ 4. Object Classes
4.1. account
- 4.2. document
+ 4.2. document 15
4.3. documentSeries
- 4.4. domainRelatedObject 16
+ 4.4. domainRelatedObject
4.5. friendlyCountry
- 4.6. rFC822LocalPart
- 4.7. room 17
+ 4.6. rFC822LocalPart 16
+ 4.7. room
4.8. simpleSecurityObject
- 5. Security Considerations
- 6. Acknowledgements
- 7. Author's Address
- References 18
- Full Copyright 19
+ 5. Security Considerations 17
+ 6. IANA Considerations
+ 7. Acknowledgments 19
+ 8. Author's Address
+ 9. Normative References
+ 10. Informative References
+ Full Copyright 20
1. Background and Intended Use
COSINE and Internet X.500 pilot projects [RFC1274]. This document
obsoletes RFC 1274.
- This document contains a summary of X.500 user schema [X.520] not
- included in LDAPv3 [RFC2252][RFC2256]. Some of these items were
+ This document includes a summary of X.500 user schema [X.520] not
+ previously specified for use with LDAP. Some of these items were
described in the inetOrgPerson [RFC2798] schema. This document
- supercedes these descriptions, replacing sections 9.1.3 and 9.3.3 of
+ supersedes these descriptions, replacing sections 9.1.3 and 9.3.3 of
RFC 2798.
-Zeilenga draft-zeilenga-ldap-user-schema-03 [Page 3]
+Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 3]
\f
-INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
their X.500 counterparts.
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-2.3. caseExactSubstringsMatch
+2.4. caseExactSubstringsMatch
- CaseExactSubstringsMatch determines whether the asserted value are
+ CaseExactSubstringsMatch determines whether the asserted value(s) are
substrings of an attribute value of DirectoryString syntax. The rule
is identical to the caseIgnoreSubstringsMatch [RFC2252] rule except
that case is not ignored. (Source: X.520)
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
-2.4. caseIgnoreListSubstringsMatch
+2.5. caseIgnoreListSubstringsMatch
-Zeilenga draft-zeilenga-ldap-user-schema-03 [Page 4]
+Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 4]
\f
-INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
CaseIgnoreListSubstringMatch compares the asserted substring with an
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
-2.5. directoryStringFirstComponentMatch
+2.6. directoryStringFirstComponentMatch
DirectoryStringFirstComponentMatch compares for equality the asserted
DirectoryString value with an attribute value of type SEQUENCE whose
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-2.6. integerOrderingMatch
+2.7. integerOrderingMatch
The integerOrderingMatch rule compares the ordering of the asserted
integer with an attribute value of Integer syntax. The rule returns
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
-2.7. keywordMatch
+2.8. keywordMatch
The keywordMatch rule compares the asserted string with keywords in an
attribute value of DirectoryString syntax. The rule returns TRUE if
-Zeilenga draft-zeilenga-ldap-user-schema-03 [Page 5]
+Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 5]
\f
-INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
X.520)
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-2.8. numericStringOrderingMatch
+2.9. numericStringOrderingMatch
NumericStringOrderingMatch compares the collation order of the
asserted string with an attribute value of NumericString syntax. The
that all space characters are skipped during comparison (case is
irrelevant as characters are numeric). (Source: X.520)
- ( 2.5.13.9 NAME 'NumericStringOrderingMatch'
+ ( 2.5.13.9 NAME 'numericStringOrderingMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
-2.9. octetStringOrderingMatch
+2.10. octetStringOrderingMatch
OctetStringOrderingMatch compares the collation order of the asserted
octet string with an attribute value of OCTET STRING syntax. The rule
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
-2.10. storedPrefixMatch
+2.11. storedPrefixMatch
StoredPrefixMatch determines whether an attribute value, whose syntax
is DirectoryString, is a prefix (i.e. initial substring) of the
-Zeilenga draft-zeilenga-ldap-user-schema-03 [Page 6]
+Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 6]
\f
-INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
which is a telephone number.
-2.11. wordMatch
+2.12. wordMatch
The wordMatch rule compares the asserted string with words in an
attribute value of DirectoryString syntax. The rule returns TRUE if
3. Attribute Types
- This section details attribute types for use in LDAP based upon their
- X.500 descriptions.
+ This section details attribute types for use in LDAP.
3.1. associatedDomain
3.3. buildingName
+ The buildingName attribute type specifies the name of the building
-Zeilenga draft-zeilenga-ldap-user-schema-03 [Page 7]
+Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 7]
\f
-INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
- The buildingName attribute type specifies the name of the building
where an organization or organizational unit is based. (Source: RFC
1274)
3.3. co
The co (Friendly Country Name) attribute type specifies names of
- countries in human readable format. The standard attribute country
- name must be one of the two-letter codes defined in [ISO 3166].
+ countries in human readable format. It is commonly used in
+ conjunction with the c (Country Name) [RFC2256] attribute type (which
+ restricted to one of the two-letter codes defined in [ISO3166]).
(Source: RFC 1274)
( 0.9.2342.19200300.100.1.43
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-3.4. destinationIndicator
-
- The destinationIndicator attribute type specifies (according to CCITT
- Recommendation F.1 and CCITT Recommendation F.31) the country and city
- associated with the object (the addressee) needed to provide the
- Public Telegram Service. An attribute value for Destination Indicator
- is a printable string containing only alphabetical characters.
- (Source: X.520)
-
- ( 2.5.4.27 NAME 'destinationIndicator'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{128} )
-
-
3.5. documentAuthor
The documentAuthor attribute type specifies the distinguished name of
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
-
-
-Zeilenga draft-zeilenga-ldap-user-schema-03 [Page 8]
-\f
-INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
-
-
3.6. documentIdentifier
The documentIdentifier attribute type specifies a unique identifier
3.7. documentLocation
The documentLocation attribute type specifies the location of the
+
+
+
+Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 8]
+\f
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
+
+
document original. (Source: RFC 1274)
( 0.9.2342.19200300.100.1.15 NAME 'documentLocation'
The documentVersion attribute type specifies the version number of a
document. (Source: RFC 1274)
-
-
-Zeilenga draft-zeilenga-ldap-user-schema-03 [Page 9]
-\f
-INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
-
-
( 0.9.2342.19200300.100.1.13 NAME 'documentVersion'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
( 0.9.2342.19200300.100.1.5 NAME ( 'drink' 'favouriteDrink' )
EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
-3.12. houseIdentifier
- The houseIdentifier attribute type specifies a linguistic construct
- used to identify a particular building, for example a house number or
- house name relative to a street, avenue, town or city, etc. An
- attribute value for houseIdentifier is a string, e.g. "14". (Source:
- X.520)
+Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 9]
+\f
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
+
- ( 2.5.4.51 NAME 'houseIdentifier'
- EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
-3.13. homePhone
+3.12. homePhone
The homePhone (Home Telephone Number) attribute type specifies a home
telephone number (e.g., "+44 71 123 4567") associated with a person.
SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
-3.14. homePostalAddress
+3.13. homePostalAddress
The homePostalAddress attribute type specifies a home postal address
- for an object. This should be limited to up to 6 lines of 30
-
-
-
-Zeilenga draft-zeilenga-ldap-user-schema-03 [Page 10]
-\f
-INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
-
-
+ for an object. This SHOULD be limited to up to 6 lines of 30
characters each. (Source: RFC 1274)
( 0.9.2342.19200300.100.1.39
SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
-3.15. host
+3.14. host
The host attribute type specifies a host computer. (Source: RFC 1274)
information pertinent to an object. It is RECOMMENDED that specific
usage of this attribute type is avoided, and that specific
requirements are met by other (possibly additional) attribute types.
- It is noted the description attribute [RFC2256] for specifying
- descriptive information pertinent to an object. (Source: RFC 1274)
+ Note that the description attribute type [RFC2256] is available for
+
+
+
+Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 10]
+\f
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
+
+
+ specifying descriptive information pertinent to an object. (Source:
+ RFC 1274)
( 0.9.2342.19200300.100.1.4
NAME 'info'
3.17. mail
The mail (rfc822mailbox) attribute type holds an the electronic mail
- address in RFC822 form (e.g.: user@example.com). Note that this
+ address in [RFC822] form (e.g.: user@example.com). Note that this
attribute SHOULD NOT be used to hold non-Internet addresses. (Source:
RFC 1274)
NAME ( 'mail' 'rfc822Mailbox' )
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch
-
-
-
-Zeilenga draft-zeilenga-ldap-user-schema-03 [Page 11]
-\f
-INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
-
-
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )
SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
+
+
+Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 11]
+\f
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
+
+
3.20. organizationalStatus
The organizationalStatus attribute type specifies a category by which
in academia might include undergraduate student, researcher, lecturer,
etc.
- A Directory administrator should probably consider carefully the
- distinctions between this and the title and userClass attributes.
- (Source: RFC 1274)
+ A Directory administrator SHOULD consider carefully the distinctions
+ between this and the title and userClass attributes. (Source: RFC
+ 1274)
( 0.9.2342.19200300.100.1.45
NAME 'organizationalStatus'
3.21. otherMailbox
The otherMailbox attribute type specifies values for electronic
-
-
-
-Zeilenga draft-zeilenga-ldap-user-schema-03 [Page 12]
-\f
-INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
-
-
mailbox types other than X.400 and RFC822. (Source: RFC 1274)
( 0.9.2342.19200300.100.1.22
"Prof". (Source: RFC 1274)
( 0.9.2342.19200300.100.1.40
+
+
+
+Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 12]
+\f
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
+
+
NAME 'personalTitle'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
3.24. roomNumber
The roomNumber attribute type specifies the room number of an object.
- Note that the cn (commonName) attribute should be used for naming room
- objects. (Source: RFC 1274)
+ Note that the cn (commonName) attribute type SHOULD be used for naming
+ room objects. (Source: RFC 1274)
( 0.9.2342.19200300.100.1.6
NAME 'roomNumber'
3.25. secretary
-
-
-
-Zeilenga draft-zeilenga-ldap-user-schema-03 [Page 13]
-\f
-INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
-
-
The secretary attribute type specifies the secretary of a person. The
attribute value for Secretary is a distinguished name. (Source: RFC
1274)
The Unique Identifier attribute type specifies a "unique identifier"
for an object represented in the Directory. The domain within which
the identifier is unique, and the exact semantics of the identifier,
+
+
+
+Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 13]
+\f
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
+
+
are for local definition. For a person, this might be an institution-
wide payroll number. For an organizational unit, it might be a
department code. An attribute value for uniqueIdentifier is a
directoryString. (Source: RFC 1274)
- ( 2.5.4.45 NAME 'uniqueIdentifier'
+ ( 0.9.2342.19200300.100.1.44 NAME 'uniqueIdentifier'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
The userClass attribute type specifies a category of computer user.
The semantics placed on this attribute are for local interpretation.
Examples of current usage od this attribute in academia are
-
-
-
-Zeilenga draft-zeilenga-ldap-user-schema-03 [Page 14]
-\f
-INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
-
-
undergraduate student, researcher, lecturer, etc. Note that the
- organizationalStatus attribute may now often be preferred as it makes
- no distinction between computer users and others. (Source: RFC 1274)
+ organizationalStatus attribute type is now often be preferred as it
+ makes no distinction between computer users and others. (Source: RFC
+ 1274)
( 0.9.2342.19200300.100.1.8 NAME 'userClass'
EQUALITY caseIgnoreMatch
4. Object Classes
- This section details attribute types for use in LDAP based upon their
- X.500 descriptions.
+ This section details object classes for use in LDAP.
+
4.1. account
The account object class is used to define entries representing
- computer accounts. The uid (userid) attribute should be used for
+ computer accounts. The uid (userid) attribute SHOULD be used for
naming entries of this object class. (Source: RFC 1274)
( 0.9.2342.19200300.100.4.5
MAY ( description $ seeAlso $ l $ o $ ou $ host ) )
+
+Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 14]
+\f
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
+
+
4.2. document
The document object class is used to define entries which represent
represents a series of documents (e.g., The Request For Comments
memos). (Source: RFC 1274)
-
-
-
-Zeilenga draft-zeilenga-ldap-user-schema-03 [Page 15]
-\f
-INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
-
-
( 0.9.2342.19200300.100.4.9
NAME 'documentSeries'
SUP top STRUCTURAL
The friendlyCountry object class is used to define country entries in
the DIT. The object class is used to allow friendlier naming of
- countries than that allowed by the object class country. The naming
- attribute of object class country, c (countryName), has to be a 2
- letter string defined in [ISO3166]. (Source: RFC 1274)
+ countries than that allowed by the object class country [RFC2256].
+ (Source: RFC 1274)
( 0.9.2342.19200300.100.4.18
+
+
+
+Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 15]
+\f
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
+
+
NAME 'friendlyCountry'
SUP country STRUCTURAL
MUST co )
4.6. rFC822LocalPart
The rFC822LocalPart object class is used to define entries which
- represent the local part of RFC822 mail addresses. This treats this
- part of an RFC822 address as a domain [RFC2247]. (Source: RFC 1274)
+ represent the local part of [RFC822] mail addresses. This treats this
+ part of an RFC 822 address as a domain [RFC2247]. (Source: RFC 1274)
( 0.9.2342.19200300.100.4.14
NAME 'rFC822localPart'
physicalDeliveryOfficeName $ postalAddress $
postalCode $ postOfficeBox $ preferredDeliveryMethod $
registeredAddress $ seeAlso $ sn $ street $
-
-
-
-Zeilenga draft-zeilenga-ldap-user-schema-03 [Page 16]
-\f
-INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
-
-
telephoneNumber $ teletexTerminalIdentifier $
telexNumber $ x121Address ) )
4.7. room
The room object class is used to define entries representing rooms.
- The cn (commonName) attribute should be used for naming entries of
+ The cn (commonName) attribute SHOULD be used for naming entries of
this object class. (Source: RFC 1274)
( 0.9.2342.19200300.100.4.7 NAME 'room'
4.8. simpleSecurityObject
- The simpleSecurityObject object class is used to allow an entry to
- have a userPassword attribute when an entry's principal object classes
- do not allow userPassword as an attribute type. (Source: RFC 1274)
+ The simpleSecurityObject object class is used to require an entry to
+ have a userPassword attribute when the entry's structural object class
+ does not require (or allow) the userPassword attribute. (Source: RFC
+ 1274)
+
( 0.9.2342.19200300.100.4.19 NAME 'simpleSecurityObject'
SUP top AUXILIARY
MUST userPassword )
+
+
+
+Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 16]
+\f
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
+
+
Note: Security considerations related to the use of simple
authentication mechanisms in LDAP are discussed in RFC 2829
[RFC2829].
appropriate.
-6. Acknowledgements
+6. IANA Considerations
- This document borrows from a number of IETF documents including RFC
- 1274 by Paul Barker and Steve Kille. This document also borrows from
- a number of ITU documents including X.520.
+ It is requested that 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: RFCXXXX
+ Author/Change Controller: IESG
+ Comments:
-7. Author's Address
+ The following descriptors should be added:
+ NAME Type OID
+ ------------------------ ---- ---------
+ booleanMatch M 2.5.13.13
+ caseExactMatch M 2.5.13.5
+ caseExactOrderingMatch M 2.5.13.6
+ caseExactSubstringsMatch M 2.5.13.7
+ caseIgnoreListSubstringsMatch M 2.5.13.12
+ directoryStringFirstComponentMatch M 2.5.13.31
+ integerOrderingMatch M 2.5.13.15
+ keywordMatch M 2.5.13.32
+ numericStringOrderingMatch M 2.5.13.9
+ octetStringOrderingMatch M 2.5.13.18
+ storedPrefixMatch M 2.5.13.41
+ wordMatch M 2.5.13.32
+ The following descriptors should be updated to refer to RFC XXXX.
+ NAME Type OID
+ ------------------------ ---- --------------------------
-Zeilenga draft-zeilenga-ldap-user-schema-03 [Page 17]
+
+
+Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 17]
+\f
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
+
+
+ account O 0.9.2342.19200300.100.4.5
+ associatedDomain A 0.9.2342.19200300.100.1.37
+ associatedName A 0.9.2342.19200300.100.1.38
+ buildingName A 0.9.2342.19200300.100.1.48
+ co A 0.9.2342.19200300.100.1.43
+ document O 0.9.2342.19200300.100.4.6
+ documentAuthor A 0.9.2342.19200300.100.1.14
+ documentIdentifier A 0.9.2342.19200300.100.1.11
+ documentLocation A 0.9.2342.19200300.100.1.15
+ documentPublisher A 0.9.2342.19200300.100.1.56
+ documentSeries O 0.9.2342.19200300.100.4.8
+ documentTitle A 0.9.2342.19200300.100.1.12
+ documentVersion A 0.9.2342.19200300.100.1.13
+ domainRelatedObject O 0.9.2342.19200300.100.4.17
+ drink A 0.9.2342.19200300.100.1.5
+ favouriteDrink A 0.9.2342.19200300.100.1.5
+ friendlyCountry O 0.9.2342.19200300.100.4.18
+ friendlyCountryName A 0.9.2342.19200300.100.1.43
+ homePhone A 0.9.2342.19200300.100.1.20
+ homePostalAddress A 0.9.2342.19200300.100.1.39
+ homeTelephone A 0.9.2342.19200300.100.1.20
+ host A 0.9.2342.19200300.100.1.9
+ info A 0.9.2342.19200300.100.1.4
+ mail A 0.9.2342.19200300.100.1.3
+ manager A 0.9.2342.19200300.100.1.10
+ mobile A 0.9.2342.19200300.100.1.41
+ mobileTelephoneNumber A 0.9.2342.19200300.100.1.41
+ organizationalStatus A 0.9.2342.19200300.100.1.45
+ otherMailbox A 0.9.2342.19200300.100.1.22
+ pager A 0.9.2342.19200300.100.1.42
+ pagerTelephoneNumber A 0.9.2342.19200300.100.1.42
+ personalTitle A 0.9.2342.19200300.100.1.40
+ RFC822LocalPart O 0.9.2342.19200300.100.4.14
+ RFC822Mailbox A 0.9.2342.19200300.100.1.3
+ room O 0.9.2342.19200300.100.4.7
+ roomNumber A 0.9.2342.19200300.100.1.6
+ secretary A 0.9.2342.19200300.100.1.21
+ simpleSecurityObject O 0.9.2342.19200300.100.4.19
+ singleLevelQuality A 0.9.2342.19200300.100.1.50
+ uid A 0.9.2342.19200300.100.1.1
+ uniqueIdentifier A 0.9.2342.19200300.100.1.44
+ userClass A 0.9.2342.19200300.100.1.8
+ userId A 0.9.2342.19200300.100.1.1
+
+ where Type A is Attribute, Type O is ObjectClass, and Type M
+ is Matching Rule.
+
+
+
+
+
+Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 18]
\f
-INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
+
+
+ This document make no OID assignments, it only associates LDAP schema
+ descriptions with existing elements of X.500 schema.
+7. Acknowledgments
+
+ This document borrows from a number of IETF documents including RFC
+ 1274 by Paul Barker and Steve Kille. This document also borrows from
+ a number of ITU documents including X.520.
+
+
+8. Author's Address
+
Kurt D. Zeilenga
OpenLDAP Foundation
<Kurt@OpenLDAP.org>
-References
-
- [ISO3166] International Standards Organization, "Codes for the
- representation of names of countries", ISO 3166.
+9. Normative References
[RFC822] D. Crocker, "Standard for the format of ARPA Internet text
- messages", August 1982.
+ messages", STD 11 (also RFC 822), August 1982.
[RFC1034] P.V. Mockapetris, "Domain names - concepts and facilities",
- November 1987.
-
- [RFC1274] P. Barker, S. Kille, "The COSINE and Internet X.500 Schema",
- November 1991.
+ STD 13 (also RFC 1034), November 1987.
- [RFC2219] S. Bradner, "Key words for use in RFCs to Indicate
- Requirement Levels", RFC 2119 (also BCP 14), March 1997.
+ [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC2247] S. Kille, M. Wahl, A. Grimstad, R. Huber, S. Sataluri,
"Using Domains in LDAP/X.500 Distinguished Names", January
[RFC2256] M. Wahl, "A Summary of the X.500(96) User Schema for use
with LDAPv3", RFC 2256, December 1997.
- [RFC2798] M. Smith, "The LDAP inetOrgPerson Object Class", RFC 2798,
- April 2000.
-
[RFC2829] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan,
"Authentication Methods for LDAP", RFC 2829, May 2000.
(v3): Technical Specification", draft-ietf-ldapbis-
ldapv3-ts-00.txt.
- [X.520] "The Directory: Selected Attribute Types", ITU
- Recommendation X.520, 1997.
+Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 19]
+\f
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 17 May 2002
-Zeilenga draft-zeilenga-ldap-user-schema-03 [Page 18]
-\f
-INTERNET-DRAFT LDAPv3: A Collection of User Schema 20 October 2001
+10. Informative References
+
+ [ISO3166] International Standards Organization, "Codes for the
+ representation of names of countries", ISO 3166.
+
+ [RFC1274] P. Barker, S. Kille, "The COSINE and Internet X.500 Schema",
+ November 1991.
+
+ [RFC2798] M. Smith, "The LDAP inetOrgPerson Object Class", RFC 2798,
+ April 2000.
+
+ [X.520] International Telephone Union, "The Directory: Selected
+ Attribute Types", X.520, 1997.
Full Copyright
- Copyright 2001, The Internet Society. All Rights Reserved.
+ 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
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga draft-zeilenga-ldap-user-schema-03 [Page 19]
+Zeilenga draft-zeilenga-ldap-user-schema-06 [Page 20]
\f
projects / openldap / commitdiff