Re: dump method for binary values

[Kurt D. Z. <Ku...@Op...>]

I believe that the RFC could stand some clarification.  It's
only LDIFv1, only a Proposed Standard.  So that's to be expected.

One thing I do note, that in the context of RFC 2849, LDAP
is LDAPv3 [RFC2251].  LDIFv1 use with LDAPv2 can be (and probably
should be) viewed as an unspecified extension.

At 03:48 PM 2/1/01 +0000, Chris Ridd wrote:
>I guess this also means that an LDIF file saved using an LDAPv2 entry can
>only then be *safely* loaded back over an LDAPv2 connection?

Yes, LDIF does not address protocol version differences.  LDAPv2
is LDAPv2, LDAPv3 is LDAPv3, mixing is dangerous.  I wrote an
I-D detailing some of the version differences you might be
interested in reading draft-zeilenga-ldapbis-vd-00.txt [which
I mean to revise shortly].  I should add something about LDIF issues
to this I-D...

>> Note: In regards to DNs, the LDIF comment only applies to the
>> "dn:".  Please note that both versions of the protocol restricts
>> LDAPDN to a subsets of UTF-8.  In particular, LDAPv2 restricts
>
>I don't see where the RFC imposes *that* restriction.

Most folks miss this one, but...

   The LDAPString is a notational convenience to indicate that, although
   strings of LDAPString type encode as OCTET STRING types, the legal
   character set in such strings is limited to the IA5 character set.

     LDAPDN ::= LDAPString

Many implementations are quite liberal in what they accept...

>So I recant. You're right, however the LDIF reader has to pretty careful
>accepting LDIF files produced from LDAPv2 UAs.

By reader, I assume you mean "a human reader" and not an LDIF parser.
An LDIF parser should have be stupid, a human dealing with applications
using different protocols needs to quite smart (or quite dumb :-).

Kurt