[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: [ldapext] UTF-8 full support in LDIF / LDIF v2

Yves Dorfsman wrote:
> Kurt Zeilenga wrote:
>> Adding UTF-8 support does appear to be in support of improving LDIF as
>> a proper interchange format.  It seems to be driven by other goals,
>> such as trying to make LDIF files displayable.   
> 
> Yes and no. My main reason for pushing this is diffing. You run into a
> problem and you want to diff the original and the problematic LDIF
> export of your directory.

Sorry, but this is a very bad use-case. Given the fact that there are
decent LDIF modules for various programming languages you can implement
a robust delta-generation of LDIF data. Doing that with line-oriented
text tools is bad practice anyway!

> If you are right, that LDIF is purely for exchanging information
> between applications, never to be looked at by humans, then why is
> the current version so human friendly ?

Most parts of LDIF data is human-readable because most data is ASCII and
most consoles or other apps do not have problems displaying ASCII. This
does not say anything about whether to lift the ASCII restriction or not.

>> I'm not convinced that removing the ASCII restrictions will be a good
>> thing.  Not only do I doubt it will have a net positive on
>> displayability of LDIF for those who have a displayability goal (I
>> don't this goal), I think it will have a net negative impact on
>> interoperability and user confusion, such as when the user creates a
>> file using one Unicode normalization algorithm, but is trying to set
>> values which require a different Unicode normalization value.
> 
> How so ?
> In the current version, you have to encode your Unicode to UTF-8, and
> then encode it again to base64. With my proposal, you would get the
> exact same UTF-8 strings as you do today, but they would not be (or
> would not have to be) encoded in base64.

I agree with Yves here.

> So really this is the issue, should the value of the line separator be
> part of the data, or should everybody (LDIF importers/exporters, LDAP
> servers, LDAP clients) treat multi-line entries as just that, several
> lines, and choose their own line separator ?

Line separators for the attribute value itself is subject of the LDAP
syntax, isn't it? So if e.g. the LDAP syntax DirectoryString allows a
line separator (don't know) it has to be distinguished from the line
separator used for LDIF line folding.

Ciao, Michael.
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext