Re: [ldapext] objectIdentifierMatch

[Steven Legg <steven.legg@eb2bcom.com>]

Kurt,

Kurt D. Zeilenga wrote:
> I note that in some cases OID and objectIdentifierMatch are
> used where it would be more appropriate for the syntax/matching
> rules for attribute descriptions to be used.  Attribute
> descriptions allow language and other tags to be specified.
>
> Unforunately, matching rules commonly used for attribute
> descriptions do not deal with ambiguity in naming of attribute
> types (cn v commonName v 2.5.4.3) as well as ambiguity
> caused by ordering of attribute options.
>
> So, we might consider designing robust 'attribute description'
> syntax and matching rules

I support this. I can't stuff an LDAP attribute description into
an OBJECT IDENTIFIER in X.500, so "attribute description" needs to
be a distinct syntax for LDAP/X.500 alignment. My preference would
be for the underlying ASN.1 type of such a syntax to be the same
as the AttributeDescription type I have defined for XLDAP, i.e.

  AttributeDescription ::= SEQUENCE {
       type        ATTRIBUTE.&id({SupportedAttributes}),
       options     SEQUENCE SIZE (1..MAX) OF
                        option UTF8String OPTIONAL }

even if the LDAP-specific encoding is defined to be the ABNF
for AttributeDescription from RFC 2251.

Regards,
Steven

> (instead of or in addition to
> an attribute type schema description extension).
>
> Kurt
>
> At 11:08 AM 2/15/2006, Kurt D. Zeilenga wrote:
>
> > 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/
> > >
> > > _______________________________________________
> > > Ldapext mailing list
> > > Ldapext@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/ldapext
> >
> >
> > _______________________________________________
> > Ldapext mailing list
> > Ldapext@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ldapext
>
>
>
> _______________________________________________
> Ldapext mailing list
> Ldapext@ietf.org
> https://www1.ietf.org/mailman/listinfo/ldapext

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext