>> 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-attrib
ute-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.
>>
>> /*
>> 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...
>> This ensures that
>>
>> 1) Generality is maintained when mapping from
>> ldap properties to mozilla.
>> 2) Consistent round tripping when editing
>> mozilla properties which are stored on
>> an ldap server
>> */
>
>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.
Thanks,
Paul.
| ? + ? = To question
----------------\
Paul Sandoz
x19219
+353-1-8199219
