[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#4402) attribute name is not recognized



>==================================
>adding new entry "cn=myObj"
>ldap_add: Invalid syntax (21)
>        additional info: myAttr: value #0 invalid per syntax
>==================================

This is not viewed as a bug in OpenLDAP Software.
draft-ietf-ldapbis-models (an approved Standard Track RFC-to-be):
  While the <descr> form is generally preferred when the usage is
  restricted to short names referring to object identifiers which
  identify like kinds of objects (e.g., attribute type descriptions,
  matching rule descriptions, object class descriptions), the
  <numericoid> form should be used when the object identifiers may
  identify multiple kinds of objects or when an unambiguous short name
  (descriptor) is not available.
  
  Implementations SHOULD treat short names (descriptors) used in an     
  ambiguous manner (as discussed above) as unrecognized.

Use of 'userPassword' here is ambiguous as could
easily be a 'userPassword' descriptor that refers to an
OID other than 2.5.4.35.  For instance, there could be
a object class named 'userPassword'.

While you may have intended values of myAttr only refer to
attribute types, there is no way to advise implementations
of this intent through the schema.   Hence, descriptors only
work in operational or built-in attributes.

I note that language of the revised LDAP specification would
allow us to accept descriptors where we believe are not
ambiguous.  Hence, this ITS could be viewed as a feature request.
Of course, it is quite unclear how slapd(8) can know that
a particular descriptor is unambiguous.

Kurt

>It seems that the attribute name is not recognized
>(I made some research on google and that was the meaning 
>of the error).
>So, i tried with the real oid, so the following LDIF content :
>
>==================================
>file test2.ldif
>=================================
>dn:cn=myObj
>objectClass:myClass
>cn:myObj
>myAttr: 2.5.4.35
>==================================
>
>and this time, it works fine.
>
>Any idea on this strange behavior ?
>Regards.