Kurt Zeilenga wrote:

On Dec 21, 2009, at 12:35 PM, Michael Ströder wrote:

...

Kurt@OpenLDAP.org wrote:

...

Yes, it has long been our practice not to publish schema elements which = are not yet well standardized. This would include any element which = carries a OpenLDAP.666 OID.

The idea being that use of such attributes should be limited to early = adopters and such.

Sorry, but this practice is inconsequent.

That's your opinion. My opinion is that we should avoid publishing ''works in progress'' in production systems. Works in progress, by their very nature, are subject to change without notice.

If you'd really like to avoid issues with attributes being falsely handled by the client because the semantics changed you would especially also have to change the attribute type's NAME. Because that's what regular naive LDAP clients look for.

A fully schema-aware client like web2ldap discovers OID changes and handles things correctly. E.g. in web2ldap plugins are preferrably registered by OID (besides some exceptions in case of missing schema descriptions). If the semantics changes and you assign a new OID web2ldap would not naively just treat it the same way. One has to explicitly register a plugin class for the new OID, off course after checking that semantics are the same then. Opposite to that if e.g. the semantics of entryCSN changes and you assign a new OID of a hidden schema description there's no chance to discover that. That's simply bad and therefore I won't follow your arguments at all.

BTW: OpenLDAP also prefers NAME handling over OIDs. So with an OpenLDAP deployment changing the OID of a schema descriptions has no effect. But changing the NAME does.

That's what I think is inconsequent: The current practice does not avoid issues. It only makes things worse.

Ciao, Michael.