[Date Prev][Date Next]
Re: Final pieces to the Netscape roaming puzzle found!
Thanks for the lightning-quick response Kurt.
"Kurt D. Zeilenga" wrote:
> At 11:25 PM 7/24/99 -0400, Kartik Subbarao wrote:
> >The fix was to correct an RFC 2251 compliance issue with OpenLDAP.
> Actually, this compatibility problem is an RFC 1777 compliance issue.
> OpenLDAP implements LDAPv2 (RFC 1777 + U-Mich enhancements). Clients
> (such as Netscape Navigator) should be careful not to send LDAPv3'ism
> (such as the "*") in LDAPv2 requests. The user vs operational
> attribute handling requirements (including the "*") are LDAPv3'isms.
> LDAPv2 makes no distinction between user and operational attribute
Oh, I see. Please excuse my ignorance. I didn't even consider v2 in my
> Your patch, though, is a good workaround. It should be treated
> as such (ie: not a fix).
Agreed. I've gone back through the OpenLDAP list archives and reread
some of the discussion. I have posted a message to some Netscape and
Mozilla newsgroups raising the awareness of the two major roaming
issues, and pointing out how Netscape could interoperate better with
OpenLDAP. (Mozilla doesn't seem to have any roaming code yet).
> Our LDAPv3 implementation (OpenLDAP-devel) already contains support
> for the features included in your patch.
As you've seen here and as I mention in my newsgroup posts, I don't know
too much about LDAP precedent. Could you explain why generating the
"modifyTimestamp" attribute upon creation might not be a Good Thing in
the LDAP world? I'm coming at this from the filesystem school of
thought, where creation and modification timestamps are both initialized
when files are created.