[Freeipa-devel] Internationalized domain names in freeIPA

[Martin Kosek]

On 11/07/2013 01:59 PM, Petr Viktorin wrote:
> On 11/05/2013 06:08 PM, John Dennis wrote:
>> On 11/05/2013 12:04 PM, Petr Viktorin wrote:
>>> On 11/05/2013 05:53 PM, John Dennis wrote:
>>>> On 11/05/2013 11:13 AM, Martin Basti wrote:
>>>>> Hi list,
>>>>>
>>>>> I'm working on ticket: https://fedorahosted.org/freeipa/ticket/3169
>>>>> UTF-8 DNS names will be converted to punycode ASCII string and stored
>>>>>
>>>>> But there is a question, how to show DNS names to user (in UI or
>>>>> dnsrecord-show/find):
>>>>> * show them in punycode
>>>>> * convert them to UTF-8 and show
>>>>> * both ways
>>>>> * add options to show them in UTF-8
>>>>>
>>>>> I'll be thankful for your opinion.
>>>>>
>>>>
>>>> We have a rule that all strings use UCS and that UCS be interchanged by
>>>> encoding UCS text in UTF-8. Therefore it seems to me the only time
>>>> punycode should ever exist is when it's necessary to encode/decode
>>>> punycode for dns operations. Since punycode is a standard Python codec
>>>> this should be trivial, you just need to determine where you do the
>>>> encode/decode (perhaps also validating user input can be successfully
>>>> encoded).
>>>
>>> In LDAP the values need to be in punycode, so bind-dyndb-ldap can
>>> process them.
>>
>> This suggests the LDAP type conversion is the right location for
>> encode/decode.
>>
>>> IMO all layers above that -- API, CLI, WebUI -- should use Unicode,
>>> except with the `--raw` flag.
> 
> The reason for this is that UTF-8 isn't as canonical a represenation of
> Punicode as, say, a DN object for DNs or a bool for boolean values. Admins
> might reasonably want to see the raw value.
> 
> Also, these values end up in DNs; I fear converting them at the LDAP wrapper
> level could open a can of worms. Do we have resources to give this the testing
> it needs?
> 
> I think converting them in the DNS plugin is the way to go.
> 

Just to clarify the terms here: DNS plugin === dns.py plugin in FreeIPA, not
bind-dyndb-ldap.

Martin