As we need to modify the whole schema to fix a typo (188.8.131.52.4.1.18060 instead of 184.108.40.206.4.1.18060) ..., this seems to be the best moment to modify these numbers :)
I was just talking to Emmanuel on IRC and he had a good idea regarding
OID assignments. Right now we have the following OID assignment scheme:
220.127.116.11.4.1.18060 is the Apache Enterprise IANA number.
18.104.22.168.4.1.18060.1 is the base for Top Level Projects.
22.214.171.124.4.1.18060.2 is reserved for the Apache infrastructure team.
So Apache Directory is assigned the following base:
Internal to the Directory TLP we are then slitting this to assign a base
to products. ApacheDS has the following OID base:
(Should really have been 126.96.36.199.4.1.18060.1.1.0 but we can fix this)
We partitioned this so we can represent schema entities using the
188.8.131.52.4.1.18060.1.1.1.1 for syntaxes
184.108.40.206.4.1.18060.1.1.1.2 for matchingRules
220.127.116.11.4.1.18060.1.1.1.3 for attributeTypes
18.104.22.168.4.1.18060.1.1.1.4 for objectClasses
22.214.171.124.4.1.18060.1.1.1.5 for dITContentRules
126.96.36.199.4.1.18060.1.1.1.6 for dITStructureRules
188.8.131.52.4.1.18060.1.1.1.7 for matchingRuleUses
184.108.40.206.4.1.18060.1.1.1.8 for nameForms
This is all dandy but we often run into problems assigning schema
elements new OIDs within their own class of identifiers. Basically if I
have to add a new attributeType for the apache.schema file I have to
search both the apachedns.schema and the apache.schema to make sure
there are no conflicts.
This is a bit of a PITA. It would be nice to make sure that scheme
ranges for different schemes are unique so assignments can be isolated
to individual schema files without problems.
So to do this it might be a good idea to create a separate OID base for
each ApacheDS specific schema. So for example we might have the
following as base schema OID's:
220.127.116.11.4.1.18060.1.1.0.0 -> apachemeta.schema
18.104.22.168.4.1.18060.1.1.0.1 -> apache.schema (core apache)
22.214.171.124.4.1.18060.1.1.0.2 -> apachedns.schema
and so on ...
Within each of these schema files we can then divide the OIDs with new
bases for syntaxes, matching rules, etc ...