Re: err=20 when rdn attr name is different that attr name in object (ITS#1997)

[Kurt@OpenLDAP.org]

It is the client which is not handling the case issue properly.
Look at the generated PDUs of both cases.

Kurt

At 08:57 AM 2002-08-26, Kevin McCarthy wrote:
>Re: you closing of ITS 1997:
>
>Per RFC 2251, Section 4.1.4:
>
>A specification may also assign one or more textual names for an attribute 
>type. These names MUST begin with a letter, and only contain ASCII 
>letters, digit characters and hyphens. They are case insensitive. (These 
>ASCII characters are identical to ISO 10646 characters whose UTF-8 
>encoding is a single byte between 0x00 and 0x7F.) 
>
>So, in fact, the "two versions" are really ONE version, and OpenLDAP is 
>buggy.
>
>There is no functional difference between the attributes, and as such, 
>slapd should not reject the request. That would be contrary to to 
>published LDAPv3 specs.
>
>Regards,
>Kevin
>
>> The "two version" simply differ by case. This should be handled properly
>> 
>> by slapd.
>> 
>> There is no schema awareness in this client; all it knows are strings. I
>> 
>> assure you it is not changing any strings into other strings, and the
>> case 
>> difference is what is being detected as a "different attribute". This
>> does 
>> not sound to me like a client bug. Do you want a netcat filter, a higher
>> 
>> level openldap log? I can assure you I do not have multiple instances of
>> 
>> the same attribute that vary by anything but case.
>> 
>> Regards,
>> Kevin
>> 
>> Quoting "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>:
>> 
>> > At 10:10 AM 2002-08-07, kmccarthy@senets.com wrote:
>> > >I was using JNDI interface from Java. When DN used mixed case in
>> RDN
>> > and 
>> > >attribute name in object was all lower, got err=20. Changed RDN attr
>> to
>> > 
>> > >all lower case and problem was fixed.
>> > 
>> > So, it's not an ldapadd(1) bug but a JNDI bug (or one in your
>> > JNDI application).
>> > 
>> > The client is sending a malformed LDAP Add Request PDU.
>> > The client generated PDU includes two versions of the
>> > same attribute in violation of the protocol and its data
>> > model.  The client should be fixed.
>> > 
>> > >This exact code worked fine w/ 2.0.18, and only flared up when I
>> > upgraded 
>> > >to 2.1.2.
>> > 
>> > Yes, we fixed a number of bugs which unintentionally
>> > allowed non-standard behavior.
>> > 
>> > Kurt
>> > 
>> > 
>> 
>> 
>> 
>> 
>> -------------------------------------------------
>> This mail sent from Biltmore Communications
>>       http://www.biltmorecomm.com
>> 
>
>
>
>
>-------------------------------------------------
>This mail sent from Biltmore Communications
>        http://www.biltmorecomm.com