[389-users] Outlook VLV index and western europe diacritics

[Rich Megginson]

Andrey Ivanov wrote:
> Hi,
>
> I  am  testing  the  389 latest git version. There is one thing i have
> noticed  concerning Outlook browsing of LDAP and VLV indexes. Though i
> think  the  change  has  happened already some time ago, in one of the
> previous versions.
>   
Can you confirm the last version that this worked in?  I suspect this 
had something to do with my matching rule changes in 1.2.6.  The goal is 
that it should work the same way as before, so this is definitely a bug.
> To make the LDAP Outlook browsing work correctly i've always used the steps described in the
> doc
> (http://www.redhat.com/docs/manuals/dir-server/8.2/admin/html/Creating_Indexes-Creating_VLV_Indexes.html)
> :
>
> dn: cn=Outlook Browse,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
> cn: Outlook Browse
> objectClass: top
> objectClass: vlvsearch
> vlvBase: ou=Utilisateurs,dc=id,dc=polytechnique,dc=edu
> vlvFilter: (&(mail=*)(cn=*))
> vlvScope: 2
>
>
> dn: cn=Outlook Browse Index,cn=Outlook Browse,cn=userRoot,cn=ldbm database,cn=
>  plugins,cn=config
> cn: Outlook Browse Index
> objectClass: top
> objectClass: vlvindex
> vlvEnabled: 1
> vlvSort: cn
>
>
>
> This  creates a VLV index, sorts  the  entries  by  cn  and  shows  them in Outlook :
> [24/Aug/2010:16:42:19 +0200] conn=24 op=2 SRCH base="ou=utilisateurs,dc=id,dc=polytechnique,dc=edu" scope=2 filter="(&(mail=*)(cn=*))" attrs="cn cn mail roleOccupant display-name displayName sn sn co o o givenName legacyexchangedn objectClass uid mailnickname title company physicalDeliveryOfficeName telephoneNumber"
> [24/Aug/2010:16:42:19 +0200] conn=24 op=2 SORT cn 
> [24/Aug/2010:16:42:19 +0200] conn=24 op=2 VLV 0:0:xac 7860:8001 (0)
> [24/Aug/2010:16:42:19 +0200] conn=24 op=2 RESULT err=0 tag=101 nentries=1 etime=0.009000
> [24/Aug/2010:16:42:19 +0200] conn=24 op=3 SRCH base="ou=utilisateurs,dc=id,dc=polytechnique,dc=edu" scope=2 filter="(&(mail=*)(cn=*))" attrs="cn cn mail roleOccupant display-name displayName sn sn co o o givenName legacyexchangedn objectClass uid mailnickname title company physicalDeliveryOfficeName telephoneNumber"
> [24/Aug/2010:16:42:19 +0200] conn=24 op=3 SORT cn 
> [24/Aug/2010:16:42:19 +0200] conn=24 op=3 VLV 0:27:7859:8001 7860:8001 (0)
> [24/Aug/2010:16:42:19 +0200] conn=24 op=3 RESULT err=0 tag=101 nentries=28 etime=0.019000
>
>
>
> In  (relatively  old) previous versions of the server the sorting took
> into  account  the  accentuated letters (like é, for example). The CNs
> with  these  letters  were  sorted  correctly  (that is, é after d and
> before f). So the entries were sorted by VLV like this :
>
> ...
> Tdo Not
> Ten Toys
> Tén Toys   <<<--
> Tfk Nev
> Tgl Mu
> ...
> Tzzz Too
> Uart New
> ...
>
> With the recent versions the server orders the CN strictly according to ASCII
> (i think) :
>
> ...
> Tdo Not
> Ten Toys
> Tfk Nev
> Tgl Mu
> ...
> Tzzz Too
> Tén Toys    <<<--
> Uart New
> ...
>
>
> That is, all the diacritical letters appear after "z".
>
> I have looked into the vlv#outlookbrowseindex.db4 file by dbscan and
> the order corresponds exactly to what Outlook shows.
>
> The questions are :
> -whether it is how it should work and
> -how do i revert to the old server behavior.
>
>
> The  sorting  with  collation  (that is, smth like
> my $sort_control = Net::LDAP::Control::Sort -> new( order => "cn:2.16.840.1.113730.3.3.2.18.1.6", critical => 1)
> ) works perfectly (i.e. é is after d and before f).
>
> I've tried several ideas to return to the old behavior :
>
> *)  i've tried to add collation rules to vlv index entries but putting
> the       value       of       the      attribute      vlvSort      to
> "cn:2.16.840.1.113730.3.3.2.18.1.6"   or  to  "cn:fr"  does  not  work
> either. Instead of changing the sorting order it produces some strange
> contents in the index vlv#outlookbrowseindex.db4 file.
>
>
> **)  then  i  thought that maybe i should change the cn index ordering
> and i have added "nsMatchingRule: 2.16.840.1.113730.3.3.2.18.1" to the
> cn  indexes  in  dse.ldif. However reindexing does not actually change
> the  order  (even  after  reindexing by smth explicit like db2index -n
> userRoot -t cn:eq,pres,sub:2.16.840.1.113730.3.3.2.18.1 ) in the index
> .db4 files.
>
>
> Any ideas/suggestions?
>
>
> Andrey Ivanov
> tel +33-(0)1-69-33-99-24
> fax +33-(0)1-69-33-99-55
>
> Direction des Systemes d'Information
> Ecole Polytechnique
> 91128 Palaiseau CEDEX
> France
>
> --
> 389 users mailing list
> 389-users at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>