Re: dump method for binary values

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

"Kurt D. Zeilenga" <Ku...@Op...> wrote:
> At 11:22 AM 2/1/01 +0000, Chris Ridd wrote:
>> Or have I got this wrong?
> 
> Yes. A value presented in LDIF MUST have the same value when
> extracted from LDIF.  Values should not be altered by LDIF
> engines on input or output.  LDIF engines encode values, they
> don't alter values (hence no syntax information is needed).

The 7th "Note" says different:

"7. Distinguished names, relative distinguished names, and attribute values
of DirectoryString syntax must be valid UTF-8 strings. Implementations that
read LDIF may interpret files in which these entities are stored in some
other character set encoding, but implementations must not generate LDIF
content which does not contain valid UTF-8 data."

Note the must not in the last part.

> If the value is presentable directly, without any alteration,
> as a SAFE-STRING form (regardless of the values actual syntax),
> then it may be presented using this form.  Otherwise the
> value is presented in base64 form.

value-spec               = ":" (    FILL 0*1(SAFE-STRING) /
                                 ":" FILL (BASE64-STRING) /
                                 "<" FILL url)
                            ; See notes 7 and 8, below

Hm, I think you're saying that the second form of value-spec doesn't have
to be legal UTF-8 once base64-decoded. That makes sense, as that's how
you'd normally include things like jpegPhotos.

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? That would be
because there are valid LDAPv2 strings that actually use T.61, but are also
valid UTF-8 byte sequences for *different* characters. Hence the comment at
the start of the second sentence of note 7 I suppose.

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

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

Cheers,

Chris