Hi Denis, These are good questions. As so many of the answers lie with the RIPE NCC or the NRO, I suppose we need input from them to proceed further.
Kind regards, Leo On Wed, Jul 29, 2020 at 3:47 PM [email protected] <[email protected]> wrote: > > Hi Leo > > Some of the questions that need to be answered include: > > -who needs to be able to read/understand/interpret which parts of the data in > the RIPE Database (maybe both the community and the NCC need input to answer > this)? > -is any of the data contained in the RIPE Database essential for the > operation of the registry and not duplicated anywhere else (maybe the NCC and > the NCC Services WG need input to answer this)? > -is any of the data important to LEAs and governments, is that a > consideration, do they have the resources to understand the data in any > format (community and LEAs input needed for this one)? > -One of the mission statements of the NRO is "Providing and promoting a > coordinated Internet number registry system" so if we are going to > internationalise the public face of the registry should it be coordinated(is > that a community, RIR or NRO question)? > > cheers > denis > > co-chair DB-WG > > On Wednesday, 29 July 2020, 21:09:55 CEST, Leo Vegoda <[email protected]> wrote: > > > Hi Denis, > > I agree that this is a registry issue and not just a database issue, > which is why I sent the message I did on 8 July. > > I'd like to understand how much of this work should be led by the RIPE > NCC versus the community. Also, because of the breadth of the issues, > should the discussion be here or on another list? > > Kind regards, > > Leo Vegoda > > On Wed, Jul 29, 2020 at 10:45 AM [email protected] > <[email protected]> wrote: > > > > 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. > > > > cheers > > denis > > > > co-chair DB-WG > > > > On Wednesday, 29 July 2020, 18:20:14 CEST, Leo Vegoda <[email protected]> > > 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 <[email protected]> > > 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, [email protected] 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 > > > > > >
