Re: dump method for binary values

[Chris R. <chr...@me...>]

"Kurt D. Zeilenga" <Ku...@Op...> wrote:
> At 06:13 PM 1/31/01 +0000, Chris Ridd wrote:
>> "Kurt D. Zeilenga" <Ku...@Op...> wrote:
>>> Producing LDIF requires no knowledge of schema.
>> 
>> It does if you have entries obtained via LDAPv2, because you won't know
>> which values need to be converted to UTF-8, which of course LDIF
>> requires.
> 
> An LDIF engine requires no knowledge of schema.  Valid LDIFv1 (for
> LDAPv2 and LDAPv3) can be produce solely by examining the values
> to be represented and then to present those values in one of the
> allowed forms as demonstrated by net::LDAP LDIF's module.

I might be wrong, but I can't see how you can render an LDAPv2 attribute
called say 'foo' with a value containing an arbitrary string of octets,
into LDIF.

If foo is a DirectoryString (or DN or RDN), then the value *must* be UTF-8
(point 7 in the "Notes" section of RFC 2849). But you don't know it's a
DirectoryString/DN/RDN, and if you guessed it was you'd then have to guess
the character set it was encoded in. Given that most LDAPv2 servers get
this completely wrong (no T.61 support), this is a problem. If they use
T.61 correctly then I agree this conversion is possible.

[Aside: there aren't any freely available T.61 <-> anything-else converters
are there?]

If foo isn't a DirectoryString or DN or RDN, then I think you can get away
with 'foo:: <base64 value>'.

So at the very least I think you need to know enough schema to know that
attributes are DirectoryStrings/DNs/RDNs or not, and then have enough faith
in the server's notion of LDAPv2 character sets.

Or have I got this wrong?

> I personally think the entry dump method should just use
> the LDIF module...

Hey, we agree on something! :-)

> Kurt
> 

Cheers,

Chris