Re: UTF-8 full support in LDIF / LDIF v2

Kurt,

Kurt Zeilenga wrote:
> 
> On Jun 16, 2009, at 4:54 PM, Steven Legg wrote:
> 
>> Also, X.500 directories already lose something in the translation when 
>> outputting
>> as LDIF.  For example, the choice in a DirectoryString is lost and if 
>> that
>> choice is teletexString then transcoding wipes out the exact octet 
>> encoding.
>> Most of the ad-hoc LDAP string encodings are lossy in some respect.
>> Such changes are tolerable because the resulting value in LDIF is the 
>> same
>> as far as the matching rules are concerned. Unicode normalization of the
>> extended LDIF output is a similar situation.
> 
> 
> The loss you are talking about is inherent in LDAP not LDIF.  That is, 
> LDIF does not lose anything (for the LDAP requests it's design to 
> represent) in translation to/from LDAP.  I don't it is tolerable for an 
> LDAP intermediate format to "lose" LDAP information.

A "here" document mechanism where the UTF-8 character sequence between
the end of the introducer and the beginning of the terminator is the
literal directory attribute value without any modification would satisfy
the no loss requirement. We could always recommend base64 encoding the
entire file to transfer it across the network, or at least treating it as
a binary file, or suggest using LDIFv1 instead for such purposes.

For me, the convenience of being able to easily view, edit or compose the
content in files I'm uploading outweighs the need to be careful about
which text handling tools I use. If others have similar or overlapping
requirements it would be better for us to use the same specification even
if it never becomes a proposed standard RFC.

Would you feel better if we called it the LDAP Data Composition Format(LDCF)
instead of LDIFv2 or Extended LDIF ?

Regards,
Steven

> 
> Unicode normalization of the LDIF will be problematic where the 
> normalization required by the directory is different.   For instance, if 
> the value is expected to be NFD but NFC was applied breakage will occur.
> 
> -- Kurt
> 
> _______________________________________________
> Ldapext mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ldapext