118454 - Mozilla LDAP Integration does not support "nickname" and "country" - only "xmozillanickname" and "countryname"

Status: RESOLVED DUPLICATE of bug 116692

(MailNews Core :: LDAP Integration, defect)

Description

[Roland Felnhofer]

John, by testing your checked in fixes for bug 108366 and bug 105103 I found out
that Mozilla does not support "nickname" as attribute for nickname and "country"
as  attribute for work-country. Some other entries are supporting up to 4
attributes (like "Department" which can be defined in LDAP as "ou", "orgunit",
"department" or "departmentnumber").


Here my proposal:

--- mailnews/addrbook/src/nsAbLDAPProperties.cpp
+++ mailnews/addrbook/src/nsAbLDAPProperties.cpp

130  // ?
131  {MozillaProperty_String, "WorkZipCode",        "zip"},
132  // ?
133  {MozillaProperty_String, "WorkCountry",        "countryname"},
+    // country
+    {MozillaProperty_String, "WorkCountry",        "country"},
+    // ?
+    {MozillaProperty_String, "WorkCountry",        "c"},
+    // ?
+    {MozillaProperty_String, "WorkCountry",        "co"},

147  // ?
148  {MozillaProperty_String, "Company",        "company"},
149  // ?
150  {MozillaProperty_String, "WorkCountry",        "countryname"},
+    // country
+    {MozillaProperty_String, "WorkCountry",        "country"},
+    // ?
+    {MozillaProperty_String, "WorkCountry",        "c"},
+    // ?
+    {MozillaProperty_String, "WorkCountry",        "co"},

89   // mozilla specific
90   {MozillaProperty_String, "NickName",        "xmozillanickname"},
+    // mozilla specific
+    {MozillaProperty_String, "NickName",        "nickname"},

Comment 1

[John Marmion]

Roland, I will create a patch to add the two attributes viz nickname and
country. Once I have tested it, I will attach the patch. I don't see any
problems in this.

Looking at the bigger picture, we need to have some discussion on how we go
forward with this. The guys who designed some of this here originally wanted to
be completely vCard compliant with a general properties interface as opposed to
specific attributes names according to Mozilla and standardize on vCard names as
much as possible.

Comment 2

[Roland Felnhofer]

John, thank you.

I agree we should have a discussion about this. I checked a couple of weeks ago
the web if there are any RFCs in respect to vCard in LDAP. As far as I could see
there is an LDAP schema for vCard calendar entries (Calendar Attributes for
vCard and LDAP http://www.faqs.org/rfcs/rfc2739.html ) and there were once a RFC
draft (http://alternic.net/drafts/drafts-r-s/draft-royer-vcard-ldap-00.html) for
other vCard entries in LDAP which expired.

Comment 3

[John Marmion]

Roland,I want to clarify the patch. You want to add 'nickname' as an additional
 LDAP attribute. You also want 'country' and 'co' and 'c'. 

Having multiple LDAP attributes mapped to one Mozilla Address Book attribute has
highlighted a problem in the existing code which is worth putting down a marker
here. I would be interested in your feedback. The mapping is held in a HashTable
 which is built from the bottom up i.e. where 'FaxNumber' is mapped to 'fax' and
 'facsimilenumber' then if both exist then the value of 'fax' is returned as it
appears first in the table. But when the Advanced Search of bug #83023 is landed
then it will be possible to search on all attributes. In the case of multiple
attributes we will need to check for e.g. FaxNumber = 123456 => we will need to
generate the following (or(fax=123456)(facsimilenumber=123456)) and not
(fax==123456) as we currently do. The Hashtable will have to be changed to
supported multiple values rather one. I might raise a bug against this.

I will wait for your clarification.

Comment 4

[Roland Felnhofer]

John, Yes, that was my intention! :-)

In respect to the bug or problem you brought up. I agree with you! It is very
important hat ALL values get returned for MOST of the fields, instead of just
returning the first one. I think there are two possibilities:
1) multiple different attributes (fax, facsimilenumber,…) mapped to one field in AB
2) one attribute with multiple values (example: mail) 
In both cases ALL values should be displayed in individually selectable (mail
address!).

The reason why I highlighted 'MOST' is, as you know that in case of
'xmozillapreferredmailformat' and 'xmozillausehtmlmail' we do not what to get 2
results returned. Either someone should get his mail in 'HTML' XOR 'plain text'.
Maybe there are more attributes like this.

In your last post you brought up the need to have a 'big picture' discussion
about 'The future of LDAP in Mozilla'. As I already said I would highly
appreciate to participate in that discussion. What form would you propose to use
to discuss this? Do you what to open a new bug? Have a discussion in the
mail-news newsgroup or do it via e-mail? 
There will be also a lot of interfaces to other areas in Mozilla S/MIME and
certificates in LDAP,...

Comment 5

[John Marmion]

Roland, I don't pretend to have any great knowledge of LDAP but I am keen to do
the 'right thing' and also consult here with the guys here who originally
designed this stuff. I don't want to end up as some arbitrator on what LDAP
attributes are supported. Ideally this should be all user defined and not hard
coded. But in the meantime, we must agree some ground rules on the hard-coded
ones. I presume you have also seen bug #118585. I am also not keen to get
involved in agreeing schemas.

So, to the ground rules on the hard-coded attributes:
I would like to see us mapping Mozilla attributes to the most common existing
LDAP attributes. Where none of the latter exist then we have used the convention
of the prefix 'xmozilla'. What order should they appear in the table? If I
create a patch for the additional attributes for 'WorkCountry' should it be in
the following order?

'c', 'co' , 'countryname'.
i.e. use the abbreviated name first.

Incidently, I thought 'country' was an object class and not a LDAP attribute and
that is why I left it out above?

One final point to clarify from your last mail. How can Mozilla display both
'fax' and 'facsimilenumber' in 'FaxNumber' ?

Comment 6

[Roland Felnhofer]

John, I agree with you that what attributes should be used should be user
definable. How much afford would it be, after we have agreed on the Mozilla
schema for those attributes, which are not already predefined by some RFCs, to
remove the hardcoded part and replace it by entries in 'mailnews.js' and
'prefs.js'? AFAIK Communicator supported that.

Something like this:
pref("ldap_2.servers.attributes.countryname", " countryname");

user_pref("ldap_2.servers.roka.attributes.countryname", "co");

> So, to the ground rules on the hard-coded attributes:
> I would like to see us mapping Mozilla attributes to the most common existing
> LDAP attributes. Where none of the latter exist then we have used the convention
> of the prefix 'xmozilla'.

I agree also on that. I think the major question is here how we deal with all
the homexxxxx attributes. – I’ll take that up with Petr and I will start a
discussion thread in mail-news.

> What order should they appear in the table? If I
> create a patch for the additional attributes for 'WorkCountry' should it be in
> the following order?

I would recommend the following order:

'co', 'c', 'countryname'

Reason: 'co' uses the full country name (example: Austria) where 'c' and
'countryname' only stores the 2-letter abbreviation (example: AT). So if the
full country name is available - us it! Otherwise fall back to the 2-letter
code. Does that sound reasonable?

> Incidently, I thought 'country' was an object class and not a LDAP attribute and
> that is why I left it out above?
You are right!! Sorry that was a mistake from my side.

> One final point to clarify from your last mail. How can Mozilla display both
> 'fax' and 'facsimilenumber' in 'FaxNumber' ?

I know that would mean a resign of the UI. I didn’t meant to solve this here and
now. But we should consider to have the possibility in the future to map
multiple attributes as well as multivalue attributes to (multivalue-) fields in
Mozilla’s AB.

Comment 7

[John Marmion]

good stuff Roland. Your comments are very helpful. This patch is begining to
take shape. The order of WorkCountry sounds very reasonable. We now need to
agree the order of 'NickName' and also the addition of the 'homexxxx' attributes
and we could get this completed.   

Comment 8

[Dan Mosedale (:dmosedale, :dmose)]

Multi-valued attributes: can we spin up a separate bug for that issue?

John writes:

> The guys who designed some of this here originally wanted to
> be completely vCard compliant with a general properties interface as opposed
> to specific attributes names according to Mozilla and standardize on vCard
> names as much as possible.

But at the moment, things aren't really implemented this way at all, right?

> Roland, I don't pretend to have any great knowledge of LDAP but I am keen to 
> do the 'right thing' and also consult here with the guys here who originally
> designed this stuff. I don't want to end up as some arbitrator on what LDAP
> attributes are supported. Ideally this should be all user defined and not hard
> coded. But in the meantime, we must agree some ground rules on the hard-coded
> ones. I presume you have also seen bug #118585. I am also not keen to get
> involved in agreeing schemas.

Whatever default extensions we use are going to be widely deployed, and will
thus form a defacto schema.  So I don't think doing the work described in 118585
and whatever the other schema bug is something that can really be avoided.
(Kudos to Roland and Petr for starting work on this).

And yes, we should allow for user override of the different attribute names
here.  But I think setting up a mechanism for that should also be spun off as a
separate bug.

Now I think there are three things we need to sort out before we can actually
fix this bug here, even after spinning off those two other bugs, all of which
probably merit some discussion.  Specifically:

1) addressbook | LDAP/inetOrgPerson + xmozilla attrs (mozillaOrgPerson?) | vCARD
| LDAP/vCARD mappings and philosophy

Right now addressbook has its own table of attributes, which has (some) mappings
to the other formats above.  Maybe this is just fine as is, or perhaps the
"native" addressbook representation should move more in the direction of one of
the mappings.  I don't have any particular opinion here.

2) how to map extensions, in general, between all of the formats (eg nickname
and co are not part of orgPerson or inetOrgPerson), so maybe they need to go in
the schema being created locally (mozillaOrgPerson)?  Perhaps they should also
be named xmozillanickname etc so that they don't conflict if they are truly
standardized at some point.  But maybe not.

3) how do we deal with home vs work issue in all the mappings?  I have to say, I
like the LDAP/vcard proposal's use of attribute type descriptions for this. 
Whether it would be practical to use this mechanism with inetOrgPerson &
friends, I don't know.  If this isn't practical, we could just punt on this
issue and have extra attributes for one of the two places.

Discussions: how about cross-posting to both .mail-news and .directory, since
these groups are both very relevant?

Comment 9

[John Marmion]

I have created the two bugs discussed:
1. bug #119143 - AB and multiple LDAP attributes
2. bug #119199 - AB and LDAP multivalued attributes

A good starting point might be an attempt to create a table which shows the
Mozilla AB attributes and their possible vCard and LDAP attribute mappings. The
LDAP attributes could be divided into different classes i.e. iNetOrgPerson. We
could also include the schemas put forward by Petr and Roland. This could be
posted to the discussion groups in attempt to kick off the discussion. 

Comment 10

[Roland Felnhofer]

Dan, I want to command on 2). It's true that neither 'nickname' nor 'co' are
part of the orgPerson or inetOrgPerson objectclass. But 'co' is already defined
by LDAPv3: A Collection of User Schema [DRAFT] (see below for a link) and it's
already wildly used and distributed with OpenLDAP as schema template COSINE. For
Nickname I haven't seen so far a 'official (draft) version' so we could stick to
'xmozillanickname'. But would it harm if we query 'nickname' and fall back to
'xmozillanickname'?

Below a collection of reverences to RFCs which might be relevant for our work:

Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions
http://www.faqs.org/rfcs/rfc2252.html

A Summary of the X.500(96) User Schema for use with LDAPv3
http://www.faqs.org/rfcs/rfc2256.html

The COSINE and Internet X.500 Schema
http://www.faqs.org/rfcs/rfc1274.html

LDAPv3: A Collection of User Schema [DRAFT]
ftp://sunsite.cnlab-switch.ch/mirror/internet-drafts/draft-zeilenga-ldap-user-schema-04.txt

Definition of the inetOrgPerson LDAP Object Class
http://www.faqs.org/rfcs/rfc2798.html

Comment 11

[Roland Felnhofer]

I created a new spin-off bug

bug 119291 - LDAP attributes should be customizable

Comment 12

[Dan Mosedale (:dmosedale, :dmose)]

I was talking to Chris Toshok, who's done the LDAP / addressbook mapping work
for Evolution, the Ximian / GNOME MUA.  The schema that they use is here:

http://cvs.gnome.org/lxr/source//evolution/addressbook/backend/pas/evolutionperson.schema

Comment 13

[Mark Smith [:mcs]]

One quick comment about subclassing inetOrgPerson (or anything else). I am not
sure if you need to define an object class at all, but if you do I strongly
encourage you to avoid subclassing any existing structural class (in other
words, don't define something like evolutionPerson). Instead, define an
auxiliary class; that way, even people who have already subclassed inetOrgPerson
can mix your schema in.

In other words, instead of using entries like this:

    dn: ...
    objectClass: mozillaPerson
    ...

(where mozillaPerson is a new structural class that has SUP inetOrgPerson or
similar) you would use entries that look like this:

    dn: ...
    objectClass: inetOrgPerson
    objectClass: mozillaObject
    ...
If someone has amazonPerson that is already subclassed from inetOrgPerson, they
would create entries like this and all would be well:

    dn: ...
    objectClass: amazonPerson
    objectClass: mozillaObject
    ...

Technically it is illegal in LDAP to have two structure objectclasses in an
entry that are not part of the same inheritance hierarchy -- so this is disallowed:

    dn: ...
    objectClass: amazonPerson
    objectClass: evolutionPerson

Using an auxiliary class will also allow people to use the mozilla-specific
schema with other kinds of entries, e.g., groups.

Comment 14

[Roland Felnhofer]

Attachment: Mozilla - LDAP - vCard comparison

John, as you proposed I generated a table based on Petr's 'Mapping overview
table' and extended it by some attributes (example vCard). 

Petr, you told me, I can use our schema proposal. So I assumed that you have no
objections I use your other files, too, to bring this project forward. ;-)
Thank you Petr for your great work in starting with that.

The table is tab separated.

Comment 15

[Roland Felnhofer]

Attachment: Mozilla - LDAP - vCard comparison

John, as you proposed I generated a table based on Petr's 'Mapping overview
table' and extended it by some attributes (example vCard). 

Petr, you told me, I can use our schema proposal. So I assumed that you have no
objections I use your other files, too, to bring this project forward. ;-)
Thank you Petr for your great work in starting with that.

The table is tab separated.

Comment 16

[Roland Felnhofer]

Attachment: Mozilla - LDAP - vCard comparison

John, as you proposed I generated a table based on Petr's 'Mapping overview
table' and extended it by some attributes (example vCard). 

Petr, you told me, I can use our schema proposal. So I assumed that you have no
objections I use your other files, too, to bring this project forward. ;-)
Thank you Petr for your great work in starting with that.

The table is tab separated.

Comment 17

[Roland Felnhofer]

Attachment: Mozilla - LDAP - vCard comparison V02

I add some additional information and prefixed all Mozillla specific attributes
with 'xMozilla'

Comment 18

[John Marmion]

Roland, The table is great. It allows me to see many of the issues that we need
to address. I believe we should firstly sort out the MAB/LDAP Mapping before
addressing the vCard issue. This is my initial review of the issues arising from
the table.

1. we should be capable of supporting the LDAP Attribute, alias and similar name 
attributes.

2. If an LDAP attribute exists then we should use it and not the xMozilla
equivalent. Thus we should delete 'xMozillaDateOfBirth'.

3. We don't currently support the following LDAP attributes which appear in the
table:
gn,c, rfc822Mail,street,co,friendlyCountryName, organizationUnitName,
organizationName, street

4. We need to rename homeURL to xMozillaHomeURL, workURL to
xMozillaWorkURL,custom1, custom2,custom3 custom4 etc. 

5. I don't see any reference in the table to the following:
pagerphone,cellphone, carphone,postofficebox,locality,
region,zip,orgunit,department,departnumber,company,birthyear

6. Why do notes and description appear like that.

7. We need to remove xMozillaPreferredMailFormat

Comment 19

[Roland Felnhofer]

John, thank you for your feedback. In respect to your points:

1) 100% agreement
2) Agree (I just messed up things a little bit in my mind ;-) – let’s drop
‘xMozilladateOfBirth’
3) Right! Plus ‘dateOfBirth’ (it’s currently not uses in AB as far as I know –
but any how
4) 100% agreement
5)
pagerphone
No LDAP RFC reference
cellphone
No LDAP RFC reference
carphone
No LDAP RFC reference
postofficebox
Error (I missed that) [RFC2256 organizationalPerson 2.5.4.18]
locality
is not an attribute it's an objectclass (2.5.6.3 RFC2256)
	(attribute would be 2.5.4.7 'l' RFC2256)
region
The only reference I found where in 
	http://www.ietf.org/proceedings/99jul/I-D/draft-ietf-roamops-ldap-phonebook-01.txt
	(Expired: 1998-09-15) 
zip
No LDAP RFC reference
orgunit
No LDAP RFC reference
department
No LDAP RFC reference (found!)
	It's hard to search for 'department' - nearly all RFCs would match.
departmentnumber
Error (I missed that) [RFC2798 inetOrgPerson 2.16.840.1.113730.3.1.2]
company
No LDAP RFC reference (found!)
	It's hard to search for 'company' - nearly all RFCs would match.
birthyear
No LDAP RFC reference

6)
notes
No LDAP RFC reference (found!)
	It's hard to search for ' notes' - nearly all RFCs would match.
7) 100% agreement

I added the ‘none-RFC-referenced’ attributes, ‘postofficebox’ and
‘departmentnumber’ to the table.

Comment 20

[Roland Felnhofer]

Attachment: Mozilla - LDAP - vCard comparison V03

Update Version 3 (‘none-RFC-referenced’ attributes, ‘postofficebox’ and
‘departmentnumber’ were addes to the table)

Comment 21

[John Marmion]

Attachment: Attempt to map MS Exchange LDAP Address Book to Mozilla

I recently connected Mozilla to MS Exchange(MSE) using LDAP. I don't pretend to
know a lot about Exchange but felt it would be good to report how Mozilla maps
against MSE. I have produced a table to show the default direct mapping of
Mozilla with MSE, those MSE attributes which have no mapping and those MSE
attributes where no mapping is possible within the existing Mozilla
configuration. It appears that MSE schema is based on the objectClass
organizationalPerson. 

I hope that this table will be a contribution to our understanding. Roland's
last attachment shows what Mozilla needs to achieve in supporting LDAP
attributes and remains the definitive mapping of Mozilla LDAP attributes. I
also hope to take a similar look at Evolution.

Comment 22

[Roland Felnhofer]

John, thank you for your additional information about how MS Exchange maps to LDAP.

When we define how Mozilla AB maps to LDAP shouldn't we consider to extend the
current mapping? I especially think about supporting to display certificate
information. I know that might open another can of worms. Storing public certs
locally in a cert DBs vs. in an LDAP tree. How to replicate between them,&
But just having the possibility to display the stored cert information would
lift the lid too much, would it.

For maintaining my LDAP tree I use the Java based "LDAP Browser/Editor" version
2.8.2 written by Jarek Gawor  (http://www-unix.mcs.anl.gov/~gawor/ldap/ ). It is
able to display certs in a very nice and useful way.

The objectclass and attribute we would have to support are:

objectclass ( 2.5.6.15 NAME 'strongAuthenticationUser' SUP top AUXILIARY
        MUST userCertificate )

 attributetype ( 2.5.4.36 NAME 'userCertificate'
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )

And than we would have to interpret the encoded information. But I think there
is anyhow code within Mozilla available (Certificate Manager) that we can use.

Comment 23

[John Marmion]

Roland, I see no reason why we should not consider extending the current
mapping. Obviously I am keen that we set limits on what we are doing. But it
should be discussed first. I know that back in April of last year, there was
some discussion between Paul Sandoz (designer of LDAP Address Book stuff) with
Dan concerning adding two new attributes to hold a user's calendar URI to
support intergration with future Calendar support plus the need for an
"EncryptionKey". Dan would be a good person to comment both on this specific
issue and how this bug in general is progressing.

Comment 24

[John Marmion]

I will attempt to summarize the status to-date in an effort to move nearer to
closure on this. There have been a number of positive developments:

1. There appears to be a general consensus that we should use attributes from
the existing published schemas e.g. inetOrgPerson rather than invent our own.
2. This list would also include evolutionPerson if this is a published schema.
3. There was a good suggestion from Mark Smith in comment #13 that we avoid
subclassing xmozillaPerson (mozillaOrgPerson?) but rather define it as an
auxiliary class.
4. We should prefix mozilla attributes with xmozilla.
5. Roland's table remains our blue print for getting agreement on the
xmozillaPerson attributes. I have a number of minor queries in regard to this:

(a) Do we need BirthYear, BirthDay etc. - Do these attributes have a place in
the schema?
(b) CellularNumber maps to mobile, do we also need cellphone and carphone?
(c) Department maps to ou and departmentnumber, do we also need orgunit and
department and company

Comment 25

[Roland Felnhofer]

John, I agree with you over 1 to 5.
ad a) No – I don’t think we need 'BirthYear', 'BirthDay'.... As long as we use
'dateOfBirth'. 'dateOfBirth' is defined as 'GeneralizedTime' and can store year,
month, day and even hour, minute and second in it.

ad b) and c) No – I thing we should leave them out, too. Instead we should try
to solve bug 119199 and allow people to use multiple values in multivalue
attributes.

Comment 26

[Daniel Zirin]

I'll agree with Roland on comment #22 and add that we store public key for an
encryption key in userSMIMECertificate attribute.  But I like how we can alter
what the attribute names are in the prefs.js file (or similar place).  Just need
to ensure that we can pull up two separate certificate public keys for each user
in a directory.

Comment 27

[Dan Mosedale (:dmosedale, :dmose)]

(This text also added to bug 116692):

We're not going to be able to fix this for 1.0, but we do need to extend the
ad-hoc schema we've got now in some ad-hoc way (sigh) in order to be able to
import and export addressbooks without losing data.  I'd like to do this in some
way that keeps us from fouling up forward compatibility so that we can get back
to this bug in the not-too-distant future.  The current action for our
spit-and-bailing-wire patch is going on in bug 119360, so any input there would
be greatly appreciated.

Comment 28

[Roland Felnhofer]

Attachment: Mozilla - LDAP - vCard - MS Exchange comparison V04

Updated to fit changes introduced with fix for bug 119360
Added John's MS Exchange comparison

Comment 29

[John Marmion]

Assigning bug to [e-mail]

Comment 30

[Henrik Gemal]

*** Bug 218466 has been marked as a duplicate of this bug. ***

Comment 31

[Dan Mosedale (:dmosedale, :dmose)]

*** This bug has been marked as a duplicate of 116692 ***