At 03:23 AM 2/15/2006, Howard Chu wrote:
It seems this matching rule is rather difficult to use in practice,
with descriptor support, yes.
given that it's supposed to accept textual descriptors in addition to numeric OIDs, but there's no way for apps to know in what context the valid descriptors reside. (See http://www.openldap.org/its/index.cgi/Software%20Bugs?id=4025 for an example of how this affected our password policy implementation, ITS#4402 for another user tripping over it in an arbitrary schema.)
It's difficult to know whether a particular descriptor
unambiguously refers to a particular OID. LDAP has always
allowed an OID to refer to different OIDs in different contexts.
I was thinking that using a new extension like e.g. X-NAMESPACE 'attr' to attribute definitions with this matching rule might help make things less ambiguous. Suggestions?
I'd prefer something like X-OID-CONTEXT than
X-NAMESPACE as the latter is not OID-specific. And as values,
I would spell them out for clarity. That is,
X-OID-CONTEXT 'attributeTypes'
Of course, even descriptors naming a particular kind of object
may be ambiguous, like 'x-foo'. This is why I suggested
'X-OID-CONTEXT' instead of 'X-OID-KIND'. The term context
implies which kind of object is being named, but the source
of the names (for 'attributeTypes', the controlling schema).
Kurt
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/