[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#3707) An unknown attribute in presence filter evaluates to (?=false) instead of (?=undefined)

At 11:43 PM 5/5/2005, ando@sys-net.it wrote:
>Kurt@OpenLDAP.org wrote:
>>At 02:51 AM 5/5/2005, ando@sys-net.it wrote:
>>>Full_Name: Pierangelo Masarati
>>>Version: HEAD/2.3/2.2
>>>OS: Linux
>>>URL: ftp://ftp.openldap.org/incoming/
>>>Submission from: (NULL) (
>>>Submitted by: ando
>>>An undefined attribute in a presence filter, e.g. "(undefined=*)", evaluates to
>>>"(?=false)", while in other filters, e.g. equality "(undefined=something)" it
>>>evaluates to "(?=undefined)".  If there isn't any rationale behind it, I'd
>>>evaluate it to "(?=undefined)" as well, at least for consistency.
>>Though I disagree with the rationale behind the RFC 2251
>>requirement, the rationale for this slapd(8) behavior is
>>the RFC 2251 requirement.
>>     The present match evaluates to TRUE where there is an attribute or
>>     subtype of the specified attribute description present in an entry,
>>     and FALSE otherwise (including a presence test with an unrecognized
>>     attribute description.)
>>I disagree as 'undefined' may be an unknown alias for a
>>present attribute description.
>My intention was to use "undefined" as a placeholder for an undefined 

That will work until someone defines an attribute called "undefined".

>let's say "(1.1=*)" vs. "(1.1=something)".  I 
>missed that bit in RFC2251, but I suspected a rationale behind the 
>current implementation.
>This is making forwarding of absolute filters by back-ldap a bit more 
>tricky.  As such, I suggest the strings "(?=true)" and "(?=false)" in 
>slapd's internal filter representation be replaced by the corresponding 
>absoluteFilter representations "(&)" and "(|)", assuming they're simply 
>an internal string representation, since I didn0t find any mention of 
>them in <draft-zeilenga-ldap-t-f>.  "(?=undefined)" and "(?=error)" do 
>not require modifications.

(&) and (|) are, with draft-zeilenga-ldap-t-f, valid filter
strings.   But what filter2bv produces is not a filter string,
it's a filter diagnostic string.  

>I can work this issue around as in slapo-rwm and back-meta, but this 
>would require yet another filter2bv conversion.

For back-ldap/back-meta, it seems one really needs access to
filter encoding as it appeared in the request so that it can
be forwarded intact (it would be nice if we had an ldap_search()
call where the filter was passed as BER value).   But given
that filter massaging would be a nice feature, you actually
need both access to filter encoding and another filter2bv

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