Subject: [ldapext] noop control vs. non-modify operations

From: Hallvard B Furuseth <[email-masked]>
Date: Sun, 23 May 2004 20:29:25 +0200

draft-zeilenga-ldap-noop-04.txt says:
>  The control is appropriate for request messages of LDAP Add, Delete,
>  Modify and ModifyDN operations [RFC2251].

I don't remember if I have suggested this before, but the control could
be useful with other operations too:

- Bind:  Verify that the credentials are correct without actually
  changing the session's authorization ID or SASL layer, and without
  abandoning outstanding operations.  Probably the server SHOULD NOT
  wait for outstanding operations either.

- Operations in general:  Check if the server supports the operation
  (with the given parameters), or that it supports some control,
  or that the user has access to perform the operation.

The noop control spec would have to say that the operation has no
effect, not only that it has no effect _on the directory_.  It should
not affect SASL/TLS layers, bind DN, or anything else.  The control
would fail if it could not test the operation without such side effects.

noOperation would be returned instead of compareTrue and compareFalse as
well as instead of success.

BTW, 'no effect' may not be entirely possible, with or without my
suggestion.  For example, in a directory where each entry is stored in a
file, Add+noop might update the time of last access for the file, and
the server might support a way to read that time.

-- 
Hallvard

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 27 May 2004 13:51:20 -0700

>>  Modify and ModifyDN operations [RFC2251].

I should also note that the control is appropriate for
extended requests of operations which update the directory,
such as the password modify extended operation [RFC3062].

>  wait for outstanding operations either.

As engineering this functionality requires special
attention to security considerations (as it would extend
LDAP authentication capabilities), I believe it best that a
separate control be used to provide this functionality.
I note that already exists controls, so called "fast bind"
or "concurrent bind" controls, which do provide this kind
functionality.

>  or that the user has access to perform the operation.

While the control could, I guess, be used to discover feature
support it is not intended to be used in that manner.

>the server might support a way to read that time.

I note that I-D does not use the term 'no effect'.  And
while any access of the directory could be viewed as
having an effect upon the directory, I think the document
is reasonable clear on which effects it this control
impacts.

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 31 May 2004 18:52:36 +0200

Kurt D. Zeilenga writes:
>> (...)

Good point.

> or "concurrent bind" controls, which do provide this kind

Pity they don't seem to be RFC'ed then.  Do you know of some such specs
or implementations that seem reasonable, and whose owners might accept
to have them RFC'ed?  I might find time to do that, and an OpenLDAP
reference implementation, sometime this year:-)

>> suggestion.  (...)
> I note that I-D does not use the term 'no effect'.

No, I did.  I was just noting that some wordsmithing or deeper work
would be needed with my suggestions, if they were accepted.

-- 
Hallvard