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

Yves,

Yves Dorfsman wrote:
[snip]
> Listing the case we have so far (please argument against if you think a 
> case is not valid):
> 
> -comparing at the file level by humans, to fix an issue for example ; 
> this imply that the user is using a display properly setup for UTF-8 
> (Yves Dorfsman).
> 
> -simplifying scripts to import/export data form/to other format to/from 
> LDIF (Steven Legg. Steven).
> 
> -simplifying online editors (Michael Stöder).
> 
> 
> 
> 
> Steven:
> Can you confirm this is what you were saying, otherwise reword ?

That is my main use case, including where some of the composition is done
by hand.

For the record, although XML documents can be more or less arbitrary UTF-8
character strings, most of the ones I deal with are pure ASCII. It is just
the line separators that require me to base64 encode such documents when
storing them as directory attribute values through LDIFv1.

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.

Regards,
Steven
_______________________________________________
Ldapext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ldapext