WDIFF

draft-ietf-ldup-lcup-02.txt --> draft-ietf-ldup-lcup-04.txt

LDUP
Internet Draft R. Megginson, Editor
Document: <draft-ietf-ldup-lcup-02.txt> draft-ietf-ldup-lcup-04.txt M. Smith
Category: Proposed Standard Netscape
Expires: July 2003 Communications
Corp.
O. Natkovich
Yahoo
J. Parham
Microsoft
Corporation
November 2001

February 2003

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]. RFC 2026 [RFC2026].

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts 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.
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-
Draft Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Abstract

This document defines the LDAP Lightweight Directory Access Protocol
(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.

Conventions used in this document

Megginson, et. al. Expires - August 2003 [Page 1]
LDAP Client Update Protocol February 2003

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]. RFC 2119 [RFC2119].

Table of Contents

1. Overview......................................................3
2. Specification of Protocol Elements............................4
2.1 Universally Unique Identifiers.............................4
2.2 LCUP Scheme and LCUP Cookie................................5
2.3 LCUP Context...............................................5
2.4 Additional LDAP Result Codes defined by LCUP...............5
2.5 Sync Request Control.......................................6
2.6 Sync Update Control........................................7
2.7 Sync Done Control..........................................7
3. Protocol Usage and Flow.......................................7
3.1 LCUP Search Requests.......................................8
3.1.1 Initial Synchronization and Full Resync................8
3.1.2 Incremental or Update Synchronization..................9
3.1.3 Persistent Only........................................9
3.2 LCUP Search Responses......................................9
3.2.1 Sync Update Informational Responses...................10
3.2.2 Cookie Return Frequency...............................10
3.2.3 Definition of an Entry That Has Entered the Result Set11
3.2.4 Definition of an Entry That Has Changed...............12
3.2.5 Definition of an Entry That Has Left the Result Set...12
3.2.6 Results For Entries Present in the Result Set.........12
3.2.7 Results For Entries That Have Left the Result Set.....13
3.3 Responses Requiring Special Consideration.................14
3.3.1 Returning Results During the Persistent Phase.........14
3.3.2 No Mixing of Sync Phase with Persist Phase............14
3.3.3 Returning Updated Results During the Sync Phase.......14
3.3.4 Operational Attributes and Administrative Entries.....15
3.3.5 Virtual Attributes....................................15
3.3.6 Modify DN and Delete Operations Applied to Subtrees...16
3.3.7 Convergence Guarantees................................16
3.4 LCUP Search Termination...................................16
3.4.1 Server Initiated Termination..........................16
3.4.2 Client Initiated Termination..........................17
3.5 Protocol Flow.............................................17
3.6 Size and Time Limits......................................18
3.7 Operations on the Same Connection.........................18
3.8 Interactions with Other Controls..........................18
4. Client Side Considerations...................................18
4.1 Using Cookies with Different Search Criteria..............18
4.2 Renaming the Base Object..................................19

Megginson, et. al. Expires - August 2003 [Page 2]
LDAP Client Update Protocol February 2003

4.3 Use of Persistent Searches With Respect to Resources......19
4.4 Continuation References to Other LCUP Contexts............19
4.5 Referral Handling.........................................19
4.6 Multiple Copies of Same Entry During Sync Phase...........19
4.7 Handling Server Out of Resources Condition................20
5. Server Implementation Considerations.........................20
5.1 Server Support for UUIDs..................................20
5.2 Example of Using an RUV as the Cookie Value...............20
5.3 Cookie Support Issues.....................................20
5.3.1 Support for Multiple Cookie Schemes...................20
5.3.2 Information Contained in the Cookie...................21
5.4 Persist Phase Response Time...............................21
5.5 Scaling Considerations....................................21
5.6 Alias Dereferencing.......................................22
6. Synchronizing Heterogeneous Data Stores......................22
Security Considerations.........................................22
Normative References............................................22
Informative References..........................................23
Acknowledgments.................................................23
Author's Addresses..............................................23
Full Copyright Statement........................................24
Appendix - Features Left Out of LCUP............................25

1. Overview

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 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 receive
notification about the changes that occur while it is on-
line. 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 is connected to the corporate network.

- applications 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 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

Megginson, et. al. Expires - August 2003 [Page 3]
LDAP Client Update Protocol February 2003

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 that protocol, called LDUP [RFC3384],
which is being defined by specifically designed to address this problem area.

There are currently several protocols in use for LDAP client server
synchronization. While each protocol addresses the LDUP IETF
working needs of a
particular group should be used for this purpose.

Several features of clients (e.g., on-line clients or off-line
clients), none satisfies the protocol distinguish it from LDUP
replication. First, the server does not maintain any state
information on behalf requirements of its clients. The all 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 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

LCUP is designed such that the server can define a naming context or some part thereof to
participate in LCUP. This document will refer does not need to this as an LCUP
Context. For example, LDUP defines a replica, a part maintain state
information on behalf of the DIT
which may participate in replication. client. The LCUP context may be
coincident with clients are responsible for
storing the replicated area, depending on information about how up to date they are with respect to
the server's
implementation. It is assumed that most server implementations of content. LCUP will make use of design avoids the server's underlying replication mechanism,
but this does not have need for LCUP-specific
update agreements to be LDUP compliant.

4. Protocol Specification

This section describes the protocol elements made between client 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 prior to each
entry as it is created. This identifier will be stored as an
operational attribute of the entry, named `entryUUID'. LCUP
use. The entryUUID
attribute is single valued. If the client wants decides when and from where to use entryUUID, it
should supply entryUUID in retrieve the list of attributes changes.
LCUP design requires clients to return in initiate the update session and
"pull" the changes from server.

LCUP search (described below). operations are subject to administrative and access control
policies enforced by the server.

2. Specification of Protocol Elements

The following sections define the new elements required to use this
protocol.

2.1 Universally Unique Identifiers

Distinguished names can change, so are therefore unreliable as
identifiers. A consistent algorithm Universally Unique Identifier (or UUID for generating such unique
identifiers may short)
MUST be standardized at some point in the future. used to uniquely identify entries used with LCUP. The definition UUID
is part of the entryUUID Sync Update control value (see below) returned with
each search result. The server SHOULD provide the UUID as a single
valued operational attribute type, written using of the
BNF form entry (e.g. "entryUUID"). We
RECOMMEND that the server provides a way to do efficient (i.e.
indexed) searches for values of AttributeDescription described UUID e.g. by using a search filter
like (entryUUID=<some UUID value>) to quickly search for and retrieve
an entry based on its UUID. Servers SHOULD use a UUID format as
specified 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 [UUID]. The UUID used by LCUP is a value of the
following ASN.1 type:

Megginson, et. al. Expires - August 2003 [Page 4]
LDAP Client Update Protocol February 2003

LCUPUUID ::= OCTET STRING

2.2 LCUP Scheme and 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. Each cookie format is
uniquely identified by its scheme. The LCUP Cookie Scheme is a value of the
following ASN.1 type:

LCUPCookie

LCUPScheme ::= SEQUENCE {
scheme LDAPOID,
value OCTET STRING OPTIONAL
}

scheme - this LDAPOID

This is the OID which identifies the format of the LCUP Cookie value.
The scheme OID, like as 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

The LCUP Cookie is a value - this of the following ASN.1 type:

LCUPCookie ::= OCTET STRING

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 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

Further uses of the LCUP Cookie value are described below.

4.3

2.3 LCUP Cookie Schemes Operational Attribute

The OIDs Context

A part of the supported DIT which is enabled for 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 is referred to as the baseObject for a
search request that contains an LCUP clientUpdate control. If
Context. A server may support one or more LCUP Contexts. For
example, a
client wants to determine what server with two naming contexts may support LCUP in one
naming context but not the other, or support different LCUP cookie
schemes are supported, it in each naming context. Each LCUP Context MAY use a base object
different cookie scheme. An LCUP search to read will not cross an LCUP
Context boundary, but will instead return a SearchResultReference
message, with the lcupCookieScheme attribute
from LDAP URL specifying the entry that will be used same host and port as
currently being searched, and with the baseObject in subsequent baseDN set to the baseDN of
the new LCUP sessions, Context. The client is then query responsible for issuing
another search using the root DSE new baseDN, and possibly a different cookie
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 Context uses a different entries as
possible.
Each value of the attribute will be cookie. The client is
responsible for maintaining a list of OIDs of the cookie
schemes followed by the DN mapping of the LCUP context which supports LDAP URL to its
corresponding cookie.

2.4 Additional LDAP Result Codes defined by LCUP

Megginson, et. al. Expires - August 2003 [Page 5]
LDAP Client Update Protocol February 2003

Implementations of this specification SHALL recognize the
schemes. following
additional resultCode values. 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 LDAP result code names and numbers
defined in the last OID will following table are to be replaced with IANA assigned
result code names and numbers per RFC 3383 [RFC3383].

lcupResourcesExhausted (TBD) the LCUP
Context DN. If the attribute server is present in a regular directory
entry in an LCUP Context, the values corresponding to DNs other than running out of resources
lcupSecurityViolation (TBD) the LCUP Context containing client is suspected of malicious
actions
lcupInvalidData (TBD) invalid scheme or cookie was supplied by
the entry MAY be omitted.

4.4 Client Update Control Value

A client initiates a synchronization session with
lcupUnsupportedScheme (TBD) The cookie scheme is a server valid OID but is
not supported by
attaching a clientUpdate control this server
lcupReloadRequired (TBD) indicates that client data needs to a search operation. The search
specification determines the part of be
reinitialized. This reason is returned
if the directory server does not contain
sufficient information tree
(DIT) the client wishes to synchronize with,
the set of attributes
it is interested in and client or if the amount of server's data was
reloaded since the client is willing to
receive. The clientUpdate control contains the client's last synchronization specification.
session

The controlType field for the

Megginson, et. al. Proposed Standard - Expires: May 2002 4

clientUpdate control is ClientUpdateControlOID (to be assigned). uses of these codes are described below.

2.5 Sync Request Control

The controlValue Sync Request Control is an OCTET STRING, whose contents are LDAP Control [RFC2251, Section 4.1.2]
where the bytes of controlType is the BER encoding of object identifier IANA-ASSIGNED-OID.1
and the following:

ClientUpdateControlValue controlValue, an OCTET STRING, contains a BER-encoded
syncRequestControlValue.

syncRequestControlValue ::= SEQUENCE {
updateType ENUMERATED {
synchronizeOnly
syncOnly (0),
synchronizeAndPersist
syncAndPersist (1),
persistOnly (2) },
sendCookieInterval INTEGER OPTIONAL,
scheme LCUPScheme OPTIONAL,
cookie LCUPCookie OPTIONAL
}

updateType - specifies the type of update requested by the client

synchronizeOnly

sendCookieInterval - the server sends all SHOULD send the data needed to
synchronize cookie back in the client with
Sync Update control value (defined below) for every
sendCookieInterval number of SearchResultEntry and
SearchResultReference PDUs returned to the server, then closes client. For example, if
the
connection

synchronizeAndPersist - value is 5, the server sends all the data needed to
synchronize the client with SHOULD send the server, then leaves open cookie back in the
connection, sending Sync
Update control value for every 5 search results returned to the client any new added, modified,
client. If this value is absent, zero or
deleted entries which satisfy the search criteria.

persistOnly - less than zero, 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
chooses the search
criteria.

cookie interval.

Megginson, et. al. Expires - a value that represents August 2003 [Page 6]
LDAP Client Update Protocol February 2003

The Sync Request Control is only applicable to the current state searchRequest
message. Use of this control is described below.

2.6 Sync Update Control

The Sync Update Control is an LDAP Control [RFC2251, Section 4.1.2]
where the client's
data. If a cookie controlType is provided, the server MUST use object identifier IANA-ASSIGNED-OID.2
and the enclosed controlValue, an OCTET STRING, contains a BER-encoded
syncUpdateControlValue.

syncUpdateControlValue ::= SEQUENCE {
stateUpdate BOOLEAN,
entryUUID LCUPUUID OPTIONAL, -- REQUIRED for entries --
UUIDAttribute AttributeType OPTIONAL,
entryLeftSet BOOLEAN,
persistPhase BOOLEAN,
scheme throughout LCUPScheme OPTIONAL,
cookie LCUPCookie OPTIONAL
}

The field UUIDAttribute contains the duration name or OID of the LCUP session or until attribute
that the client should use to perform searches for entries based on
the UUID. The client should be able to use it in an
LCUP context boundary is crossed, since a new cookie may equality search
filter e.g. "(<uuid attribute>=<entry UUID value>)" and should be
required
able to use it in that case. If the value or scheme part attribute list of the cookie
is invalid, search request to return
its value. The UUIDAttribute field may be omitted if the server MUST return immediately does
not support searching on the UUID values.

The Sync Update Control is only applicable to SearchResultEntry and
SearchResultReference messages. Although entryUUID is OPTIONAL, it
MUST be used with SearchResultEntry messages. Use of this control is
described below.

2.7 Sync Done Control

The Sync Done Control is an LDAP Control [RFC2251, Section 4.1.2]
where the controlType is the object identifier IANA-ASSIGNED-OID.3
and the controlValue contains a BER-encoded syncDoneValue.

syncDoneValue ::= SEQUENCE {
scheme LCUPScheme OPTIONAL,
cookie LCUPCookie OPTIONAL
}

The Sync Done Control is only applicable to SearchResultDone message with the clientUpdateDone message.
Use of this control
attached is described below.

3. Protocol Usage and Flow

Megginson, et. al. Expires - August 2003 [Page 7]
LDAP Client Update Protocol February 2003

3.1 LCUP Search Requests

A client initiates a synchronization or persistent search session
with the reason set a server by attaching a Sync Request control to an LDAP
searchRequest message. The search specification determines the value part
of lcupInvalidCookie
(see below). Also, the LDAP result code MUST be
unwillingToPerform. If directory information tree (DIT) the scheme part client wishes to
synchronize with, the set of attributes it is interested in and the
amount of data the cookie client is a valid
OID, but willing to receive. The Sync Request
control contains the client's request specification.

If there is not supported, an error condition, the server MUST return immediately
with return a
SearchResultDone message with the clientUpdateDone control
attached with the reason resultCode set to an error code.
This table maps a condition to its corresponding behavior and
resultCode.

Condition Behavior or resultCode

Sync Request Control is not Server behaves as [RFC2251, Section
supported 4.1.2] - specifically, if the value
criticality of
lcupUnsupportedScheme (see below). Also, the LDAP result code
MUST be unwillingToPerform.

If the cookie control is omitted, FALSE,
the server MAY use any scheme it
supports.

4.5 Entry Update Control Value

In response to the client's synchronization request, will process the server
returns one request
as a normal search request

Scheme is not supported lcupUnsupportedScheme

A control value field is lcupInvalidData
invalid (e.g. illegal
updateType, 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

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

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 scheme 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 a valid OID, or 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 invalid)

Server is running out of resource
lcupSecurityViolation (2) the lcupResourcesExhausted
resources

Server suspects client is suspected of lcupSecurityViolation
malicious
actions
lcupInvalidCookie (3) invalid cookie was supplied by behavior (frequent
connects/disconnects, etc.)

The server cannot bring the lcupReloadRequired
client - both/either up to date (server data
has been reloaded, or other
changes that prevent
convergence)

3.1.1 Initial Synchronization and Full Resync

For an initial synchronization or full resync, the scheme
and/or fields of the value part was invalid
lcupUnsupportedScheme (4) The Sync
Request control MUST be specified as follows:

Megginson, et. al. Expires - August 2003 [Page 8]
LDAP Client Update Protocol February 2003

updateType - MUST be set to syncOnly or syncAndPersist
sendCookieInterval - MAY be set
scheme part of - MAY be set - if set, the cookie is a
valid OID but is not supported by server MUST use this specified
scheme or return lcupUnsupportedScheme (see above) - if not set, the
server
lcupClientDisconnect (5) client requested search termination
using MAY use any scheme it supports.
cookie - MUST NOT be set

If the stopClientUpdate request
(defined below)
lcupReloadRequired (6) indicates that was successful, the client data needs will receive results as
described in the section "LCUP Search Responses" below.

3.1.2 Incremental or Update Synchronization

For an incremental or update synchronization, the fields of the Sync
Request control MUST be specified as follows:

updateType - MUST be set to syncOnly or syncAndPersist
sendCookieInterval - MAY be reinitialized. This reason is
returned if set
scheme - MUST be set
cookie - MUST be set

The client SHOULD always use the server does not
contain sufficient information to
synchronize latest cookie it received from the client or that
server.

If the
server's data request was reloaded since successful, the
last synchronization session

reasonText - The reasonText field client will receive results as
described in the section "LCUP Search Responses" below.

3.1.3 Persistent Only

For persistent only search request, the fields of this construct may, at the
server's option, Sync Request
MUST be used specified as follows:

updateType - MUST be set to return a string containing a textual,
human-readable (terminal control and page formatting characters
should persistOnly
sendCookieInterval - MAY be avoided) error diagnostic. As set
scheme - MAY be set - if set, the server MUST use this error diagnostic is specified
scheme or return lcupUnsupportedScheme (see above) - if not standardized, implementations MUST NOT rely on set, the values
returned. If
server MAY use any scheme it supports.
cookie - MAY be set, but the server chooses not to return a textual
diagnostic, MUST ignore it

If the reasonText field of request was successful, the
ClientUpdateDoneControlValue MUST contain a zero length string.
The reasonText should be limited to characters client will receive results as
described in the range 0x00 section "LCUP Search Responses" below.

3.2 LCUP Search Responses

In response to
0x7F.

cookie - the client's LCUP cookie value request, the server returns zero or
more SearchResultEntry or SearchResultReference PDU that represents fits the current
client's specification, followed by a SearchResultDone PDU. The
behavior is as specified in [RFC2251 Section 4.5]. Each
SearchResultEntry or SearchResultReference PDU also contains a Sync
Update control that describes the LCUP state of the client's data. Although this value is OPTIONAL, it MUST be set returned entry.

Megginson, et. al. Proposed Standard Expires - Expires: May 2002 7 August 2003 [Page 9]
LDAP Client Update Protocol February 2003

The SearchResultDone PDU contains a Sync Done control. The following
sections specify behaviors in addition to [RFC2251 Section 4.5].

3.2.1 Sync Update Informational Responses

The server may use the ClientUpdateDoneControlValue if Sync Update control to return information not
related to a particular entry. It MAY do this at any time to return
a cookie to the reason is lcupSuccess client, or
lcupClientDisconnect and the LDAP search result code is success.
This provides a good "checksum" of what to inform the server thinks client that the state sync phase
of the client is. If some error occurred, either an LDAP a syncAndPersist search
error (e.g. insufficientAccessRights) or an LCUP error (e.g.
lcupUnsupportedScheme), is complete and the cookie persist phase has
begun. It MAY be omitted.

If server resources become tight, do this during the server can terminate one or
more search operations by sending persist phase even though no entry
has changed that would have normally triggered a SearchResultDone message response. In order
to do this it is REQUIRED to return the
client(s). Unless the client sets following:

- A SearchResultEntry PDU with the updateType objectName field set to
persistOnly, the server attaches a clientUpdateDone control that
contains the cookie that corresponds to DN of
the current state baseObject of the
client's data search request and the with an empty attribute
list.
- A Sync Update control value of with the reason field is fields set to
lcupResourcesExhausted. A server the following:
stateUpdate - MUST be set policy is used to decide which
searches to terminate. This can also TRUE
entryUUID - SHOULD be used as a security mechanism set to disconnect clients that are suspected the UUID of malicious actions, but
if the server can infer that baseObject of the client is malicious,
search request
entryLeftSet - MUST be set to FALSE
persistPhase - MUST be FALSE if the server
should return lcupSecurityViolation search is in the reason field sync phase
of the
response.

4.7 Stop Client Update Request a request, and Response

The Stop Client Update operation MUST be TRUE if the search is an LDAPv3 Extended Operation
[RFC2251, Section 4.12] and in the
persist phase
UUIDAttribute - SHOULD only be set if this is identified by either the first
result returned or if the OBJECT IDENTIFIER
stopClientUpdateRequestOID (to attribute has changed
scheme - MUST be assigned). This section details
the syntax of set if the protocol.

An LDAPv3 Extended Request cookie is defined in [LDAPv3] as follows:

ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
requestName [0] LDAPOID,
requestValue [1] OCTET STRING OPTIONAL
} set and the cookie format
has changed; otherwise, it MAY be omitted
cookie - SHOULD be set

If the client needs server merely wants to return a cookie to terminate the synchronization process and client, it
wishes to obtain
should return as above with the cookie that represents the current state of its
data, it issues field set.

During a stopClientUpdateRequest extended operation. The
operation carries syncAndPersist request, the following data. The extended operation
requestValue is an OCTET STRING, whose contents are server MUST return as above
immediately after the bytes last entry of the
BER encoding sync phase has been sent and
before the first entry of the following:

StopClientUpdateRequestValue ::= MessageID

StopClientUpdateRequestValue - persist phase has been sent. In this
case, the message ID of persistPhase field MUST be set to TRUE. This lets the search
client know that
included the original clientUpdate control

The server responds immediately with a stopClientUpdateResponse
extended operation that carries no data, sync phase is complete 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. persist phase is
starting.

3.2.2 Cookie Return Frequency

The server
SHOULD send as few cookie field of these remaining SearchResultEntry PDUs as
possible. Finally, the server sends the message SearchResultDone
with the clientUpdateDone Sync Update control attached. The value of the reason

Megginson, et. al. Proposed Standard - Expires: May 2002 8 MAY be set in any
returned result, during both the clientUpdateDone control value MUST be either an error code
(some value other than lcupSuccess) or lcupClientDisconnect. sync phase and the persist phase.
The
stopClientUpdateResponse is sent only to satisfy LDAP requirement
that every server must issue an extended response for each extended
request it receives.

If should return the cookie to the client often enough for
the client is not interested to resync in the state information, it can
simply abandon a reasonable period of time in case the
search operation is disconnected or disconnect from otherwise terminated. The
sendCookieInterval field in the server. Sync Request control is a suggestion

Megginson, et. al. Expires - August 2003 [Page 10]
LDAP Client Update Protocol February 2003

to the server of how often to return the cookie in the Sync Update
control. The server SHOULD respect this value.

The requestName portion scheme field of the stopClientUpdate must Sync Update control value MUST be set if the
OID stopClientUpdateOID (to
cookie is set and the cookie format has changed; otherwise, it MAY be assigned). The requestValue
omitted.

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
message ID corresponding Sync Update control value, so
that if they have to reconnect, they do not have to process many
redundant entries. These clients should set the client's search request. If sendCookieInterval
in the
message ID is Sync Request control value to a low number, perhaps even 1.
Some clients may have a limited bandwidth connection, and may not valid,
want to receive the server MUST send cookie very often, or even at all (however, the
cookie is always sent back to in the client an
LDAP error code of unwillingToPerform.

4.8 Protocol Flow

The client server interaction can proceed Sync Done control value upon
successful completion). These clients should set the
sendCookieInterval in three different ways
depending on the client's requirements. Protocol flows beginning
with an asterisk (*) are optional or conditional.

If Sync Request control value to a high
number.

A reasonable behavior of the client's intent server is not to synchronize return the cookie only when
data but to trigger
actions in response to directory modifications, the protocol
proceeds as follows:

C->S Sends a search operation with LCUP context has changed, even if the client has
specified a clientUpdate control attached.
The search specification determines frequent sendCookieInterval. If nothing has changed, the part of
server can probably save some bandwidth by not returning the DIT cookie.

3.2.3 Definition of an Entry That Has Entered the
client wishes Result Set

An entry SHALL BE considered to synchronize with and have entered the client's search
result set of attributes it
is interested in. The updateType field if one of the control value
should be set to persistOnly.
*S->C If there following conditions is an error (invalid search scope, invalid cookie) met:

- During the server returns sync phase for an incremental sync operation, the appropriate error codes and terminates entry
is present in the request (SearchResultDone message with optional
clientUpdateDone control)
S->C Sends change notification search result set but was not present before; this
can be due to the client for each change to entry being added via an LDAP Add operation, or by
the
data within entry being moved into the client's search specification. Each
SearchResultEntry may have result set by an entryUpdate control attached.
*S->C If the server starts to run out of resources LDAP Modify DN
operation, or by some modification to the client is
suspected of malicious actions, entry that causes it to
enter the server SHOULD terminate result set (e.g. adding an attribute value that matches the
clients search operation filter), or by sending some meta-data change that causes the
entry to enter the client a
SearchResultDone message with clientUpdateDone control
attached. The result set (e.g. relaxing of some access control contains
that permits the reason field set entry to be visible to
lcupResourcesExhausted or lcupSecurityViolation depending on the reason client)

- During the persist phase for termination. The server MAY provide more
details to a persistent search operation, the client via
entry enters the reasonText field of search result set; this can be due to the control.
*C->S If entry
being added via an LDAP Add operation, or by the client receives lcupResourcesExhausted error from entry being moved
into the
server, it MUST wait for a while before attempting another
synchronization session with result set by an LDAP Modify DN operation, or by some
modification to the server. It is RECOMMENDED entry that clients use an exponential backoff strategy.
C->S The client terminates causes it to enter the search. The client can do this by
abandoning result set
(e.g. adding an attribute value that matches the clients search operation, disconnecting from the
server,
filter), or by sending some meta-data change that causes the stopClientUpdate extended operation.
*S->C If entry to enter
the server receives result set (e.g. relaxing of some access control that permits the stopClientUpdate extended op, it
will immediately send back
entry to be visible to the stopClientUpdate extended op client)

Megginson, et. al. Proposed Standard Expires - Expires: May 2002 9

response
*S->C If the client sent the stopClientUpdate extended op, August 2003 [Page 11]
LDAP Client Update Protocol February 2003

3.2.4 Definition of an Entry That Has Changed

An entry SHALL BE considered to be changed if one or more of the
server MAY send any pending SearchResultEntry PDUs
attributes in its
outgoing queue
*S->C If the client sent attribute list in the stopClientUpdate extended op, after search request have been
modified. For example, if the
server sends search request listed the response attributes
"cn sn uid", and any pending SearchResultEntry
PDUs, the server sends there is an entry in the SearchResultDone message client's search result set
with the
clientUpdateDone control attached. The value of the reason
field of "cn" attribute that has been modified, the clientUpdateDone control value will entry is
considered to be either
lcupClientDisconnect modified. The modification may be due to an LDAP
Modify operation or by some lcup error code (not
lcupSuccess).
S->C Stops sending changes change to the client and closes meta-data for the connection.

If entry
(e.g. virtual attributes) that causes some change to the client's intent value of the
specified attributes.

The converse of this is that an entry SHALL NOT BE considered to synchronize with be
changed if none of the server and then
disconnect, attributes in the attribute list of the protocol proceeds as follows:

C->S Sends a search operation with
request are modified attributes of the clientUpdate control
attached. The entry. For example, if the
search request listed the attributes "cn sn uid", and there is an
entry in the client's search specification determines result set with the part "foo" attribute that
has been modified, and none of the
DIT "cn" or "sn" or "uid" attributes
have been modified, the client wishes entry is NOT considered to synchronize with, be changed.

3.2.5 Definition of an Entry That Has Left the Result Set

An entry SHALL BE considered to have left the client's search result
set if one of
attributes it the following conditions is interested in and met:

- During the amount of data sync phase for an incremental sync operation, the
client is willing to receive. If this entry
is not present in the initial
synchronization session, search result set but was present before; this
can be due to the client either does not provide a
cookie entry being deleted via an LDAP Delete operation,
or provides a cookie with no value; otherwise, by the
cookie field of entry leaving the control is result set via an LDAP Modify DN
operation, or by some modification to the cookie received from entry that causes it to
leave the server at result set (e.g. changing/removing an attribute value so
that it no longer matches the end of client's search filter), or by some
meta-data change that causes the last synchronization session. If entry to leave the scheme field result set (e.g.
adding of some access control that denies the cookie was provided, entry to be visible to
the server MUST
use that scheme throughout client)

- During the duration of persist phase for a persistent search operation, the LCUP session
entry leaves the search result set; this can be due to the entry
being deleted via an LDAP Delete operation, or
until by the entry leaving
the result set via an LCUP boundary is crossed, since LDAP Modify DN operation, or by some
modification to the server will
usually require a different cookie in entry that case anyway. (Note causes it to leave the result set
(e.g. changing/removing an attribute value so that it no longer
matches the client's search filter), or by some meta-data change that
causes the client can synchronize with different servers during
different synchronization sessions.) The updateType field of entry to leave the control value is result set (e.g. adding of some access
control that denies the entry to be visible to synchronizeOnly.
*S->C If there is an error (invalid search scope, invalid cookie) the server returns client).

3.2.6 Results For Entries Present in the appropriate error codes and terminates Result Set

Megginson, et. al. Expires - August 2003 [Page 12]
LDAP Client Update Protocol February 2003

An entry SHOULD be returned as present under the following
conditions:

- The request (SearchResultDone message with optional
clientUpdateDone control)
*S->C If no cookie is specified in the clientUpdate control, an initial synchronization or if
the value field of full resync request
and the cookie entry is empty, the server sends all
data that matches present in the client's search specification followed
by the SearchResultDone message with a clientUpdateDone
control attached. result set
- The control contains request is an incremental synchronization and the cookie that
corresponds to entry has
changed or entered the current state of result set since the client's data last sync
- The search is in the persist phase and the
reason flag set to lcupSuccess.
*S->C If an invalid cookie is specified, entry enters the server sends result
set or changes

For a SearchResultEntry return, the
SearchResultDone message with clientUpdateDone control
attached. The reason field fields of the Sync Update control is
value MUST be set as follows:

stateUpdate - MUST be set to FALSE
entryUUID - MUST be set to
lcupInvalidCookie and the reasonText field MAY contain
explanation UUID of the error.
*S->C If a valid cookie entry
entryLeftSet - MUST be set to FALSE
persistPhase - MUST be set to FALSE if during the sync phase or
TRUE if during the persist phase
UUIDAttribute - SHOULD only be set if this is specified and either the data that matches first
result returned or if the
search specification attribute has been reloaded or changed
scheme - as above
cookie - as above

The searchResultReference return will look the same, except that the server does
entryUUID is not required. If it is specified, it MUST contain enough state information to synchronize the client,
the server sends a SearchResultDone message with
clientUpdateDone control attached. The reason field
UUID of the
control is set to lcupReloadRequired and DSE holding the reasonText field

Megginson, et. al. Proposed Standard - Expires: May 2002 10

MAY contain explanation of reference knowledge.

3.2.7 Results For Entries That Have Left the error.
*S->C If Result Set

An entry SHOULD be returned as having left the cookie is valid and result set under the client
following conditions:

- The request is up to date, an incremental synchronization during the
server sends a success response to sync phase
and the client.
S->C If entry has left the cookie result set
- The search is valid in the persist phase and there is data to the entry has left the
result set

An entry SHOULD be sent, returned as having left the
server sends result set under the modified entries to
following conditions:

- The entry has left the client. Each result set as a result of an LDAP Delete or
LDAP Modify DN operation against the entry itself (i.e. not as a
result of an operation against its parent or ancestor)

For a SearchResultEntry contains return where the attributes requested by entry has left the
client in result
set, the search specification regardless fields of whether they
were modified. An entryUpdate control with the entryDeleted
field Sync Update control value MUST be set to TRUE as
follows:

stateUpdate - MUST be attached to every deleted entry. The
server may also periodically attach an entryUpdate control to
the entries sent set to the client FALSE

Megginson, et. al. Expires - August 2003 [Page 13]
LDAP Client Update Protocol February 2003

entryUUID - MUST be set to indicate the current state UUID of the client's data. In entry that case, the cookie field of the
control represents the state of the client's data including left the entry
result set
entryLeftSet - MUST be set to TRUE
persistPhase - MUST be set to which FALSE if during the control is attached. Once all sync phase or
TRUE if during the
changes are sent, persist phase
UUIDAttribute - SHOULD only be set if this is either the server sends a SearchResultDone with first
result returned or if the
clientUpdateDone control attached. attribute has changed
scheme - as above
cookie - as above

The control contains searchResultReference return will look the
cookie same, except that represents the current state of
entryUUID is not required. If it is specified, it MUST contain the client's data.
The reason field
UUID of the control is set to lcupSuccess.
The client stores the cookie received from DSE holding the reference knowledge.

Some server until
the next synchronization session.
*C->S If implementations keep track of deleted entries using a
tombstone - a hidden entry that keeps track of the reason field state, but not all
of the control is set lcupReloadRequired, data, of an entry that has been deleted. In this case, the client clears its data store and repeats
tombstone may not contain all of the
synchronization process by sending original attributes of the search operation with
clientUpdate control that contains no cookie, or that contains
a cookie with no value field.

If
entry, and therefore it may be impossible for the client's intent is server to determine
if an entry should be synchronized with removed from the server and
stay notified about data modifications, result set based on the protocol proceeds as
follows:

C->S The client behaves exactly as
attributes in the previous case except it
sets client's search request. Servers SHOULD keep
enough information about the updateType field attributes in the control value deleted entries to
synchronizeAndPersist.
S->C The server behaves exactly as in
determine if an entry should be removed from the previous case except result set. Since
this may not be possible, the
connection is kept open after server MAY return an entry as having
left the initial result set of changes is
sent to the client. A SearchResultDone message even if it is not sent to
the client; instead, the server keeps sending changes to or never was in the
client.
*S->C If client's
result set. Clients MUST ignore these notifications.

3.3 Responses Requiring Special Consideration

The following sections describe special handling that may be required
when returning results.

3.3.1 Returning Results During the server starts to run out of resources or Persistent Phase

During the client is
suspected of malicious actions, persistent phase, the server SHOULD terminate return the search operation by sending changed
entries to the client as quickly as possible.

3.3.2 No Mixing of Sync Phase with Persist Phase

During a
SearchResultDone message sync phase, the server MUST NOT return any entries with clientUpdateDone control
attached. The control contains the reason field
persistPhase flag 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 TRUE, and during the
server, it persist phase, all
entries returned MUST wait for a while before attempting another
synchronization session with have the server. We recommend
exponential backoff strategy.
C->S Sends a stopClientUpdateRequest extended operation persistPhase flag set to the TRUE. The
server to terminate the synchronization session.
S->C Responds with a stopClientUpdateResponse extended operation
followed by a SearchResultDone MUST NOT mix and match sync phase entries with persist phase
entries. If there are any sync phase entries to return, they MUST be
returned before any persist phase entries are returned.

3.3.3 Returning Updated Results During the clientUpdateDone Sync Phase

Megginson, et. al. Proposed Standard Expires - Expires: May 2002 11

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 August 2003 [Page 14]
LDAP Client Update Protocol February 2003

There may not be present
if some error occurred.

4.9 Size and Time Limits

The search request size or updates to the entries in the time limits can only be imposed for
non-persistent operations, those that result set the updateType field of a sync phase
search during the actual search operation. If the ClientUpdateControlValue DSA is under a
heavy update load, and it attempts to send all of those updated
entries to synchronizeOnly (for the entire
operation) or synchronizeAndPersist (for client in addition to the initial synchronization
phase only). All other operations MUST set both limits updates it was already
planning to 0. The
server SHOULD ignore the limits set send for persistent operations.

4.10 Changes vs. Operations

The server sends to the client modified entries rather than
operations. Given this model, sync phase, the server communicates a modifyDN
operation in one may never get to the
end of two ways: by sending the client sync phase. Therefore, it is left up to the current form discretion of
the entry (with its new DN) along with an entryUUID attribute, or
by sending server implementation to decide when the client is "in sync" -
that is, when to end a deletion for syncOnly request, or when to send the previous DN Sync
Update Informational Response between the sync phase and an entry
for the new DN. persist
phase of a syncAndPersist request. The latter method must be used server MAY send the same
entry multiple times during the sync phase if the entry changes
during the sync phase.

A reasonable behavior is for the server does
not support to generate a cookie based on
the entryUUID attribute. In either case, if server state at the time the client
state shows that initiated the object LCUP request,
and only send entries up to that underwent point during the modifyDN operation
was sync phase.
Entries updated after that point will be returned only during the root
persist phase of a subtree, the client syncAndPersist request, or only upon an
incremental synchronization.

3.3.4 Operational Attributes and Administrative Entries

An operational attribute MUST infer that be returned if it is specified in the
attributes list and would normally be returned as subject to the DNs
constraints of all
objects in [RFC2251 Section 4.5].

LDAP Subentries [SUBENTRY] MUST be returned if they would normally be
returned by the subtree search request.

3.3.5 Virtual Attributes

An entry may have changed such that they reflect attributes whose presence in the new
DN entry, or presence
of values of the subtree root.

4.11 Operations on the Same Connection

It attribute, is permissible for the client to issue other LDAP operations generated on the connection used fly, possibly by some
mechanism outside of 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, entry, elsewhere in the server will DIT. An example of
this is collective attributes [COLLECTIVE]. These attributes shall
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 referred 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 as virtual attributes.

LCUP
control. A server MAY ignore treats these attributes the LCUP control if it is non-critical
and it same way as normal, non-virtual
attributes. One consequence of this is supplied with other critical controls. If a server
receives a critical LCUP control with another critical control, and that if you change the server does not support both controls at
definition of a virtual attribute such that it makes the same time, value of
that attribute change in many entries in the client's search scope,
this means that a server SHOULD may have to return unavailableCriticalExtension.

5. Additional Features

Megginson, et. al. Proposed Standard - Expires: May 2002 12

There are several features present in other protocols or considered
useful by clients many entries to the
client as a result of that are currently one change. It is not included in anticipated that
this will be a frequent occurrence, and the protocol
primarily because they are difficult server has the option to implement on
simply force the server.
These features are briefly discussed in this section. This section
is intended client to open resync if necessary.

It is also possible that a discussion on future LDAP control will allow the merits of including client
to request only virtual or only non-virtual attributes.

Megginson, et. al. Expires - August 2003 [Page 15]
LDAP Client Update Protocol February 2003

3.3.6 Modify DN and
approaches Delete Operations Applied to implementing these features.

5.1 Triggered Search Change Type

This feature Subtrees

There is present in the Triggered Search specification. A
flag a special case where a Modify DN or a Delete operation is attached to each entry returned
applied to the client indicating the
reason why this base entry is returned. The possible reasons from the
draft are
"- notChange: the of a subtree, and either that base entry existed or
entries in the directory and matched subtree are within the scope of an LCUP search at
request. In this case, all of the time entries in the operation is being performed,
- enteredSet: subtree are
implicitly renamed or removed.

In either of these cases, the entry entered server MUST do one of the result, following:
- leftSet: the treat all of these entries as having been renamed or removed and
return each entry left to the result, client as such
- modified: decide that this would be prohibitively expensive, and force the entry was part of
client to resync

If the result set, was modified or search base object has been 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 has
received a noSuchObject as the client's result of a search
specification and request, the client can remove
MAY use the associated data from its
data store. Ironically, this feature entryUUID and UUIDAttribute to locate the new DN that is
the hardest to implement on result of the server because modify DN operation.

3.3.7 Convergence Guarantees

If at any time during an LCUP search, either during the sync phase or
the persist phase, the server does not keep track of determines that it cannot guarantee
that it can bring the client's
state copy of the data to eventual
convergence, it SHOULD immediately terminate the LCUP search request
and has no easy way return a SearchResultDone message with a resultCode of telling which entries moved out
lcupReloadRequired. This can also happen at the beginning of
scope between an
incremental synchronization sessions with the client.

A compromise could be reached by only providing this feature for the
operations that occur while request, if the client presents a cookie
that is connected out of date or otherwise unable to the server. be processed. The client
should then issue an initial synchronization request.

This can happen, for example, if the data on the server is easier reloaded,
or if there has been some change to accomplish because the decision about meta-data that makes it
impossible for the change
type can server to determine if a particular entry should
or should not be made based only on part of the search result set, or if the meta-data
change without need makes it too resource intensive 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 server to calculate
the notion of changeTypes. proper result set.

The server can also return lcupReloadRequired if it determines that
it would be more efficient for the client
specifies which type of updates will cause entries to be returned, perform a reload, for
example, if too many entries have changed and optionally whether a simple reload would
be much faster.

3.4 LCUP Search Termination

3.4.1 Server Initiated Termination

When the server tags each returned entry with has successfully finished processing the
type of change that caused that entry client's
request, it attaches a Sync Done control 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 SearchResultDone

Megginson, et. al. Expires - August 2003 [Page 16]
LDAP Client Update Protocol February 2003

message and sends it that may concern to the client. The client may have to have However, if the SearchResultDone
message contains a
local index of entries by DN resultCode that is not success or unique identifier to determine
lcupClientDisconnect, the Sync Done control MAY be omitted. Although
the LCUP cookie is OPTIONAL in the Sync Done control value, it MUST
be set if the entry has been added or just modified. It SearchResultDone resultCode is easy for clients
to determine success or
lcupClientDisconnect. The server SHOULD also set the cookie if the entry has been deleted because
resultCode is lcupResourcesExhausted, timeLimitExceeded,
sizeLimitExceeded, or adminLimitExceeded. This allows the entryDeleted
value of client to
more easily resync later. If some error occurred, either an LDAP
search error (e.g. insufficientAccessRights) or an LCUP error (e.g.
lcupUnsupportedScheme), the entryUpdateControl will cookie MAY be TRUE.

5.3 Sending Changes

Megginson, et. al. Proposed Standard - Expires: May 2002 13

Some earlier synchronization protocols sent omitted. If the client(s) only cookie is
set, the
modified attributes of scheme MUST be set also if the entry rather than cookie format has changed,
otherwise, it MAY be omitted.

If server resources become tight, the entire entry. While
this approach server can significantly reduce the amount of data returned terminate one or
more search operations by sending a SearchResultDone message to the client, it has several disadvantages. First, unless
client(s) with a resultCode of lcupResourcesExhausted. The server
SHOULD attach a
separate mechanism (like Sync Done control with the change type described above) cookie set. A server side
policy is used to
notify 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 client about entries moving into server can infer that the search scope,
sending only
client is malicious, the changes can result in server SHOULD return lcupSecurityViolation
instead.

3.4.2 Client Initiated Termination

If the client having an
incomplete version of needs to terminate the data. Let's consider an example. An
attribute synchronization process and it
wishes to obtain the cookie that represents the current state of its
data, it issues an entry is modified. As LDAP Cancel operation [CANCEL]. The server
responds immediately with a result LDAP Cancel response [CANCEL]. The
server MAY send any pending SearchResultEntry or
SearchResultReference 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 messages as possible. Finally,
the change, server sends the
entry enters message SearchResultDone with the scope Sync Done
control attached. If the search was successful up to that point, the
resultCode field of the client's search. SearchResultDone message MUST be canceled
[CANCEL], and the cookie MUST be set in the Sync Done control. If only
there is an error condition, the changes
are sent, server MAY return as described in
section 3.4.1 above, or MAY return as described in [CANCEL].

If the client would never see is not interested in the initial data of state information, it can
simply abandon the entry.
Second, search operation or disconnect from the server.

3.5 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.

Megginson, et. al. Expires - August 2003 [Page 17]
LDAP Client Update Protocol February 2003

3.6 Size and Time Limits

The server SHALL support size and time limits as specified in
[RFC2251, Section 5]. The server SHOULD ensure that if the operation
is hard terminated due to implement since these conditions, the server might not
contain sufficient information cookie is sent back to construct the changes based solely
client.

3.7 Operations 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 Same Connection

It is permissible for the client has the previous version of to issue other LDAP operations on
the data and can perform
value connection used by value comparisons.

5.4 Data Size Limits

Some earlier synchronization protocols allowed clients to control the amount of data sent protocol. Since each LDAP request/response
carries a message id there will be no ambiguity about which PDU
belongs to them in which operation. By sharing the search response. This feature
was intended connection among multiple
operations, the server will be able to allow clients conserve its resources.

3.8 Interactions with limited resources Other Controls

LCUP defines neither restrictions nor guarantees about the ability to process
synchronization data
use the controls defined in batches. However, an this document in conjunction with other
LDAP search operation
already provides the means controls, except for the client to specify the size limit
by setting following: A server MAY ignore non-
critical controls supplied with the sizeLimit field in LCUP control. A server MAY
ignore an LCUP defined 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 SearchRequest to server
does not support both controls at the maximum
number of entries same time, the client server SHOULD
return unavailableCriticalExtension.

It is willing up to receive. While the
granularity is not server implementation to determine if the same, server
supports controls such as the assumption is that LCUP protocol
will be implemented by regular LDAP clients Sort or VLV or similar controls that can deal with
change the
limitations order of the LDAP protocol.

5.5 Data Ordering

Some earlier synchronization protocols allowed a client to specify
that parent entries should be sent before to the children client. But note that it
may be difficult or impossible for add
operations and children entries sent before their parents during
delete operations. This ordering helps clients to maintain a
hierarchical view server to perform an incremental
synchronization in the presence of such controls, since the data in their data store. While possibly
useful, this feature is relatively hard to implement and is
expensive to perform.

6. cookie
will typically be based off a change number, or CSN, or timestamp, or
some criteria other than an alphabetical order.

4. Client Side Considerations

There are several issues that the implementors of a synchronization
client need to consider:

4.1 Using Cookies with Different Search Criteria

The cookie received from the server after a synchronization session can
SHOULD only be used with the same or more restrictive search specification than as the search
that generated the cookie. The
server will reject Some servers MAY allow the search operation cookie to be
used with a cookie more restrictive search specification than the search
that generated the cookie. If the server does not satisfy this condition. support the
cookie, it MUST return lcupInvalidCookie. This is because the client
can end up with an incomplete data store otherwise. A more

Megginson, et. al. Expires - August 2003 [Page 18]
LDAP Client Update Protocol February 2003

restrictive search specification is the one that generates would generate a subset
of the data produced by the original search specification.

Megginson, et. al. Proposed Standard - Expires: May 2002 14

4.2 Renaming the Base Object

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 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 Unique Identifier UUID rather then than DN based addressing.

4.3 Use of Persistent Searches With Respect to Resources

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.

4.4 Continuation References to Other LCUP Contexts

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

4.5 Referral Handling

The client
had requested neverDerefAliases or derefFindingBaseObj as the
derefAliases field in may receive a referral (Referral [RFC2251 SECTION 4.1.11])
when the search request [RFC2251, Section
4.5.1]. If the client specifies base is a value other than
neverDerefAliases or derefFindingBaseObj, subordinate reference, and this will end
the operation.

4.6 Multiple Copies of Same Entry During Sync Phase

The server will return
protocolError to MAY send the client.

- Changes to data (e.g., that might affect same entry multiple times during a sync phase
if the LCUP client's
filter or scope) or meta-data (e.g., that might affect entry changes during the
client's read access) may affect sync phase. The client SHOULD use
the presence last sent copy of entries in the
search set. Servers MAY notify LCUP clients entry as the current one.

Megginson, et. al. Expires - August 2003 [Page 19]
LDAP Client Update Protocol February 2003

4.7 Handling Server Out of changes to Resources Condition

If the
search set that result from such changes, but an LCUP client MUST
NOT assume that such notification will occur. Therefore, in receives an lcupResourcesExhausted or
lcupSecurityViolation resultCode, the
case where a client SHOULD wait at least 5
seconds before attempting another operation. It is maintaining a cache of entries using LCUP,
the data held by RECOMMENDED that
the client use an exponential backoff strategy, but different clients
may be a superset or a subset of want to use different backoff strategies.

5. Server Implementation Considerations

5.1 Server Support for UUIDs

Servers MUST support UUIDs. UUIDs are required in the Sync Update
control. Additionally, server implementers SHOULD make the UUID
values for the entries that would be returned by a new search request. For
example, if access control meta information is changed available as an attribute of the entry, and
provide indexing or other mechanisms to deny
access allow clients to particular entries search for
an entry using the UUID attribute in the search result set, and the
access filter. The
syncUpdate control information is outside of the search scope (e.g.,
in provides a parent entry), field UUIDAttribute to allow the server
to let the client may have entries stored locally
which are no longer part know the name or OID of its desired search set. Similarly,

Megginson, et. al. Proposed Standard - Expires: May 2002 15

if entries are added to the search result set due attribute to changes in
meta-data, the client's cache use to
search for an entry by UUID.

5.2 Example of entries may not include these
entries.

7. Server Implementation Considerations Using an RUV as the Cookie Value

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 reinitialized. RUV
satisfies the
client's cookie when there is a size limit imposed on three most important properties of the search
results by either cookie: (1) it
uniquely identifies the state of client's request or by data, (2) it can be used to
synchronize with multiple servers, and (3) it can be used to detect
that the server's
configuration. data was reloaded. 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.

5.3 Cookie Support Issues

5.3.1 Support for Multiple Cookie Schemes

A server may support one or more LCUP cookie schemes. It is expected
that schemes will be published along with their OIDs as RFCs. The

Megginson, et. al. Expires - August 2003 [Page 20]
LDAP Client Update Protocol February 2003

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 support 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 MUST send a SearchResultReference
[RFC2251, SECTION 4.5.3] when the LCUP Context

Megginson, et. al. Proposed Standard - Expires: May 2002 16 for a returned entry
changes. The server SHOULD return send all entries
for a particular LCUP Context before returning a reference references to other LCUP
Contexts or non LCUP enabled parts of in the DIT, search scope first, in order to
minimize the processing burden on allow the clients. clients to
process these searches in parallel. 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

5.3.2 Information Contained in the client's last session, but an LCUP
client MUST NOT assume that such notification will occur. For
example, Cookie

The cookie must contain enough information to allow 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
determine whether the object's deletion. An LDUP
compliant implementation cookie can achieve this through be safely used with the use of entry
tombstones. The implementation should avoid aggressive tombstone
purging since lack of tombstones would cause client's data to search
specification it is attached to. As discussed earlier in the
document, the cookie SHOULD only be
reloaded. We suggest used with the search
specification that only is equal to the tombstone content be removed
during one for which the regular trimming cycle while tombstones themselves are
discarded much less frequently. cookie was
generated, but some servers MAY support using a cookie with a search
specification that is more restrictive than the one used to generate
the cookie.

5.4 Persist Phase Response Time

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 during the server is kept open. persist
phase. This is intentional as any specific maximum delay would be
impossible to meet in a distributed directory service implementation.
Server
implementors implementers are encouraged to minimize the delay before
sending notifications to ensure that clients' needs for timeliness of
change notification are met.

Implementors

5.5 Scaling Considerations

Implementers 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 implementers are also encouraged
to support a large number of client connections if they need to
support large numbers of persistent operations.

Megginson, et. al. Expires - August 2003 [Page 21]
LDAP Client Update Protocol February 2003

5.6 Alias Dereferencing

LCUP design does not consider issues associated with alias
dereferencing in search. Clients MUST specify derefAliases as either
neverDerefAliases or derefFindingBaseObj. Servers are to return
protocolError if the client specifies either derefInSearching or
derefAlways.

6. Synchronizing Heterogeneous Data Stores

Clients, like a meta directory join engine, synchronizing multiple
writable data stores stores, will only work correctly if each piece of
information is comes from a single mastered (for instance, only by authoritative data source. In a
replicated environment, an LDUP
compliant directory). LCUP Context should employ the same
conflict resolution scheme across all its replicas. 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.

Security Considerations

Megginson, et. al. Proposed Standard - Expires: May 2002 17

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 malicious clients.
In addition, the servers SHOULD provide the problem.

10. means to limit the number
of resources that can be consumed by a single client.

Normative References

[KEYWORDS]

[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.

[RFC2119] S. Bradner, "Keywords "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119, 2119), March 1997.

Megginson, et. al. Expires - August 2003 [Page 22]
LDAP Client Update Protocol February 2003

[RFC2251] M. Wahl, T. Howes, S. Kille Kille, "Lightweight Directory
Access Protocol", 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.

11. Acknowledgements

[X.680] ITU-T, "Abstract Syntax Notation One (ASN.1) -
Specification of Basic Notation", X.680, 1994.

[X.690] ITU-T, "Specification of ASN.1 encoding rules: Basic,
Canonical, and Distinguished Encoding Rules", X.690,
1994.

[CANCEL] K. Zeilenga, "LDAP Cancel Extended Operation", draft-
zeilenga-ldap-cancel-xx.txt, a work in progress.

[UUID] International Organization for Standardization (ISO),
"Information technology - Open Systems Interconnection -
Remote Procedure Call", ISO/IEC 11578:1996.

Informative References

[RFC3383] K. Zeilenga, "IANA Considerations for LDAP", BCP 64 also
RFC 3383), September 2002.

[RFC3384] E. Stokes, et. al., "LDAPv3 Replication Requirements",
RFC3384, October 2002.

[SUBENTRY] K. Zeilenga, S. Legg, "Subentries in LDAP", draft-
zeilenga-ldap-subentry-xx.txt, a work in progress.

[COLLECTIVE] K. Zeilenga, "Collective Attributes in LDAP", draft-
zeilenga-ldap-collective-xx.txt, a work in progress.

Acknowledgments

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. The members of the IETF LDUP working group made
significant contributions to this document.

Author's Addresses

Rich Megginson
Netscape Communications Corp.
901 San Antonio Rd. Corp., an America Online company.

Megginson, et. al. Proposed Standard Expires - Expires: May 2002 18

Palo Alto, August 2003 [Page 23]
LDAP Client Update Protocol February 2003

360 W. Caribbean Drive
Sunnyvale, CA 94303-4900
Mail Stop SCA17 - 201 94089
USA
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, Corp., an America Online company.
360 W. Caribbean Drive
Sunnyvale, CA 94303-4900
Mail Stop SCA17 - 201 94089
USA
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

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.

Megginson, et. al. Expires - August 2003 [Page 24]
LDAP Client Update Protocol February 2003

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 Features Left Out of Changes

Megginson, et. al. Proposed Standard - Expires: May 2002 19

Changes new to version 02:

Section 4.2: The lcupCookieScheme operational attribute MUST be LCUP

There are several features present in other protocols or considered
useful by clients that are currently not included in the root DSE, and MAY be protocol
primarily because they are difficult to implement on the server.
These features are briefly discussed in this section.

Triggered Search Change Type

This feature is present in entries. Each
value of the attribute in Triggered Search specification. A flag
is attached to each entry returned to the root DSE will be a list of OIDs of
cookie schemes followed by client indicating the DN of
reason why this entry is returned. The possible reasons from the LCUP context which
supports
draft are
- notChange: the schemes. The attribute value entry existed in the DIT entries will
be directory and matched the list of OIDs followed by
search at the time the operation is being performed,
- enteredSet: the DN of entry entered the LCUP context.

section 4.5 result,
- leftSet: the entry uuid is now MAY instead of MUST left the result,
- 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, modified: the client MAY
request that entry was part of the Unique Identifier attribute be returned by
specifying it result set, was modified or
renamed, and still is in the attribute list result set.

The leftSet feature is particularly useful because it indicates to be returned by the search
request.

section 4.5 - added "or
the base DN of client that an entry is no longer within the client's search
request."
specification and the client can remove the associated data from its
data store. Ironically, this feature is the hardest to implement on
the phrase. "The server MAY send the entry at because the
root server does not keep track of the client's tree, or the base DN
state and has no easy way of telling which entries moved out of scope
between synchronization sessions with the client's search
request." I think client. A compromise could
be reached by only providing this clarifies which entry feature for the client may
search for.

section 4.6 - operations that
occur while the clientUpdateDone control client is now optional for
error conditions. Also, the cookie value of connected to the control server. This 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 easier to section 6:
"For alias dereferencing,
accomplish because the server will behave as if decision about the client
had requested neverDerefAliases or derefFindingBaseObj as change type can be made
based only on the change without need for any historical information.
This, however, would add complexity to the
derefAliases field protocol.

Persistent Search Change Type

This feature is present in the Persistent Search specification.
Persistent search request [RFC2251, Section 4.5.1].
If has the notion of changeTypes. The client specifies a value other than neverDerefAliases or
derefFindingBaseObj, the server
which type of updates will return protocolError cause entries to be returned, and
optionally whether the
client."

Changed this in section 6:
Because an LCUP client specifies server tags each returned entry with the area type
of the tree with which
it wishes change that caused that entry to synchronize through the standard be returned.

Megginson, et. al. Expires - August 2003 [Page 25]
LDAP search
specification, Client Update Protocol February 2003

For LCUP, the client can be intention is full synchronization, not partial. Each
entry returned noSuchObject error if
the root of the synchronization area was renamed between by an LCUP search will have some change associated
with it that may concern the
synchronization sessions "or during client. The client may have to have a synchronization session"

Changes new
local index of entries by DN or UUID to version 01:

The opaque cookie determine if the entry has
been split into two parts - a scheme which
is an OID, and a value. The value may added or may not have a format
known just modified. It is easy for clients to determine if
the client, depending on entry has been deleted because the specified scheme. Section
4.2 describes entryLeftSet value of the new cookie format and defines Sync
Update control will be TRUE.

Sending Changes

Some earlier synchronization protocols sent the LCUP Cookie
Value.

Megginson, et. al. Proposed Standard - Expires: May 2002 20

Added new section 4.3 - client(s) only the lcupCookieScheme operational
attribute.

Changes new to version 00:

Added
modified attributes of the definition for Unique Identifier (basically copied from entry rather than the entire entry. While
this approach can significantly reduce the LDUP model doc http://search.ietf.org/internet-drafts/draft-
ietf-ldup-model-06.txt. I needed amount of data returned to add
the definition here
because LCUP needs client, it has several disadvantages. First, unless a Unique Identifier but should not be dependent
on LDUP.

Removed all normative references to LDUP. I've left separate
mechanism (like the
implementation suggestions that refer change type described above) is used to LDUP, but LCUP should not
be dependent on LDUP.

Cleaned up notify
the protocol flows.

Removed this text from section 4.8: "Clients MUST NOT issue
multiple synchronization requests on client about entries moving into the same connection. This is
because search scope, sending only
the protocol includes changes can result in the client having an extended operation and it would
be impossible to decide which synchronization session it belongs
to." - This incomplete version of
the data. Let's consider an example. An attribute of an entry is no longer true, since
modified. As a result of the extended operation now
includes change, the message ID entry enters the scope of
the search request.

"Client Side Consideration" section - client's search. If only the changes are sent, the client will would
never
receive a referral or continuation reference

Added section 12. Acknowledgements

Removed normative references see the initial data of the entry. Second, this feature is hard
to documents implement since the server might not depended on.

Removed explicit references to software vendors.

Section 4.1 - Changed ClientUpdateControlValue contain sufficient
information to remove construct 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 changes based solely on the server's
state and
entryDeleted no longer have DEFAULT values, they must be specified
- this eliminates any potential ambiguity.

Added the client's cookie. On the other hand, this text 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.

Data Size Limits

Some earlier synchronization protocols allowed clients to control the description
amount of the entryDeleted field
(section 4.2): "The server SHOULD also set this data sent to TRUE if the
entry has left 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 result set. As far as operation
already provides the means for the client
is concerned, a deleted entry is no different than an entry which
has left to specify the result set."
Section 4.2 - Added an explanation of size limit
by setting the concept and requirement
for sizeLimit field in the Unique Identifier.

Section 4.4 - Added SearchRequest to the extended operation a request value
containing maximum
number of entries the message id 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 operation LDAP protocol will
implement LCUP.

Data Ordering

Some earlier synchronization protocols allowed a client to stop.

Megginson, et. al. Proposed Standard - Expires: May 2002 21

Updated contact information specify
that parent entries should be sent before the children for Olga.

Removed Michael Armijo add
operations and added Jeff Parham as an author.

Changes new children entries sent before their parents during
delete operations. This ordering helps clients to previous version:

"Authors" section - added Rich Megginson as the new editor.

"Client Side Consideration" section - added a note and maintain a question
concerning referral and continuation reference handling.

"Client Update Control Value" section (4.1) - clarified the meaning
hierarchical view of keepConnection and added a table summarizing the effects of
different values of keepConnection and changesOnly.

"Stop data in their data store. While possibly

Megginson, et. al. Expires - August 2003 [Page 26]
LDAP Client Update Request and Response" - added section 4.4
describing Protocol February 2003

useful, this extended operation. feature is relatively hard to implement and is expensive
to perform.

Megginson, et. al. Proposed Standard Expires - Expires: May 2002 22 August 2003 [Page 27]

----