Re: 'Unrecognized OIDs in request' control (Was: 'return unknown attrs' control)

["Pierangelo Masarati" <ando@sys-net.it>]

> Kurt D. Zeilenga wrote:
>> If a client wanted to know which OIDs/descriptors were unknown,
>> it could simply rely on published schema(s) for the subtree(s) and
>> other published information.  (Note that the published
>> subschema/information may be incomplete, but then so would be the
>> information in the control.)
>>
>> Personally, I think this control extension would not be all that
>> useful (over existing discovery mechanisms).
>
> It's also my impression that such a control would mean high complexity
> also at the client's side which is not justified by what you gain with it.

The rationale behind Hallvard's idea is that __OpenLDAP__ clients should
use it, while slapd would make it available to other clients that request
it; it should do nothing on the server's side, and send no response (or a
successful one, depending on how that response is designed) if everything
is fine, so when operations are correct the client should not bother about
it.  It would help careless users in finding mistakes in their operations.

>
> I'd also recommend to query the sub schema sub entry.

Well, in this case the client (think of ldapsearch) should query the
subschemasubentry first, and for every operation, and check if all the
OIDs used in the operation are defined and comply with the use the client
is making.  This IMHO is not fully adequate, although desirable, because
it requires too much knowledge (and wisdom) in the client, and too much
unnecessary work if the operation is fine.  For example, in case of a
search, ldapsearch should do a lot operations that are unrequired because
everything is likely to be fine.  With the above control, ldapsearch
should just issue the control, and, in case its response is unsuccessful,
check what caused the insuccess.  The server, on the other side, should
only arrange a bit more information as a consequence to the failure of
tests it's going to perform anyway.

We need to be able to deal with dumb clients, and we should be able to
provide, on demand, the amount of information the client didn't have when
it issued the operation (either because it couldn't collect it, or because
it was so lazy not to ask for).

Putting this into a(n optional) control seems reasonable, because there
would be no impact if it's not requested.

See it as the error messages a compiler sends back; they're not necessary
because if the code is wrong the programmer should know it in advance, as
he pretends to know that programming language; compilers then shouldn't
even need to handle programming errors, just bail out (or SIGSEGV...).

p.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it


    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497