[turba] First shot at a new ldap schema.

[eculp at encontacto.net]

Quoting Adam Tauno Williams <adam at morrison-ind.com>:

| >>One might want to consider create a subtree for each application, so that
| >>"team" can create schema without concern about OID collision.
| >>
| >> Like
| >>1.3.6.1.4.1.13040.2.1.* Horde global attributes
| >>1.3.6.1.4.1.13040.2.2.* Horde global objectclasses
| >>1.3.6.1.4.1.13040.3.1.* IMP attributes
| >>1.3.6.1.4.1.13040.3.2.* IMP objectclasses
| >>1.3.6.1.4.1.13040.4.1.* Turba attributes
| >>1.3.6.1.4.1.13040.4.2.* Turba objectclasses
| >>
| >>It is a nice way to share an OID space across projects/divisions
| >That sounds like a good idea to me. If someone can organize the latest
| >revisions into a schema file, I'll look at actually getting something into
| >CVS...
| 
| My attempt is attached.
| 
| I included the new Turba attributes, as well as an auxillary objectclass to
| allow them to be added to existing objects.

Awesome, Adam.  Thanks.  After seeing this I'm going to have to redo
min :-)  

I'm in the process of implementing the new schema[s] while upgrading to 
openldap 2.1.12.  Upon adding the rfc2377.schema, errors are 
generated on the matching and substring rules that I was able to quiet
by changing from 
  EQUALITY caseIgnoreMatch
  SUBSTR caseIgnoreMatch
to
  EQUALITY caseIgnoreIA5Match
  SUBSTR caseIgnoreIA5SubstringsMatch

That solves the immediate problem and it seems to work.  I'm pretty
sure I shouldn't do that but what would be the correct solution?  Has
anyone else runing 2.1.xx seen this problem with the rfc2377 schema?
How did you solve it?

Thanks,

ed

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