> > While person, organizatioalPerson and internetOrgPerson do provide basic
> > data keys, they lack other ones like second address, second email,

Wrong;  "mail" is multivalued.

> Such attributes secondSomething are horrible. Try to define precise
> semantics and use-cases. And try to argue why there is no need for
> attributes thirdSomething. ;-)

Yes, agree 100%.

> > birthday,
> This is really missing. I'm using my own AUXILIARY object class msPerson
> which also contains such an attribute.

Several quasi-standard schemas do add birthday,  such as the schema used
by evolution.

> > instant messaging names
> I'd argue that these are specific to certain IM applications. Each of
> these applications should define an AUXILIARY object class to be added
> to person entries

Probably, and sadly, the best solution.  It would be very nice if
someone with "clout" would address this issue.

> > On my search for the golden schema I found Mozilla's
> > mozillaAbPersonAlpha and evolutionPerson. Mozilla's schema looks kinda
> > alpha to me.
> > Evolution and Thunderbird don't support each other's schema, and
> > KAddressbook also doesn't like one of them.
> I'd avoid all of these. IMHO they are broken.

No more broken then a custom one.

> > Is there something like a standard schema that, if not all, but most
> > address applications support?
> Nothing more than inetOrgPerson.

Probably the best you can do is combine the available schemas.

# Objectclass: mHybridPerson
# Description: Seals the break in objectclass inheritence created
#   by officePerson and evolutionPerson descending from inetOrgPerson
objectclass ( 1.3.6.1.4.1.6921.1.12
  NAME 'mHybridPerson'
  DESC 'Combine several objectclasses to support multiple MUAs'
  SUP ( inetOrgPerson $ officePerson $ evolutionPerson )
  STRUCTURAL )



---
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.

Reply via email to