[turba] First shot at a new ldap schema.

[Adam Tauno Williams]

>I'm attaching a first shot at a new schema for ldap.  Would those
>who are using ldap take a look please because I'm pretty sure that I
>don't know what I'm doing:-).  I'll list a couple of my concerns.
>There are currently 35 dynamically generated prefs by the make_schema.php
>script taking OID values from  1.3.6.1.4.1.13040.1.2.4.1 to 
>1.3.6.1.4.1.13040.1.2.4.35  

Great.

>I started a new sequence with 201 for pgppublickey - 202 for smimepublickey 
>these have a SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{1024} that I think is
>UTF8. 

Are you sure there isn't a defined attribute for pgp public keys?  I'll do a
little research on this one.

>Does that sound right or should it be binary?  EQUALITY is caseIgnoreMatch
>- 203 is assigned for turbaMembers and 204 is for turbaType.  If the OID
>  sequence is ok they should be ok.
>- I added 205 for freeBusyUrl.  I set it up as ascii string (26) and 
>  caseIgnoreIA5Match.  I've never used this.  I assume that it is for
>  meetings.  Amith is this working for you?

We shouldn't recreate schema from rfc2739.  Many large LDAP sites will already
have this schema loaded as it is used by some popular applications.

It appears that caseIgnoreIA5Match is what is commonly used although there has
been some debate about this since URL's can contain non-UTF8 characters.  As of
RFC2181 DNS names may be any binary value (really good for asian languages,
etc..).  But there really hasn't been any consensus how to resolve that issue.

We can certainly include it in horde (as rfc2739.schema),  but it shouldn't be
enabled by default.  We could even put it in horde.schema but commented out. 
Then have people who want to acquire this schema from Horde rather than a public
schema repository can do so. I don't know what the easiest solution would be.

>Please let me know what changes should be made and how we might want to
>maintain this in the future as new applications are added.  

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

>Thanks Amith for getting this rolling and Adam for his guidance and
>his awesome 400+ page ldap3.pdf.

Your welcome.  (And the next version tops 500 pages :)

Adam Tauno Williams
Network & Systems Administrator
Morrison Industries
Grand Rapids, Mi. USA