LCUP comments

Sorry, I've been sitting on these for some time now...

- Section 4: Need to talk about server behavior regarding alias
dereferencing. There is a note in the "Client Side  Considerations", but
it needs to be stated in the protocol section.

- Section 4.4: Persistent search has the notion of changeTypes. The
client specifies which type of updates will cause  entries to be
returned, and optionally whether the server tags each returned entry
with the type of change that caused  that entry to be returned. This
feature is missing both from the Protocol Specification (Section 4) and
Additional  Features (Section 5). Client implementors use this
functionality in persistent search.

- Section 4.4: Descriptions of synchronizeAndPersist and persistOnly
are missing the moddn operation (only mention add,  mod, delete).

- Section 4.4: Description of persistOnly needs to clairify "new" to
reflect that it is in regard to the last sync  session.

- Section 4.5 states that deleted entries only contain the DN and
entryUUID. There are existing persistent search  applications that index
or name entries using other attributes (like mail). I personally like
this restriction, but I'm  convinced that application writers will
bristle.

- Section 4.5: Description of entryDeleted states that the server MAY
set this to TRUE if the entry leaves search scope.  I believe this
introduces interoperability problems sufficient to remove it or make it
a MUST.

- Section 4.6: Description of lcupClientDisconnect could be more clear
if it were stated: "client requested search  termination using the Stop
Client Update Request". This is because the Stop Client Update Request
has not yet been talked  about in the draft.

- Section 4.7: There is no OID or value specified for the
stopClientUpdateResponse.

- Section 4.7: Third to last paragraph ("If server resources become
tight...") doesn't belong in this section.

- Section 4.7: The last two paragraphs seem redundant.

- Section 6: First consideration implies that the cookie holds the
previous search criteria. May be a good thing, but  should be explicitly
called out.

- Section 6: Second consideration calls out a scenario that can happen
between sync sessions and the appropriate  behavior. This same scenario
can happen during a sync session, and the same behavior should be
applied.

Jim