323608 - ldap schema's use of displayName has changed since Thunderbird 1.0x

Status: RESOLVED FIXED

(MailNews Core :: Address Book, defect)

Description

[anilo_sysadmin]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8) Gecko/20051111 Firefox/1.5

when I upgrade from thunderbird 1.0.7 to 1.5 the ldap-queries do not work;
also with 1.6a1 it does not work; downgrading to 1.0.7 it does work;
I also created a NEW profile -> same problem; then I traced the query with windump; the ldap-queries are DIFFERENT!

when I query a name with 8 characters:

thunderbird 1.0.7 sends 627 Bytes of data, everything works;
thunderbird 1.5 and 1.6a1 sends 945 Bytes of data; the ldap server does not return the requested result;

What is the difference in the code???


Reproducible: Always

Steps to Reproduce:
1. thunderbird 1.0.7: query a name with 8 characters; OK
2. thunderbird 1.5 (or 1.6a1); server does not respond the requested data;

Comment 1

[Mark Banner (:standard8)]

Is the problem just with address book searches or auto-complete as well?

> What is the difference in the code???

There have been various fixes and improvements, including allowing attribute mapping for ldap via prefs including a revised schema implementation (see bug 119291 and bug 116692).

The Thunderbird trunk nightlies, now also have the facility to log what Thunderbird is doing wrt to ldap queries.

See this link for a draft mozilla ldap schema and how to turn on the logging facility:

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

Comment 2

[Brendan Bellina]

There has been a recent flurry of activity on the Internet2 MACE-Dir list about this.  There is a concern that the change in the LDAP search filter used by the Address Book will prevent matches.  The LDAP search filter in 1.0 queried on cn, givenname, sn, and mail, but in TB 1.5 cn has been dropped in favor of displayName.  This is not good because:
1. displayName is not normally an indexed attribute, so timeouts are going to occur
2. displayName cannot contain all of the values cn could so matches will fail.

The before-and-after wildcarding used in the Address Book is not sufficient to find people with middle initials/names.

In standards-based LDAP directories cn "common name" contains all of the values of a person's name to facilitate searching.  displayName is a single-value intended to be used for display, NOT searching.  If a directory cn is populated with a formal name and a name based on nickname, displayName will only contain one of them and therefore the Address Book in 1.5 will only be able to find the person based on one value, not both.

The Address Book search filter should be changed to match the filter used for composition which uses the correct attributes and acceptable wildcarding.

I have tested this with TB 1.5 for Mac OS X and Windows.

Comment 3

[Mark Banner (:standard8)]

(In reply to comment #2)
> The Address Book search filter should be changed to match the filter used for
> composition which uses the correct attributes and acceptable wildcarding.

The wildcarding issue is a separate bug that I think is already filed somewhere and would have been present in 1.0. Please keep bugs to one issue per a bug.

Having said that, the display name/cn could be the issue here.

Comment 4

[Brendan Bellina]

(In reply to comment #3)
> (In reply to comment #2)
> The wildcarding issue is a separate bug that I think is already filed somewhere
> and would have been present in 1.0. Please keep bugs to one issue per a bug.

I'm not reporting the wildcarding as a bug.  My point is that using (displayname=*first last*) is not sufficient to encompass all of the possible values that using (cn=*first last*) did.

The change from cn to displayname may make sense for those used to Microsoft AD's use of cn and displayname. AD uses cn as a single-valued unique login identifier and embeds it in the dn.  Because of that they index displayname and have their applications (like Outlook Express) search on it instead of cn.  Other directories follow the standard definition of cn being a multi-valued common name attribute and displayname does not need to be indexed because searches against it are not needed.

If you want Thunderbird to work well with AD then searching on displayname rather than cn makes sense.  For other directories it doesn't.  Searching on both doesn't make sense either since that will still require non-AD directories to index directoryname.

Comment 5

[Mark Banner (:standard8)]

cc'ing mcs - do you have an opinion about comments 2 and 4?

Comment 6

[Brendan Bellina]

(In reply to comment #4)
> both doesn't make sense either since that will still require non-AD directories
> to index directoryname.

That should have read "displayname", not "directoryname".

Sorry.

Brendan

Comment 7

[Mark Smith [:mcs]]

I agree with comments 2 and 4.  The norm outside of the Active Directory world is for displayName to contain one preferred name and cn to contain all names a person is known by.  The challenge is to pick something that will work well for both AD and non-AD situations... and even then, most LDAP directory servers are flexible with respect to which attributes are indexed and so on.  Bottom line: it is hard to pick one thing that will work well for everyone.

Was the change from searching on cn to searching on displayName done in response to a specific problem?  I probably overlooked that change in some other bug report.

Comment 8

[Jon Miner]

(In reply to comment #7)
> I agree with comments 2 and 4.  The norm outside of the Active Directory world
> is for displayName to contain one preferred name and cn to contain all names a
> person is known by. 

(just to be painfully exact...)

Novell eDirectory (or whatever they call NDS these days) I believe uses CN for the username as well.

jon

Comment 9

[Dan Mosedale (:dmosedale, :dmose)]

(In reply to comment #7)
>
> Was the change from searching on cn to searching on displayName done in
> response to a specific problem?  I probably overlooked that change in some
> other bug report.

This was part of the ldap schema overhaul (bug 116692) as well as the attribute map changes that implemented it.  It was mostly due to my not understanding the subtleties of typical cn usage outside the Active Directory world.

As far as what to do now, well, hmmm.  In some ideal world, our defaults would play reasonably well in both situations.  It would be interesting to know how well we play with ActiveDirectory in general anyway, since, if I recall correctly, they don't actually use inetOrgPerson by default.

Brendan says:

> Searching on both doesn't make sense either since that will still require
> non-AD directories to index displayName.

It's not clear to me that asking server admins to index displayName is such a bad thing.  Can you elaborate on your objection to this strategy?

Note that in the short term, which attribute to use can be overridden by a preference.

For the long term, what I'd really like to see would be support of schema autodiscovery (eg that described by the now expired Internet-Draft referenced in bug 290889).

Comment 10

[Mark Smith [:mcs]]

(In reply to comment #9)
> As far as what to do now, well, hmmm.  In some ideal world, our defaults would
> play reasonably well in both situations.  It would be interesting to know how
> well we play with ActiveDirectory in general anyway, since, if I recall
> correctly, they don't actually use inetOrgPerson by default.

Yes.  Can someone who has access to an A-D system comment here?


> It's not clear to me that asking server admins to index displayName is such a
> bad thing.  Can you elaborate on your objection to this strategy?

It is bad to require that directory admins make any changes to support Thunderbird users.  The problem with searching by displayName by default is that if most LDAP installations do not have it indexed, the administrators may quickly dislike tbird because it is hitting them with "bad" searches.

> For the long term, what I'd really like to see would be support of schema
> autodiscovery (eg that described by the now expired Internet-Draft referenced
> in bug 290889).

I would not wait for a new I-D or other new specification.  The practical thing to do is to implement autodiscovery of some kind without counting on any new LDAP features.  I know some other LDAP clients do things like discover whether they are talking to A-D or not.  In general this is a messy, difficult problem.    We really need input from the user community to determine what to do here.
> 

Comment 11

[Brendan Bellina]

Thunderbird being free and multi-platform gives it wide appeal in the higher-ed community where there is little funding for these sorts of things and IT usually does not dictate client OS choices.  Also in higher-education - at least in the US - you find that most LDAP directories are going to be either iPlanet or SunDS, with a growing number of OpenLDAP.  Active Directory is generally not used in higher education except in departmental capacities - business schools and the like.  If you have to choose, I would consider going with the published standard usage of cn and displayname and providing a means for those using AD or Novell to override the search filter.  As it is right now the only solution for those in higher-ed is to change the user pref ldap_2.servers.default.attrmap.DisplayName to cn,commonname.  If there needs to be burden it should not be on those who have followed the standard attribute definitions.

The standard definition is:
   2.3.  Display Name

   When displaying an entry, especially within a one-line summary list,
   it is useful to be able to identify a name to be used.  Since other
   attribute types such as 'cn' are multivalued, an additional attribute
   type is needed.  Display name is defined for this purpose.

This makes clear that cn is for multi-valued names - not as AD and Novell are using it - and that displayname is for displaying one value that is likely also in cn, not searching.  Microsoft and Novell are broken by design.

Comment 12

[Quanah Gibson-Mount]

I'd note that the entire problem here is that Thunderbird simply doesn't correctly support setting custom search filters.  This is related to bug 286815 that I filed some time ago, and discussed in detail at:

http://www.stanford.edu/~quanah/directory/email/

Comment 13

[Brendan Bellina]

The inetOrgPerson RFC 2798 definition of displayname certainly indicates that cn is expected to be multi-valued and displayname is expected to be populated with one and only one of the values from cn.  The LDIF example of Babs Jenson in the RFC shows this explicitly:

   objectClass: inetOrgPerson
   cn: Barbara Jensen
   cn: Babs Jensen
   displayName: Babs Jensen

Example text is only that, an example, though.  And RFC 2256 which defines cn doesn't state that the attribute MUST be single-valued, but doesn't describe it as a list of names either.

How do we get a definitive answer on what the authors of these RFC's intended?  If we have been wrong in populating cn and displayname like the example in RFC 2256 then it would be good to know.

Brendan Bellina

Comment 14

[Brendan Bellina]

>> If we have been wrong in populating cn and displayname like the example in RFC 2256 then it would be good to know.

I meant the example in RFC 2798, not 2256.

Brendan Bellina

Comment 15

[Dan Mosedale (:dmosedale, :dmose)]

(In reply to comment #10)
> > For the long term, what I'd really like to see would be support of schema
> > autodiscovery (eg that described by the now expired Internet-Draft 
> > referenced in bug 290889).
> 
> I would not wait for a new I-D or other new specification.  The practical
> thing to do is to implement autodiscovery of some kind without counting on
> any new LDAP features.  I know some other LDAP clients do things like
> discover whether they are talking to A-D or not.  In general this is a
> messy, difficult problem.

Well, in a world where there were one or more people devoted to doing LDAP stuff in Mozilla addressbook, I would probably want to immediately implement something along the lines of the draft described in that bug.  If I recall correctly, it had the advantage of not needing any special server support other than the server admin configuring the schema map entry.  An argument could be made for specifically detecting A-D, Novell, etc and adapting to them, but pushing forward something that could reasonably be standardized to address this seems like a better strategy to me.  Any waiting for this work to happen is unlikely to be waiting on a standard as much as waiting for someone to sign up to do the work.  Further discussion along those lines should probably continue in bug 290889.

(In reply to comment #12)
> I'd note that the entire problem here is that Thunderbird simply doesn't
> correctly support setting custom search filters.  

This bug is about the default schema that is being used by the addressbook code.  It's already possible to set the default schema back to the way it used to be (i.e. cn instead of displayName) in 1.5.  So there's already a workaround, but it's inconvenient.  Any custom search filter would provide a similar but different workaround, with the same level of inconvenience.  So as far as I can tell, that bug is orthogonal to this.

I think the next step here is to find out how well we play (and can play, given our dependence on inetOrgPerson) with Active Directory by default, since the answer to that has implications regarding how we weigh various alternatives going forward.  If someone is interested in volunteering to do that research, it would be very helpful.

Comment 16

[Laurent Bauvens]

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

Comment 17

[Dan Mosedale (:dmosedale, :dmose)]

This seems to be frustrating a number of people.  If we want to revert back to using cn here, I think we need to do it now before too many institutions get around to deploying 1.5.  As such, I think making a decision here should block 1.5.0.1.

Comment 18

[Scott MacGregor]

Dan, what's your gut call on what to do here? I'd be ok with reverting back to the 1.0.x behavior but have little background on the right thing to do. 

Comment 19

[Dan Mosedale (:dmosedale, :dmose)]

My gut call is that we probably want to revert it.  However, there's one more person I'd like to consult with before making a decision.  More to come...

Comment 20

[Bryan Wright]

In reply to <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=323608#c15">comment #15</a>:

> It's already possible to set the default schema back to the way it used
> to be (i.e. cn instead of displayName) in 1.5.

Where can this be changed?  I'm running into the displayName/cn problem
here.  Our ldap data only defines displayName for our undergraduates.
This means that, under Thunderbird 1.5, lookups for faculty, staff and graduate
students fail.

Comment 21

[Brendan Bellina]

(In reply to comment #20)
> Where can this be changed?  I'm running into the displayName/cn problem
> here.  Our ldap data only defines displayName for our undergraduates.
> This means that, under Thunderbird 1.5, lookups for faculty, staff and graduate
> students fail.

Go into the TB Config Editor:
- for Windows: Tools/Options/Advanced Tab/Config Editor button
- for Mac: Thunderbird Preferences/Advanced Tab/Config Editor button

Double-click on
  ldap_2.servers.default.attrmap.DisplayName
and change its value from
  displayName,cn,commonname
to
  cn,commonname

Exit the Config Editor and restart Thunderbird.

That should do it.

Comment 22

[Bryan Wright]

In reply to comment #21:

That seems to work, although the first time I tried it after restarting
Thunderbird, it seemed to take a really long time before it returned
any results.  Subsequent tries seemed normally fast, though, so it may
just have been a local anomaly.

For the benefit of anybody watching, I'll add that the way to change the
settings under Linux is:

Edit --> Preferences --> "Advanced" tab --> click on "Config Editor...",
then change the appropriate setting.

Comment 23

[Anton Bobrov]

folks, sorry for jumping in here but i dont understand what is
the problem with AD you have by using cn and not displayname ?
cn is in there by default as well as inetOrgPerson objectclass
theoretically cn can be ditched from the schema by local admin
but i seriously doubt anybody would do that coz it will cause
all kinds of diff things to break. cn attr in AD is indeed a
singlevalue which is against the standards but thats not the
point. the point is that any organization can choose how they
want to deploy their DS so that DNs of their users are unique.
say it can be a multivalued cn with mixing firstname lastname
with employee id or it can be a different attribute say uid or
similar. cn is present tho and can be searched for unlike the
displayname which isnt always there. if one thinks that using
displayname in the search filter would improve hitting the 
right results in some deployments it can be added to the end 
of OR search filter tho it can have a negative impact on perf.
imho its not worth it and should only be added if people do
experience problems on reasonable number of deployments or if
attributes can be configured or marked/unmarked in some conf
panel in UI. anyways for what it worth i agree with those who 
ask to make cn attribute default instead of displayname attr.

Comment 24

[Iain MacDonnell]

+1 for reverting to CN - my corporate directory is not indexed on displayName either (and I don't directly control it).

Comment 25

[Scott MacGregor]

Attachment: possible patch to revert the behavior to the way it was for 1.0

This patch should revert us back back to cn like we used in 1.0.

I'd support Dan's decision to revert this change and can drive it into 1.8.0.2 if dmose still agrees.

Comment 26

[Stefan]

(In reply to comment #11)
> Thunderbird being free and multi-platform gives it wide appeal in the higher-ed
> community where there is little funding for these sorts of things and IT
> usually does not dictate client OS choices.  Also in higher-education - at
> least in the US - you find that most LDAP directories are going to be either
> iPlanet or SunDS, with a growing number of OpenLDAP.  Active Directory is
> generally not used in higher education except in departmental capacities -
> business schools and the like.  If you have to choose, I would consider going
> with the published standard usage of cn and displayname and providing a means
> for those using AD or Novell to override the search filter.  As it is right now

CN will work with Novell as well. But it would be very nice to be able to configure the searchfilters... 


> the only solution for those in higher-ed is to change the user pref
> ldap_2.servers.default.attrmap.DisplayName to cn,commonname.  If there needs to
> be burden it should not be on those who have followed the standard attribute
> definitions.
> 
> The standard definition is:
>    2.3.  Display Name
> 
>    When displaying an entry, especially within a one-line summary list,
>    it is useful to be able to identify a name to be used.  Since other
>    attribute types such as 'cn' are multivalued, an additional attribute
>    type is needed.  Display name is defined for this purpose.
> 
> This makes clear that cn is for multi-valued names - not as AD and Novell are
> using it - and that displayname is for displaying one value that is likely also
> in cn, not searching.  Microsoft and Novell are broken by design.
> 

I don't know what point you're trying to make, but if the searchfilter Thunderbird uses contains a CN, everything will work fine. But as of the 1.5 version, it apparently doesn't use that anymore. Displayname will work with Novell as well. What I'm looking for is an overview for the changes between 1.0x and 1.5 which cause lookups to fail...

Comment 27

[Brendan Bellina]

(In reply to comment #26)
> (In reply to comment #11)
> > the only solution for those in higher-ed is to change the user pref
> > ldap_2.servers.default.attrmap.DisplayName to cn,commonname.  If there needs to
> > be burden it should not be on those who have followed the standard attribute
> > definitions.
> > 
> > The standard definition is:
> >    2.3.  Display Name
> > 
> >    When displaying an entry, especially within a one-line summary list,
> >    it is useful to be able to identify a name to be used.  Since other
> >    attribute types such as 'cn' are multivalued, an additional attribute
> >    type is needed.  Display name is defined for this purpose.
> > 
> > This makes clear that cn is for multi-valued names - not as AD and Novell are
> > using it - and that displayname is for displaying one value that is likely also
> > in cn, not searching.  Microsoft and Novell are broken by design.
> > 
> 
> I don't know what point you're trying to make,

My point is that Microsoft and Novell have deviated from standard attribute usage.  Products that do not support preferences for these sorts of things should follow the standards.

> but if the searchfilter Thunderbird uses contains a CN, everything will work fine.

Not correct.  The Thunderbird searchfilter makes two mistakes: (1) it excludes cn, and (2) it includes displayname.  On directory servers other than Microsoft AD and Novell eDirectory, excluding cn will reduce positive hits when searching and including displayname will cause unindexed searches and timeouts.

> What I'm looking for is an overview for the changes between 1.0x and 1.5 which cause lookups to fail...

Here is a description of what was changed:

Here is the first search done using Thunderbird 1.0 when composing an email and typing "Brendan Bellina":
[25/Jan/2006:12:40:55 -0800] conn=1606311 op=1 msgId=2 - SRCH base="dc=usc,dc=edu" scope=2 filter="(|(cn=Brendan*Bellina*)(mail=Brendan*Bellina*)(sn=Brendan*Bellina*))" attrs="cn mail"
[25/Jan/2006:12:40:55 -0800] conn=1606311 op=1 msgId=2 - RESULT err=0 tag=101 nentries=1 etime=0

Here is the second search done using Thunderbird 1.0 this time from the Address Book and typing "Brendan Bellina":
[25/Jan/2006:12:41:09 -0800] conn=1606312 op=1 msgId=2 - SRCH base="dc=usc,dc=edu" scope=2 filter="(|(mail=*Brendan Bellina*)(cn=*Brendan Bellina*)(givenName=*Brendan Bellina*)(sn=*Brendan Bellina*))" attrs="modifyTimestamp xmozillausehtmlmail description notes custom4 custom3 custom2 custom1 birthyear homeurl workurl nscpaimscreenname c company o departmentNumber department orgunit ou title c zip postalCode region st l l street postOfficeBox carphone cellphone mobile pagerphone pager facsimileTelephoneNumber facsimileTelephoneNumber homePhone telephoneNumber xmozillasecondemail mail xmozillanickname displayName cn cn sn sn givenName"
[25/Jan/2006:12:41:09 -0800] conn=1606312 op=1 msgId=2 - RESULT err=0 tag=101 nentries=1 etime=0

Now switching to Thunderbird 1.5 which uses the same filter as 1.0.  Here is the first search done when composing an email and typing "Brendan Bellina":
[25/Jan/2006:12:42:06 -0800] conn=1606313 op=1 msgId=2 - SRCH base="dc=usc,dc=edu" scope=2 filter="(|(cn=Brendan*Bellina*)(mail=Brendan*Bellina*)(sn=Brendan*Bellina*))" attrs="cn mail"
[25/Jan/2006:12:42:06 -0800] conn=1606313 op=1 msgId=2 - RESULT err=0 tag=101 nentries=1 etime=0

And here is the second search done using Thunderbird 1.5 from the Address Book and typing "Brendan Bellina".  The filter used and attributes asked for are different than in TB 1.0:
[25/Jan/2006:12:42:17 -0800] conn=1606314 op=1 msgId=2 - SRCH base="dc=usc,dc=edu" scope=2 filter="(|(mail=*Brendan Bellina*)(displayName=*Brendan Bellina*)
(givenName=*Brendan Bellina*)(sn=*Brendan Bellina*))" attrs="company o title modifyTimestamp mozillahomeurl homeurl st region mozillacustom2 custom2 mozillahomecountryname description notes department departmentNumber ou orgunit mobile cellphone carphone mozillahomestate mozillacustom1 custom1 mozillanickname xmozillanickname mozillaworkurl workurl facsimileTelephoneNumber facsimileTelephoneNumber telephoneNumber mozillahomestreet mozillasecondemail xmozillasecond
email mozillacustom4 custom4 nsaimid nscpaimscreenname street street postOfficeBox l l homePhone displayName cn cn givenName mozillahomepostalcode mozillahomelocalityname mozillacustom3 custom3 mozillaworkstreet2 mozillausehtmlmail xmozillausehtmlmail mozillahomestreet2 postalCode zip c c pager pagerphone mail sn sn birthyear"

So what has actually changed affects only the Address Book, not email composition. They are now asking for different attributes (they dropped some and added others) and changed the search filter from:

(|(mail=*Brendan Bellina*)(cn=*Brendan Bellina*)(givenName=*Brendan Bellina*)(sn=*Brendan Bellina*))
to:
(|(mail=*Brendan Bellina*)(displayName=*Brendan Bellina*)(givenName=*Brendan Bellina*)(sn=*Brendan Bellina*))

So the only difference in the filter is they replaced cn with displayName.  There were no changes to the wildcarding which has apparently always been inconsistent with the email address lookup while composing.

Comment 28

[Dan Mosedale (:dmosedale, :dmose)]

Comment on attachment 212179 [details] [diff] [review]
possible patch to revert the behavior to the way it was for 1.0

Yeah, this reversion does seem to be the way to go.  r=dmose

Comment 29

[Scott MacGregor]

Comment on attachment 212179 [details] [diff] [review]
possible patch to revert the behavior to the way it was for 1.0

I'll land this in the appropriate places.

Comment 30

[Stefan]

(In reply to comment #27)
> (In reply to comment #26)
> > (In reply to comment #11)
==> CUT
> > 
> > I don't know what point you're trying to make,
> 
> My point is that Microsoft and Novell have deviated from standard attribute
> usage.  Products that do not support preferences for these sorts of things
> should follow the standards.

You may be right on AD (it's been a while since I've worked with that but I seem to remember them not being quite up to standard on this) but not on Novell's eDir. Actually, the changes to Thunderbird's search filter cause lookups to fail on eDir as well (that's even how I found this bug, when updating to 1.5 suddenly things stopped working on both eDir and OpenLDAP). I think with the possible exception of iPlanet Edir is currently most standards compliant

> 
> > but if the searchfilter Thunderbird uses contains a CN, everything will work fine.
> 
> Not correct.  The Thunderbird searchfilter makes two mistakes: (1) it excludes
> cn, and (2) it includes displayname.  On directory servers other than Microsoft
> AD and Novell eDirectory, excluding cn will reduce positive hits when searching

On (1), agree. This should never have been excluded. As I said, it causes lookups to fail on Novell as well, because while displayname is available as an attribute it's not used by default. On (2): including an extra search attribute (even if it's one that's maybe not meant for search actions) doesn't hurt IMHO, it might give someone somewhere extra flexibility (e.g. AD users)

> and including displayname will cause unindexed searches and timeouts.
> 
> > What I'm looking for is an overview for the changes between 1.0x and 1.5 which cause lookups to fail...
> 
> Here is a description of what was changed:
> 

Thanks! This is what I was looking for. 

==> CUT

> 
> So the only difference in the filter is they replaced cn with displayName. 
> There were no changes to the wildcarding which has apparently always been
> inconsistent with the email address lookup while composing.
> 

Strange inconsistency though, it actually had us looking elsewhere for a while. Should be corrected too IMHO. 

At least I just saw a status change to resolved on this bug. Scott, am I right in assuming the next release will revert to 1.0x behaviour?

Comment 31

[Scott MacGregor]

(In reply to comment #30)
> 
> At least I just saw a status change to resolved on this bug. Scott, am I right
> in assuming the next release will revert to 1.0x behaviour?
> 

yup! 1.5.0.2

Comment 32

[Brendan Bellina]

(In reply to comment #30)
> (In reply to comment #27)
> > (In reply to comment #26)
> > > (In reply to comment #11)
> ==> CUT
> > > 
> > > I don't know what point you're trying to make,
> > 
> > My point is that Microsoft and Novell have deviated from standard attribute
> > usage.  Products that do not support preferences for these sorts of things
> > should follow the standards.
> 
> You may be right on AD (it's been a while since I've worked with that but I
> seem to remember them not being quite up to standard on this) but not on
> Novell's eDir. Actually, the changes to Thunderbird's search filter cause
> lookups to fail on eDir as well (that's even how I found this bug, when
> updating to 1.5 suddenly things stopped working on both eDir and OpenLDAP). I
> think with the possible exception of iPlanet Edir is currently most standards
> compliant

You may be right.  My knowledge of Novell is second-hand.  When I originally said on another email thread that AD was the only directory I knew of that used cn as a single-valued login id, someone else responded that Novel eDir uses cn this way as well.

> > 
> > > but if the searchfilter Thunderbird uses contains a CN, everything will work fine.
> > 
> > Not correct.  The Thunderbird searchfilter makes two mistakes: (1) it excludes
> > cn, and (2) it includes displayname.  On directory servers other than Microsoft
> > AD and Novell eDirectory, excluding cn will reduce positive hits when searching
> 
> On (1), agree. This should never have been excluded. As I said, it causes
> lookups to fail on Novell as well, because while displayname is available as an
> attribute it's not used by default. On (2): including an extra search attribute
> (even if it's one that's maybe not meant for search actions) doesn't hurt IMHO,
> it might give someone somewhere extra flexibility (e.g. AD users)

The problem is that unindexed searches can walk the directory, slowing the response down, and in a large directory timeout without returning any data.  displayname is an attribute that is part of inetOrgPerson so it is generally defined and often populated, but because it is intended for display it is not usually indexed.  Thunderbird isn't the first to search on displayname though, Microsoft starting doing it a couple of years ago with Outlook.  It isn't appropriate though for a product to force directory admins to modify their configuration for compatibility, even if it is defining an index.
> 
> > and including displayname will cause unindexed searches and timeouts.
> > 
> > 

> > So the only difference in the filter is they replaced cn with displayName. 
> > There were no changes to the wildcarding which has apparently always been
> > inconsistent with the email address lookup while composing.
> > 
> 
> Strange inconsistency though, it actually had us looking elsewhere for a while.
> Should be corrected too IMHO.

I agree.  That would have to be a different bug report though.  And wouldn't be s bug that was introduced in TB 1.5.

Comment 33

[Robert Fleming]

(In reply to comment #31)
> (In reply to comment #30)
> > 
> > At least I just saw a status change to resolved on this bug. Scott, am I right
> > in assuming the next release will revert to 1.0x behaviour?
> > 
> 
> yup! 1.5.0.2
> 

http://www.mozilla.org/projects/thunderbird/specs/ldap.html still reflects the old default.