Re: [ldapext] dc+idn

Kurt D. Zeilenga wrote:
> 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.

Right, but this is no worse than what the client can expect today! Today
the client will se ACE-encoded values in dc and associatedDomain. Those
are perfectly legal domain names. The transfer option simply allows
clients and servers who implement this option to retrieve the
ACE-decoded values. This would naturally depend on feature-negotiation
(via say the root-DSE).

	MVH leifj

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