Paul Sandoz <[EMAIL PROTECTED]> writes:
>
> >> Attached is the Mozilla card to LDAP attribute
> >> mapping that is currenly used. This is based on
> >> the LDIF conversion code.
> >> At some point it might be advantageous to have
> >> a mapping table in the preferences, or changes to
> >> the default. I presume this would be required by
> >> some enterprise clients?
> >
> >Yeah, I would think so. We could either have preferences override
> >individual values like 4.5 (see
> >
>
>>http://docs.iplanet.com/docs/manuals/communicator/ldap45.htm#customizing-attribute-names
>
> >
> >for details) or just have a single preference that overrides the file
> >the table is read from. The former might be preferable, since it
> >would probably play more nicely with preferences locking stuff. I've
> >CCed the prefs newsgroup in case any of the experts in that area have
> >comments on this. Conceivably both options could be used together.
> >
>
> I like the idea of relating ldap attributes to
> ldap attributes and fixing the relationship between
> Mozilla card properties and ldap attributes.
This seems like a good idea. But isn't it orthogonal to the above
question of how we connect it to the preferences? I'd be interested
in hearing if any of the prefs & prefs locking folks have any opinions
on this...
> >> /*
> >> Table defining the relationship between
> >> mozilla card properties and corresponding
> >> ldap properties.
> >>
> >> Multiple entries for a mozilla property define
> >> there is a many to one relationship between
> >> ldap properties and the mozilla counterpart.
> >>
> >> There is a one to one relationship between
> >> a mozilla property and the ldap counterpart.
> >> If there are multiple entries for a mozilla
> >> property the first takes precedence.
> >
> >What if there are multiple entries for an LDAP property? I don't
> >_think_ LDAP guarantees that they will be returned in a predictable
> >order, though I could be wrong.
> >
>
> Currently there is no provision for managing multiple
> entries, the first one wins. I was not sure how to
> deal multiple entries...
I just asked Leif about this, and he said that the protocol does not
guarantee a predictable order, though the current versions of the
Netscape/iPlanet directory server happen to return them in the same
order every time. I'm not real sure what could be done about this
either, other than making the address book code support multi-valued
properties like LDAP does. I'm not also sure what the UI and code
implications of this are (ie whether it's really practical). But it
would probably solve Gerv's multiple email address problem.
> >It would be cool to have comments in the table describing the origin
> >(ie objectClass) where each of those attributes come from. I suspect
> >most of them are from inetOrgPerson, but there's definitely a few that
> >aren't.
> >
>
> Yep, most are inetOrg or from the super classes.
> I will update.
Great!
Dan
--
