Re: Migrating from iPlanet, 'binary' issues

["Lon Tierney" <ltierney@mykungfuisthebest.net>]

Thanks Kurt. Please see my comments and questions below:

> IIRC, some attributes of "binary" syntax require ;binary, some
> require it be absent.  OpenLDAP can only handle those which
> require ;binary to be absent for all attribute types of the binary
> syntax.

Not familiar with "IIRC" acronym, but I think I understand your comment
to mean that OpenLDAP has been hard-coded to know that attributes with
syntax 1.3.6.1.4.1.1466.115.121.1.5 can not be transfered via the
";binary" transfer method. Please correct if I am mistaken.

Is there a way in the schema that I can specify it is required or not?
Can I turn off syntax checking, or do I have to disable schema checking
all together?

>  One can easily hack the server so that it only supports
> those which require it to be present for all attribute types of the
> binary syntax (by adding a flag to indicate the syntax
> requires ;binary).

My goal is to allow the developers (you and friends) to maintain the
software, and (hopefuly) use the product as it is provided. I really
don't want to hack anything - rather use it as it is intended.

>>Apparently this does not work with
>>OpenLDAP 2.x? (Many items in iPlanet default schema are "binary"
>>syntax, which are not so in OpenLDAP, like userCertificate)
>
> userCertificate, as defined in RFC 2256, has certificate syntax
> but is requested and transferred with the ;binary transfer option.

Indeed, but that does not change the fact that iPlanet chose syntax
1.3.6.1.4.1.1466.115.121.1.5 (really, they did) in their schema.

> (Don't confuse binary syntax with the ;binary transfer option.)

I'm not, I don't think. Just to be sure I will use the full syntax number
from here on versus the word "binary".

>>To remedy this issue I tried to follow the suggestion in the admin
>>guide (section 8.2.4.2) and hacked my current schema to make it an
>>Octet String (1.3.6.1.4.1.1466.115.121.1.40) thinking this would allow
>>me to use the ";binary" option - no luck here either.
>
> I note that no where in the admin guide does it suggest that
> you "hack" provided schema.

Indeed it does not, and I am not hacking provided schema. I am hacking my
own schema that I modled from iPlanet's schema. My assumption from your
response is that section 8.2.4.2 is missleading to me because the use of
syntax 1.3.6.1.4.1.1466.115.121.1.40 and the suggestion that "you could
.... describe the value using ASN.1 and use the ;binary transfer option"
are not related, and in fact will not/don't work.

>>2) what syntaxes OpenLDAP cares about
>
> Generally, OpenLDAP only supports ;binary were the syntax doesn't have
> a native LDAP string encoding.  The binary syntax does
> have a native LDAP string encoding and is used with a number of
> attribute types.  Hence, the current flags for the binary
> syntax doesn't require (or allow) use of the ;binary option.

Is there a list of the other syntaxes that do not allow, or require the
";binary" transfer option? Or is there a list of which syntax has a
native LDAP string encoding?
Obviously I am ignorant about what "LDAP string encoding" is, most likely
from my years of using iPlanet which stores and returns exactly what you
give it. Is there some pointer that you can give me so that I can read up
on this so as to ask more intelligent questions?

Thanks for your help,
-lon