Hi there,

I found this thread:
http://www.openldap.org/lists/openldap-software/200010/msg00794.html

But it is dated 12 years ago, so I imagine it will be a little bit
outdated. Also it claims to be a bug in version 2.0.x while I am using 2.4
in RHEL6.

Then some discussions about how to implement some zero-length options back
in 2002 and 2004. So it doesn't seem pretty confusing to me. I still don't
know if it is possible to have zero-length strings attributes in OpenLDAP
and how.

When you mean my software is broken which one do you mean? My installation
of OpenLDAP or the software using OpenLDAP.

For the record the attribute definition is:

attributeTypes: ( 1.3.6.1.4.1.42.2.27.999.1.99.6 NAME ( 'securityQuestion'
) DESC 'Attribute to store the securityQuestion' EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'User Defined' )
  *.1.15 == ldap string

Thanks in advance.

On 10 October 2012 01:02, Howard Chu <[email protected]> wrote:

> Emilio García wrote:
>
>> Dear all,
>>
>> Is there a way to define a string to be empty in OpenLDAP Schema? I read
>> that
>> RFC 2252 doesnt allow empty strings. But is there any workaround for this
>> like
>> a different SYNTAX or attribute type? We have a preexisting software which
>> tries to write empty strings and it is crashing because of this.
>>
>
> google site:www.openldap.org zero-length strings
>
> This has been hashed out numerous times. Your software is broken.
> --
>   -- Howard Chu
>   CTO, Symas Corp.           http://www.symas.com
>   Director, Highland Sun     http://highlandsun.com/hyc/
>   Chief Architect, OpenLDAP  
> http://www.openldap.org/**project/<http://www.openldap.org/project/>
>

Cloudreach Limited is a limited company registered in England with registered 
number 06975407

The above terms reflect a potential business arrangement, are provided solely 
as a basis for further discussion, 
and are not intended to be and do not constitute a legally binding obligation. 
No legally binding obligations 
will be created, implied, or inferred until an agreement in final form is 
executed in writing by all parties involved.

This email may be confidential or privileged. If you received this 
communication by mistake, please don't forward 
it to anyone else, please erase all copies and attachments, and please let us 
know that it has gone to the wrong person.

Reply via email to