[db-wg] NWI-11 Internationalised Domain Names

 Hi Leo
As I have said many times, internationalising the RIPE Database is not a technical issue, it is a registry issue. I think it does need a separate process from the database requirements. Especially if we consider it as a cross registry issue.
Incidentally I did suggest on this mailing list several months ago that the requirements task force considers the issue of UTF-8. No one from the task force has yet replied to me on that or any other comment I have made about the requirements.
cheersdenis
co-chair DB-WG
    On Wednesday, 29 July 2020, 18:20:14 CEST, Leo Vegoda <leo at vegoda.org> wrote:  
 
 Hi,

Thanks for providing the impact analysis for this initial change.

What should the process be for introducing greater support for
internationalization in the RIPE Database? George, Cynthia and others
have made good points about the need to improve internationalization
of more than just e-mail addresses. Is that support something that
should be handled through the process that follows the final report of
the Database TF or does it need to be addressed separately?

Thanks,

Leo

On Wed, Jul 29, 2020 at 8:03 AM Edward Shryane via db-wg <db-wg at ripe.net> wrote:
>
> Dear Colleagues,
>
> Here is the impact analysis for the NWI-11 implementation.
>
> The Database team plans to implement NWI-11 as per the Solution Definition:
> https://www.ripe.net/ripe/mail/archives/db-wg/2020-June/006525.html
>
> (1) Impact to Whois Update
>
> The implementation will automatically apply Punycode encoding (as per RFC 5891) to the domain part of an email address during Whois update.
>
> The encoding is only applied to an IDN domain name, and changes the current behaviour as follows:
> - ASCII encoded values will not be affected (as before).
> - Non-ASCII but latin-1 encoded values will be encoded as Punycode.
> - Non-latin-1 encoded values (e.g. UTF-8) will also be encoded as Punycode. These values previously were transformed to latin-1, with a '?' substitution.
>
> The local part of an email address must only contain ASCII characters. If non-ASCII characters are found in the local part, the address is rejected as invalid.
>
> 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).
>
> If an email address is converted to Punycode, a warning will be included in the update response.
>
> Any Punycode conversion failure will result in the attribute value being rejected as invalid. A workaround in this case is to encode the value before submitting the update.
>
> (2) Impact to Whois Query
>
> When querying the RIPE database, any Punycode encoded email address is returned as-is (i.e it is not decoded).
>
> (3) Impact to Existing Data
>
> We will perform a cleanup to convert any existing non-ASCII (but latin-1 encoded) IDN domain names to Punycode in attributes with an email address syntax. This affects very few objects. The maintainer(s) will be notified by email beforehand.
>
> (4) Impact to Whois Documentation
>
> We will update the database documentation with details of this behaviour change.
>
> (5) Release Timeline
>
> We expect the NWI-11 implementation to take about 1 month (including code changes and testing), and will include the feature in the Whois 1.98 release.
>
> As usual, we will deploy the release to the Release Candidate environment for 2 weeks before production, to allow for testing.
>
> Regards
> Ed Shryane
> RIPE NCC
>
>
>
> On 23 Jul 2020, at 12:00, ripedenis at yahoo.co.uk wrote:
>
> Hi Ed
>
> The chairs see there is a consensus to move forward with implementing Punycode. Can you present an impact analysis explaining what changes you propose, what effect those changes will have on updates and queries (by all the different methods), if anyone needs to modify their software interacting with the database.
>
> cheers
> denis
>
> co-chair DB-WG
>
>  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/db-wg/attachments/20200729/614a8081/attachment.html>