masarati@aero.polimi.it writes:
Well, the fact is that memberURL is stored in the data. As soon as we accept that value, we need to deal with it. The current behavior of slapo-dynlist(5) consists in ignoring it (the resulting filter cannot be parsed). We should rather reject values like this when written in the database, but this would probably break other applications. So I believe the fix is better than silently ignoring these values.
I disagree. Data validation in LDAP is generally the user's job, LDAP syntaxes are very rough in that regard.
If this is a fix to make dynlist compatible with the rest of OpenLDAP's handling of URLs in data (e.g. the ref attribute), then this is a good fix and I'm way to late to complain. But in my view, if this fix is introducing an incompatibility with the LDAP spec, then it's not.