Re: Netscape Roaming Profile for OpenLDAP v2

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

At 01:18 AM 9/9/00 +0200, Hugo.van.der.Kooij@caiw.nl wrote:
>Testing seems to be fine but I noticed that all examples show clear text
>with nsLIData where I have some encoded (and hence not readable by humans)
>datablok.

The examples you have seen may have used LDIF's base64 encoding
mechanism.  OpenLDAP tools will automatically switch to this format
when needed for output (and always accepts it on input).  Likely
looks like:

nsLIData:: Base64Data==

>The old definition (for OpenLDAP 1.2) used 'bin' and the new (OpenLDAP
>2.x) definition uses  1.3.6.1.4.1.1466.115.121.1.5 for this data.

1.3.6.1.4.1.1466.115.121.1.5 is LDAPv3 'binary' which implies the value
should be described by ASN.1 and encoded using the Basic Encoding
Rules (see RFC 2252).

The OpenLDAP 'bin' syntax can be any value of zero or more octets
(bytes).  Basically, anything of old 'bin' syntax is a BLOB.  It
was used to hold values of any syntax (including audio, jpeg,
binary, octetString, certificates, etc).  I would be surprised
if the values of this attribute are BER encoded.  However, if
this is was Netscape publishes as the syntax, this is the syntax.

When converting schema definitions from LDAPv2 to LDAPv3, it's
best to go back to what the actual LDAPv2 syntax was.  That is,
the OpenLDAP 1.x 'bin' is quite meaningless.  It does not say
anything about the syntax of the values.  It says 'treat values
as BLOBS'.  In OpenLDAP 2.0, every value as a syntax.  Though
many syntaxes are treated as BLOBS, an appropriate syntax must
be assigned.

>Willit be safe remove the data and use another type instead?

Safe in what respect?  corruption of the database?  Likely not.
I certainly would not make such changes on a production system.

>Or is there another reason for apparently different content?

One first has to determine if the content is actually different
or whether it's just a presentation issue.  If different, then
it could be any number of issues.