> ando(a)sys-net.it wrote:
>> Hallvard B Furuseth wrote:
>>> ando(a)sys-net.it writes:
>>>> On a related note, if this can be considered of general usefulness, LDAP
>>>> specs would need to be changed in order to define a finer grain of
>>>> attribute request; something like:
>>>> empty or "*" ; all user, except attrs that need to be
>>>> "+" ; all operational
>>>> <all including attrs that need to be explicitly requested>
>>> Would it be cleaner if slapo-cloak redefines the attributes to be
>>> operational, or to behave as if they are? Maybe give them an
>>> X-AS-OPERATIONAL extension? Or would that just mess up schema code,
>>> things like attribute inheritance?
>> I think things would mess up.
> I'd also recommend *not* to turn user attribute types into operational
> attribute types. This would certainly confuse schema-aware clients.
>> Moreover, I see a number of features system administrators could ask
>> for; e.g. hide attributes only when matching a URI (base, scope,
> Well, that's something many overlays would benefit from.
In fact, based on recent modifications to slapo-constraint(5) and other
overlays, I'm considering the opportunity to introduce generic helpers
to parse and check this type of generic limitations.
We've discussed this before - overlays ought to have a configurable range of
effect, using an X.500 Subtree Search Specification.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/