116692 - Define official Mozilla LDAP schema extension

Status: RESOLVED FIXED

(MailNews Core :: LDAP Integration, defect, P2)

Description

[Roland Felnhofer]

As far as I know there is no official Mozilla LDAP schema extension available.

Currently I use my own OID in my xmozilla schema. Mozilla should have his own
official LDAP schema extension.

Comment 1

[Roland Felnhofer]

Attachment: LDAP schema extension for Mozilla

Proposal for the mozilla LDAP schema extension (xmozilla.schema) using my
privat OID

Comment 2

[Srilatha Moturi]

over to dmose

Comment 3

[Dan Mosedale (:dmosedale, :dmose)]

Agreed; we should do this. It's not something I'm gonna have time to poke at
real soon, though.  Roland, if you want to take the lead on this, feel free to
take this bug from me and go for it.

Comment 4

[Roland Felnhofer]

Dan, I can take this bug. I just checked if Mozilla already has his own OID
number. As far I can see it doesn’t seems so. ( I checked
http://www.isi.edu/in-notes/iana/assignments/enterprise-numbers )
Shell I request a number for Mozilla or is there a more 'senior' person who will
do that. 
To request it, I would need the following information:
*  Company Name : The Mozilla Organization
*  Company Address : ?
*  Company Phone Number : ?
*  Contact Name : Scott MacGregor or Michael Hein or Mark C. Smith or Me ???
*  Contact Address : ?
*  Contact Phone : ?
*  Contact Email : ?
*  FAX Number : ?
(Here it can be requested: http://www.iana.com/cgi-bin/enterprise.pl )
As soon as I have the official Mozilla OID I’ll post the first proposal. In
addition I would like to start a public discussion about the official schema in
one of the news groups. Would you recommended to use
netscape.public.mozilla.mail-news or netscape.public.mozilla.directory? I
personally would go with mail-news – the audience is larger.

Comment 5

[Roland Felnhofer]

As proposed by Dan I'll take this bug.

Comment 6

[Dan Mosedale (:dmosedale, :dmose)]

I think the thing to do is to set up an alias to be the "virtual owner" of this,
probably <[e-mail]>.  And any interested folks (probably most of
the CC list of this bug) could request to be put on that alias.  We can use
contact info for one or more mozilla.organs at AOL for the physical contact info
(I'm happy to volunteer).

Thoughts?

This schema will presumably cover at least stuff that the browser users, but
could potentially cover other things that the SDK owners care about as well (if
there are any.)

Comment 7

[Mark Smith [:mcs]]

I am a little lost.  Why does schema need to be defined for the mozilla client?
 Shouldn't the mozilla client be as schema agnostic as possible (very flexible?)
Looking at the attachement, some of the schema may be mozilla specific and some
may just not be defined anywhere else yet.

Comment 8

[Roland Felnhofer]

Mark, the schema doesn

Comment 9

[Roland Felnhofer]

Mark, the schema does not have to be defined for the client but for the LDAP
server. Nonetheless the Mozilla AB client shows a fixed set of attributes served
by a particular server. You can only use attributes on an LDAP server if you
have defined them in advanced. (You could disable schema check 

Comment 10

[Roland Felnhofer]

Dan, thank you for volunteering.

*  Company Name : The Mozilla Organization
*  Company Address : ?
*  Company Phone Number : ?
*  Contact Name : Dan Mosedale
*  Contact Address : ?
*  Contact Phone : ?
*  Contact Email : [e-mail]
*  FAX Number : ?

Could you provide me with the missing information? As soon as I have it and the
mail alias is set up I will request the OID.

Comment 11

[Roland Felnhofer]

I think we have here some duplication here.

Scope of bug 116692
* Define Mozilla schema
* Request official Mozilla OID

Scope of bug 118454:
* Extend Mozilla schema

Scope of bug 118585:
* Define Mozilla schema
* Extend Mozilla schema

We should consolidate your bugs.

Comment 12

[Roland Felnhofer]

Dan, any news concerning the official Mozilla LDAP mail address and the rest of
information I need to request an OID for Mozilla? 

Comment 13

[Roland Felnhofer]

Hi Dan,
I still would need some additional information to request the OID.
Any news concerning that pending issue? (see posts above)
Cheers
Roland

Comment 14

[Dan Mosedale (:dmosedale, :dmose)]

Sorry for dropping the ball on this Roland; I've been flooded in other stuff. 
We're not going to be able to fix this for 1.0, obviously, 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 15

[Kristof Petr]

Hello Dan,

can you sent to Roland all necessary info to make
administrative work to retrieve Enterprise OID 
for Mozilla Project, please?

I bet you will finish this homework in less than
5 minutes.

Thanks
   Petr

Comment 16

[Dan Mosedale (:dmosedale, :dmose)]

Petr: OK, thanks for prodding me on this:

*  Company Name : mozilla.org
*  Company Address : 360 W. Caribbean Dr., Mail Stop MV-066
*  Company Phone Number : 650-937-5905
*  Contact Name : Dan Mosedale
*  Contact Address : 360 W. Caribbean Dr., Mail Stop MV-066
*  Contact Phone : [phone]
*  Contact Email : [e-mail]
*  FAX Number : 650-937-2103

I've created the ldap-schema alias and pointed it to me.  If anyone else reading
this would like to be on the list, send me mail, and I'll add you.

Comment 17

[Roland Felnhofer]

Dan, thank you for the information. I just requested the OID. Can you let the
alias also point to me. ([e-mail])
Petr, thank you for your support.

 

Comment 18

[Roland Felnhofer]

Attachment: Mozilla LDAP schema V0.1

Comment 19

[Robert John Churchill]

For yucks, I added Roland's schema v0.1 into my (RH 7.3) slapd.conf, blew away
the gdbm files to start fresh, restarted slapd, and imported some LDIFs.  A few
issues I noticed:


o  for boolean values, OpenLDAP is completely braindead and only accepts either
TRUE or FALSE [yes, OpenLDAP's slapd is even case *sensitive* due to using
memcmp();  the developer at least added a comment indicating it was braindead
<sigh>]... so, it would be great if Mozilla would output one of the two values,
completely UPPERCASEd, when exporting LDIF data.


o  "xmozillaUseHtmlMail" is used solely in Mozilla in a couple of spots:
        nsAbLDAPProperties.cpp line 176
        nsAddressBook.cpp line 129
        nsAddressBook.cpp line 1220

but using schema v0.1's definition:

    attributetype ( 1.3.6.1.4.1.13769.2.1.2
        NAME ( 'mozillaUseHtmlMail' 'xmozillaUseHtmlMail' )

where 'mozillaUseHtmlMail' comes before 'xmozillaUseHtmlMail', the
HTML/Plaintext setting breaks.  The quick fix is to swap the two strings in the
schema file.  A better fix would be for Mozilla to recognize either.  :)

Comment 20

[Robert John Churchill]

Similar issues with xmozillanickname, homeurl, workurl, custom[1-4], etc.

Comment 21

[Roland Felnhofer]

Robert, first of all thank you for testing the schema and your feedback. I know
that there are (some) inconsistencies between the schema and what you get when
you make an LDIF export from your local Mozilla address book. Basically when I
designed the schema I had two choices. Either make it completely consistent with
Mozilla's LDIF export which is inconsistent to itself.  Some of the attributes
are 'mozilla' prefixed, some are "xmozilla" prefixed and some do not have any
prefix. So my choice was to 'brake'  LDIF import for the sake of consistency
within the schema (everything is "mozilla" prefixed). I only made an exception
for "xmozillaUseHtmlMail" and "xmozillaNickname" where I tied to use an alias
for the "xmozilla" prefixed attribute and it lead to some problems.

I hope you support my idea to try to make the Mozilla address book (LDAP)
attributes more consistent and change the LDIF export in a way it fits the
schema instead the other way round. - more ideas and feedback appreciated. In
addition - I don't know if some of the attribute definitions are, from a LDAP
RFC point of few, correct.

Comment 22

[Roland Felnhofer]

Attachment: Mozilla LDAP schema V0.2

I removed the two xmozilla aliases and added 'c' for 'countryName'(RFC2256:
ISO-3166 country 2-letter code) and 'co' for 'friendlyCountryName'(RFC1274:
friendly country name).
This two attributes are not use in objectclass person nor in inetorgperson.
These attributes are only used in objectclass 'country' and 'friendlyCountry'.
Objectclasses 'country' can not be used together with 'inetorgperson' because
both are structural from top (and 'friendlyCountry' is structural from
'country')

This schema will only work if changes are made in different parts of Mozilla.
To request these changes I will file a new bug.

Comment 23

[Brice Ruth]

What bug is being filed to add support for this schema? I'd like to track
progress on that bug as well.

Cheers.

Comment 24

[Roland Felnhofer]

Hi Brice,
check bug 157928 it's the Meta-bug for that.
Cheers
Roland

Comment 25

[Kristof Petr]

Note to #22:

Finally I did found time to look at ldap schema.

Version 0.2 looks very well.

I have no objection again it.

Comment 26

[Brice Ruth]

Correct me if I'm wrong, but I think we'll be needing to define some sort of
migration plan for bug 157928, so that folks that have created their own schemas
that correspond to the current way Moz exports to LDIF (and reads the LDAP
fields) won't all of a sudden be out in the cold when Moz starts using this
proposed schema to export to LDIF and to internally map Address Book fields.
This could be as simple as a preference that indicates "use_new_ldap_schema" or
not. By default, start shipping Moz (after a time) with it turned on and provide
information to LDAP administrators on how to disable this preference (either via
GUI or prefs.js) so that their systems stay compatible until they transition
their directories to the new schema.

Comment 27

[Roland Felnhofer]

Hi Petr,
thank you for your support.

Comment 28

[Roland Felnhofer]

Hi Brice,

may be we should check via newsgroup if there are really a lot of admins out
which would mind to migrate immediately from the old LDIF export format to the
new schema.
If there is no (or very few) response we should re-think if the effort of
implementing this migration path makes sense. Maybe we can simply provide this
people with a simple perl script which would migrate the old attributes into the
new ones?

If we have to add migration code into Mozilla we should already define how long
(how many releases) it will stay until it gets removed from the code again.
Second I would propose to call the preference something like
'use_ldap_legacy_structure' or 'use_ldap_legacy_schema'. If it is needed it
could be added to then by the user/admin into the prefs file and set to true but
by default it's not there.

Nonetheless what we do, we should file a new bug for that. Do you want to do
that? If yes please link it with the meta-bug (bug 157928)

Comment 29

[Brice Ruth]

Probably not a bad idea to just ask on the newsgroup to see how many people the
new schema would affect. Let's go that route before we file another bug.

Comment 30

[Roland Felnhofer]

Brice, are you kicking off the discussion? I would propose to post that question
in mail-news and directory.

Comment 31

[Roland Felnhofer]

Dan, a more organisational question. As soon as we agree on the first official
version of the Mozilla schema, can we check it in into the CVS tree and
distribute it with the binary nightly builds and releases?

Comment 32

[Brice Ruth]

I propose that the discussion be kicked off. I don't currently have access to a
news client, unfortunately, so could someone else outline what the ramifications
of the new schema will be to administrators that have adapted their LDAP
directories to be compatible with the current Mozilla architecture?

Comment 33

[Roland Felnhofer]

Brice, in about an hour I will make the posts.

Comment 34

[Curtis Nelson]

Nice work.  It would be great if you could create an attachment of a complete
example ldif we could use to import into our directory to better test this.  I
have a hacked together inetOrgPerson template I've been using, but it would be
nice to have a "Babs Jensen" Mozilla template so when we report bugs we're
working off similiar records.  Or at least have an idea of what record this
schema might support.  Thanks.  

Comment 35

[Roland Felnhofer]

Hi Curtis, I'll try to provide you with some examples tomorrow (CET).

Comment 36

[Roland Felnhofer]

Attachment: Test LDIF for Mozilla schema V0.2

Finally... Here is a LDIF file for testing all attributes used by Mozilla
schema V0.2.

My patch I posted
(http://bugzilla.mozilla.org/attachment.cgi?id=92142&action=view) seems to have
a bug in respect of displaying 'mozillaPostalAddress2',
'mozillaHomePostalAddress2' and 'postalAddress'. I try to fix that soon!

Comment 37

[Roland Felnhofer]

I created a new version of the patch
(http://bugzilla.mozilla.org/attachment.cgi?id=92887&action=view). I hope it works!

Comment 38

[Kristof Petr]

To comment #26:

Brice, dont affraid about people using LDAP based Mozilla AB _now_.
They are (i) total crazy or (ii) advanced admins (but usualy both).

Bloating software with dirty temporary workarounds (what no one need it)
is bad idea.

The Right Way to migrate is dump everything to ldiff, run it through
simple awk/perl script and reimport it again.

Comment 39

[Roland Felnhofer]

Petr, I agree (now) with you. I posted, as promised, in
netscape.public.mozilla.mail-news and netscape.public.mozilla.directory the
question if there is any need for a migration path. - So far 0 (zero) response!

I think it's fair to interpret that as "NO migration path is needed!"

Comment 40

[John Woodell]

As an LDAP admin, I agree that 'search and replace' is a fact of life
when working with LDIF files.

Before you call this schema final, it may be a good idea to look at
the attributes used by MS Outlook, just in case there is an obvious overlap.

The following document covers this issue very nicely:
http://www.yolinux.com/TUTORIALS/LinuxTutorialLDAP-GILSchemaExtension.html

Kurt Zeilenga ([e-mail]) has also defined some of these attributes:   
       
http://www.yolinux.com/TUTORIALS/OpenLDAP2.0-ExtendedStooges-extension.schema.txt

Comment 41

[Dan Mosedale (:dmosedale, :dmose)]

OK, I've just returned from a week's vacation and am starting to catch up on bug
mail.  Some thoughts:

Roland wrote:
>
> Dan, a more organisational question. As soon as we agree on the first official
> version of the Mozilla schema, can we check it in into the CVS tree and
> distribute it with the binary nightly builds and releases?

Sounds good to me.

> I created a new version of the patch

I think there are actually three different places that need to be patched (yeah,
this should all be centralized somewhere; there's a bug open on that).  In
addition to the one you patched, I think both import and export need to be dealt
with.  sspitzer, can you confirm this?

Petr wrote:
>
> Brice, dont affraid about people using LDAP based Mozilla AB _now_.
> They are (i) total crazy or (ii) advanced admins (but usualy both).

I don't think this is necessarily true, especially given that Netscape will soon
have shipped three versions (6.1, and 6.2 and 7.0) based on the existing Mozilla
code.

> Bloating software with dirty temporary workarounds (what no one need it)
> is bad idea.
> 
> The Right Way to migrate is dump everything to ldiff, run it through
> simple awk/perl script and reimport it again.

I'm not sure how I feel about this.  Brice's suggestion is certainly friendlier.

Roland wrote:
>
> Petr, I agree (now) with you. I posted, as promised, in
> netscape.public.mozilla.mail-news and netscape.public.mozilla.directory the
> question if there is any need for a migration path. - So far 0 (zero)
> response!
>
> I think it's fair to interpret that as "NO migration path is needed!"

I disagree that this is a particularly reasonable interpretation of that data. 
These are developer newsgroups.

However, because the export/re-import deal isn't too onerous, I'd be willing to
go along with providing no migration strategy to start with, and if people
really scream, we can include one at that point.

Comment 42

[Dan Mosedale (:dmosedale, :dmose)]

As far as the schema itself goes: 

* should we use "moz" instead of "mozilla" as the prefix just to keep things
shorter?

* rather than SecondEmail, how about AlternateEmail, in recognition of the fact
that people might want to make this multi-valued (and someday Mozilla might deal
with that reasonably :-).

* if I understand things correctly, if someone wants to turn on schema-checking
on their server, and they're not running OpenLDAP, they will need to go get
copies of core.schema and cosine.schema from OpenLDAP, correct?  And if they're
using ActiveDirectory, they'll need to get a copy of the M$ patch that supports
inetOrgPerson too?

Comment 43

[Roland Felnhofer]

John, I hope all LDAP admins agree with you.

> Before you call this schema final, it may be a good idea to look at
> the attributes used by MS Outlook, just in case there is an obvious overlap.

 Thank you for your hint. I was my fault not to already mention that. There is
all ready a bug 118454 dealing with that. We generated a file where we compaired
LDAP, MS  Exchange, Mozilla and vCard
(http://bugzilla.mozilla.org/attachment.cgi?id=83041&action=view).

I think the only weak point in our Mozilla LDAP schema is 'mozillaHomeUrl' and
'mozillaWorkUrl'. Currently there is a definition for 'labeledURI' (RFC 2079 -
ftp://ftp.isi.edu/in-notes/rfc2079.txt). The only problem in using that
attribute instead of  'mozillaHomeUrl' and 'mozillaWorkUrl' the distinction of
what type or URI (/ URL) is stored in that attribute is made by having an
undefined description after the URI, separated my 1 or more spaces. So Mozilla
would have to read all 'labeledURI' entries and analyze what's behind the space
and depending on that, either assign it to 'WorkUrl' or 'HomeUrl'. Without
question it would be desirable to do it that way. But I'm afraid that would
affect a lot of code in Mozilla and would take a significant long time until we
could get that productive. Nonetheless there is anyhow a bug 119199 dealing with
the problem that Mozilla currently does not support multi-value attributes. So I
would recommend to go, for the time being, with 'mozillaHomeUrl' and
'mozillaWorkUrl'. May be in the future we can get rid of it, together with
'SecondMailAddress' which would become obsolete, too, as soon as Mozilla can
deal with multi-value attributes.

Comment 44

[Roland Felnhofer]

Dan,
>> distribute it with the binary nightly builds and releases?
> Sounds good to me.
Great!

> I think both import and export need to be dealt with.

I thought of dealing with that in bug 157926 separately. We could have a LDAP
"read"-schema which would vary  from the LDIF import/export format without
actually breaking the code. Obviously we do not want that! But that was the
reason why I filed it as an individual bug with a dependency to this one.

> I disagree that this is a particularly reasonable interpretation of that data. 
> These are developer newsgroups.

I had no better idea how to address the LDAP admins

> However, because the export/re-import deal isn't too onerous, I'd be willing to
> go along with providing no migration strategy to start with, and if people
> really scream, we can include one at that point.

Fine with me.

> should we use "moz" instead of "mozilla" as the prefix just to keep things
shorter?

I don't have any strong preferences or good reasons for one or the other prefix,
but I like "mozilla" more. Maybe because it's more obvious that a so prefixed
attribute belongs to the Mozilla schema.

> ...SecondEmail, how about AlternateEmail...

I thought as soon as Mozilla can deal with multi-value attributes we would get
rid of SecondEmail and only using 'mail'. If I'm right I wouldn't see too much
benefit in changing that attribute - but also in that case - no strong feelings
(as long it only concerns the attribute name, not the multi-value issue!) 

> if I understand things correctly, if someone wants to turn on schema-checking
> on their server, and they're not running OpenLDAP, they will need to go get
> copies of core.schema and cosine.schema from OpenLDAP, correct?

Actually I don't think so. What someone would need is a schema, how every it is
called in his LDAP implementation, that supports the attributes and
objectclasses defined in RFC2256, RFC2798 and RFC1274 and used by our
addressbook. That is basically the objectclasses 'Person', '
organizationalPerson' and  'inetOrgPerson'  plus the attribute definition for
'c' ('countryName') and/or 'co' ('friendlyCountryName'). Correct me if I'm
wrong, but I think that all LDAP implementations are providing schemas for that
objectclasses and attributes. I'm quite sure it should not be a problem for you
or sspitzer to check that - at least for the Netscape / iPlanet LDAP server ;-)


> And if they're using ActiveDirectory, they'll need to get a copy of the M$ 
> patch that supports inetOrgPerson too?

I'll not start here a religious discussion. So I'll answer your question in a
generic way:
As long as a LDAP server implementation complies with RFCs and it's
"improvements" and "additional features" are not  incompatible with RFCs it
should not be a problem. 
Is that the case with M$ ActiveDirectory when it comes to standard compliance? 

Comment 45

[Kristof Petr]

Attachment: Mozilla LDAP schema V0.3

Added number of version into comment on beginning of file
Change mozillaSecondeMail -> mozillaSecondEmail mistypo

Comment 46

[Chan Min Wai]

Will the change actually make any difference?

Comment 47

[Chan Min Wai]

I'm now using Open Office, and guess what I found...
They are also using the LDAP format that Mozilla use on the address book.

This tell me that we are in big trouble, we are not only blocks Mozilla but Open
Office as well. did we actually have a old standard schema for that?

If not why they use it?

Comment 48

[Roland Felnhofer]

>did we actually have a old standard schema for that?

>If not why they use it?

As far as I know, there had never been something like a standard  Netscape nor a Mozilla schema.
I don't know why Open Office where using it, but I suspect in absence of an official schema they used what they could get. I think that makes it even more urgent and important to define an official one.

Comment 49

[Chan Min Wai]

I've Just drop a message to them, I hope we can have fast reply and can slove
this issure ASAP.

Comment 50

[John Marmion]

The existing LDAP schema and LDAP Address Book in mozilla was partly due to a
contribution by OpenOffice.org (OOo) programmers. Our aim  was to add some
enterprise functionality to mozilla and also as a means of accessing LDAP
Directory data sources for OOo through integration with mozilla. See
http://abzilla.mozdev.org. So our paths are inextricably linked on this issue
and we are watching the development of this with interest. 

Comment 51

[Chan Min Wai]

Is this problem sloved yet :)

Comment 52

[Roland Felnhofer]

Attachment: Mozilla LDAP schema V0.4

Adding support for new attribute "nscpAimScreenName".

Comment 53

[Roland Felnhofer]

Attachment: Mozilla LDAP schema V0.4

Forgot to add "nscpAimScreenName" to the objectClass

Comment 54

[Mark Smith [:mcs]]

On nscpAIMScreenName: as far as I know, that attribute type is only used
internally by AOL. Is it being used elsewhere? Unfortunately, there are many
different attribute types that are all designed to hold AIM IDs. Netscape
Directory Server 6.x supports one named nsAIMID "out of the box."

Comment 55

[Roland Felnhofer]

Dear all,
To clarify a little bit what my intentions was in respect to the "official
Mozilla LDAP schema"

If an LDAP attribute is used by Mozilla('s address card) and not already defined
by an official (RFC) LDAP schema it should become part of the Mozilla schema.

So somebody can setup any LDAP server (OpenLDAP, Netscape, …) use official
schemas and Mozilla's schema, can turn schema checking on, on his server and all
values in the address card can be displayed when the data source is this LDAP
server.

So in response to Mark's post (comment 54) – if somebody is using another LDAP
server than Netscape's this attribute (nscpAimScreenName) is not defined in any
of the official schemas and he can't use this attribute in his directory.
Nonetheless if the attribute is already used by Netscape's LDAP server
internal/private schema we should use the same OID as Netscape.

Comment 56

[Mark Smith [:mcs]]

In response to Roland's comment 55, thanks for the explanation. I would argue
that you should replace nscpAIMScreenName with nsAIMid because nsAIMid ships
with one LDAP server implementation and is well defined with respect to OID,
etc.  Here is the definition:

attributeTypes: (
  2.16.840.1.113730.3.1.2013
  NAME 'nsAIMid'
  DESC 'AOL Instant Messenger (AIM) Identity'
  SYNTAX 2.16.840.1.113730.3.7.1
  )

Comment 57

[Chan Min Wai]

Propose of cancel the Line 2 address and replacing them with a sperator "$" on
line 1 as $ is one of the RFC standard so that it could read other LDAP address
standard.

http://ldap.akbkhome.com/objectclass/organization.html#postalAddress

Comment 58

[Roland Felnhofer]

Mark, (comment 56) when I said "... using the same OID as Netscape ..." I meant
OID AND attribute name. So thank you for providing me with the attribute definition.

All we need to do is to convince Seth to change "nsAbLDAPProperties.cpp" (He
implemented that attribute in the first place bug 142845. Now as soon as it is
done I will remove "nscpAIMScreenName" and add "nsAIMid" to the schema.

Index: addrbook/src/nsAbLDAPProperties.cpp

-    {MozillaProperty_String, "_AimScreenName",        "nscpaimscreenname"},
+    {MozillaProperty_String, "_AimScreenName",        "nsaimd"},

Comment 59

[Roland Felnhofer]

Chan, I agree with you in principal. But I want to avoid that checking-in of
this schema gets more and more delayed. I opened that bug 2001-12-23 and today
we have 2002-10-17 so it’s now nearly a year old. We already got an OID for
Mozilla. 

So all we need to close this bug and check in the first official Mozilla schema
is to agree on it!

If the code changes are not to significant and doing it doesn’t take too long –
let’s go for it. But I would propose you file an separate bug. 

Comment 60

[Chan Min Wai]

Well, I've actually open a sperated Bug on 2002-08-16 on
http://bugzilla.mozilla.org/show_bug.cgi?id=163069 but no one respond me at that
time. Until Now I think this is the place for it and not a sperated places.

Sorry for being late, but it is still better than none.

At then same time, I agree with we should close this Bug ASAP, And I'm sure we
can make both of them coexits.

Comment 61

[Chan Min Wai]

I'm trying to user the new schema with the 0.4 schema But it give me a few problem.

1. The Attribute type is writter wrongly. it should be

attributeTypes (
  2.16.840.1.113730.3.1.2013
  NAME 'nsAIMid'
  DESC 'AOL Instant Messenger (AIM) Identity'
  SYNTAX 2.16.840.1.113730.3.7.1
  )

2. The Syntax 2.16.840.1.113730.3.7.1 is an Netscape Directory Server OID, and
can't be use on the Open LDAP server unless it is  well define. 

Can someone get the Netscape Directory Server OID to work with Openldap?

Thank You.

Comment 62

[Chan Min Wai]

Additional Configuration for mozillaSeondEmail seggusting to change to.

attributetype ( 1.3.6.1.4.1.13769.2.1.3
	NAME 'mozillaSecondEmail' 
	EQUALITY caseIgnoreIA5Match
	SUBSTR caseIgnoreIA5SubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )

Without the Equality and Substr you will not be able to clear the
mozillaSecondEmail after it is set. 
(This is just copy from core.schema  mail Attribute)

attributetype ( 0.9.2342.19200300.100.1.3
	NAME ( 'mail' 'rfc822Mailbox' )
	DESC 'RFC1274: RFC822 Mailbox'
	EQUALITY caseIgnoreIA5Match
	SUBSTR caseIgnoreIA5SubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )

Thank You

Comment 63

[Mark Smith [:mcs]]

The syntax defined by OID 2.16.840.1.113730.3.7.1 is not publically documented;
sorry. I forgot about that issue. The syntax is one we defined specifically for
AOL ScreenNames. I doubt OpenLDAP has anything similar. Among other things, it
supports matching that is space-insensitive as well as case-insensitive (so
"John Q Smith" matches "john q smith" and "johnqsmith"). I am not sure what to
do about this. Does OpenLDAP allow you to easily add new syntaxes?

Comment 64

[Roland Felnhofer]

Attachment: Mozilla LDAP schema V0.5

Added EQUALITY caseIgnoreIA5Match and SUBSTR caseIgnoreIA5SubstringsMatch to
'mozillaSecondEmail'

Comment 65

[Roland Felnhofer]

Chan, Mark, I'll check if it's possible to add another syntax in OpenLdap.

Comment 66

[Roland Felnhofer]

Mark, you said in comment 64
> I doubt OpenLDAP has anything similar. Among other things, it
> supports matching that is space-insensitive as well as case-insensitive (so
> "John Q Smith" matches "john q smith" and "johnqsmith")

It depends on what "other things" means, but in OpenLDAP you have:

        EQUALITY telephoneNumberMatch
        SUBSTR telephoneNumberSubstringsMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
surprisingly it does not only allows phone NUMBERS it also allows characters.

I used your example "John Q Smith" and misused the attribute 'pager' for my
tests; it has the above equality, substr, syntax definition.

Result:
Ldap entry:     pager=johnqsmith
search for:     pager=johnqsmith       FOUND
search for:     pager=john q smith     FOUND
search for:     pager=John Q Smith     FOUND
search for:     pager=JohnQSmith       FOUND

Ldap entry:     pager=John Q Smith
search for:     pager=johnqsmith       FOUND
search for:     pager=john q smith     FOUND
search for:     pager=John Q Smith     FOUND
search for:     pager=JohnQSmith       FOUND

The downside is that that kind of definition would also ignore "-" 
What do you think?

Comment 67

[Mark Smith [:mcs]]

Except for also ignoring - characters, telephoneNumberMatch will work fairly
well for AOL Screennames. See:

  http://www.alvestrand.no/objectid/2.5.13.20.html

If your goal is to have one schema file that can be distributed with the Mozilla
client and used with all LDAP servers, using different syntaxes and matching
rules in different servers is not an option. But perhaps we could provide advice
(e.g., use the Netscape syntax if your server supports it; otherwise use this
other syntax  and matching rules instead).

Comment 68

[Chan Min Wai]

So, Mark what is your advise? I've check a few post on OpenLDAP and the problem
for defination new SYNTAX. is that you have to recompile with Hacking or
recompile with some options (somthing like -new-syntax I forgot).

So that you can define some syntax later in your schema files. but for what I
know it is only for testing purpose only.

Comment 69

[Mark Smith [:mcs]]

My advice is to use nsAIMID and the Netscape syntax, but also provide an
alternative (nsAIMID with the telephoneNumber syntax and rules). Not a perfect
solution, but an OK one.

Comment 70

[Roland Felnhofer]

Attachment: Mozilla LDAP schema V0.6

I changed "nscpAIMScreenName" to "nsAIMid" and add 2 different attribute
definitions. One for LDAP server supporting  SYNTAX 2.16.840.1.113730.3.7.1,
one for servers not supporting that syntax.

Both are currently commented out .

Comment 71

[Mark Smith [:mcs]]

Comment on attachment 104856 [details]
Mozilla LDAP schema V0.6

Please replace iPlanet with Netscape in the nsAIMID comments. The
iPlanet/SunONE DS does not support the AIM syntax, but Netscape DS 6.x does.

Comment 72

[Roland Felnhofer]

Attachment: Mozilla LDAP schema V0.6

Replaced "iPlanet" with "Netscape 6.x"

Comment 73

[Chan Min Wai]

Did you all have any plan to add ICQ UIN in as well :)  (cause I'm using it)
Well, I think we should close this and as the same time check about These :
mozillaNickname, mozillaHomeCountryName for the last time.

cause they don't have any SYNTAX.

time is ticking...

Comment 74

[Roland Felnhofer]

I would recommend to check-in a core schema as soon as possible and extend it's
scope (ICQ UIN,...) in later versions. For the moment I think we should focus on
attributes used in the address book client or are relevant for Mozilla itself.

'mozillaNickname', 'mozillaHomeState' and 'mozillaHomeCountryName' HAVE Syntax
definition. Not explicit but implicit (derived from 'name') by SUP.

But if all of you feel better if it is defined explicitly for all attributes, I
can change it.

Comment 75

[Chan Min Wai]

That is ok, and let and please... check-in a core schema ASAP. 
At the same we should change Bug 157926 and Bug 157925 

Comment 76

[Markus M. May]

I have a problem with the schema (V0.6) and OpenLDAP on Linux. I get an error
Unexpected token before NAME ( 'mozillaNickname' )
Any hints?

Comment 77

[Chan Min Wai]

The Problem didn't happen to me, did you add core.schema and cosine.schema and
inetorgperson.schema.

They are require.

Comment 78

[Chan Min Wai]

Could this Schema be check in Now?

Comment 79

[Chan Min Wai]

May I know what is the out come?
Please and Thank You.

And anyone is having problem with it?
Should this be test on the 1.2 final?

Comment 80

[Roland Felnhofer]

Dan, Yulian,
what is missing to check in this schema? I think it's now long enough around, so
everybody was able to make his input. 

Comment 81

[Chan Min Wai]

May I know, what version of Mozilla will be using this?
Cause I've changed a Web Base Ldap (Rolodap) to work with it.

So that you can use Openldap with Web as input and Mozilla to view.
You can find it here
http://asia.briefcase.yahoo.com/dcmwai/
Under My Documents

Comment 82

[Chan Min Wai]

Are we getting it to the wrong Target Milestone, the next released would be 1.2
Final and Not 1.2 Beta.

Anyone? 1.2 Beta is released and 1.2 Final will be Stop on 30-Nov.

We better be fast.

Comment 83

[Frédéric COIFFIER]

I would like to use OpenLDAP as LDAP server for the current version of Mozilla
(1.2) and I would like use the LDIF exported file to fill my LDAP database.

Are there anyone who have reached to do this ? Are there links which explain that ?

Comment 84

[Chan Min Wai]

Well, we are actually redefind the LDAP Schema so that it can be use in Other
LDAP server Like OpenLDAP. But I think we've miss the 1.2 version. The source
code is not Check In Yet. 

I don't think there is any there, Sorry for that.
But you can always goto the "Future Version" With the Patch.

Comment 85

[Chan Min Wai]

I think we should get Both Bug 157925 and Bug 157926 Work.
The Schema is not working without them.
Then We Need to Seek for Review. Super Review and Appoval.
Roland Please get review from [e-mail].
(On Action Edit) Put a ? on review and [e-mail] on the Box.

Comment 86

[Asa Dotzler [:asa]]

We're not going to hold 1.3a for this. That doesn't mean that the fix won't be
included in 1.3a. (The "wanted1.3a" flag has been changed to "blocking1.3a" to
more accurately reflect how the flag is used by [e-mail]). 

Comment 87

[Dan Mosedale (:dmosedale, :dmose)]

Sorry I've been away from this bug for so long, I've been concentrating on spam
work recently.  I'll try and get to this soon. It won't make 1.3alpha, but
hopefully 1.3beta.

Comment 88

[John Woodell]

PROCESS:

I exported an LDIF from the most current mozilla browser (1.3b):
http://www.netpress.com/mozilla/ab2ldap_1/jsmith_mz13_ldif

I made some changes to that it was valid and a good test:
http://www.netpress.com/mozilla/ab2ldap_1/jsmith_mzED_ldif

I had to made some changes so that I could importing the LDIF
into three LDAP server (netscape 4x, openldap 20 and 2.1):

http://www.netpress.com/mozilla/ab2ldap_1/mozilla_ns4x.schema
http://www.netpress.com/mozilla/ab2ldap_1/mozilla_op20.schema

I also saved the result from an ldapsearch:
http://www.netpress.com/mozilla/ab2ldap_1/jsmith_op20_ldif
http://www.netpress.com/mozilla/ab2ldap_1/jsmith_ns4x_ldif

Which indicated that the data is actually there.
Two oooof these servers are publicly visible if you
want to teat against them:

(these URLs will work in Communicator 4.x)
ldap://ns4xldap.netpress.com/cn=John Jacob Jingleheimer
Smith,ou=people,dc=netpress,dc=com
ldap://openldap.netpress.com/cn=John Jacob Jingleheimer
Smith,ou=people,dc=netpress,dc=com

CONCLUSIONS:

I want to see all this data in the address book, but:
- The attributes 'postalAddress' should be 'street'.
- The attribute 'dislayName' fails when in netscape 4.x
- The 'street' and 'c' (country) attributes fail when in OpenLDAP 2.0
- Nothing comes acress when you point to OpenLDAP 2.1  :-(

For the two servers that can see the data:
- Everything on the third tab comes across fine (custom1-4, description)
- the 'postalAddress' needs to be changes to 'street',
  the 'postalAddress' should be (in my opinion):  
  street + ", " + l + ", " + st + "  " + postalCode:
- None of the home address stuff is showing up,
  I expect I can try using xmozilla... and see if that works.

More on this later...

Comment 89

[John Woodell]

ANOTHER TEST... (running Mozilla 1.3b - Gecko/20030103)

Output from mozilla AB was modified to match the 'official' schema:
http://www.netpress.com/mozilla/ab2ldap_2/jsmith_fix.ldif

Here is my slightly tweeked version:
(objectclass is STRUCTURAL, and SUB to inetOrgPerson)
http://www.netpress.com/mozilla/ab2ldap_2/mozillaOrgPerson.schema

I also saved the result from an ldapsearch:
http://www.netpress.com/mozilla/ab2ldap_2/jsmith_op2m_ldif

CONCLUSIONS:

The attributes that were showing up in the AB are bow missing (as expected).

When you use the V0.6 schema, you do a lot of work on the exported LDIF
which then hides the attributes from the AB. Nobody wahte this, I'm sure.

I suggest that 'we' crack open the AB LDAP interface and tell it to look
for both the old and new attributes. I can write up a test case if you
think that would be helpful.

The mapping in this schema workd because LDAP returns the first entry:
http://www.netpress.com/mozilla/ab2ldap_1/mozilla_op20.schema

Comment 90

[Chan Min Wai]

I'm quit blur for comment 88 and comment 89.
What are they for actually, backwords compitablilty?

Thank You

Comment 91

[Chan Min Wai]

request to be review and checkin on 1.3 Beta.

It have been too long and it is now solve.
For the time being, we will need to be compitable with the old schema
(unofficial) until we find a way to mirgade the data.

Comment 92

[John Keiser (jkeiser)]

Comment on attachment 104858 [details]
Mozilla LDAP schema V0.6

I'm not clear what the issue was getting this reviewed, but putting it in the
review queue so it doesn't get lost.

Comment 93

[Dan Mosedale (:dmosedale, :dmose)]

I suck for not getting back to this much sooner; sorry everyone.  I'm on
vacation for the next week, but this is too late for 1.3 anyway, I think.  I'll
try and look at it soon.

Comment 94

[Ming Deng]

To make mozilla AB output to be a decent data source for generic ldap database,
we may need to differentiate organization objects and person objects. 
An Address Card may not necessarily be created for a person, it can also be
created for an oganization. Many Address Cards in my collected address book are
not for persons but for organizations. If we can make persons and organizations
 look different, then people could get better focused search results (by using
objectClass=person) and won't miss collected organization records at searchs
when they don't know mozilla's address cards of organizations were put into
person objectClass.

Though I know it would be difficult, but claiming those address cards as
"person", "organizationalPerson" or "inetOrgPerson", as mozilla currently does,
has problems.  Object "person" (so as organizationalPerson and inetOrgPerson)
requires a mandatory "sn" attribute, which is not garenteed for all address
cards, and this attribute does not make sense for organizations.

Comment 95

[Bill Mair]

I have reorganized and extended the entries in nsAbLDAPProperties.cpp.

This displays all of the entries on the LDAP server in the address card.

I have kept the original entries for backward compatability, and added the
entries for MozillaOrgPerson. I hope that this change can make it to the
1.3 final.

I have opened the bug "Address cards do not display all of the information
stored on LDAP server", please refer to
http://bugzilla.mozilla.org/show_bug.cgi?id=195526 for the complete table

Comment 96

[John Woodell]

Regarding comment <A href="#c90">90</A>

- attributes should be displayed when browsing OpenLDAP with Mozilla AB.
- attributes should have only valid names
  ("_AimScreenName" is not valid, it makes OpenLDAP sick).
- Use 'street' not 'postalAddress' when you mean street.
  the 'postalAddress' should be a dynamic attribute that returns
  [ street + ", " + l + ", " +  st "  " + postalcode ]

Comment 97

[Paul Berendsen]

John Woodell wrote in comment #96:
- ...  the 'postalAddress' should be a dynamic attribute
  that returns
  [ street + ", " + l + ", " +  st "  " + postalcode ]

Are you sure about that?  Why?
Is that an LDAP standard?
Or do you say that because in the USA postal addresses
are made up like that?

Comment 98

[Bill Mair]

John Woodell wrote in comment #96:
- ...  the 'postalAddress' should be a dynamic attribute
  that returns
  [ street + ", " + l + ", " +  st "  " + postalcode ]


'postalAddress' is defined in the LDAP standard as being part of the
organizationalPerson object, and is by no means a "virtual" field.

A postal address may be completely different to the real address, consider a
large organization, where one department is at location A, i.e. the
'streetAddress', the company also has a PO box, i.e. the 'postofficebox', and
the address of the HQ, i.e. the postalAddress.

See http://bugzilla.mozilla.org/show_bug.cgi?id=195526 for the fields and their
equivalent entries in MozillaAB

Comment 99

[Maurice Galland]

Regarding comment #94, I agree with Ming Deng. How about being able to create
entries with objectClass=o for organizations? In our LDAP directory, we do
separate people and organizations in two distinct ou.

Comment 100

[Matthias Wimmer]

Why are there attributes for a second mail address and postal address? 
Shouldn't be all mail addresses specified as multible "mail" attributes in a record? 
(Same with postalAddress ...) 

Comment 101

[Chan Min Wai]

If we delay the implementation of this official LDAP schema, there will be no
more changes. As time being, most people is starting to change to LDAP and this
is the time we implementatiaon this.

I Strongly Suggest that we being included on 1.4 Beta and if possible include on
the 1.4 final. 

for the time being we will still be compatible with the old and unofficial
schema as Bug 157925 show.

For Comment #99 and Comment #94, that is a good suggestion but somehow making
things very difficult. I do see the benefit to make them different because there
are different need. But Somehow this will delay the LDAP Schema to be Official,
For the time being, We have to Make this schema Official and discuss this later
one. Cause it does involve Addressbook Development.

For Comment #100 there are many way to do so, and there are no any default way
or easy way. Using One Atribute does have a good point when the address is
display is a Text Box. However, Netscape and Mozilla does have 2nd line on the
Address which make us much different from all MS LDAP Product. I've state this
on Bug 163069. This will be bring forward to the 2nd level once this is make
Official.

Comment 102

[John Woodell]

Attachment: example LDIF using standard attributes/objectclasses

This ldif shows standard values for three objects: locality, organization and
inetOrgPerson

Comment 103

[John Woodell]

Regarding Comment #97 and Comment #98,

I need to clarify what I tried to say. An LDAP server will not always have
a one-to-one mapping for attributes like a relational database would.
The 'street' element of your primary address should use the 'street' 
attribute, while 'postalAddress', 'registeredAddress' and 'homePostalAddress'
should be the entire adress:

  street: 466 Ellis Street
  l: Mountain View
  st: CA
  postalCode: 94043
  postalAddress: 466 Ellis, Mountain View, CA 94043
  registeredAddress: 360 W. Carribean Drive, Sunnyvale, CA 94089
  homePostalAddress: 200 Mission Street, Suite 20, San Francisco, CA 93123

See my previous attachment.

Also, the example ldif for the mozilla schema should use 'mozillaHomeStreet'
instead of 'homePostalAddress', which should be a complete address:

  mozillaHomeStreet: Hugo Street 15
  mozillaHomeLocality: Foolvill
  mozillaHomeState: SW
  mozillaHomePostalCode: 4711
  Hugo Street 15, Foolvill, SW 4711

Comment 104

[Stefan Lohrum]

Attachment: Test case for Display Names with Comma

Exporting an address card which contains a comma in "Last Name" or "Display"
field to DLDIF format, OPENLDAP complaines that there is a no valid string-
representation of distinguished name.

Either "dn:" must not contain a comma between master and s or the value
double quotaion marks are to be used.

The example in the attached file is checked with Mozilla 1.3.1
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425]

Comment 105

[Alberto S�ez]

Hello, I’m trying to populate my LDAP server with from Mozilla Address book (I 
have about 400 registers). 
I’ve spend some time, trying to do this. At last, I have found this bug line. 
But now I don’t know what to do.

I’ve tried to change the ldif file with a sed/awk/perl script, using one of 
your schemas in my openldap server (I’ve test all of them: from the firs 
abmozillaPerson  of Kristof Petr , V6 from Roland Felnhofer, and the ones from 
John Woodell ) and none works.

 This is because this is necessary not only to change the name for the objects 
an attrs, but following the rules of the LDAP schema: Ej: an InteOrgPerson 
needs to have an sn entry: and the ldif file froma mozillaAB sometimes doesn’t 
generates an sn entry for each person (this is only an example). This work is 
very hard to do with a simple sed/awl/perl script. 

Do I need to path the mozilla source code to generate a correct ldif file? This 
is the last straw who brakes the camel’s back.  I only need to get my ab entries

 One more item:  The V6 schema doesn’t works with openldap 2.1 : the server 
complains about the line: 
‘sAIMid $ ‘

Thanks a lot for your efforts

Comment 106

[Ming Deng]

I would advice to forget about the schema now, until mozilla.org has worked out
a decent version. Spend more time to work out a perl program of yourself, so you
can import mozilla ldif into inetOrgPerson object class.

Comment 107

[Roland Felnhofer]

Regarding Comment #105

Alberto, before you can use schema V0.6 you have to adapt it to your LDAP server.
Most LDAP server (OpenLDAP 2.1.x, ...) don't support SYNTAX
2.16.840.1.113730.3.7.1. So I had to do a little trick and use SYNTAX
1.3.6.1.4.1.1466.115.121.1.50 instead.

If you want to use schema V0.6 with OpenLDAP 2.1.x (that is what I do) just
un-comment the following part in the schema file.

# attributetype ( 1.3.6.1.4.1.13769.2.1.13
#	NAME ( 'nsAIMid' )
#	DESC 'AOL Instant Messenger (AIM) Identity'
#	EQUALITY telephoneNumberMatch
#	SUBSTR telephoneNumberSubstringsMatch
#	SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )

I've never used Mozilla's internal address book, so I have very few experience
what you have to do to make its so-called LDIF export really LDAP compliant. But
if you try it with some test records you will find it out very soon.

Everytime I update Mozilla I patch the Addressbook to use this unofficial
Mozilla schema extension and I'm very satisfied with it for quite a long time.
(Finally I gave up that these small little changes would make it into the
official source to let Mozilla use LDAP in a useful way)

Comment 108

[Johny]

Attachment: Perl script for address book conversion

This is my home grown script for doing conversion of an Address Book which I
import to Moz from Outlook and then export as LDIF. It contains fixes for all
the amusing conditions I could find, the only thing it doesn't cater for of
those I encountered are Groups, but I don't have any I want in LDAP, so I don't
care ;)

Feel free to use, I'd appreciate a wee note saying 'thanks' if you find it
useful, and if you have improvements (this is my first Perl program! ;) or
suggestions for them I'd love an email :)

Comment 109

[P h i l l]

This line needs adding to the perl script:

 $line =~ s/xmozillausehtmlmail/mozillausehtmlmail/;

Comment 110

[Robert Sander]

Hi!

I'm not interested in importing from Mozilla to OpenLDAP but the other way
around. Using an LDAP server with Mozilla's addressbook.

Some attributes get through but some not. Even attributes defined in this latest
schema do not get shown in Mozilla's addressbook.

Is there a table where the working attributes are shown?

Comment 111

[John Woodell]

Comment #110 is absolutely true. If you export you mozilla address book,
and load it into LDAP, several attributes will be missing when you point
mozilla at the LDAP server.

 - mozillaSecondEmail does not show up (for example).
 - mozillaNickname and mozillaUseHtmlMail do seem to work.

Seems like there needs to be another bug that deals with this.

Load this ldif into LDAP and you will see what I mean:
http://www.netpress.com/mozilla/ab2ldap_z/jsmith_nice_ldif

Comment 112

[Bill Mair]

See http://bugzilla.mozilla.org/show_bug.cgi?id=195526

I have already uploaded a patch for this problem.

It resolves the various versions of mozilla LDAP and displays them correctly,
including things like the addess.

Bill

Comment 113

[Chan Min Wai]

This bug is almost 2 years old, Somebody please help.

Comment 114

[Hadmut Danisch]

Is anyone working on defining an LDAP scheme for addressbooks?

Hadmut

Comment 115

[Harold Beumer]

I don't see any recent activity on this or related bugs.

Please see also (meta) bug 157928
This meta bug is a summary of three related LDAP/LDIF problems:
1) there seems to be no officially approved LDAP schema
   (there is a 0.6 version around however, status is unknown)
2) Mozilla doesn't read Home* contact fields from LDAP server
   (these fields are specified in the o.6 version of the LDAP schema
3) LDIF import/export is not consistent with LDAP schema (different
   names for contact fields

With these bugs solved, Mozilla Mail/Thunderbird will be a viable
alternative for anyone wanting to move away from Outlook/Exchange
server for their e-mail clients and central address book server.

Comment 116

[Hadmut Danisch]

There are more problems. I recently reported several bugs in the 
LDAP part of mozilla, some of them turned out to be known for years.

I just had to keep a list of people in an openldap 
directory. The Mozilla "GetMap" button requires the country
to be set properly. Mozilla evaluates the "c" attribute, but
none of the schemes which come with openldap or set by mozilla
have a c attribute.

Would it be possible to form an LDAP subgroup defining a new
address scheme as an internet standard and to define what
to do with it and its semantics? A scheme that supports
all those opensource address applications and e.g. synchronization 
with PDAs, mobile phones, Voice-over-IP applications? I'd be
happy to contribute.

This would make life much easier and help to get Mozilla become
the best browser for addressbooks also. 

regards
Hadmut

Comment 117

[Roland Felnhofer]

Attachment: Mozilla LDAP schema V0.6.1

Comment 118

[Roland Felnhofer]

Comment on attachment 142856 [details]
Mozilla LDAP schema V0.6.1

Add description about attribute definition for "c" and "co"

Comment 119

[Roland Felnhofer]

I think the time has come to finally agree on the first version of the Mozilla
LDAP schema extension. It is not perfect, it would not solve all issues
regarding open source address book application - BUT - it will allow start /
finalise some other pending bug which will allow that all fields of the address
card can be used regardless of the data source. Might it be the local address
book or a LDAP server.

So lets change the version 0.6.1 into 1.0 and call it "The first official
Mozilla LDAP schema extension" get approval and check it in into the tree.

Comment 120

[Hans-Peter Lackner]

Yes. It is finally time to do that.

Comment 121

[Hadmut Danisch]

Hi,

making this available as a "first schema" is good to fix the 
most important problem fast. 

I'd nevertheless propose to redesign the schema and the addressbook software. 
Having each address consisting of exactly "home" and "business" doesn't meet
all requirements. (There's also a bug report asking for an arbitrary number
of address entry per person.)


So a good schema would support this is a more standardized way.
The LDAP way to do it would be to create a plain address schema and
to have several address entries under the person's object. With such 
a schema you would be much more flexible and could have as many
addresses per person as you want or need. But since such a schema
requires major changes in the source code, this would rather be 
schema 2.0.

regards
Hadmut

Comment 122

[Frank Wein [:mcsmurf]]

Comment on attachment 104858 [details]
Mozilla LDAP schema V0.6

removing obsolete review request

Comment 123

[Hadmut Danisch]

Maybe it would be a good idea to have a look 
other open source addressbook applications such as
KDE's kaddressbook or Gnome's rubrica, or the 
palm address structure to build a common LDAP scheme suitable
for all information, also supporting categories.

If Mozilla is intended to be an alternative to Outlook,
addressbook functions must be improved and a common 
standard must be created.

regards
Hadmut

Comment 124

[Kurosch Saremi]

Hi,

i have a suggestion for the next Version of the mozillaOrgPerson schema. It
would b ea good idea to change the SYNTAX of mozillaCustom1-4 from
1.3.6.1.4.1.1466.115.121.1.26 to 1.3.6.1.4.1.1466.115.121.1.15, since then it
would be possible to save UTF-8 values in it. Things like German-Umlauts. This
is necessary for users outside the US who will add this schema to their LDAP-Server.

 

Comment 125

[Roland Felnhofer]

Attachment: Mozilla LDAP schema V0.6.2

Hi Kurosch,
good idea! I changed the schema.
The syntax for mozillaCustom1 - 4 is now 1.3.6.1.4.1.1466.115.121.1.15

Comment 126

[Kurosch Saremi]

> The syntax for mozillaCustom1 - 4 is now 1.3.6.1.4.1.1466.115.121.1.15
>

Hi Roland,

i have another question regarding the schema. Why did you use 'mozillaNickname'
and not 'xmozillaNickname', since that is the objectname that mozilla is asking
for when it performs an LDAP-query. Same with the following objectnames:
       
mozillaNickname     -> xmozillaNickname
mozillaUseHtmlMail  -> xmozillaUseHtmlMail
mozillaSecondEmail  -> xmozillaSecondEmail 
mozillaHomeUrl      -> HomeUrl
mozillaWorkUrl      -> WorkUrl
mozillaCustom1      -> Custom1
mozillaCustom2      -> Custom2
mozillaCustom3      -> Custom3
mozillaCustom4      -> Custom4

When you rename the objectnames on the leftside to the rightside names, you get
a really nice output when you query your ldap-addessbook with the 
mozilla/thunderbird addressbook.

Did i get anything wrong?

Regards,
Kurosch

Comment 127

[Hadmut Danisch]

Hi, 

just a few questions about the schema:

- I can remember that many years ago Netscape
  Navigator was able to display a jpeg image for 
  an LDAP address record. Has this feature been 
  dropped completely?

- What about X509 and PGP keys? Shouldn't an address
  schema contain attributes for them?

- What about enigmail's per-recipient configuration?
  Choice of encryption S/MIME or PGP?
  
regards
Hadmut


 

Comment 128

[Marc Williams]

I'm probably showing my Mozilla ignorance here, but why was this bug
resolved/fixed?  Are one of these attached schemas officially available
elsewhere besides bugzilla?

Comment 129

[Roland Felnhofer]

The problem is fixed - but it's not checked in yet!
I re-opened the bug

Comment 130

[Marc Williams]

That's great!  Is the schema going to be V0.6.2?  Or some other one?  Also, what
will the mapping in nsAbLDAPProperties.cpp look like?  (I hope you get rid of
the current streetAddress since it's not part of inetOrgPerson.schema. 
postalAddress would be a good unused substitute...)

I just built my first Thunderbird this afternoon after having modified
nsAbLDAPProperties.cpp to match V0.6.2 schema.  Fired up a new ldif on the ldap
server and it turned out spectacular - all (well, amost) the fields in the
address book are now being populated.

But if the schemas and/or nsAbLDAPProperties.cpp files are going to be changing
any time soon...  That's why I'm asking what they're going to be looking like.

Comment 131

[Daniel Wang]

fyi, I'm doing http://wangrepublic.org/daniel/mozilla/prefs/address . It's quite
a mess now. If anyone knowledgeable in LDAP in Mozilla would like to help, I'd
appreciate it very much.

Comment 132

[Roland Felnhofer]

(In reply to comment #130)
> ... Is the schema going to be V0.6.2?  Or some other one? 
> 

Asking me I would say let's go with version 0.6.2 (maybe rename it into 1.0 but
go with the attribute as they are defined in 0.6.2)

> But if the schemas and/or nsAbLDAPProperties.cpp files are going to be changing
> any time soon...  That's why I'm asking what they're going to be looking like.

I don't expect any fast changes - it took ages until we reached the point where
we are now (I opened this bug 2001-12-23 09:31 PDT) and there were just one
minor change since 2002-11-01 06:18 PDT.

I can not tell you how log it takes until the schema gets checked-in - I can not
do it and there is still 'review' and 'superreview' missing.

!!! Dan !!! - any news from the review and check-in front?

Comment 133

[Marc Williams]

Is it a safe assumption that a new nsAbLDAPProperties.cpp would be forthcoming
in parallel with the new schema?

Comment 134

[Roland Felnhofer]

(In reply to comment #133)

I hope so. The patch is already there.

Comment 135

[Marc Williams]

(In reply to comment #134)
> (In reply to comment #133)
> 
> I hope so. The patch is already there.

I just saw the Thunderbird 0.9 Release Notes draft.  It would appear that these
LDAP fixes are not going to be included.  If so, that's disappointing to say the
least.  Especially considering how long they've been available.

Comment 136

[Harold Beumer]

I hope so too! There are many more ideas about extending the LDAP schema, but
let's first include this one and use it.

IMHO this really should be included in Thunderbird 1.0 release because LDAP
support is now inconsistent and unusable. The solution is there and is not very
complex..... What about setting this bug to "blocking-aviary 1.0" ???

Several bugs should be solved at once since they are related:
bug #157925, bug #157926, bug #157928, bug #116692. It's not only the schema,
but LDAP querying and LDIF export should be made consistent with this schema.

Comment 137

[Jared]

Agreed, I'd also like to see this incorporated into Thunderbird 1.0 (and the
Mozilla Suite).  This bug was opened very close to three years ago now, had been
worked on for the entire time, and has racked up 136 comments.  Obviously, there
is great interest in getting this issue resolved.

At this point, we have a patch that's been well tested and accepted.  What is
preventing it's inclusion?

Comment 138

[David :Bienvenu]

pardon my ignorance, but does this patch actually change the way thunderbird
behaves? Is there any point to taking it without changing LDAP querying and LDIF
export?

Comment 139

[Marc Williams]

(In reply to comment #138)
> pardon my ignorance, but does this patch actually change the way thunderbird
> behaves? Is there any point to taking it without changing LDAP querying and LDIF
> export?

Sure.  See comment #133 and #134.

Comment 140

[David :Bienvenu]

er, that seems to imply that we'd need the patch in bug 157925 at minimum

Comment 141

[Harold Beumer]

Yes, we should patch in at least bug #157925 (querying the LDAP server) and bug
#157926 (LDIF export).

Problem is that these other two bugs don't have severity "blocker" and I'm
afraid they won't get the attention they deserve.

Comment 142

[John Woodell]

I agree that bug #157925 is critical. The client MUST be able to display
that same attributes from LDAP that the internal address books can.

Comment 143

[John Woodell]

Before pulling the trigger on this, I would suggest that 'we' add the
rest of the attributes to the objectclass to make 'mozillaOrgPerson' 
truely 'SUP top AUXILIARY'.... and not 'SUP inetOrgPerson STRUCTURAL'.

SUP top AUXILIARY --> should contain all attributes used by the address book
                      even if many oth them are defined elsewhere. 
                      The objectclass 'posixAccount' is a good example.
                      Attributes cn and uid are in the core.schema file.

SUP inetOrgPerson STRUCTURAL --> would inherit attributes from person, 
                                 organizationalPerson and inetOrgPerson.
#########################        Given that person requires sn and cn,
# I had suggested this  #        this is a poor choice because an AB entry
#|in the past, my bad.  #        may only have an e-mail address. Further,
#########################        most LDAP servers will enforce only one
                                 STRUCTURAL objectclass per entry.
                                 
objectclass ( 1.3.6.1.1.1.2.0 NAME 'posixAccount' 
        SUP top AUXILIARY
        MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory )
        MAY ( userPassword $ loginShell $ gecos $ description ) )

objectclass ( 2.16.840.1.113730.3.2.2 NAME 'inetOrgPerson'  
        SUP organizationalPerson STRUCTURAL
        MAY ( audio ... mail ... uid ... ) )

Comment 144

[Roland Felnhofer]

I would go with 'SUP inetOrgPerson STRUCTURAL'. Each entry should have at least
a name. In an address book you store addresses and an address belongs to some
entity and each entity has a name. So enforcing one ('sn' and 'cn' can be the
same) attribute I think is acceptable. I always saw the Mozilla schema as an
extension to existing schemas. I would actually appreciate more if we wouldn't
have to define a Mozilla schema because there would be already an object class
that allows defining a "complete" person and all its attributes would be
displayed by Mozilla.  

But if it makes the whole community feel better - let's stay with 'SUP top
AUXILIARY' and add all the attributes from person, organizationalPerson and
inetOrgPerson.

I WANT TO GET THIS SCHEMA CHECKED-IN.

Comment 145

[Dan Mosedale (:dmosedale, :dmose)]

I'll be working on trying to drive this and related patches into the tree today
and tommorrow, hopefully including the aviary branch of tbird, assuming these
patches stay within the level of risk-tolerance that the branch is accepting
now.  (I think they will, but one never knows...) 

As far as inetOrgPerson goes, the collected addressbook currently supports cards
without a name, so if we want to in the future allow collected addressbooks to
be on LDAP servers (once the ldapmodify patches land), that may not be an
acceptable constraint...

Comment 146

[Marc Williams]

(In reply to comment #144)
> I would go with 'SUP inetOrgPerson STRUCTURAL'. Each entry should have at least
> 
> But if it makes the whole community feel better - let's stay with 'SUP top
> AUXILIARY' and add all the attributes from person, organizationalPerson and
> inetOrgPerson.
> 
> I WANT TO GET THIS SCHEMA CHECKED-IN.
> 

In case you're looking for feedback, my vote would also be with SUP top
AUXILIARY.

Comment 147

[Marc Williams]

(In reply to comment #145)
> I'll be working on trying to drive this and related patches into the tree today
> and tommorrow, hopefully including the aviary branch of tbird, assuming these
> patches stay within the level of risk-tolerance that the branch is accepting
> now.  (I think they will, but one never knows...) 
> 

Thank you, thank you, a million thank you's...  Getting this in Tbird would be
the absolute bees knees!


> As far as inetOrgPerson goes, the collected addressbook currently supports cards
> without a name, so if we want to in the future allow collected addressbooks to
> be on LDAP servers (once the ldapmodify patches land), that may not be an
> acceptable constraint...
> 

Sorry for being possible obtuse, but *what* may not be an acceptable constraint?

Comment 148

[John Woodell]

Attachment: mozillaOrgPerson objectclass with all attributes

This updated objectclass contains some attributes that were missing.
These are all the attributes that thunderbird 9 exports, so there may
be some attributes missing.

Comment 149

[John Woodell]

Will the address book ever export 'userCertificate' attribute?

This file seems to be getting certs from LDAP...
content/messenger-smime/certFetchingStatus.js

Comment 150

[John Woodell]

This is a point I made in Comment #88, but I want to be as clear as possible...

I read the comments in the schema files and tested a few LDAP clients:
 - Oracle Calendar (formerly Steltor / CS&T, was in Communicator 4.x)
 - Various versions of Outlook and Eudora (and Netscape Communicator)

If you want an address to display properly in all possible clients,
you would use the 'street' and 'postalAddress' attributes as indicated here...

street: 466 Ellis Street, Suite E
l: Mountain View
st: CA
postalCode: 94043
postalAddress: 466 Ellis, Suite E, Mountain View, CA 94043

I'm not expecting the address book to export the composite address,
but I think it should use 'street' not 'postalAddress'.

Further, 'mozillaHomePostalAddress2' and 'mozillaPostalAddress2' are unneeded.
the 'street' and 'mozillaHomePostalAddress' (which could be mozillaHomeStreet)
should be multivalued attributes.

------------------------------

I had a brief discussion with dmose about multivalued attributes. He had stated
that there is no guarantee what order they will be in, and I also remembered
hearing or reading that, but I have never found that to be the case with both
netscape and openldap servers. I realize this has more to do with bug #157925,
but it helps explain my point above. Given this person in LDAP...

dn: cn=Tom Smith,ou=People,dc=foo,dc=com
objectclass: inetorgperson
cn: Tom Smith
cn: Thomas Zachary Smith
givenName: Tom
givenName: Tommy
givenName: Thomas
initials: Z
initials: Zachary
sn: Smith
sn: Smith-Jones
sn: Jones

A standard client should display...

First:   Tom         Last:   Smith
Display: Tom Smith   Middle: Z

A search for Jones or Zachary will return this entry.
In OpenLDAP you can do (name=Zachary), because all the
atributes listed are childres of 'name', but so is 'title',
so this is not a great time-saver in real-world applications.
Note: other clients use 'initials' for middleName, so I do as well.

Comment 151

[John Woodell]

Looking at bug #157925, it seems 'street' is valid. I hope last one wins!

     {MozillaProperty_String, "WorkAddress",        "postofficebox"},
     // ?
     {MozillaProperty_String, "WorkAddress",        "streetaddress"},
     // ?
+    {MozillaProperty_String, "WorkAddress",        "postaladdress"},
+    // ?
+    {MozillaProperty_String, "WorkAddress",        "street"},
+    // ?
+    {MozillaProperty_String, "WorkAddress2",       "mozillapostaladdress2"},

Also, I figured out why my street attribute was missing. Netscape servers
often come with attributes that are lowercase. OpenLDAP was sending 'street'
and 'streetAddress', but mozilla was looiing for 'streetaddress'.

I was able to fix this issue for no by making the following schema change:

#attributetype ( 2.5.4.9 NAME ( 'street' 'streetAddress' )
attributetype ( 2.5.4.9 NAME ( 'streetaddress' 'street' )

Comment 152

[David A. Cobb]

[Jumping in where a new voice is probably as welcome as the itch]

Comment#150: 
<quote>A search for Jones or Zachary will return this entry.
In OpenLDAP you can do (name=Zachary), because all the
atributes listed are childres of 'name', but so is 'title',
so this is not a great time-saver in real-world applications.
Note: other clients use 'initials' for middleName, so I do as well.
</quote>

But other /PEOPLE/ sometimes use a firstInitial and middleName thus:
J. William Fulbright

I know, we tell them they can't do this because our program can't deal with it.

All things considered, one is probably stuck with <givenNames>.  Given the
cultural variety we can come up with in only a few moments' thought, one may be
best off with <familyName>, <givenNames>. 

Just to make things utterly malign, how about the traditional Chinese style of
displaying <familyName> first - without the 'comma', thanks very much.  

Things like "Title" ought not, probably, be included in the <dn>; one remains
the same person, with the same address, after one receives her PhD.

Comment 153

[John Woodell]

If you don't try to prove that his first or middle name isn't something,
you can do whatever you want, just make sure the first entry is the one
you want display....

dn: cn=Zack Smith,ou=People,dc=foo,dc=com
objectclass: inetorgperson
cn: Zack Smith
cn: T Zack Smith
cn: T Zachary Smith
cn: Thomas Zachary Smith
givenName: Zack
givenName: Zachary
givenName: Tom
givenName: Tommy
givenName: Thomas
initials: Zachary
sn: Smith

dn: cn=J William Fulbright,ou=People,dc=foo,dc=com
objectclass: inetorgperson
cn: J William Fulbright
cn: John William Fulbright
cn: Bill Fulbright
givenName: J
givenName: John
givenName: William
givenName: Bill
initials: William
initials: Bill
sn: Fulbright

Comment 154

[Roland Felnhofer]

Comment #150, Comment #151, Comment #152 and Comment #153

The biggest problem I currently see with multi-value LDAP entries and Mozilla is
not if Mozilla always returns the same value for repeated queries (it does - and
it's at least in my setup: OpenLDAP: slapd 2.2.6 and Mozilla 2004101904 always
the FIRST attribute entry.) 
For example I have in my LDAP record 5 mail addresses:
	mail: [e-mail]
	mail: [e-mail]
	mail: [e-mail]
	mail: [e-mail]
	mail: [e-mail]
Mozilla always returns ‘[e-mail]’ in the address card and for
address lookup in mail.

To come back to the "problem" - it is not very easy to influence the order of
these values. As far as I know they are sorted in a chronological way. So adding
a new mail value would add it at the end. I'm not aware of any open source or
freeware LDAP editor which supports changing the order in a convenient way. So
if I want to get a new entry displayed in Mozilla I have to do the following:

1) change the first existing mail entry to become the (new) one you want to see
in the address card.
2) add the old one again so it stays at the end of the chain.

Not a big deal but annoying. In addition I am not sure if we can rely on the
server behaviour in respect of maintaining the chronological sort order for the
future. Is this is a RFC defined behaviour for LDAP?
 
- But let’s continue this discussion in bug #119199

Comment 155

[Roland Felnhofer]

Questions, Assumptions and Summary 

For the schema:        
    1)We replace ‘postalAddress’ by ‘street’ 
    2)We prefix all Mozilla “private” attributes with ‘mozilla’ (custom1 –
custom4, WorkUrl, …) 
    3)We define the Mozilla objectclass ‘mozillaOrgPerson’ as ‘SUP top
AUXILIARY’ and add all attributes from person, organizationalPerson and
inetOrgPerson which have currently a field in the address book card to get
displayed to the ‘MAY’ section. 

After we have checked in the first version of the Mozilla schema we start
thinking what additional attributes we want or need in the future (certs,
jpegPhoto, …) 
I think it’s now time get a first version of this schema out people (developers,
LDAP admins, …) can rely on. 

For the code: 
    See bug #157926 for Mozilla LDIF import/export code changes
    See bug #157925 for support of LDAP attributes in Mozilla address cards
(backward compatibility and new attributes) 

If you agree to the above part I will file today an updated version of the
Mozilla schema.

Comment 156

[Mark Smith [:mcs]]

Regarding Comment #151: LDAP attribute type names are case insensitive.  So all
clients and servers should recognize streetaddress as streetAddress or even
STREETADDRESS.

To answer the question posed in Comment #154: "I am not sure if we can rely on the
server behaviour in respect of maintaining the chronological sort order for the
future. Is this is a RFC defined behaviour for LDAP?"  The answer is no, the
LDAP specifications say that attribute values are an unordered set.  That said,
most LDAP server implementations try to preserve the order of attribute values,
e.g., if you enter values as A B C they will most likely be returned as A B C
and not C B A.

Comment 157

[Chan Min Wai]

I'm not sure if this is openldap problem or the schema problem.
But I'm having problem when removing the value of the following field in anyway.

homePostalAddress
postalAddress
mozillaPostalAddress2
mozillaHomePostalAddress2

I'm not too sure if I'm the only one who have the problem.
If it is my problem, I'm sorry for this message. But Please check.

Comment 158

[Dan Mosedale (:dmosedale, :dmose)]

(In reply to comment #131)
> fyi, I'm doing http://wangrepublic.org/daniel/mozilla/prefs/address . It's quite
> a mess now. If anyone knowledgeable in LDAP in Mozilla would like to help, I'd
> appreciate it very much.

Find me on IRC sometime and I can help you sort this out.

Comment 159

[Dan Mosedale (:dmosedale, :dmose)]

(In reply to comment #147)
>
> > As far as inetOrgPerson goes, the collected addressbook currently supports
> > cards without a name, so if we want to in the future allow collected 
> > addressbooks to be on LDAP servers (once the ldapmodify patches land), that 
> > may not be an acceptable constraint...
> > 
> 
> Sorry for being possible obtuse, but *what* may not be an acceptable 
> constraint?

Requiring an addressbook card to have an sn or cn attribute.

Comment 160

[Dan Mosedale (:dmosedale, :dmose)]

(In reply to comment #149)
> Will the address book ever export 'userCertificate' attribute?
> 
> This file seems to be getting certs from LDAP...
> content/messenger-smime/certFetchingStatus.js
> 

Seems like it would be a reasonable thing to do at some point, yeah.

Comment 161

[Anze Zagar]

(In reply to comment #155)
>     3)We define the Mozilla objectclass ‘mozillaOrgPerson’ as ‘SUP top
> AUXILIARY’ and add all attributes from person, organizationalPerson and
> inetOrgPerson which have currently a field in the address book card to get
> displayed to the ‘MAY’ section. 

I'm not sure I understand why adding all the attributes, that are
already defined in existing object classes, is necessary.
mozillaOrgPerson should only provide those supplementary attributes not
provided by inetOrgPerson nor any of its ancestors (person &
organizationalPerson).

So a definition of a sample ldap entry should be something like:

dn: cn=John Smith,ou=addressbook,dc=example,dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
objectclass: mozillaOrgPerson
givenName: John
sn: Smith
cn: John Smith
xmozillanickname: Johnny
mail: [e-mail]
xmozillausehtmlmail: true
...

(here, mozillaOrgPerson is an auxiliary object class that serves as a
suppliment to inetOrgPerson structural object class)


Problematic are only 'sn' & 'cn' attributes because they are obligatory,
which forbids you to have an empty address card in your ldap directory.
Because 'cn' is normally used as unique identifier with 'dn', it should
probably not even map to Mozilla's "display name" but store some
internal unique identification string instead (possibly something
random(?) because there can always be more different people with the
same "display name"). On the other hand, 'displayName' of the
inetOrgPerson can be used to store Mozilla's "display name" information.
'sn' is still a problem, though!

Comment 162

[John Woodell]

I can clearly explain why mozillaOrgPerson should not be a child 
of inetOrgPerson, but I will post that later. In brief, the AB card 
in an object that knows nothing of most of the attributes in inetOrgPerson,
and it should not be the only child of inetOrgPeson.

Also, I had not noticed that xmozillanickname and xmozillausehtml had been
removed from the schema. I really this they need to be the, and listed first.
Other clients (lik outlook) work with those exact attribute names.

Comment 163

[Roland Felnhofer]

(In reply to comment #162)

> Also, I had not noticed that xmozillanickname and xmozillausehtml had been
> removed from the schema. I really this they need to be the, and listed first.
> Other clients (lik outlook) work with those exact attribute names.
> 

Hi John,
If it can be ensured that using 'xmozillanickname' and 'xmozillausehtml' as
alias for 'mozillaNickname' and 'mozillaUseHtmlMail' do not create any problems
I have no objections to do so. But if there is the slightest risk I would be
against it.
A lot of problems we have to face in IT today are related to backward
compatibility. In doubt let's make a clear cut. This schema should NOT ensure
that other applications are happy with it. It should ensure that from NOW on
there is a uniform schema (all Mozilla private attributes are
'mozilla'-prefixed) for Mozilla which satisfies the needs of storing all
CURRENTLY used address book values in LDAP. It should also ensure in case there
is a need that it can be extended (certs, jpegPhoto,...).

If  we don't make NOW a clear cut we will have to maintain all this legathy
attributes for ever - this adds complexity - complexity adds problems.

If we define this schema now, application developers which are using some
Mozilla (Netscape) legathy attributes will change their code to become compliant
with this new (and first) official schema. 

Comment 164

[Roland Felnhofer]

Attachment: Mozilla LDAP schema V0.6.3

Added attributes to objectclass definition for standard attributes (without
redundancy ['departmentNumber' and 'postOfficeBox']) so it becomes a true 'SUP
top AUXILIARY' object class. Nonetheless other attributes may be read in
absence of an 'official' attribute. For example: If 'street' is missing
'postOfficeBox' will be used instead.

Comment 165

[John Woodell]

OK, both xmozillausehtmlmail and xmozillanickname only used by Netscape 4.x,
and Mozilla (not Outlook), so I suppose they can be renamed at this point.

I did find that Outlook (and Active Directory) use a few attributes that
have been defined, and should probably be used by the mozilla AB. This way,
mozilla AB should be able to display these attributes when pointing at an
Active Directory server, and Outlook will display then from LDAP.

otherMailbox ... not mozillaSecondEmail
wwwHomePage .... not mozillaHomeUrl
url ............ not mozillaWorkUrl
department ..... when exists (instead of ou and departmentNumber)

These were registered under OID 1.2.840.113556 (Microsoft)

# http://msdn.microsoft.com/library/en-us/adschema/adschema/a_othermailbox.asp
attributetype ( 1.2.840.113556.1.4.651 NAME 'otherMailbox' ...)

# http://msdn.microsoft.com/library/en-us/adschema/adschema/a_wwwhomepage.asp
attributetype ( 1.2.840.113556.1.2.464 NAME 'wwwHomePage' ...)

# http://msdn.microsoft.com/library/en-us/adschema/adschema/a_url.asp
attributetype ( 1.2.840.113556.1.4.749 NAME 'url' ...)

# http://msdn.microsoft.com/library/en-us/adschema/adschema/a_department.asp
attributetype ( 1.2.840.113556.1.2.141 NAME 'department' ...)

Comment 166

[John Woodell]

More Outlook mapping information for the previous link:
http://www.openldap.org/faq/data/cache/294.html

---------------

Something else that should be looked at... like postalAddress, 
homePostalAddress is defined as the entire address, not simply
the streetAddress component, which is why the other components 
have not been defined.

It would be appropriate to define mozillaHomePostalAddress,
and use it when exporting to LDIF. We could use homePostalAddress 
when reading from LDAP if mozillaHomePostalAddress does not exist.
This is what outlook does, but they have a multi-line field, so the
homePostalAddress fits without the need to parse it into the components.

Comment 167

[John Woodell]

Regrading 'c' & 'co' (as in 'US' & 'UnitedStates'), I don't see the need 
for both to be in the objectclass. Only one should be exported... right?

The GUI seems to indicate that something long (like 'co') should be entered, 
but I think that looks odd below the address on the main AB layout, 
and I wonder if the 'Map' button even uses it.

I would be all for exporting co (countryFrienlyName), 
and reading both (but using 'co' over 'c'). 

Comment 168

[John Woodell]

Regarding Comment #165, is seems that Outlook Express really does
use xmozillausehtmlmail and related attributes...

A = WinNT4 + IE4/OE4 / C:\Program Files\Outlook Express\WABImp.DLL
B = Win98  + IE5/OE5 / C:\Program Files\Outlook Express\WABImp.DLL

AB   xmozillaconference
AB   xmozillanickname
AB   xmozillauseconferenceserver
AB   xmozillausehtmlmail

http://www.openldap.org/faq/data/cache/293.html

Comment 169

[Hadmut Danisch]

Hi,

just a question: What about x509 certificates (as mentioned before) and
PGP keys? Shouldn't the mozilla schema include them as well as they are used
for e-mail, or should other schemas be melted in?

regards
Hadmut

Comment 170

[Anze Zagar]

(In reply to comment #164)
I still see no reason why mozillaOrgPerson should contain those common
attributes that are already contained by other object classes (like cn, sn,
givenName, displayName, ... which are all already contained /directly or
indirectly/ by inetOrgPerson).

This is especially questionable because mozillaOrgPerson is declared as an
auxiliary object class. According to RFC #2252: "Every ldap entry should contain
an abstract class ('top' or 'alias'), AT LEAST ONE structural object class, and
zero or more auxiliary object classes". Meaning that each mozilla address book
entry will have to contain (besides 'mozillaOrgPerson') also 'top' and at least
one structural object class (e.g. 'person' or rather
'person'+'organizationalPerson'+'inetOrgPerson').

Each entry will so have to contain something like:
objectclass: top                    <-- abstract (needed)
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson          <-- structural (needed)
objectclass: mozillaOrgPerson       <-- auxiliary

Adding 'person' will reenforce 'cn' and 'sn' to become MUST attributes (although
these attributes are now declared as MAY in mozillaOrgPerson). Besides I'm not
even sure if specifications allow some attribute to be declared twice in two
different object classes (e.g 'cn' is in person and mozillaOrgPerson) of one
ldap entry, anyways.


PS: I noted that there is a hash missing in front of the comment in line #75:
"un-comment for all LDAP server NOT supporting SYNTAX 2.16.840.1.113730.3.7.1"
of the lates schema proposal.

Comment 171

[John Woodell]

Yes, maybe the objectclass should be called 'mozillaAddressBookEntry':

objectclass: top                      <-- abstract
objectclass: LDAPsubEntry             <-- structural
objectclass: mozillaAddressBookEntry  <-- auxiliary 

I used 'posixAccount' as an example, which works like this:

objectclass: top           <-- abstract
objectclass: account       <-- structural  (must uid)
objectclass: posixAccount  <-- auxiliary

NT and UNIX accounts can be created without a FULLNAME or GECOS (sn),
so the Person structural objectclass is a poor choice.

I'm starting to think that we could define two objectclasses:

  'mozillaOrgPerson' SUP top AUXILIARY MAY (...
  'mozillaAddressBookEntry' SUP inetOrgPerson STRUCTURAL MUST ( cn ) ...

The AB would always export the same thing, but users that want create
other kinds of entries (Resources, Locations, Departments) can use the
AUXILIARY objectclass to make their entries browsable by the AB.

Defining this mozillaAddressBookEntry objectclass would admins a clear
picture of the attributes used by each AB card... which is nice.

I would be OK if the AB forced me to enter a lastName (sn) before I am
allowed to save a new card. It seems odd that a user would want to have
a bunch a cards with no name at all... which is currently possible.

Comment 172

[Roland Felnhofer]

(In reply to comment #165)
> OK, both xmozillausehtmlmail and xmozillanickname only used by Netscape 4.x,
> and Mozilla (not Outlook), so I suppose they can be renamed at this point.

OK - Super

> otherMailbox ... not mozillaSecondEmail
> wwwHomePage .... not mozillaHomeUrl
> url ............ not mozillaWorkUrl
> department ..... when exists (instead of ou and departmentNumber)
> 

In principal no objections - the only problem I could imagine is that a user can
not write the above attributes due to security restrictions. This applies
especially for 'otherMailbox' (Update Privilege 	Domain administrator)
The rights for 'wwwHomePage', 'url' and 'department' less restrictive (Update
Privilege 	Domain administrator or account owner) but still could cause some
problems for workgroups.

Comment 173

[Roland Felnhofer]

> It would be appropriate to define mozillaHomePostalAddress,
> and use it when exporting to LDIF. We could use homePostalAddress 
> when reading from LDAP if mozillaHomePostalAddress does not exist.
> This is what outlook does, but they have a multi-line field, so the
> homePostalAddress fits without the need to parse it into the components.

Agree! - but for the name I would propose 'mozillaHomeStreet' to make it obvious
that this attribute should only contain the street name.

Comment 174

[Leif Hedstrom]

(In reply to comment #171)
> objectclass: top                      <-- abstract
> objectclass: LDAPsubEntry             <-- structural
> objectclass: mozillaAddressBookEntry  <-- auxiliary 

I think Anze's proposal makes a lot of sense, making mozillaOrgPerson
auxilliary, and use an existing structural objectclass like inetOrgPerson for
"standard" attributes (like CN, SN etc.). I'm not sure that using LDAPsubEntry
makes sense here, it seems somewhat unrelated.

Before finalizing on the schema, I'd like to see an example LDIF file, that we
can try to import into various LDAP servers. I understand DNs will have to be
massaged before import, but that's OK.

Speaking of DNs, I'm not a huge fan of using CNs in the DN, we could possible
have a multi-value RDN (e.g. CN+Mail), but I've avoided that in the past due to
poor support from many servers and APIs. Cleanest would be to simply use the
Mail attribute as the RDN, since it's certain to be unique.

I don't know if we need the dual objectclasses talked about, but I'm not 100% up
to snuff on all the details of the Abook client. For one thing, how would the
exporting mechanism know if an Abook entry is a "person" or a "resource"? Do we
distinguish that in the Mozilla client?

Comment 175

[Roland Felnhofer]

(In reply to comment #167)
> Regrading 'c' & 'co' (as in 'US' & 'UnitedStates'), I don't see the need 
> for both to be in the objectclass. Only one should be exported... right?
> 
Sorry I don't get what you me with exported. - LDIF export or displayed

> The GUI seems to indicate that something long (like 'co') should be entered, 
> but I think that looks odd below the address on the main AB layout, 
> and I wonder if the 'Map' button even uses it.
> 
> I would be all for exporting co (countryFrienlyName), 
> and reading both (but using 'co' over 'c'). 
> 


I thought about this today in the bath tube ;-). For the time being I see no way
around dealing with both attributes. 
I agree with you that for displaying the 'friendlyCountryName' much better. I
don't think that too many people would not know what 'US' stands for. But who
knows what 'MP' stands for? (its 'Northern Mariana Islands').

The problem with the 'friendlyCountryName' arises, as you expected, with the
Map-Button. It actually accepts it (I tested it in the past) but most
locate-URLs expects the 2-letter country code and gets confused when you send
the full name.

So what about the following:
Introduce a new internal Mozilla variable like "WorkCountryCode" and
"HomeCountryCode"

If both attributes are there map:
co	->	WorkCountry	-> displayed in GUI
c	->	WorkCountryCode	-> used for Map
(same for 'Home...')

In case one is missing both internal variables gets loaded with the same LDAP
attribute.

Comment 176

[Roland Felnhofer]

(In reply to comment #169)

Yes, but not in the first version.

Comment 177

[Roland Felnhofer]

(In reply to comment #170)

> According to RFC #2252: "Every ldap entry should contain
> an abstract class ('top' or 'alias'), AT LEAST ONE structural object class, 

Good point! And OpenLdap becomes at least more and more picky when it comes to
RFC compliance - meaning if your LDIF file strictures does not comply you can't
import it!

> 
> PS: I noted that there is a hash missing in front of the comment in line #75:
> "un-comment for all LDAP server NOT supporting SYNTAX 2.16.840.1.113730.3.7.1"
> of the lates schema proposal.
> 

OH - thank you! I will change it with the next version.

Comment 178

[Roland Felnhofer]

I think I want to restate here again what my intention was with the official
Mozilla schema:

*****
It defines the PRIMARY SUPPORTED attributes for the Mozilla Address book (an
later maybe additional stuff that should be stored in LDAP)

It DOES NOT mean that Mozilla will ONLY support these attributes.
*****


In "nsAbLDAPProperties.cpp" (bug #157925) we will support a large range of LDAP
attributes which are not defined in the OFFICAL Mozilla schema. But attributes
defined in the Mozilla schema shell always "win" over other attributes.

In the offical Schema there is always only ONE attribute for one purpose (field
in the address book card). The only exception might be 'c' and 'co' (explanation
see:  comment #175)

The reason behind this is that the schema should also be a help for users and
developers what are the LDAP attributes which are "supported best" in Mozilla. 


I think of 3 different groups of LDAP address book users:

1) The "freaks" they have 2-oo computers with 2-oo mail clients for one mail
account - The want to share their address book between all involved entities.
(maybe most of the people working on this bug belong to it)

2) Small companies (incl. smaller academia o or ou) 5 - 300 users. They might
maintain an LDAP environment just as an address book - they are very flexible in
the design of their LDAP environment - This I see as the area where the Mozilla
LDAP integration might become most important and desired.

3) Enterprise - 'flexibility' very low - Very complex environments - already
multiple LDAP installations with different schemas for different needs. That is
the place where the Lotus Notes - Exchange battle takes place. Here it might
take quite a while until Mozilla becomes an important player.


 

Comment 179

[John Woodell]

Attachment: Two sample objectclasses

We could define a couple objectclasseslike this...

Comment 180

[Roland Felnhofer]

Attachment: Mozilla LDAP schema V0.6.4

removed 'homePostalAddress'
added 'mozillaHomeStreet'

Comment 181

[Roland Felnhofer]

(In reply to comment #179)

> We could define a couple objectclasseslike this...

I like it!

I think as soon as we agree on the objectclass definition we should add the
attribute definition for attributes not defined in RFCs (Microsoft or other
'private' attributes) to the schema. Maybe we should also add all attributes
used, even if they are defined in RFCs but comment them out - for documentation
or in case someone has only a very "slim" set of schemas coming with his LDAP
installation.

Comment 182

[John Woodell]

For clarity, I suggest we set the following mapping in nsAbLDAPProperties.cpp

  {MozillaProperty_String, "HomeAddress",        "mozillahomestreet"},
  {MozillaProperty_String, "HomeAddress2",       "mozillahomestreet2"},
  {MozillaProperty_String, "WorkAddress",        "street"},
  {MozillaProperty_String, "WorkAddress2",       "mozillaworkstreet2"},

I have already submitted a patch with these names in bug 157925, 
as well as the adschema attribute names. If the above attribute
names look good, the patch bug 157925 should be done.

- - -

Regarding the adschema attribute names. I think we should include them
in the mozilla schema file because they are built into AD, and I cannot
imagine Redmond will publish in OpenLDAP format. I'm also suggesting that
we NOT define mozilla+ attribute names for these, but instead treat them
like other published attributes... Outlook clients use them already.

Comment 183

[John Woodell]

Regarding Comment #165, I'm backing down on 'otherMailbox' attribute.
I think we should use 'mozillaSecondEmail' instead. This is clearly defined 
as an address that is not X.400 and rfc822, but we could display it only
if 'mozillaSecondEmail' does not exist. It should not be in the objectclass.

# cosine
# The Other Mailbox attribute type specifies values for electronic
# mailbox types other than X.400 and rfc822.

# adschema
# Contains other additional mail addresses in a form such as CCMAIL: JohnDoe.

Comment 184

[Dan Mosedale (:dmosedale, :dmose)]

A few comments:

* We seem to have minimum upper bounds set on the lengths of some attributes and
not others, and the ones that do upper bounds seem to be somewhat inconsistent
with one another.  How were these numbers selected?  Is there a compelling
reason to have these upper bounds at all?

* The comment in 0.6.4 at the top of the file lists it as version 0.6.3.

* dcmwai: I don't underestand your comment 157, can you please explain in more
detail what problem you're having?

More comments shortly.

Comment 185

[John Woodell]

Attachment: adschema attributes

Some adschema attributes in openldap format, 
could be appended to the mozilla schema file.

Comment 186

[Dan Mosedale (:dmosedale, :dmose)]

(In reply to comment #179)
>
> Two sample objectclasses
> 
> We could define a couple objectclasseslike this...

What's the point of defining the structural class at all?  Why not just use
inetOrgPerson + mozillaAddrBookEntry?  At some point down the road, we might
need to switch from inetOrgPerson to clone within the cn/sn restriction, but I
don't see why we need it now.

Comment 187

[John Woodell]

(In reply to comment #186)

A solution for exporting an LDIF that can be loaded into an LDAP server,
that does not require that you guess 'sn' from entries with no name...

1. Grab 'mail.identity.id1.useremail', (example: [e-mail]),
   then turn that into a basedn, like this 'ou=contacts,dc=foobar,dc=com'.

2. Shove whatever you can into the 'cn' attribute when it is empty. 
   When you have a 'mail' attribute (or something else to uniquify it), 
   shove that in the RDN as well...

   DN: cn=stiffler+mail=[e-mail],ou=contacts,dc=foobar,dc=com
   objectclass: top
   objectclass: mozillaAddrBookEntry
   cn: stiffler
   mail: [e-mail]
   . . .

   DN: cn=MOM+telephonenumber=415-555-1212,ou=contacts,dc=foobar,dc=com
   objectclass: top
   objectclass: mozillaAddrBookEntry
   cn: MOM
   telephonenumber: 415-555-1212
   . . .

   DN: cn=Dan Smith+mail=[e-mail],ou=contacts,dc=foobar,dc=com
   objectclass: top
   objectclass: mozillaAddrBookEntry
   cn: Dan Smith
   givenName: Dan
   sn: Smith
   mail: [e-mail]
   . . .

The objectclass would look like this...

  objectclass ( 1.3.6.1.4.1.13769.2.2.1 NAME 'mozillaAddressBookEntry' 
      SUP top STRUCTURAL
      MUST ( cn )
      MAY ( ... ) )

This objectclass would not be very helpful for people who want to design 
a complex directory that can be viewed by the AB (corporate LDAP admins), 
but it would be perfect for people that want to quickly export to OpenLDAP...

Comment 188

[Dan Mosedale (:dmosedale, :dmose)]

(In reply to comment #187)
> (In reply to comment #186)
> 
> A solution for exporting an LDIF that can be loaded into an LDAP server,
> that does not require that you guess 'sn' from entries with no name...

You can still do that with the auxilliary class plus a structural class to be
defined later without without duplicating all the addrbook attributes.  Because
getting it into Thunderbird 1.0 at this point is already iffy, we need to
minimize changes.  So I propose to concentrate on an auxilliary class (+
fallback attrs) in this and the other bugs that we want to try and land for 1.0;
 and spin that problem off into another bug to do be dealt with post 1.0.

Comment 189

[John Woodell]

I'm not suggestion that you force an entry to have a name,
but this would need to happen with you export.

An entry will not load without at least one STRUCTURAL objectclass.
If you don't mind making up a cn on-the-fly, when you export,
you could use 'organizationalRole'...

Comment 190

[John Woodell]

Mozilla users will certainly created AB cards that are people,
but they may also created cards for mailing lists, companies,
resources, locations, etc. These non-people cards may not have
a lastName (sn), so 'organizationalRole' would be a good choice
instead of 'inetOrgPerson' to be SUP to 'mozillaAddressBookEntry'.

Comment 191

[Dan Mosedale (:dmosedale, :dmose)]

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

Comment 192

[John Woodell]

Attachment: another take at schema

This is what I would do, but this is not difinitive

Comment 193

[John Woodell]

Attachment: mozillaAddressBookEntry.schema

Same idea... but with attributes for street2 attribute.

Comment 194

[David A. Cobb]

re: Comment#190 -- Non-human addressbook entries.  
[is it PC to say "non-human"? Do we need to say "non-sentient"?  It's too darn
late at night]

Indeed, I have many many cards with the last names "Discussion List" and "List
Server"  They are very big families :)
Apart from LDAP, you gotta have something that shows up in the lists, that I can
make some sense of.
On the other hand, I really really don't think we should make it easy to stick
"Collected Addresses" into an LDAP server ( or anywhere else off of the local
machine ).  Just too much junk winds up in there.  Even if I restrict the
collection to outbound mail -- before the whole dam internet winds up in my AB
-- many discussion list replies are "Reply-to" both the list and the original
sender; but I don't much care to save the sender's name on file.

Comment 195

[John Woodell]

Attachment: mozillaAddressBookEntry.schema

There is no need for displayName and preferredOU to be in the objectclass
because they will never be exported. A put MozillaHomeUrl back so that now
all the listed attributes are from RFCs or listed in the schema.

Comment 196

[Hadmut Danisch]

Hi,

wouldn't it be better to include the attributes for 
jpeg image, pgp key, x509 key right now instead 
of extending the scheme later?

Hadmut

Comment 197

[John Woodell]

(regarding Comment #196)

Until the AB displays images, probably not.

I agree about certificates : Comment #149

Comment 198

[Hadmut Danisch]

Mozilla does fetch x509 certificates from LDAP, but this
seems to be completely independent from AB. However, since
this is a Mozilla function, the schema should include
x509 (and PGP) certs.

About jpeg: Netscape navigator already was able to display the 
image, and most other LDAP address browsers do this as well. So 
the mozilla AB should probably display them as well. If they do it, 
would you like to issue a new schema and ask everyone to replace
it? Isn't it better to have it in the schema right now?

This is a chicken-and-egg-problem: AB doesn't display because the 
schema doesn't have it, and the schema doesn't have it because 
AB doesn't display.


Hadmut

Comment 199

[John Woodell]

I saw a spec for the AB that showed a picture loaded into custom2,
but currently, there is no way for the user to add a photo to a card,
so I would not expect LDAP support for this feature.

I do think the AB should support photos.

Comment 200

[Roland Felnhofer]

(In reply to comment #199)
> ... so I would not expect LDAP support for this feature.
agree

> I do think the AB should support photos.
agree

(In reply to comment #198)
> This is a chicken-and-egg-problem: 
The egg was first (mutation) - really  -  so this one is solved.

> AB doesn't display because the  schema doesn't have it, and the schema 
> doesn't have it because AB doesn't display.
Each new feature has to come with an extension of the Mozilla schema.
As long as you extend the schema and don't change existing attribute definitions
it should not be a problem.

Comment 201

[Jared]

Hi, everyone.  Not sure if this is the right place to request something or not,
but I've been following this thread for quite some time, and I figure with all
the work going on right now it's a good place to start...

Would it be possible to add a birthday field to the address book?  I use
Thunderbird as my primary (actually, sole) PIM application, but one thing that I
need to keep track of (and, always forget) is birthdays.  I know I could use a
custom field for this, but it'd be really nice to have something specifically
for this purpose.  I've seen several other PIM apps add this capability (most
notably Palm's Contacts app, which I keep synced with Thunderbird), so it
shouldn't be much of a stretch for Thunderbird to add support.

Anyway, just wanted to post my request.  If this is not the proper place, I'd
appreciate a point in the right direction.  Thanks, and I'm definitely looking
forward to full compatability between Thunderbird and OpenLDAP, even if it will
have to wait until post-1.0.  :-)

Comment 202

[John Woodell]

(regarding Comment #201)

Actually, bug 157925 was going to add this, even though the GUI
did not have a field to show it. I suggested that we focus 
on supporting the all attributes that are currently in the GUI
before branching out with new, hidden features, but this
was also an attempt to simplify for the 1.0 relase.

You can see birthyear and dateofbirth attributes in this diff:
https://bugzilla.mozilla.org/attachment.cgi?id=142156&action=diff

Comment 203

[John Woodell]

Some people have also asked for free/busy url support,
to be more compatible with evolution and outlook.

The schema seems to be in this link:
http://lists.ximian.com/archives/public/evolution/2002-April/017782.html

Comment 204

[John Woodell]

Maybe the AB should be redesigned to store all cards in abook.mab
so that they are objects constructed from an ldap schema file...
and adding attributes to the schema would auto-magically add new
fields in the GUI. 

That could create ugly AB card layout, but it would give users
the ability to modify their local schema file, and change how
the AB looks/works (or simply make it not work anymore).

Comment 205

[Hadmut Danisch]

I am absolutely unhappy with the fixed limitation to just 
two addresses per person (private business) and the limitation 
to the given entry types. I would prefer to have an ldap 
entry per person with multiple subentries, one for each address.
Other users might have other preferences.

New proposal: Completely remove LDAP from Mozilla.
Add a new universal interface which allows to plugin just any
program to fetch mails from anywhere, called like a cgi script.
Have it output a HTML page when an address was found. Have it 
parse HTML forms when new addresses are entered or for searching.

And then implement an LDAP plugin just as a default plugin and
programming example.

Hadmut

Comment 206

[John Woodell]

(In reply to comment #205)

50 email addresses can be inserted into one ldap entry.
The standard 'mail' LDAP attribute is multivalued.

Comment 207

[Hadmut Danisch]

reply to #206:

- I wasn't talking about e-mail addresses, but postal addresses. 
  Street, City, ZIP. Many of my contacts have several private
  and several business addresses (including myself).

- But e-mail is also problem: Mozilla is unable to display and use
  more than one entry.

- Even if Mozilla could: How would you distinguish those 50 
  e-mail addresses? Which one is the private one, which is the 
  businness one, which is the mobile, which the one for the 
  role as president of any organisation? This doesn't work.

Mozilla should be able to open multiple address entries per 
person, and each entry should allow to enter street, city, 
zip, phone, fax, email



Hadmut

Comment 208

[John Woodell]

I was poking around IBM's schema repository and noticed 
that they have two additional person objectclasses.

LiPerson is 'SUP person STRUCTURAL' ... as we would expect.
 ePerson is 'SUP top AUXILIARY' ....... and has only MAY attributes.

This second objectClass could be difficult to display in a list
because every attribute could be empty, and the objectclass would
still be valid. You could have 200 empty entries (for example).
Unfortunately, this is how the Mozilla AB works today.

http://www-1.ibm.com/servers/eserver/iseries/ldap/schema/html/ObjectClass/liPerson.html
http://www-1.ibm.com/servers/eserver/iseries/ldap/schema/html/ObjectClass/ePerson.html

Comment 209

[Carsten Menke]

@comment 201

I think a dayofbirth or birtday field has also some more usefull benefits, with
regards of the evolement of Mozilla Sunbird, it would be nice to add alarms
automatically, based on the birtdays of certain entries of the Mozilla Addressbook.

For this to work of course a field like this has to exists in the LDAP Schema

My 0.02 ¢

Comment 210

[Lukasz Stelmach]

(In reply to comment #205)
> I am absolutely unhappy with the fixed limitation to just 
> two addresses per person (private business) and the limitation 
> to the given entry types. 

I addmit that this is a kind of limit if you plan to run ldap only as an
addressbook. For  me and addressbook functionality is of nice addition to the
directory system. I would like to let people in my company use the directory as
an "internal" addressbook. "External" addresses, however, are kept in personal
addressbooks of each employee for they collect the addresses they need. IMHO
there is completely no need to store more than two (business and private)
addresses of each employee.

Best regards,
Lukasz

Comment 211

[Gavin Lawrie]

(In reply to comment #210)
> For  me and addressbook functionality is of nice addition to the
> directory system.

For me this type of LDAP functionality is more general - it has the potential to
provide the underpinnings of an approach to cross-platform shared access to a
common address list without the need for web-based access: if the Mozilla LDAP
addressbookentry schema is defined, and supported via TBird etc, then it gives
something open against which other clients can be tuned into and something other
apps can be designed to talk to too - avoiding the need for Exchange or other
such closed solutions to be deployed.

All we need then is for Sunbird to learn how to link events to the LDAP entries,
and you have the core of a very powerful open-standards groupware system.

Gavin

Comment 212

[John Woodell]

Attachment: MS Address Entry

There has been some discussion about using c vs co.
Looks like MS was able to figure out how to provide
a dropdown for country selection. Seems reasonable.

Comment 213

[Jarl Nicolson]

I don't know what is happening with this, but i'll post anyway.

I must admit i'm a little new to LDAP, but from what i've read/seen,
inetOrgPerson would inherit from organizationalPerson and then from person, so
making a mozillaAddressBookEntry object with SUP inetOrgPerson STRUCTURAL would
be useless anyway, you would still need the cn and sn.

At least that's what it appears to me from my recent experiences with OpenLDAP.
 If I create a new entry with the only object being inetOrgPerson (and top,
obviously), cn and sn are still required.  Please correct me if i'm wrong.

Therefor, if anything, we should create a mozillaAddressBookEntry SUP top
STRUCTURAL and then just define base attributes in there.  After that we could
always extend it in the AUXILIARY object.

If thinks work as I think they do, doing it this way would mean would could have
basically anything as an address book entry.  Perhaps it could be taken a step
further and make the STRUCTURAL object just 'mozillaEntry', to allow for other
things (calendar? I don't know if there is already a calendar objectClass around

If I'm way off the mark, I apologise in advance.  Whatever happens, I'd be great
if this could get in ASAP.

Comment 214

[Gintautas Grigelionis]

Why is mozilla searching for nscpaimscreenname? What schema is this attribute in?

Comment 215

[Craig Harding]

Why can't it just be setup so that someone can change the prefs file so that
certain ldap attributes point to the addressbook fields? I just made my addbook
in ldap and I have some fields that I'd like to change the name of.. anyways..
I'm trying to find the code in the source of thunderbird to change this myself
or even add the 'Home' portion of the ldap entries so that they show correctly
(if not at all) when I click on the names in the addressbook.

(In reply to comment #213)
> I don't know what is happening with this, but i'll post anyway.
> 
> I must admit i'm a little new to LDAP, but from what i've read/seen,
> inetOrgPerson would inherit from organizationalPerson and then from person, so
> making a mozillaAddressBookEntry object with SUP inetOrgPerson STRUCTURAL would
> be useless anyway, you would still need the cn and sn.
> 
> At least that's what it appears to me from my recent experiences with OpenLDAP.
>  If I create a new entry with the only object being inetOrgPerson (and top,
> obviously), cn and sn are still required.  Please correct me if i'm wrong.
> 
> Therefor, if anything, we should create a mozillaAddressBookEntry SUP top
> STRUCTURAL and then just define base attributes in there.  After that we could
> always extend it in the AUXILIARY object.
> 
> If thinks work as I think they do, doing it this way would mean would could have
> basically anything as an address book entry.  Perhaps it could be taken a step
> further and make the STRUCTURAL object just 'mozillaEntry', to allow for other
> things (calendar? I don't know if there is already a calendar objectClass around
> 
> If I'm way off the mark, I apologise in advance.  Whatever happens, I'd be great
> if this could get in ASAP.

Comment 216

[Craig Harding]

Just FYI, in mailnews/addrbook/src/nsAbLDAPProperties.cpp on line 115 of
thunderbird-1.0 source the line exists:

// No Home* properties defined yet

between the addressbook person's contact info and the Work Address info.

Comment 217

[Bill Mair]

I submitted a patch for a different naming of fields a year and a half ago and
it is still listed as NEW. See: https://bugzilla.mozilla.org/show_bug.cgi?id=195526

This would solve a lot of the problems people are having while using equivelant
schemes.

I would really appreciate it if one of the commiters could have a look at this.

Comment 218

[Bill Mair]

Although the patch I posted is not 100%, it's better than the current situation.

I personally think that a configurable mapping file would be the better way to
go, allowing the enduser to define the mapping "per server", therefore not
requiring a compile/patch to get it to work.

Simply documenting/defining the fields that the address book displays and
allowing the user to map them to the LDAP server values.

Adding it to the prefs.js could be an option, possibly a seperate ldap.js would
work too.

Something like:

...
user_pref("ldap_2.servers.myldapserver.field.DisplayName","cn");
user_pref("ldap_2.servers.myldapserver.field.WorkAddress","postaladdress");
...
etc.

And provide a default set of values that the user can then edit as required.

Having this kind of 1:1 mapping would also make it easier for implementing an
editor because there would be a direct relationship between what is displayed
and the LDAP value assigned to it, something that my patch doesn't address at
all. For viewing the patch is fine, but if an editor were to be implemented then
it wouldn't suffice.

BTW I might add that sorting/assigning the fields to their respective schemes
should also be carried out as I did to help future maintainability.

Comment 219

[Hadmut Danisch]

Craig, Bill,

you might want to have a look at my proposal in Bug 282223, 
which, in my eyes, would solve all these problems.

Instead of hardcoded LDAP, mozilla should have a general API for plugins
or external scripts to enter, display, fetch addresses from arbitrary sources. 
You could easily implement any LDAP or SQL structure you'd prefer. 
You could even access MS Exchange or use your PGP keyring or incoming 
Mailbox as an address book.

regards
Hadmut

Comment 220

[Dan Mosedale (:dmosedale, :dmose)]

Taking.  I hope to drive this into the tree for Thunderbird 1.1.

Comment 221

[John Woodell]

I can imagine a the mozilla AB working just like outlook/palm
with a multi-line input field in an advanced popup...
https://bugzilla.mozilla.org/attachment.cgi?id=169295

The postalAddress and homePostalAddress addributes would contain 
a composite of the the other related attributes. Theses two and 
the street and MozillaHomeStreet attributes could be multi-line.

One important question: How should newlines be encoded?
- parse/encode with the $ character a specified in postalAddress schema
- base64 encode the entire string as is currently done with description

I won't lose any sleep over this feature.   :-)

Comment 222

[Hadmut Danisch]

...and what do you do if someone has more than just these 
two addresses? E.g. if someone has two homes? Or two job 
addresses?

Hadmut

Comment 223

[John Woodell]

(In reply to comment #222)
> ...and what do you do if someone has two homes? 

The postalAddress and homePostalAddress attributes are multivalued, 
and each attribute 'should be limited to up to 6 lines of 30 characters each'
so LDAP is not an issue, but I would not expect the mozilla AB to display 
these alternate addresses... but it certainly could.

Comment 224

[Craig Harding]

(In reply to comment #220)
> Taking.  I hope to drive this into the tree for Thunderbird 1.1.

Will this mean it'll be in the nightlies before the TBird 1.1 release? I would
really like to try it and see if it works, etc.

Comment 225

[Ian Broughton]

(In reply to comment #224)
> (In reply to comment #220)
> > Taking.  I hope to drive this into the tree for Thunderbird 1.1.
> 
> Will this mean it'll be in the nightlies before the TBird 1.1 release? I would
> really like to try it and see if it works, etc.

Any one know if this is in the nightlies yet?
Can someone post when this is in/due in.
Will 86405 be done too?

Comment 226

[Asa Dotzler [:asa]]

Dan, are we blocking 1.1 on this? 

Comment 227

[Dan Mosedale (:dmosedale, :dmose)]

Asa: I would like to, yes.  The fact that our current default LDAP schema is
missing a significant number of the attributes that our addressbook supports
hurts our deployment story. 

Comment 228

[Worcester12345]

Patched 12/21. Bitrot?

Comment 229

[Jaime Mitchell (use [e-mail] for email)]

[e-mail] do not set the blocking flag only
drivers@mozilla are able to do that.

Comment 230

[Ian Broughton]

(In reply to comment #229)
> [e-mail] do not set the blocking flag only
> drivers@mozilla are able to do that.

I appologise. 
Why could I do this anyway? 
I would have thought this was a restricted function.

Comment 231

[Mike Connor [:mconnor]]

Dan says this should be ready, needs to make b4 or it slips.

Comment 232

[Dan Mosedale (:dmosedale, :dmose)]

Attachment: new schema patch, v1

I believe that my biggest mistake with this bug was in thinking that it was
reasonable to treat "create an official schema" as a single unit of work.  So I
propose, with this patch, to change strategy.  Specifically, this patch changes
the LDAP code, and the LDIF import and export code to use the schema in
mozillaAddressBookEntry.schema attachment with a couple of tweaks.  The
objectclass name is changed from mozillaAbPersonObsolete to
mozillaAbPersonAlpha.  The idea is that this is a fine start, since it allows
all visible addressbook UI elements to mapped to LDAP attributes, so we can at
least avoid most dataloss.  Specific issues with the choices I've made here
should be addressed by filing future, separate bugs.  Eventually, once the
schema truly becomes stable, we can rev the objectclass name to
mozillaAbPerson.

The changes that I made from the schema attachment (attachment 166746 [details]) are:

* homePhone is used in preference to homeTelephoneNumber, as per RFC 2798
* the capitalization of mozillaSecondEmail was chosen
* displayName is used
* company is preferred to o

Comment 233

[Hadmut Danisch]

Ask yourself a question:

What is your goal?

- Do you want to publish the one and only "Mozilla Address Book Scheme", 
  and expect that everyone is so impressed that they immediately 
  reconfigure and adapt their LDAP servers, ADS, NDS, ... to make it 
  suitable to Mozilla (which is highly unprobable, since where I am 
  working only 2% of users use the mozilla address book, but the 
  ADS must be running),

- or do you want to make the mozilla address book usable with existing 
  LDAP servers. In that case you have to accept that there are plenty 
  of LDAP servers with different schemes, even with attribute names in 
  different languages. 


If you want to make the Mozilla address book usable, then you have to give up
the idea of a single schema. It simply doesn't work this way.

You need to make mozilla adaptable to any existing LDAP server and whatever
scheme it is using. 


The small solution would be to completely drop the idea of a Mozilla LDAP 
schema and to modify the configuration window for LDAP address books, 
where you enter the server name, port, base, dn: List all mozilla address
attributes and allow the user to enter the corresponding LDAP attribute names
for every single LDAP server. This way you could query servers with different
schema. 

The better solution would be to turn the LDAP driver into a general API 
(see bug 282223 ) to allow querying and writing any kind of database.

Comment 234

[Ian Broughton]

My Goal (I know this was not realy addressed to me the end user) is to be able 
to edit LDAP entries on our company LDAP server(Vpop).
This allows me then to bin Exchange as mozilla has sunbird already (the other 
component needed).
The edit commands exist in the LDAP standard.
But this bug is in theory blocking 86405.
So the Defining a Standard single schema is irrelivent to me.

Please comment.

Regards
Ian
The end user tring not to install Exchange!

Comment 235

[David :Bienvenu]

Comment on attachment 190678 [details] [diff] [review]
new schema patch, v1

I'd probably use the ? operator here but it's up to you if you think that's
less readable...

+      if (kNotFound != column.Find("true"))
+	 mDatabase->AddPreferMailFormat(newRow, nsIAbPreferMailFormat::html);
+      else if (kNotFound != column.Find("false"))
+	 mDatabase->AddPreferMailFormat(newRow,
nsIAbPreferMailFormat::plaintext);
+      else
+	 mDatabase->AddPreferMailFormat(newRow,
nsIAbPreferMailFormat::unknown);

Comment 236

[Dan Mosedale (:dmosedale, :dmose)]

Comment on attachment 190678 [details] [diff] [review]
new schema patch, v1

Found at least one bug in my patch; new patch forthcoming.

Comment 237

[Dan Mosedale (:dmosedale, :dmose)]

Attachment: patch, v2

This patch reverts the change that exported the addressbook displayname column
as "displayName" rather than "cn".  There's a bunch of magic in import and
export code that depends on that being cn; I've filed bug 302364 to address
that.  I left the code David pointed out alone, as it mirrors other code in the
same method.  The real solution to that style problem is to not use this goofy
hand-hacked datastructure for import (that whole code wants to be re-written in
JS, I just know it!).  Carrying forward r+ from David.

Comment 238

[Dan Mosedale (:dmosedale, :dmose)]

(In reply to comment #233) 
> 
> The small solution would be to completely drop the idea of a Mozilla LDAP 
> schema and to modify the configuration window for LDAP address books, 
> where you enter the server name, port, base, dn: List all mozilla address
> attributes and allow the user to enter the corresponding LDAP attribute names
> for every single LDAP server. This way you could query servers with different
> schema. 

In fact, this is more-or-less solved as of 1.1a1 when the fix for bug 119921 
was checked in.  LDAP attributes mappings can now all be edited on a per-server
basis using about:config.  For the longer-term, easier-to-deploy proposal, see
the schema autodiscovery proposal in bug 290889.

> The better solution would be to turn the LDAP driver into a general API 
> (see bug 282223 ) to allow querying and writing any kind of database.

This is a good idea as well; I'll comment more in that bug.

The idea of the "official schema" (ie this bug) is that we need to have default
for cases where users don't have an existing schema that they want to use.

Comment 239

[John Peacock]

(In reply to comment #238)
> In fact, this is more-or-less solved as of 1.1a1 when the fix for bug 119921 
> was checked in.  LDAP attributes mappings can now all be edited on a per-server
> basis using about:config.  For the longer-term, easier-to-deploy proposal, see

I see nothing in the above bug # which has anything to do with LDAP or
about:config (it's a dupe about sending files via forms).  I tried to do
a search about LDAP and about:config and I see nothing obvious that you
could be referring to.

However, I downloaded Thunderbird 1.1a2 and played around with the about:config
and although I could edit the attribute mappings, it appears that they don't
have any effect yet.  In particular, DisplayName in the AddressBook still uses
CN and not the DisplayName that the LDAP directory is presenting (checked with
another tool).  Does that part of this rely on the patch associated with 116692
being applied?

Comment 240

[Dan Mosedale (:dmosedale, :dmose)]

(In reply to comment #239)
> (In reply to comment #238)
> > In fact, this is more-or-less solved as of 1.1a1 when the fix for bug 119921 
> > was checked in.  LDAP attributes mappings can now all be edited on a per-server
> > basis using about:config.  For the longer-term, easier-to-deploy proposal, see
> 
> I see nothing in the above bug # which has anything to do with LDAP or
> about:config (it's a dupe about sending files via forms). 

Sorry, I meant to type bug 119291.

> However, I downloaded Thunderbird 1.1a2 and played around with the 
> about:config and although I could edit the attribute mappings, it appears
> that they don't have any effect yet.  In particular, DisplayName in the
> AddressBook still uses CN and not the DisplayName that the LDAP directory
> is presenting (checked with another tool).  Does that part of this rely on
> the patch associated with 116692 being applied?

No, although you may need to restart for any edits you have to take effect. 
Whatever the problem is, feel free to file a new bug in Core : MailNews LDAP
Integration on it.
> 

Comment 241

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Comment on attachment 190732 [details] [diff] [review]
patch, v2

Assuming that we don't really want to be using .EqualsLiteral for the
comparisons to the fixed attribute strings, sr=shaver.

(If so, sr=shaver with that changed. =))

Comment 242

[Dan Mosedale (:dmosedale, :dmose)]

Attachment: patch, v3

Good catch on the EqualsLiteral thing.	Fixed.	Carrying forward r+ and sr+.

Comment 243

[Dan Mosedale (:dmosedale, :dmose)]

Patch checked in.  Please open new, individual bugs about problems with the
schema as now checked-in, and we can address them individually.

If anyone is interested in updating the schema file to match what is now checked
in, I'd be willing to put that into CVS so that it could easily be kept up to
date as the code itself evolves.  After that's done, I propose we close this bug

Comment 244

[John Woodell]

> If anyone is interested in updating the schema file...

I need to determine what 'our' current objectives for the schema are.

Comment 245

[John Woodell]

(In reply to comment #239)
> In particular, DisplayName in the AddressBook still uses
> CN and not the DisplayName that the LDAP directory is presenting...

It will be a crime if the "custom attribute mapping" feature
kills the "use cn when displayName is not present" feature.

Comment 246

[Hadmut Danisch]

What about X509 certificates and jpeg images?

- X509 certificates:

  See comment #149, comment #160, comment #169, comment #197, comment #198

  Still not in the schema. 

- Jpeg images are a common attribute of address book entries and the 
  good ole Netscape Navigator I used arround 1998 could display jpeg 
  images from LDAP directories. 

  Would be nice to support a feature that existed ~8 years ago. :-)

regards
Hadmut

Comment 247

[Roland Felnhofer]

(In reply to comment #244)
> > If anyone is interested in updating the schema file...
> 
> I need to determine what 'our' current objectives for the schema are.

Hi John,
I would go for what Dan wrote in comment #238 : 
> The idea of the "official schema" (ie this bug) is that we need to have default
> for cases where users don't have an existing schema that they want to use.

Provide defaults for all addressbook fields CURRENTLY available.
As soon as new addressbook fields appear (for example: image of a person) we can 
extend it and release a new version.

Comment 248

[John Woodell]

Attachment: more attributes from inetorgperson.schema

(In reply to comment #247)
> ...we need to have default for cases where users 
> don't have an existing schema that they want to use.

OK, so there are two possible schema files currently posted:
- mozillaOrgPerson (id=166038)
- mozillaAddressBookEntry (id=166746)

What exactly needs to change to match what is checked in?

Note: the attachment is for reference when we add 
jpegPhoto and certificate attributes to the schema.

Comment 249

[Roland Felnhofer]

Comment on attachment 166038 [details]
Mozilla LDAP schema V0.6.4

(In reply to comment #248)
Hi John,
no objections to mark my schema obsolete in favor of mozillaAddressBookEntry
(id=166746)

Comment 250

[John Woodell]

OK, so we are NOT extending inetOrgPerson, right?

Will we ever be able to have MUST for cn, or are 
we thinking we'll export a uuid for each entry? 

Comment 251

[Dan Mosedale (:dmosedale, :dmose)]

Removing blocking flags since enough of this has landed that there's no need to
block the branch.  I'll catch up on and respond to recent comments here soon (ie
in the next few days, I hope).

Comment 252

[Ola Thoresen]

Could we - pretty please with sugar on top - cooperate with (among others) the 
evolution-developers on this schema?
Many users use different MUAs, or they switch between their regular MUA and some 
webmail solution and so on.
The contact list should really be accessible from all clients, and this requires 
the fields to be the same in all schemas.

I know some objectclasses are specific for the different MUAs, but that could be 
 solved with one unified schema for all clients, containing everything that more 
than one client need, and small extentions to this with only the few classes 
that are really MUA specific.

Comment 253

[Barton Phillips]

It is hard to find a sutable set of schema definitions. Please publish one set
and put it on the web page so people can find it.

Comment 254

[Mark Banner (:standard8)]

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

Comment 255

[Don Seiler]

FYI:  http://wiki.mozilla.org/MailNews:LDAP_Address_Books

mozillaAbPersonAlpha is the new hotness.  This has been confirmed after discussion in #maildev on mozilla irc.

Comment 256

[John Woodell]

I am surprised to see 'MUST ( cn )', given that I have previously 
been able to add lots of AB entries with only an email address,
but this seems like a good thing regardless.

I'm very happy to see that it is 'SUP top AUXILIARY' (not inetOrgPerson)
My AB has entries that are not a person, but are a location or group.

Comment 257

[Bob Smith]

(In reply to comment #255)
> FYI:  http://wiki.mozilla.org/MailNews:LDAP_Address_Books
> 
> mozillaAbPersonAlpha is the new hotness.  This has been confirmed after
> discussion in #maildev on mozilla irc.
> 

I have updated http://www.sudleyplace.com/LDAP/ and the associated PHP conversion script to handle TB 1.5RC1 and mozillaAbPersonAlpha.schema.  Please let me know if there is anything I've missed.

Comment 258

[Bob Smith]

(In reply to comment #255)
> FYI:  http://wiki.mozilla.org/MailNews:LDAP_Address_Books
> 
> mozillaAbPersonAlpha is the new hotness.  This has been confirmed after
> discussion in #maildev on mozilla irc.

There are a few discrepancies between TB 1.5RC1 and the Alpha schema it apparently relies upon.  These are pointed out in my web page http://www.sudleyplace.com/LDAP/index.html#Editing, so I won't repeat them explicitly here.  However, I would like to understand whether or not this is due to my misunderstanding the issues.

Comment 259

[Mark Banner (:standard8)]

(In reply to comment #258)
> There are a few discrepancies between TB 1.5RC1 and the Alpha schema it
> apparently relies upon.  These are pointed out in my web page
> http://www.sudleyplace.com/LDAP/index.html#Editing, so I won't repeat them
> explicitly here.  However, I would like to understand whether or not this is
> due to my misunderstanding the issues.

Actually, the Alpha schema *does* match TB 1.5 default ldap server setup. It doesn't match the ldif export setup which probably won't be fixed until after 1.5. The relevant bug is Bug 119948, which although the title isn't obvious it will be fixing the ldif export setup.

Comment 260

[Ian Broughton]

Ok Chaps I have found a solution
I don't like it but There is a package called Xconnect this intigrates:
Contacts and Calendars(multi platform).
It's the only solution for me at the moment (except going down the Exchange server route).
I know this costs and thats why I don't like it!
And yes I want to support the Open Source route but the company conserned can't wait any longer!

Comment 261

[Ian Broughton]

I've had quite a few people email me regarding this solution so here's the details.
Here's a few links for you to look at hope they help everyone:-

We use (on this site):- Vpop3(mail server) www.pscs.co.uk they have Vcap (online calendars) and use LDAP (with an link to the Vpop3 server for outlook contacts (Beta version)) But we only use the Vpop3 email server bit at the moment. Their support is V good and the product is in continuous development.

We are looking at using (on this site):-Xcconect for the calendars and contacts http://xcnetwork.com/index.jsp this is vgood but expensive. Support is good (what we've needed of it) IIE needs a bit of a tweak on the server, but other wise no problems. This solution has now compleated the trial and will be installed over the next few months.

It has been suggested that we look at:-

Kolab 

http://www.kolab.org/ with the Thunderbird plugin http://www.gargan.org/extensions/synckolab.html

Not looked at yet

and 

Visnetic

Again not looked at yet

The problem we have is that we are multiplatform and multi sites, with PC's only, Pc/Mac and Mac only sites with various per site server solutions (an IT nightmare!).

Comment 262

[Dan Mosedale (:dmosedale, :dmose)]

Assigning bugs that I'm not actively working on back to nobody; use SearchForThis as a search term if you want to delete all related bugmail at once.

Comment 263

[Wayne Mery (:wsmwk)]

changing to sev=normal - this bug blocks others (3 of 4 are ENH), but is not a blocker to development nor a release

Comment 264

[Worcester12345]

(In reply to Roland Felnhofer from comment #0)
> As far as I know there is no official Mozilla LDAP schema extension
> available.
> 
> Currently I use my own OID in my xmozilla schema. Mozilla should have his own
> official LDAP schema extension.

Is there a place where the "how to" on this workaround is explained, until this bug gets fixed?

Thanks.

Comment 265

[Mark Banner (:standard8)]

(In reply to Worcester12345 from comment #264)
> Is there a place where the "how to" on this workaround is explained, until
> this bug gets fixed?

The current alpha schema is available at https://wiki.mozilla.org/MailNews:LDAP_Address_Books#LDAP_Address_Book_Schema

Comment 266

[石庭豐 (Seak, Teng-Fong)]

In the "de facto" schema, it lacks a field for "last modified date" time-stamp.  Moreover, it would be nice if this field contain a string in ISO 8601 format (YYYY-MM-DDThh:mm:ssZ) to make data exchange easier.

Furthermore, it also lacks fields for photos which are implemented in recent TB.

Comment 267

[Marco van Beek]

Hi. LDAP already has bunch of internal attributes, including a last modified date called modifytimestamp. There is also a createTimestamp, and a creatorsName as well.

As far as a Photo is concerned, there is one defined in inetOrgPerson. LDAP works best when you can build on existing schemas, as that way systems can exchange information properly.

Comment 268

[石庭豐 (Seak, Teng-Fong)]

(In reply to Marco van Beek from comment #267)
> Hi. LDAP already has bunch of internal attributes, including a last modified
> date called modifytimestamp. There is also a createTimestamp, and a
> creatorsName as well.

From which object class?  Nevertheless, we still need to mention the attributes in the *schema*.

> As far as a Photo is concerned, there is one defined in inetOrgPerson. LDAP
> works best when you can build on existing schemas, as that way systems can
> exchange information properly.

Have you read the Photo attribute in detail? That attribute does not match our need in TB Address Book:
* There are three possible values for Photo in TB-ABook: Generic, "computer", "URL"

1. How do you match Generic to Photo attribute of inetOrgPerson?
2. For "computer", the attribute MIGHT be useful but I'm not convinced.  Look at that attribute: it is using some old format for fax!  Come on!  Are you still living in the 20th century?
3. How do you match the URL to Photo attribute?

Comment 269

[Marco van Beek]

(In reply to 石庭豐 (Seak, Teng-Fong) from comment #268)
> 
> From which object class?  Nevertheless, we still need to mention the
> attributes in the *schema*.

Back off. Read the text in my post. Mainly the bit that says "INTERNAL ATTRIBUTE". Then read RFC4512. Mainly the bit just above 3.4.1 where it says "Servers SHOULD maintain the 'creatorsName', 'createTimestamp', 'modifiersName', and 'modifyTimestamp' attributes for all entries of the DIT." Admittedly Microsoft ignore that but use an attribute called lastChanged.
 
> Have you read the Photo attribute in detail? That attribute does not match
> our need in TB Address Book:
> * There are three possible values for Photo in TB-ABook: Generic,
> "computer", "URL"

Okay. I will acknowledge that I should have looked up the full name of the attribute to avoid confusion. I was referring to "jpegPhoto", which actually comes up first if you do a search of the RFC. If you read RFC2798, it says "2.6. JPEG Photograph: Used to store one or more images of a person using the JPEG File Interchange Format [JFIF]."

It is an attribute to store an image, which if you are using LDAP to share an address book is the safest way of doing it, since an external URL could become infected by malware, and an internal "on this computer" link is of no use to another user.

So actually, I did know what I was talking about. I just made the fundamental error of assuming I was talking to someone intelligent. However, the rudeness in your reply has made me realise my mistake.

Comment 270

[John Woodell]

The world has changed a bit in the ten years since I last commented on this bug.

Comment 271

[Marco van Beek]

Just a bit :-). With CardDAV gathering pace as a server-side solution, it is my opinion that any LDAP solution has to be optimised for sharing data properly with other systems. The only reason I persist with LDAP over CardDAV is that my office VoIP system can do LDAP lookups and my fax machine can do LDAP lookups, neither of which are likely to integrate with CardDAV in the near future. I also hacked a version of Z-Push to allow me to two-way sync a pair of LDAP address books onto our mobile phones (a private and a company one), We also use a hacked version of Contagged for a web interface, and the system has been running nicely for about 8 years now. Quite frankly, in all that time, we have only need to create two object classes and one attribute, the two classes were to allow us to add existing attributes to part of the tree that could not use the original class due to conflicts, and the attribute to allow us to store a primary email address for sending email via z-push.

Comment 272

[Chan Min Wai]

Having waiting from 2002 until now...
A decade had pass...

I think that we should really drop all that and move it to the generics or other standard schema and drop this.

It is really no point to process with the current schema.

Comment 273

[Worcester12345]

(In reply to Chan Min Wai from comment #272)
> Having waiting from 2002 until now...
> A decade had pass...
> 
> I think that we should really drop all that and move it to the generics or
> other standard schema and drop this.
> 
> It is really no point to process with the current schema.

And another 3 years. 

Should this bug be reincarnated? I see a "patch, v3" sitting there.

It would be GREAT to see some finality (in a good way) to this. 

MOZILLA: TAKE A BOLD STEP!

Comment 274

[Daniel Albers]

The right bold move would be to finally close this as WONTFIX. Especially given the pending departure of Thunderbird from Mozilla.

Comment 275

[Bill Mair]

As far as I am concerned this issue has become obsolete.

I now use ownCloud (CardDAV) to manage and sync my addresses across my various devices, so I am no longer using LDAP as an address management system.

Comment 276

[Daniel Albers]

Same for me. I don't know why my previous comment was flagged as spam, I was being entirely serious.

Comment 277

[Daner]

Is it possible to use the ownCloud CardDAV address book directly from Thunderbird? How?

Comment 278

[Bill Mair]

I use the SOGo connector (http://sogo.nu/download.html#/frontends) together with lightning for CardDAV and CalDAV sync.

Comment 279

[Wayne Mery (:wsmwk)]

(In reply to Daniel Albers from comment #276)
> Same for me. I don't know why my previous comment was flagged as spam, I was
> being entirely serious.

Because in bugzilla comments should offer constructive information that helps the cause of the original bug report. 


(In reply to Worcester12345 from comment #273)
> ... 
> MOZILLA: TAKE A BOLD STEP!

It's great to see so much interest.  So let's take stock

- Mozilla is no position to do anything about ldap, it's all volunteers and has been for quite a while. It is by the good will and hard effort of volunteers that Thunderbird still survives.
- In the last several years at least it is not a lack of will nor lack of desire to address ldap that has hamperred ldap development. It is fundamentally a total lack of ldap expertise. We've encountered one or two with expertise who are not existing contributors but they did not step up to help, and no one else has volunteered to learn.  Perhaps more telling, no one/no company has offered to pay a developer with the skills to do it, including oddly enough enteprise organizations with a vested interest of users numbering in the hundreds of thousands no doubt. Our wishing that ldap will blossom isn't going to change anything - a developer is needed. So if someone knows someone, please make it known.
- Alternatives exist - some OK (it's great to hear about them), and some not so great.
- dmose in comment 243 sez patch landed and close the bug, pending storage of the schema.  The schema is at https://wiki.mozilla.org/MailNews:Mozilla_LDAP_Address_Book_Schema but the bug never got closed.

As for the disposition of this bug, it should have been closed when patch landed for Thunderbird 1.5=mozilla1.8. As suggested in comment 243, the path forward for all your outstanding issues is "Please open new, individual bugs about problems with the schema as now checked-in, and we can address them individually."  No doubt there is room for improvement. So please find other bug reports which match your concern (linked to meta Bug 36557 or this query http://mzl.la/1UKEUQY), or file a new bug. (Schema is mentioned in these bugs http://mzl.la/1UKGD8U)

Docs:
https://wiki.mozilla.org/MailNews:LDAP_Address_Books
https://developer.mozilla.org/en-US/docs/Mozilla/Thunderbird/LDAP_Support
http://kb.mozillazine.org/Sharing_address_books
plus stuff on the net, like http://chuckles34.net/howto-setup-ldap-address-book-for-thunderbird

If you have ideas and resources about moving ldap forward there places mentioned in https://wiki.mozilla.org/Thunderbird/CommunicationChannels