>> > Well, it would appear that openldap might be throwing error=20 a
>> > little too liberally:
>
>> No, SLAMD is generating an invalid ASN.1 encoding of the entry here.
>> Note that X.500 defines an "entry" to be a SET of attributes;
>> mathematically, in sets, elements are unique - can only appear once.
>> This is explicitly stated in X.501 "All attributes in an entry shall be
>> of distinct attribute types." The ASN.1 definition for the Add operation
>> (RFC2251) says:
>>
>> AddRequest ::= [APPLICATION 8] SEQUENCE {
>> entry LDAPDN,
>> attributes AttributeList }
>>
>> AttributeList ::= SEQUENCE OF SEQUENCE {
>> type AttributeDescription,
>> vals SET OF AttributeValue }
>>
>> The proper way to encode a single attribute with multiple values is to
>> include the "type" once, followed by all of the multiple values. SLAMD
>> is sending the type multiple times, with one value each time, which is
>> clearly an invalid encoding.
>>
>
>>
>> Hi Matt,
>>
>> This is actually a bug with SLAMD, and not OpenLDAP. Symas has been
>> aware of it for some time, and will be submitting a fix back to Neil.
>>
>> Regards,
>> Quanah
>>
>
> He actually sent me a fix about ten minutes ago. His fix is for 2.0
> branch of slamd, and I'm testing it on 1.8 (it's not working yet), but
> let's see if we can get him involved in this thread and we can figure
> it out. I'm cc-ing him, and pasting in initial replies. (he already
> has my initial posts)
I'm already following up to Neil, since I'm on the slamd-discuss list.
And I already have a fix for the 1.8.2 release. ;)