jclowser at unitedmessaging.com wrote: > Rich Megginson wrote: > >> Unfortunately, the objectclass "account" is a structural objectclass, >> which means you can't "mix it in" with other structural objectclasses >> such as inetOrgPerson. So I think either the standard needs to be >> revised to make account auxiliary, or create a new objectclass >> (auxAccount?). > > > What keeps you from doing this (I ask because I've mixed these before, > and nothing "bad" happened)? Where is that restriction defined? (I > feel kinda stupid if I've been doing this for all these years and in all > that time it hasn't been "allowed" :) ) Well, for example if you like to somehow integrate with OpenLDAP, recent versions, 2.1 and higher iirc, enforce structural integrity and do not allow the administrator to disable it. IMO, structural integrity should be observed, but the administrator should have the chance to turn it off, just like schema checking. To that end, I would like to see FDS enable structural integrity checking by default, with an on-off toggle. -- Mike
