[Date Prev][Date Next]
Re: Migrating from iPlanet, 'binary' issues
At 04:52 PM 2002-12-04, Lon Tierney wrote:
>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
>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 184.108.40.206.4.1.14220.127.116.11.5 can not be transfered via the
>";binary" transfer method.
>Is there a way in the schema that I can specify it is required or not?
Assuming you mean the loadable schema, no. It's specified as
a flag to the built-in schema. That is, the specification of
the binary syntax in schema_init.c provides this requirement.
>Can I turn off syntax checking, or do I have to disable schema checking
No and no.
>> 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.
I intended OpenLDAP to be hacked. :-)
>>>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
>18.104.22.168.4.1.1422.214.171.124.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".
Qualifying it as "binary syntax" or the ;binary transfer option is
generally sufficient. What confuses must folks is that, for both,
binary does not imply "an arbitrary sequence of binary values".
The binary syntax should have been called the ANY syntax (referring
to any ASN.1 data type) and the ;binary transfer option should have been
called the ;ber (for Basic Encoding Rules) transfer option. Oh
>>>To remedy this issue I tried to follow the suggestion in the admin
>>>guide (section 126.96.36.199) and hacked my current schema to make it an
>>>Octet String (188.8.131.52.4.1.14184.108.40.206.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 220.127.116.11 is missleading to me because the use of
>syntax 18.104.22.168.4.1.1422.214.171.124.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.
Likely that could be better worded... or the "describe..." bit
deleted (as implementing new syntaxes requires adding code).
>>>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?
Yes, in schema_init.c, everything marked SLAP_SYNTAX_BINARY requires
;binary to be present and every which isn't so marked requires ;binary
to be absent.
>Or is there a list of which syntax has a native LDAP string encoding?
In OpenLDAP, everything marked SLAP_SYNTAX_BINARY doesn't (yet on the
standard track) have 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?
RFC 2251 & 2252... but, I note, the relevant text has been known to
confuse experienced LDAP'ers.
>Thanks for your help,