A vital part in the design and definition of directory services is the definition of the data model or schema, which consists of the definition of object classes, attributetypes, attribute syntaxes and matching rules. Due to the fact that there is no reliable registry where to find allready defined schema, there is a considerable amount of effort doubling also in the academic community. The wheel so to speak is being invented again and again. Another negative result of this is that duplicate schema names can have different definition structures, which might confuse applications that don't use the OIDs assigned to scheme elements. Not only in the academic realm this problem exists, the commercial world has the same problems.
LDAP Schema definitions exist for a large number of different subjects, e.g. white and yellow pages services, Authorization and authentication, video conferencing, computing ressources, printer, policy, etc. etc.
There had been several attempts to provide a solution for these problems. One was the IETF WG called schema that among other workdefined MIME types for exchanging information about schema (RFC 2927). The Open Group intended to run a registry based on this technology, but was not able to find the respective funding. The funding searched for was half a person per year. After this failed there was a so called grass root approach from an individual in Hong Kong (see http://ldap.akbkhome.com) where a number of schema definitions were made available and a web formular to add comments. Unfortunately this work has ceased due to jobswitch. After contacting the person, he showed his willingness to co-operate in future attempts.
Another activity that can be mentioned here is the OID-Registry of Harald Alvestrand at http://www.alvestrand.no/objectid. Being a registry for all OIDs, not only for LDAP schema elements, it has a broader scope and the registry is not complete and is dependent on submissions from interested user.
What still is missing is an up to date registry of LDAP schema elements, which also contains metadata about the defined schema to make it easily searchable and which provides an interface for schema definitions made using the MIME type defined in RFC 2927. This proposed project wants to fill this gap.
Set up a LDAP schema registry, with an easy browsable and searchable Web interface, as well as an interface based on MIME types defined in RFC 2927 for sumissions of new schema. Search for all schema definitions made in Standard bodies like the IETF and include them into the registry. Develope a business model to keep the registry alive after the end of the project.
| Deliverable | Description | In charge | Starting month | Ending month | Kind of deliverable |
| A | Website | DAASI | 1 | 12 | Website |
| B | Survey of previous work | DAASI | 1 | 2 | Report |
| C | Definition of a metadata format | DAASI | 3 | 4 | Document |
| D | Policy definition | DAASI | 3 | 4 | Document |
| E | Design of the software | DAASI | 4 | 5 | Specification |
| F | Implementation of search and browse interface | DAASI | 5 | 7 | Software |
| G | Implementation of the MIME interface | DAASI | 7 | 8 | Software |
| H | Inclusion of schema | DAASI | 8 | 10 | Report |
| I | Promotion | DAASI | 7 | 12 | Travel reports and presentations |
| J | Business model | DAASI | 11 | 12 | Document |
| K | Final report | DAASI | 12 | 12 | Report |
| Phase | Description | deliverables | Finished by month |
| 1 | finish design phase | B, C, D, E | 5 |
| 2 | Finish software | F and G | 8 |
| 3 | Include data and registry online | H | 10 |
| 4 | Final report | K | 12 |
A bi-monthly progress report will be produced. This report will be accessible via the project web page. TERENA will provide a template for this report.
A TERENA Technical Report will be produced with an evaluation of the registry. DAASI will deliver the contents of this report while TERENA takes care of the marking up.
The draft versions of the deliverables will be discussed on the several Mailinglists.
The result of this project will help everyone who wants to deploy a directory service and is in need to find appropriate schema definitions. It might happen that after the evaluation of the registry and the business plan additional implementation work will be neccessary. In this case a follow on project will be applied for.