Colleagues
There has been some discussion recently and many times over the years about 
addressing this issue. The chairs believe there has been enough support shown 
to move forward with this. We would therefore like to present this as 'NWI-11 
Internationalised Domain Names'. We propose a problem statement based on the 
text provided recently by Leo Vegoda, as shown below.
The RIPE NCC has a proposal for a solution to this problem using punycode. We 
would like to ask the RIPE NCC to present this proposal to the working group. 
If anyone has any other proposals for a solution, we welcome a discussion on 
this matter.
cheersdenis
co-chair DB-WG

Problem Statement
The RIPE NCC service region includes countries whose language is not written 
using Latin script. Many of the languages used in the RIPE NCC service region 
are written in Latin script but use diacritical marks that fall outside the 
US-ASCII character set. Internationalized Domain Names (IDNs) support the use 
of these scripts in DNS.
ICANN began delegating IDN Top-Level Domains as part of a test program in 2007 
and the IETF updated the IDNA protocol in 2008 and as of mid 2020, there were 
over 160 IDN TLDs in the root zone.
The IETF published eight standards track RFCs on using IDNs in e-mail in 2012 
and 2013. It is reasonable that organizations communicating with people whose 
preferred script is not Latin-based would want to use an IDN domain for e-mail 
as well as a web presence. It is also likely that the registry for an IDN TLD 
would want to use that TLD for its e-mail addresses.
RFC 3912 explicitly notes that the WHOIS protocol has not been 
internationalized while recognizing that some servers attempt to do so. RDAP 
has been deployed by the RIPE NCC and explicitly supports internationalization 
by UTF-8 encoding all queries and responses.
The RIPE community could decide to ignore EAI by trying to require 
organizations to deploy a secondary e-mail address for use in the RIPE 
Database. This would reduce the effectiveness of the RIPE Database as the 
secondary address is less likely to be monitored and used, and so be 
ineffective.

Reply via email to