Sync Replication using refreshAndPersist

["James Courtney" <jamey@elementalsecurity.com>]

Hey OpenLDAP folk,
	Thanks to Howard Chu getting me over the OpenLDAP 2.2 control
criticality bug I can now sucessfully chat with Openldap 2.2.15 using
the Sync Replication control (1.3.6.1.4.1.4203.1.9.1.1,
draft-zeilenga-ldup-sync-06.txt) through JNDI.  When I specify a mode of
refreshOnly (mode=1) I get a nice search and a state cookie back (via
the Sync Done Control, 1.3.6.1.4.1.4203.1.9.1.3) which I can use to
repeat the search and get only modified items.

Cool!

Now I have two issues:

1) I don't (seem to) get back a "Sync State (Response) Control" with
each SearchResult(Entry) I receive through JNDI from the search request.
In JNDI the server "Response" controls only seem to become available
after the enumeration of SearchResult objects has been fully retreived.
I don't seem able to get one control for each SearchResult and thus make
the proper determination as to the type of operation the result
represents (present, add, modify, delete).

2) The "refreshAndPersist" (mode=3) mode of Sync Replication relies upon
a Sync Info Message (section 2.5 of draft-zeilenga-ldup-sync-06.txt)
which is a LDAP "Intermediate Response Message" (rfc 3771, Zeilenga).  I
don't see an abstraction in JNDI for handling these "Intermediate
Response Messages".

Accoring to RFC 3771 "Intermediate Response Messages" can't be
implemented using the standard LDAPv3 extension mechanism so thus I
can't hope to use the JNDI ExtendedRequest and ExtendedResponse objects
to "get at" this functionality.

The Novell NDK "LDAP Classes for Java" also seem to lack this
functionality.

Does anyone have experience with this or suggestions on how to handle
"Intermediate Response Messages"?

Have I just strayed to close to the bleeding edge here?

Thanks in advance for your time and help.

Best regards,

Jamey


James Courtney
Software Engineer
Elemental Security, Inc.