<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">Dear Working Group,</div><div class=""><div class=""><br class=""></div><div class="">I'd like to propose the following Solution Definition for NWI-11.</div><div class=""><br class=""></div><div class="">Introduction</div><div class=""><br class=""></div><div class="">Currently, the RIPE database supports email addresses encoded in the Latin-1 character set. However an email address can have an Internationalised Domain Name (IDN), with characters outside Latin-1 (i.e. Unicode). This causes interoperability problems as non-ASCII characters in an email address may not be accepted by a mail server, and only a small subset of Unicode characters can be encoded as Latin-1.</div><div class=""><br class=""></div><div class="">Solution Definition</div><div class=""><br class=""></div><div class="">In order to support Internationalised Domain Names (IDN) in an email address in the RIPE database, I propose to automatically encode email addresses in the Punycode format. Punycode (as defined in RFC 3492) is a way to encode strings containing Unicode characters, such as internationalised domain name (IDN) domains, into ASCII. </div><div class=""><br class=""></div><div class="">When updating the RIPE database, it is already possible to submit a Punycode encoded value (i.e. with ASCII encoding) for an email address value, but this change automates the conversion of any non-ASCII encoded email address to Punycode.</div><div class=""><br class=""></div><div class="">This change will only affect attributes with an email address syntax (i.e. abuse-mailbox, e-mail, irt-nfy, mnt-nfy, notify, ref-nfy, upd-to).</div><div class=""><br class=""></div><div class="">Automatic Punycode encoding will only be applied to the domain part of the email address. The local part of the address must only contain ASCII characters. If non-ASCII characters are found in the local part, the address is rejected as invalid.</div><div class=""><br class=""></div><div class="">When querying the RIPE database, any Punycode encoded email address is returned in Punycode (i.e it is not decoded).</div><div class=""><br class=""></div><div class="">I welcome feedback from the community on this proposal.</div><div class=""><br class=""></div><div class="">Regards</div><div class="">Ed Shryane</div><div class="">RIPE NCC</div><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class="">On 22 Jun 2020, at 22:49, ripedenis--- via db-wg <<a href="mailto:db-wg@ripe.net" class="">db-wg@ripe.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><div class="ydp79c1deccyahoo-style-wrap" style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:16px;"><div dir="ltr" data-setdir="false" class="">Colleagues</div><div dir="ltr" data-setdir="false" class=""><br class=""></div><div dir="ltr" data-setdir="false" class="">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<span class=""> Internationalised Domain Names'. We propose a problem statement based on the text provided recently by Leo Vegoda, as shown below.</span></div><div dir="ltr" data-setdir="false" class=""><span class=""><br class=""></span></div><div dir="ltr" data-setdir="false" class=""><span class="">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.</span></div><div dir="ltr" data-setdir="false" class=""><span class=""><br class=""></span></div><div dir="ltr" data-setdir="false" class="">cheers</div><div dir="ltr" data-setdir="false" class="">denis</div><div dir="ltr" data-setdir="false" class=""><br class=""></div><div dir="ltr" data-setdir="false" class="">co-chair DB-WG</div><div dir="ltr" data-setdir="false" class=""><br class=""></div><div dir="ltr" data-setdir="false" class=""><br class=""></div><div dir="ltr" data-setdir="false" class="">Problem Statement</div><div dir="ltr" data-setdir="false" class=""><br class=""></div><div dir="ltr" data-setdir="false" class=""><div class=""><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div></div><br class=""></div></div></div></div></blockquote></div><br class=""></div></body></html>