Re: Migrating from iPlanet, "binary" issues

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 01:20 PM 2002-12-04, Lon Tierney wrote:

>I am exploring migrating from iPlanet 4.x to OpenLDAP. The first item is
>a simple compatability check, and I have run into a (seemingly)
>undocumented snag.
>
>When porting our schema from iPlanet to OpenLDAP everything worked OK.
>However, when adding values into the directory I ran into an issue with
>the "binary" syntax (1.3.6.1.4.1.1466.115.121.1.5) and the ";binary"
>transfer option. One of our schema elements is a "binary" syntax that is
>sent with the ";binary" option.

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.  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).

Hacking the server so that presence/absence requirement is per
attribute would be a lot more work...  because encoding requirements
per syntax, not per attribute type.

>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.

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

>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.

>The specific error I get is:
>option "binary" with type not supported; Undefined attribute type

Yes.  We don't support ;binary transfer of octet strings, only
transfer in their native LDAP string encodings.

>I have seen some discussion about a year ago on this topic on the dev
>list, but I fail to see anything in the guides stating what is
>implemented. Can anyone answer the following questions for me:
>1) What are the rules for ";binary" and syntaxes?

The technical specification, technically speaking, allows ;binary
to be used with any syntax but only mandates it use with a few
(namely, the X.509 certificate syntaxes).

>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.

>3) how it treats objects sent to it with the ";binary" option versus ones
>not (for example, the schema says I have to use ";binary" for
>userCertificate to set it - why?

;binary means that values are requested or returned in BER form.
Lack of ;binary means values are requested or returned in their
native LDAP string forms.

OpenLDAP doesn't support conversion between BER and string forms,
so its one or the other (per syntax).

>what do I get if I don't retreive that way?

See above.

>What if I send base64?)

base64 is not used "on-the-wire" (unless the syntax's native
string encoding actually calls for it (few, if any, do)).