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

Re: T.61 -> Unicode conversion



At 10:04 AM 11/9/2004, Hallvard B Furuseth wrote:
>Kurt D. Zeilenga writes:
>>> Can it happen that a Modify operation contains an UTF-8 value which
>>> according to Appendix A does not match an existing value in the entry,
>>> but which the server stores as a T.61 value which does match an existing
>>> value?
>>
>> I believe [Models] prevents this through its (values must
>> be different, values must be preserved) requirements.
>
>There have been quite a lot of disputes about whether characters in
>different character sets are equivalent or not, though I don't know if
>that applies to T.61->Unicode mapping. I do remember that the meaning
>of some character combinations were redefined for T.61 (not in relation
>to Unicode, I think).  Something about an umlaut-like mark which should
>or shouldn't mean umlaut?
>
>Anyway, implementors who disagreed about this would get different
>results, and maybe different results from the Appendix.

Implementors who follow the Appendix should produce identical
results.

>In particular
>if they have implemented T.61->Unicode(LDAP) first, and add stringprep
>later.

Okay, I think I see what your getting at.  Likely [Syntax]
should say that when a directory string is transcoded to
Unicode for transfer using UTF-8, that transcoding should
be done in a fashion consistent with LDAPprep transcode
step (and hence the appendix).

Kurt