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.