Re: (ITS#5861) Assert control on Add request fails

[Kurt@OpenLDAP.org]

On Dec 20, 2008, at 12:13 PM, ando@sys-net.it wrote:

> h.b.furuseth@usit.uio.no wrote:
>> Full_Name: Hallvard B Furuseth
>> Version: HEAD
>> OS: Linux
>> URL:
>> Submission from: (NULL) (129.240.6.233)
>> Submitted by: hallvard
>>
>>
>> RFC 4528 says the Assert control is appropriate for Add.

Yes.

>> Slapd disagrees:

No.  slapd(8) is saying the control is unavailable.  That's quite  
different than saying it is inappropriate.

>>
>>
>> $ ldapadd -xhlocalhost:3890 -e\!assert='(objectClass=organization)'  
>> <test.ldif
>> adding new entry "o=test"
>> ldap_add: Critical extension is unavailable (12)
>>        additional info: critical extension is unavailable
>
> According to this thread
>
> <http://www.openldap.org/lists/openldap-software/200512/msg00250.html>
>
> the author of the assertion control (Kurt :) believes the current
> specification is flawed.  In fact, the assertion control is intended  
> to
> apply to the contents of the DIT.  The entry does not belong to the  
> DIT
> until the operation is completed, so assertion cannot apply.

Those comments were in respect to the I-D (when it was a work in  
progress).

The specification does allow for the control to be attached to Add  
requests.  Though it might seem kind of pointless, a client might do  
it as it is not itself capable of evaluating some assertion.

I would argue that it fine for a server which cannot handle the  
control in this (or other cases) to return  
unavailableCriticalExtension.  The specification certainly doesn't  
require a server to make use of the control in cases where it might be  
asserted.

This is not to say slapd(8) shouldn't be updated to make use of the  
control when provided with Add requests, just saying it's technically  
okay that it doesn't.