Final pieces to the Netscape roaming puzzle found!

[Kartik Subbarao <subbarao@computer.org>]

I've crossed the final hurdle on the Netscape roaming problem (in my
case, picking up one system's bookmarks from a different system).

I have successfully tested the following scenario:

1. Set up roaming from system A to OpenLDAP server O. A synchronizes
bookmarks to O. Exit Netscape on A.
2. Delete bookmarks file on B.
3. Set up roaming from B to O.
4. B picks up bookmarks from O. Exit Netscape on B.
5. Make a change to bookmarks on A, and exit Netscape.
6. Start Netscape on B. B picks up the change made on A.

The fix was to correct an RFC 2251 compliance issue with OpenLDAP. I've
submitted the bug to the OpenLDAP ITS. For now, you can get the patch
at:

ftp://ftp.openldap.org/incoming/Kartik-Subbarao-990724.patch

Now for the details. It turns out that Netscape Communicator does the
equivalent of:

ldapsearch -h roamingserver -b
nsLIElementType=bookmarks,nsLIProfileName=Name,[rest of dn]
'objectclass=*' '*' modifyTimeStamp

The problem was that OpenLDAP wasn't interpreting the '*' in the
attributes list. According to RFC 2251, '*' in the attributes list is
synonymous with an empty list -- it means get all user attributes. It's
used for cases like this, where you want to get all user attributes, as
well as an operational attribute (e.g. modifyTimestamp).

[As an aside -- OpenLDAP doesn't seem to draw a distinction between user
attributes and operational attributes like modifytimestamp. It will
return them even without them being explicitly queried for. I'm not sure
if that's incorrect behavior, or if it's in the realm of undefined
behavior. It doesn't seem to break anything, but based on my reading of
RFC2251 and 2252, I think it'd be better if OpenLDAP didn't
automatically return operational attributes.]

Now, go out there and roam free on the OpenLDAP range!!! :-)

	-Kartik

--
Email: subbarao@computer.org
WWW:   http://www.geocities.com/SiliconValley/Way/1234/