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

Re: (ITS#3706) [enhancement] back-ldap/back-meta don't handle T-F filters



ando@sys-net.it wrote:

>Full_Name: Pierangelo Masarati
>Version: HEAD/2.3/2.2
>OS: Linux (Whitebox)
>URL: ftp://ftp.openldap.org/incoming/
>Submission from: (NULL) (81.72.89.40)
>Submitted by: ando
>
>
>back-ldap and back-meta, when dealing with pre-computed filters that evaluate to
>TRUE or FALSE as per <draft-zeilenga-ldap-t-f>, propagate the string "(?=true)"
>or "(?=false)" which is used internally by slapd to mark "(&)" and "(|)",
>respectively.
>
>According to <draft-zeilenga-ldap-t-f>, they should rather rewrite it back to
>"(&)" and "(|)", if the remote server is known to support them; in any case, the
>propagated string is meaningless.
>
>A workaround for servers that don't support it could be "(objectClass=*)" and
>"(!(objectClass=*))".  A configuration switch could be defined that informs the
>backend if the remote server supports the feature, or the backend could be
>instructed about discovering the feature as per RFC3674.
>
Do you suggest reconstructing the filter string (thus duplicating all of 
the work of filter2bv)? It seems to me it would be better to just fix 
filter2bv to use the correct notation here.

-- 
  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support