>From <draft-ietf-ldup-lcup-03.txt:
>
> LDAP Client Update Protocol
>
>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
>
> The LCUP protocol is intended to allow LDAP clients to synchronize
> with the content stored by LDAP servers.
LCUP and LDAP should be spelled on on first use in body.
Normative reference to draft-ietf-ldapbis-ldapv3-ts
(or RFC 2251) added.
> 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 IETF is
> developing a LDAP replication protocol, called [LDUP], which is
> specifically designed to address this problem area.
LDUP should be spelled out on first use. [LDUP] should be
added to a new "Informative References" section.
> 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.
I suggest the following paragraph provide a synopsis of the LCUP
design, not a comparision to LDUP. Hence, I suggest the first
paragraph be deleted.
> Several features of the protocol distinguish it from LDUP
> replication. LCUP is designed such that the server does not need to
> maintain state information on behalf of the client. The clients are
> responsible for storing the information about how up to date they
> are with respect to the server's content. LCUP design avoids the
> need for LCUP-specific update agreements to be made between client
> and server prior to LCUP use. The client decides when and from where
> to retrieve the changes. LCUP design requires clients to initiate
> the update session and "pull" the changes from server.
Both of the following paragraphs should be incorporated into the
Protocol Specification.
> LCUP operations are subject to administrative and access
> control policies enforced by the server.
>
> A part of the DIT which is enabled for LCUP is referred to as an
> LCUP Context. A server may support one or more LCUP Contexts.
First use of DIT (in body of memo) should be spelled out.
Is a part a subtree?
>4. Protocol Specification
>
> This section describes the protocol elements and the protocol flow.
>
>4.1 Universally Unique Identifiers
>
> Distinguished names can change, so are therefore unreliable
> as identifiers. The server SHOULD assign a Universally Unique
> Identifier (or UUID for short) to each entry as it is created.
Does this protocol work when UUIDs are not assigned?
I believe that the protocol needs to mandate use of UUID,
that is, UUIDs are necessary to ensure interoperability.
I suggest that instead of transferring it as an attribute
(as the attribute may not be requested), that the control attached
to entry responses include the UUID. Then how the server maintains
the UUID becomes irrelevant. Then its okay for this schema to be
only recommended. Otherwise, this schema needs to be required and
the client needs to be required to always request return of this
attribute and a server always required to provide it.
> This identifier will be stored as an operational attribute of the entry,
> named `entryUUID'. The entryUUID attribute is single valued. A
> consistent algorithm for generating such universally unique
> identifiers may be standardized at some point in the future.
Subsequent introduction of a consistent algorithm would be
problematic as existing implements might use a variety of
algorithms. Fortunately there already is a algorithm which
we can RECOMMEND be used here. That is, UUIDs as defined in
ISO/IEC 11578:1996. Basically, the I-D should say
"MUST be use unique, SHOULD be generated per ISO/IEC
11578."
> 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 `universally unique entry identifier'
> EQUALITY caseIgnoreMatch
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
> SINGLE-VALUE
> NO-USER-MODIFICATION
> USAGE directoryOperation )
s/`/'/
Add:
The directoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax
and the caseIgnoreMatch matching rule are defined in [RFC2252].
Also, you need to note that this schema definition is line
wrapped for readability. Suggest OID-To-Be-Specified be
replaced with <IANA-ASSIGNED-OID>.1 (likewise elsewhere) and
then add a note to the Editor (near top of memo):
[[Note to RFC-Editor: The string <IANA-ASSIGNED-OID> is
to be replaced with the IANA assigned OID requested in
Section X.]]
Where section X is the IANA Considerations section (which should
be added). I can offer text for this section if necessary
(or you can use draft-zeilenga-ldap-*.txt as examples).
Note that the next (and final) revision of draft-ietf-ldapbis-iana
will have a "LDAP Protocol Mechansims" registry. It will be
required to register OIDs of Controls and Extended Operations.
Schema for entryCSN should be provided as OPTIONAL.
>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:
Need reference to X.680.
> LCUPCookie ::= SEQUENCE {
> scheme LDAPOID,
> value OCTET STRING OPTIONAL
> }
>
> scheme - this is the OID which identifies the format of the value.
Spell out OID on first use.
> 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.
I will separately comment on cookie schemes.
> 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.
s/a full/full/
> Further uses of the LCUP Cookie value are described below.
>
>4.3 Additional LDAP Result Codes defined by LCUP
>
> The LDAP result code names and numbers defined in the following
> table are to be replaced with IANA assigned result code names and
> numbers per draft-ietf-ldapbis-iana-xx.txt.
I suggest the above sentence be incorporated into an "IANA
Considerations" section (see draft-zeilenga-ldap-cancel-xx.txt
for example).
Regardless, add:
Implementations of this specification SHALL recognize the
following additional resultCode values:
> lcupResourcesExhausted (TBD) the server is running out of
> resources
Seems like a general purpose service code could be returned instead.
> lcupSecurityViolation (TBD) the client is suspected of malicious
> actions
Seems like a general purpose security code could be returned instead.
> lcupInvalidCookie (TBD) invalid cookie was supplied by the
> client - both/either the scheme
> and/or the value part was invalid
Seems like protocolError or lcupUnsupportedScheme should be returned
instead.
> lcupUnsupportedScheme (TBD) The scheme part of the cookie is a
> valid OID but is not supported by
> this server
> lcupClientDisconnect (TBD) client requested search termination
> using the LDAP Cancel extended
> operation request [CANCEL]
[CANCEL] requires the canceled resultCode be returned.
> lcupReloadRequired (TBD) 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 if the
> server's data was reloaded since the
> last synchronization session
>
> The uses of these codes are described below.
>
>4.4 Client Update Control Value
>
> A client initiates a synchronization session with a server by
> attaching a clientUpdate control to an LDAP searchRequest message.
This would be better worded:
A client initiates a synchronization session with a server by
issuing an LDAP searchRequest with includes a clientUpdate
control.
> The client SHOULD specify entryUUID in the attributes list in the
> searchRequest message. 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 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:
Reference to X.690 here. Also, the control should be encoded
per Section 5.1 of RFC 2251.
> ClientUpdateControlValue ::= SEQUENCE {
> updateType ENUMERATED {
> synchronizeOnly (0),
> synchronizeAndPersist (1),
> persistOnly (2) },
> sendCookieInterval INTEGER OPTIONAL,
> 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 that 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 that satisfy the search
> criteria.
>
> sendCookieInterval û (optional) the server SHOULD send the cookie
s/û/-/ (ASCII)
SHOULD misused here. This should define the semantics of
the field. The RECOMMENDATION that servers implement this
semantic should be stated separately.
> back in the entryUpdate control value for every
> sendCookieInterval number of SearchResultEntry PDUs returned to
> the client. For example, if the value is 5, the server SHOULD
> send the cookie back in the entryUpdate control value for every 5
> search results returned to the client. If this value is absent,
> zero or less than zero, the server chooses the interval.
>
> 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 resultCode set to the value of
> lcupInvalidCookie. 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 resultCode set to the
> value of lcupUnsupportedScheme.
>
> 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 that describes the LCUP state of the returned
> entry. To represent a deleted entry, the server attaches an
> entryUpdate control to the corresponding SearchResultEntry. The
> SearchResultEntry corresponding to a deleted entry MUST contain a
> valid DN and SHOULD contain a valid UUID but, to reduce the amount
> of data sent to the client, it SHOULD not contain any other
> attributes.
s/SHOULD/MUST/
The DN provided may not be same as known previously to the client.
Hence, the UUID is necessary to communicate exactly which entry
needs to be deleted. Additionally, the client needs to be warned
that a new entry with same DN may have been created and, as changes
may be sent out of order, may receive the new entry before the
old entry is deleted.
> Furthermore, the server may elect to periodically return to the
> client the cookie that represents the state of the client's data.
How does the server send a new cookie when it has no entry to send?
> This information is useful in case the client crashes or gets
> disconnected. The client MAY specify how often to receive the cookie
> by the use of the sendCookieInterval in the clientUpdate control
> value (see above). If the client does not specify a value, the
> server will determine the interval.
>
> 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:
BER per Section 5.1 of RFC 2251, please.
Add reference to X.690.
> EntryUpdateControlValue ::= SEQUENCE {
> stateUpdate BOOLEAN,
> entryDeleted BOOLEAN,
> cookie LCUPCookie OPTIONAL
> }
BOOLEANs should have default values and be optional. Only
sent if value isn't default.
> 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, which should contain a valid LDAPDN in
> the objectName field, and MAY contain an entryUUID attribute, but
> SHOULD NOT contain any other attributes. 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 that 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
>
> 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 that is not success or lcupClientDisconnect,
>
>
>
> 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 {
> cookie LCUPCookie OPTIONAL
> }
>
> cookie - the LCUP cookie value that represents the current state of
> the client's data. Although this value is OPTIONAL, it MUST be set
> in the ClientUpdateDoneControlValue if the SearchResultDone
> resultCode is success or lcupClientDisconnect. 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) with a resultCode of lcupResourcesExhausted. 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. 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 instead.
>
>4.7 Client Initiated Termination
>
> 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 an LDAP Cancel operation [CANCEL]. The server
> responds immediately with a LDAP Cancel response [CANCEL]. 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.
>
> If the client is not interested in the state information, it can
> simply abandon the search operation or disconnect from the server.
>
>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 optional clientUpdateDone
> control attached. The resultCode in the SearchResultDone
> mesasge SHOULD be set to lcupResourcesExhausted or
> lcupSecurityViolation depending on the reason for termination.
> *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 an LDAP Cancel operation.
> *S->C If the server receives the LDAP Cancel op, it will immediately
> send back the LDAP Cancel response
> *S->C If the server sent the LDAP Cancel response, the server MAY
> send any pending SearchResultEntry PDUs in its outgoing queue
> *S->C If the server sent the LDAP Cancel response, after the server
> sends the response and any pending SearchResultEntry PDUs, the
> server sends the SearchResultDone message with the
> clientUpdateDone control attached. The resultCode in the
> SearchResultDone message will be either lcupClientDisconnect
> or some LDAP error code (not success).
> 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. If
> synchronization was successful, the resultCode in the
> SearchResultDone message should be success.
> *S->C If an invalid cookie is specified, the server sends the
> SearchResultDone message with the resultCode set to
> lcupInvalidCookie.
> *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 the
> resultCode set to lcupReloadRequired.
> *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 successfully, 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 resultCode in the
> SearchResultDone message is set to success. If the resultCode
> is not success, the server may OPTIONALLY attach the
> clientUpdateDone control to the SearchResultDone message.
> The client stores the cookie received from the server until
> the next synchronization session.
> *C->S If the resultCode in the SearchResultDone message 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 the resultCode set to
> lcupResourcesExhausted or lcupSecurityViolation depending on
> the reason for termination.
> *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 an LDAP Cancel operation to the server to terminate the
> synchronization session.
> S->C Responds with an LDAP Cancel response, followed optionally by
> SearchResultEntry PDUs, followed by a SearchResultDone with
> the clientUpdateDone control optionally attached. If the
> control is present, it contains the cookie that represents the
> current state of the client's data. The value of the
> resultCode in the SearchResultDone message will be either
> lcupClientDisconnect or some other LDAPResult resultCode (not
> success). 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.
Why?
It seems quite reasonable for implementations to support
size and time limits during persistent operations.
>4.10 Changes vs. Operations
>
> A server that supports UUIDs SHOULD communicate a modifyDN
> operation by sending the client the current form of the entry (with
> its new DN) along with an entryUUID attribute. A server that does
> not support UUIDs SHOULD communicate a modifyDN operation by sending
> the client a deletion for the previous DN followed by an entry for
> the new DN. Note that for servers that do not support UUIDs, no
> guarantees are made about the correctness of the client state in the
> presence of modifyDN operations.
Hence, UUIDs support should be mandated.
> Communicating modifyDN operations by sending a delete of the old DN
> followed by an entry with the new DN makes it impossible for an LCUP
> client to distinguish between a modifyDN operation, which is one
> atomic operation, and an delete operation followed by an add of a
> new entry. The loss of information about atomicity may cause
> problems for some LCUP clients. For example, when an entry is
> renamed, a client that manages resources such as a person's mailbox
> might delete the mailbox and everything in it instead of merely
> changing the name associated with the mailbox.
>
> Also note that regardless of how a modifyDN operation is
> communicated to the client, 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.
This is problematic and may lead to incorrect synchronization.
Consider a subtree at base cn=A, with child cn=B,cn=A, which is
moved to cn=C. Then new entry is added at cn=A and child
cn=B,cn=C moved back to cn=B,cn=A. If the entry for the
rename of the child is sent previous to the rename of the
parent, then the client would not pick up on the move.
I don't have a solution to offer... yet.
>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
This section is not consistent with RFC 2251.
> 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 the server recongize the control, it MUST make use of it.
If the client provides a set of recongized controls which don't
make sense to the client, the server should return an error.
> 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.
s/SHOULD/MUST/
How does this control interact with existing search controls?
Paging? Sorting? Matched Values? Duplicate entries? etc.
>5. Additional Features
>
> 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.
Add informative reference.
> 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.
Add informative reference.
> 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 UUID 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
>
> 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 regular LDAP
> clients that can deal with the limitations of the LDAP protocol will
> implement LCUP.
But LCUP places undue restrictions on size and time limits...
>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
>
> Clients SHOULD always specify entryUUID in the SearchRequest
> attribute list.
>
> 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.
>
> 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 UUID 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 UUID rather than 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).
Are servers allowed to send continuation references at anytime?
How do they notify the client that a reference presently sent
has been modified or deleted?
Seems to me, like aliases, it may be best to say LCUP control
implies ManageDsaIT (at least when it comes to subordinate
references).
> The client may receive a referral (Referral [RFC2251 SECTION
> 4.1.11]) when the search base is a subordinate reference, and this
> will end the operation.
A referral can be returned for many reasons. Also, it should
be stated that the client may chase the referral and, in doing
so, initiates a new LCUP synchronization operation.
> 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.
The first sentence is oddly worded. I suggest the paragraph
be replaced with:
LCUP design does not consider issues assoicated with alias
dereferencing in search. Clients MUST specify derefAliases
as either neverDerefAliases or derefFindingBaseObj. Servers
are to return protcolError if the client specifies either
derefInSearching or derefAlways.
>
> 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, 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.
>
> Some clients may wish to perform an initial synchronization in order
> to prime a cache or establish a baseline set of entries, then look
> for changes after that. The recommended way to do this is to first
> issue an LCUP search with the updateType field of the clientUpdate
> control value set to synchronizeOnly, then after that search
> successfully completes, immediately issue an LCUP search with the
> updateType field of the clientUpdate control value set to
> synchronizeAndPersist.
>
> Some clients may have unreliable connections, for example, a
> wireless device or a WAN connection. These clients may want to
> insure that the cookie is returned often in the entryUpdate control
> value, so that if they have to reconnect, they do not have to
> process many redundant entries. These clients should set the
> sendCookieInterval in the clientUpdate control value to a low
> number, perhaps even 1. Also, some clients may have a limited
> bandwidth connection, and may not want to receive the cookie very
> often, or even at all (however, the cookie is always sent back in
> the clientUpdateDone control value upon successful completion).
> These clients should set the sendCookieInterval in the clientUpdate
> control value to a high number.
>
>7. Server Implementation Considerations
>
> Servers SHOULD support UUIDs. Otherwise, it will be very difficult
> to support modifyDN operations. Adding support for UUIDs should be
> seen as a necessary component of LCUP.
s/SHOULD/MUST/
> 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
> 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
>
> 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. Normative 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.
>
> [CANCEL] K. Zeilenga, "LDAP Cancel Extended Operation",
> draft-zeilenga-ldap-cancel-xx.txt, a work in progress.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature