Subject: Re: [ldapext] True filter vs. (objectClass=*)

From: John McMeeking <[email-masked]>
Date: Fri, 2 Jan 2004 07:02:45 -0600

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:       [email-masked]                                           
                      <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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

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

---

From: John McMeeking <[email-masked]>
Date: Fri, 2 Jan 2004 08:00:04 -0600

Disregard my last post.  I hadn't had my morning coffee yet.

I was reading this with respect to the wrong I-D (ldapbis-protocol, not
draft-zeilenga-ldap-t-f).  And the DEFAULT of "and : {}" is the LDAP (&).

John  McMeeking

                      John                                                                                           
                      McMeeking/Rocheste        To:       Hallvard B Furuseth <[email-masked]>             
                      r/IBM@IBMUS               cc:       [email-masked]                                           
                      Sent by:                  Subject:  Re: [ldapext] True filter vs. (objectClass=*)              
                      ldapext-admin@ietf                                                                             
                      .org                                                                                           

                      01/02/2004 07:02                                                                               
                      AM                                                                                             

John  McMeeking

                      Hallvard B

                      <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

--
Hallvard