[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: [ldapext] True filter vs. (objectClass=*)
I do not believe (&) or (|) are valid filters, though the ASN.1 does seem
to imply they are valid.
RFC 2251 and [protocol], para 4.5.1:
The 'and', 'or' and 'not' choices can be used to form combinations of
filters. At least one filter element MUST be present in an 'and' or
'or' choice.
I interpret that as meaning you can do (&(...)) or (|(...)), where (...) is
some filter element, but not (&) or (|).
I don't know how to interpret the "and : {} " in X.511:
SearchArgument ::= OPTIONALLY-PROTECTED {
SET {
[intervening components deleted]
filter [2] Filter DEFAULT and : { },
John McMeeking
Hallvard B
Furuseth To: ldapext@ietf.org
<h.b.furuseth@usi cc:
t.uio.no> Subject: [ldapext] True filter vs. (objectClass=*)
Sent by:
ldapext-admin@iet
f.org
01/01/2004 08:13
AM
I suggest to add this statement to draft-zeilenga-ldap-t-f:
Whenever the "(objectClass=*)" filter will succeed (including
reading the Root DSE), the "(&)" filter will also succeed.
rfc2251 section 3.4 explicitly says the (objectClass=*) filter
should be used to read the root DSE. It does _not_ say 'any filter
which matches the root DSE', so as currently defined the TRUE filter
might not work here. (OTOH, there is one filter which properly may
succeed when TRUE fails: (objectClass=subschema) to read schema.)
--
Hallvard
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext