[email protected] wrote: > [email protected] wrote: >> [email protected] wrote: >>> Hallvard B Furuseth wrote: >>>> [email protected] 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 explicitly req. >>>>> "+" ; 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, >>> filter), >> 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/
