Proposal: A possibly feasible method to invent OIDs for incomplete entries

[Julio Sanchez Fernandez <jsanchez@OpenLDAP.org>]

Well, let me summarize the rationale.  We absolutely *need* to have OIDs
on all schema data that require it and that we publish.  For attribute
types and object classes whare no OID is known, we have several options:

	- Reject them at definition time
	- Not publish them

All these options are hard on administrators and/or clients making use of
the information.  Publishing broken definitions, even if it seems a common
"solution" is really against the standard and may break clients.  We may
be able to parse that ("be liberal") but we cannot inflict it upon others
("be conservative").

The current situation for 2.0 is that compliance is left to the
administrator.  If she wants to have a compliant server, she must find the
needed OIDs or assign them herself.

We may leave it at that.  But maybe we might help.  First, let's see what
are the relevant requirements for assigned OIDs:

	- Must be below a properly delegated point, we might assign a
	  branch below the OpenLDAP OID tree.
	- Must be stable, i.e. a given thing will always have the same OID
	  even after restarting the server with new object classes or
	  attribute types.
	- Ideally, different servers should compute the same number
	  independently.
	- A changed definition should get a new OID.

A method that meets these requirements is hashing on the textual
definition of the thing, then decompose the hash in an appropriate number
of integers (say, 16 for MD5), dot-separate the parts and prepend a fixed
prefix.

The resulting OIDs are ugly as hell, but I'd rather call that a feature.

Opinions?

Julio