On 13/12/03 5:19 pm, Kurt D. Zeilenga <[EMAIL PROTECTED]> wrote: > Note that few (if anyone) really implements LDAPv2 as specified in > its IETF technical specification (RFC 1777, etc.). When version 2 > is selected, you really get generally get something which I call > LDAPv2+ (LDAPv2 with U-Mich extensions) or LDAPv2++ (LDAPv2+ with > other extensions). This is why the IETF choose to move the > LDAPv2 TS to historic AND recommend that LDAPv3 be used instead > (of LDAPv2, LDAPv2+, LDAPv2++, ...).
I know of at least one implementation that's pretty close to the RFCs, but you're quite right that most people decided to diverge and use incorrect character sets, and bodge in extra bits like these pseudo-referrals, etc. It is a great reason to use LDAPv3 instead. (Which has been around for 6 or so years, which is almost an eternity :-) > Anyways, LDAP_PARTIAL_RESULTS comes from LDAPv2+, was described > in various U-Mich papers, and is supported (with limitations) > by a number of directory servers and APIs. The code indicates > that errorMessage field contains referral/reference information. That was my understanding too, just from glancing at the code Dan posted. > Even ignoring the overload of this field, the mechanism is > significantly flawed in design (cannot distinguish referral v. > continuation references) which makes it unusable in modern > directory systems. Another reason to use LDAPv3... > > Given that all directory vendors support LDAPv3, I see no reason > why any new client-side support for LDAPv2[+[+]] (or features > thereof). Legacy apps can just use legacy libraries. > > Kurt Just say no to LDAPv2. Cheers, Chris
