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

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

Steven Legg wrote:
> 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.

Steven, like Kurt I cannot see how the loss of the choice in a
DirectoryString stored in a X.500 directory is prevented by the "here"
document mechanism since it's simply already lost when retrieving the
DirectoryString attribute via LDAP. (Well, one might think about
inventing a scheme with attribute sub-types to keep the choice...)

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