[email protected] a écrit :
Hi,
The attibuteType description is as below. email2 is our application name
we use, but actually while updating the ldap we use the ibm-otherEmail
attribute name
dn:
m-oid=2.16.840.1.113730.3.2.2.1.14,ou=attributeTypes,cn=other,ou=schema
objectClass: metaTop
objectClass: metaAttributeType
objectClass: top
m-collective: FALSE
m-description: user groups
m-equality: caseIgnoreMatch
m-name: ibm-otherEmail
m-nousermodification: FALSE
m-obsolete: FALSE
m-oid: 2.16.840.1.113730.3.2.2.1.14
m-singlevalue: FALSE
m-syntax: 1.3.6.1.4.1.1466.115.121.1.15
The 1.3.6.1.4.1.1466.115.121.1.15 syntax does not allow you to store
null values into the entry, per RFC 4517, 3.3.6 :
"A value of the Directory String syntax is a string of **one** or more
arbitrary characters from the Universal Character Set (UCS) [UCS]. A
zero-length character string is not permitted. The LDAP-specific
encoding of a value of this syntax is the UTF-8 encoding [RFC3629] of
the character string. Such encodings conform to the following ABNF:
DirectoryString = 1*UTF8
The <UTF8> rule is defined in [RFC4512].
Example:
This is a value of Directory String containing #...@.
Servers and clients MUST be prepared to receive arbitrary UCS code
points, including code points outside the range of printable ASCII
and code points not presently assigned to any character.
Attribute type definitions using the Directory String syntax should
not restrict the format of Directory String values, e.g., by
requiring that the character string conforms to specific patterns
described by ABNF. A new syntax should be defined in such cases.
The LDAP definition for the Directory String syntax is:
( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' )..."
You should use another Syntax, like IA5 String
(1.3.6.1.4.1.1466.115.121.1.26) which allows null values.
