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

Re: [ldapext] dc+idn



At 03:44 PM 11/10/2004, Leif Johansson wrote:
>Kurt D. Zeilenga wrote:
>>At 02:31 PM 11/8/2004, Leif Johansson wrote:
>>
>>>Could someone summarize the state of affairs with "internationalized
>>>dc"? It seems to me that there is an urgent need looming here.
>>
>>First, here are some earlier starts on this:
>>  http://www.watersprings.org/pub/id/draft-zeilenga-ldap-idn-04.txt
>>  http://www.watersprings.org/pub/id/draft-hall-ldap-idn-00.txt
>>However, at present, I'm thinking that internationalization
>>of domain components (and like things) is better handled
>>above the directory.... otherwise internationalized
>>and non-internationalized clients will not interoperate
>>properly.
>
>Well that may be so but It occured to me the other day that one way
>to allow the directory to expose idn's to the user is to create a
>transfer option (;idna-decode or something to that effect) which
>would return dc and associatedDomain in the ACE-decoded form. A
>quick read of the application requirements from RFC3490 seems to
>indicate that a transfer option might be constructed that would
>fullfill these requirements.

The problem with this approach is that until the transfer
encoding is widely implemented and deployed, clients could
not rely on its presence.  With the above-the-directory
approach, internationalized clients can be developed and
deployed today need for internationalized support in the
servers.

Kurt


>        MVH leifj
>
>
>_______________________________________________
>Ldapext mailing list
>Ldapext@ietf.org
>https://www1.ietf.org/mailman/listinfo/ldapext


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext