[EMAIL PROTECTED] wrote: > > I tend to lean towards keeping things as standard and consistent as > possible, require 6 to 8 object classes for a person entry. A consultant > is suggesting limiting the number of object classes.
Hmm, you have to think about dependencies. You might want to keep the number of these low since published object classes might get modified (without change in OID or descriptor). Additionally not every published object class is a real "standard" object class. Many object classes are modeled for a particular purpose by vendors. Figure out if you can find a (public) document usable as normative reference in your own documentation specifying the object class you plan to use. Also it depends on whether the existence of an object class imposes a special semantic on that person object. You have to investigate on this. E.g. posixAccount requires uidNumber. You could prefill such an attribute with dummy values. But what happens then? Last not least not every published object class for personal data is designed well. I tend to implement a custom auxilliary object class and add published object classes whenever needed for the particular application they were designed for. But it really depends on what you're after. There's no general rule. Ciao, Michael. --- You are currently subscribed to [email protected] as: [EMAIL PROTECTED] To unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the SUBJECT of the message.
