Michael Str�der wrote:
Hi Michael.
>
> I would not define a Mozilla LDAP scheme. I'd just like to see a mapping
> which already seems to be there.
>
We too, but it is not possible.
To store two different entries - workstreet and homestreet
(both are SYNTAX 1.3.6.1.4.1.1466.115.121.1.15), you must
use two different attributes. Multivalued attributes are
not solution in this case.
>
> mozillaAbPersonObsolete is defined as structural object class directly
> derived from top. Today most times the structural object class
> inetOrgPerson defined in RFC2798 is used for person entries. Many
> applications deal with attributes allowed in this object class very well.
>
> Now according to LDAPv3 each LDAP entry may only have one structural
> object class assigned to it (which strictly spoken cannot be altered
> later without removing and readding the entry).
>
> inetOrgPerson is derived from organizationalPerson (structural) which is
> derived from person (structural) which is derived from top (abstract).
> Therefore the LDAP server might return all three object classes as
> attribute values for attribute objectClass which looks like a person
> entry has three structural object classes. But in fact it only has
> inetOrgPerson as structural object class.
>
> Having said that it's clear that it's illegal to have an entry with
> object classes inetOrgPerson (very common) *and* mozillaAbPersonObsolete.
> => you have to create separate entries with different distinguished
> names to store the Mozilla-specific attributes.
>
> Now licensing costs for e.g. iPlanet or Netscape Directory Server and
> many others are calculated by counting distinguished names...
>
> Got the message?
Not! I drink 1 liter coffee by now, what is too less to wake up my
brain after morning. But Im continue on it ;-)
>
> Two possible solutions to add the Mozilla-specific attributes (if really
> needed):
>
> 1. Derive (sub-class) mozillaAbPersonObsolete from inetOrgPerson. This
> has the caveat that it does not work in most corporate directories where
> often the schema for person entries is already extended by sub-classing
> inetOrgPerson. (No circles allowed in sub-classing, no inheritance
> possible from more than one structural object class...)
>
> 2. Make mozillaAbPersonObsolete an auxiliary object class which can be
> added and removed to/from any entry. (An entry may have added or removed
> auxiliary object classes after creation.)
>
Can you write more details about it, please? Did not you want
to make some examples?
I looked to www.stroeder.com, so I know you are engage
on this branch.
Thanks
Petr
