NWI-11 Internationalised Domain Names
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.
Dear Working Group, I'd like to propose the following Solution Definition for NWI-11. Introduction 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. Solution Definition 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. 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. 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). 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. When querying the RIPE database, any Punycode encoded email address is returned in Punycode (i.e it is not decoded). I welcome feedback from the community on this proposal. Regards Ed Shryane RIPE NCC
On 22 Jun 2020, at 22:49, ripedenis--- via db-wg <db-wg@ripe.net> wrote:
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.
cheers denis
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.
Hi Ed, On Fri, Jun 26, 2020 at 7:55 AM Edward Shryane via db-wg <db-wg@ripe.net> wrote: [...]
I welcome feedback from the community on this proposal.
From my personal perspective, this is a welcome first step on the road towards strong internationalization support in the RIPE Database. It also seems like a conservative deployment that has a low probability of causing interoperability problems for automatic systems that query the database to obtain contact information. Thank you.
Kind regards, Leo Vegoda
Leo Vegoda via db-wg wrote on 26/06/2020 17:54:
From my personal perspective, this is a welcome first step on the road towards strong internationalization support in the RIPE Database. It also seems like a conservative deployment that has a low probability of causing interoperability problems for automatic systems that query the database to obtain contact information. Thank you.
looks reasonable. Nick
Colleagues Does anyone have any further comments on this proposal from the RIPE NCC? If there are no objections or alternative suggestions then we can ask the RIPE NCC to implement this proposal. cheersdenis co-chair DB-WG On Friday, 26 June 2020, 16:55:04 CEST, Edward Shryane <eshryane@ripe.net> wrote: Dear Working Group, I'd like to propose the following Solution Definition for NWI-11. Introduction 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. Solution Definition 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. 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. 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). 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. When querying the RIPE database, any Punycode encoded email address is returned in Punycode (i.e it is not decoded). I welcome feedback from the community on this proposal. RegardsEd ShryaneRIPE NCC On 22 Jun 2020, at 22:49, ripedenis--- via db-wg <db-wg@ripe.net> wrote: 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.
Hi, I don't get it. Does the RIPE DB prevent the usage of punycode? Can someone give me an example, where punycode doesn't work or why punycode isn't good enough? Regards, Benedikt On 22.06.20 22:49, ripedenis--- via db-wg wrote:
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.
cheers denis
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.
Hi, On Tue, Jul 07, 2020 at 02:53:47PM +0200, Benedikt Neuffer via db-wg wrote:
I don't get it. Does the RIPE DB prevent the usage of punycode?
Can someone give me an example, where punycode doesn't work or why punycode isn't good enough?
From what I understand, the intent is to convert incoming e-mail: attributes in "non-punycode format" to punycode before storing in the DB. I do not have a very strong opinion on this proposed implementation. In the long run, I think punycode is a horrible, horrible hack and must die in flames. So if we can have a proper database with proper charset support, my surname would appreciate. And yes, this will most likely involve UTF-8 internally and export filters (I do not want to see UTF-8, ever, if I can have ISO8859-15 instead - yeah, come, sue me) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Hello Gert, Benedikt,
On 7 Jul 2020, at 15:03, Gert Doering via db-wg <db-wg@ripe.net> wrote:
Hi,
On Tue, Jul 07, 2020 at 02:53:47PM +0200, Benedikt Neuffer via db-wg wrote:
I don't get it. Does the RIPE DB prevent the usage of punycode?
Can someone give me an example, where punycode doesn't work or why punycode isn't good enough?
From what I understand, the intent is to convert incoming e-mail: attributes in "non-punycode format" to punycode before storing in the DB.
You are correct. From my Solution Definition: "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." This automated conversion will allow any email address with an IDN (non-ASCII) domain name to be stored as Punycode. Regards Ed Shryane RIPE NCC
Hi Ed, On 07.07.20 15:20, Edward Shryane wrote:
Hello Gert, Benedikt,
On 7 Jul 2020, at 15:03, Gert Doering via db-wg <db-wg@ripe.net> wrote:
Hi,
On Tue, Jul 07, 2020 at 02:53:47PM +0200, Benedikt Neuffer via db-wg wrote:
I don't get it. Does the RIPE DB prevent the usage of punycode?
Can someone give me an example, where punycode doesn't work or why punycode isn't good enough?
From what I understand, the intent is to convert incoming e-mail: attributes in "non-punycode format" to punycode before storing in the DB.
You are correct.
From my Solution Definition:
"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."
This automated conversion will allow any email address with an IDN (non-ASCII) domain name to be stored as Punycode.
ok, thanks for the details. Know I understand the intention. I think that is the best thing one can do for now. I am in for this change. Regards, Bene
Hi Gert, On 07.07.20 15:03, Gert Doering wrote:
Hi,
On Tue, Jul 07, 2020 at 02:53:47PM +0200, Benedikt Neuffer via db-wg wrote:
I don't get it. Does the RIPE DB prevent the usage of punycode?
Can someone give me an example, where punycode doesn't work or why punycode isn't good enough?
From what I understand, the intent is to convert incoming e-mail: attributes in "non-punycode format" to punycode before storing in the DB.
I do not have a very strong opinion on this proposed implementation.
In the long run, I think punycode is a horrible, horrible hack and must die in flames. So if we can have a proper database with proper charset support, my surname would appreciate.
And yes, this will most likely involve UTF-8 internally and export filters (I do not want to see UTF-8, ever, if I can have ISO8859-15 instead - yeah, come, sue me)
I think at the moment it would be easier to update the clients to convert punycode in whatever encoding you prefer. Regards, Benedikt
Hi, On Tue, Jul 07, 2020 at 05:03:01PM +0200, Benedikt Neuffer wrote:
I think at the moment it would be easier to update the clients to convert punycode in whatever encoding you prefer.
Cementing this abomination even more... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Gert Doering via db-wg wrote on 07/07/2020 16:21:
On Tue, Jul 07, 2020 at 05:03:01PM +0200, Benedikt Neuffer wrote:
I think at the moment it would be easier to update the clients to convert punycode in whatever encoding you prefer.
Cementing this abomination even more...
No-one likes punycode. Do you have a better suggestion? Would raw utf8 work here? How much would it break? If there were broader support in the ripedb codebase for utf8, would it be possible to work towards a day in the future when the ripedb could formally support utf8 across multiple different field types, not just email addresses? Nick
Hi Nick "would it be possible to work towards a day in the future when the ripedb could formally support utf8 across multiple different field types, not just email addresses?" The technical aspect of utilising utf-8 in the RIPE Database has been looked at several times by the RIPE NCC, but it never moves forward because of the social/political/registry/legal issues which cannot be resolved at the technical level: -Should we allow all/some/none of the data content to be in non Latin characters?-Is there some data content that must be in Latin characters (for the correct functioning of the registry?), some that can be duplicated in Latin and local characters, some that can be in any format chosen by the resource holder?-If some data is duplicated how will the duplicate sets of data be verified as a consistent set (does it need to be the same data)?-Who needs to be able to interpret which parts of the data content and for what purpose?-Who can make these decisions (this is the bit that has been missing ever since the subject of utf-8 was first raised many years ago)? Probably puny code can be implemented for IDNs in a matter of weeks, full implementation of utf-8 may take years. cheersdenis co-chair DB-WG On Tuesday, 7 July 2020, 23:54:13 CEST, Nick Hilliard via db-wg <db-wg@ripe.net> wrote: Gert Doering via db-wg wrote on 07/07/2020 16:21:
On Tue, Jul 07, 2020 at 05:03:01PM +0200, Benedikt Neuffer wrote:
I think at the moment it would be easier to update the clients to convert punycode in whatever encoding you prefer.
Cementing this abomination even more...
No-one likes punycode. Do you have a better suggestion? Would raw utf8 work here? How much would it break? If there were broader support in the ripedb codebase for utf8, would it be possible to work towards a day in the future when the ripedb could formally support utf8 across multiple different field types, not just email addresses? Nick
On Tue, Jul 7, 2020 at 6:05 PM ripedenis--- via db-wg <db-wg@ripe.net> wrote:
Hi Nick
"would it be possible to work towards a day in the future when the ripedb could formally support utf8 across multiple different field types, not just email addresses?"
The technical aspect of utilising utf-8 in the RIPE Database has been looked at several times by the RIPE NCC, but it never moves forward because of the social/political/registry/legal issues which cannot be resolved at the technical level:
I think we need to consider the whole registry and not just the RIPE Database. The creation of objects to describe organizations is still relatively new. That information was placed in the RIPE Database, but it could have been placed elsewhere, with an outward link from the RIPE Database.
-Should we allow all/some/none of the data content to be in non Latin characters?
Cynthia's message from earlier today [1] gives at least one case where it would be useful to present names in a format that aids searching in external data sources. I support adding good support for internationalization in the RIPE registry. I'd like it to be done in a way that minimizes the chance of surprising organizations who miss a few announcements and find their tools breaking because of character set issues. Kind regards, Leo Vegoda [1] https://www.ripe.net/ripe/mail/archives/db-wg/2020-July/006567.html
Hi, On Tue, Jul 07, 2020 at 10:53:40PM +0100, Nick Hilliard wrote:
Do you have a better suggestion? Would raw utf8 work here? How much would it break? If there were broader support in the ripedb codebase for utf8, would it be possible to work towards a day in the future when the ripedb could formally support utf8 across multiple different field types, not just email addresses?
That was my suggestion. UTF8 internal, with an output filter to whatever charset the client can handle, possibly defaulting to ISO8859-1 on "whois" sessions. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
From outside your region, but since we run a "fork" of the RIPE DB code, I would like to add some comments.
APNIC has seen clear demand from our community for multiple language alternatives to be possible for at least these attributes: contact address (all parts), person names and org names. It seems to make sense to include remarks as well. This is a strong, continuing signal of interest, concern from our region. It’s not a case of having whois objects in “other languages”, but of allowing multiple additional language versions of existing attributes (allowing policy to still require latin script attributes). This is analogous to RDAP where the data model has explicitly allowed us to tag the objects/elements as having alternates. The need comes from the fact that the primary language/script for these things is the local language, not English. Making whois less useful for communities in those countries/economies, and less likely to be accurate. Having to coerce data into western/english script is reducing the value proposition behind the service. Raw UTF-8 would work better here. It would permit the model to be extended naturally into multiple script models. I understand its inherently more complex than uplift to punycode of the domain elements in things, but the underlying problem in Whois and language goes beyond the specific domain-name context. I guess I am saying "I agree with Gert and I think my community wants this too" -George On Wed, Jul 8, 2020 at 4:04 PM Gert Doering via db-wg <db-wg@ripe.net> wrote:
Hi,
On Tue, Jul 07, 2020 at 10:53:40PM +0100, Nick Hilliard wrote:
Do you have a better suggestion? Would raw utf8 work here? How much would it break? If there were broader support in the ripedb codebase for utf8, would it be possible to work towards a day in the future when the ripedb could formally support utf8 across multiple different field types, not just email addresses?
That was my suggestion. UTF8 internal, with an output filter to whatever charset the client can handle, possibly defaulting to ISO8859-1 on "whois" sessions.
Gert Doering -- NetMaster -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
George Michaelson via db-wg wrote on 10/07/2020 01:15:
Raw UTF-8 would work better here. It would permit the model to be extended naturally into multiple script models. I understand its inherently more complex than uplift to punycode of the domain elements in things, but the underlying problem in Whois and language goes beyond the specific domain-name context.
I guess I am saying "I agree with Gert and I think my community wants this too"
fundamentally yeah - it's a bit colonial to continue ignoring the reality that us-ascii is inappropriate for large chunks of the world. Nick
Hi Nick, George "fundamentally yeah - it's a bit colonial to continue ignoring the reality that us-ascii is inappropriate for large chunks of the world." I totally agree with the drive to disengage with the colonial past and move on in all areas of life. However, the RIR Databases reflect a public global registry of IP addresses, and in parts also serve as IRRs. If we are going to allow all character sets within these databases then we must answer a number of non technical questions, such as:-What is a global IP address registry?-What purpose does it/do they serve?-Who is it for?-Who needs to be able to read, understand, interpret, convert what parts of it? Before we even ask those questions we need to consider who is going to answer these questions and on whose behalf? Is this going to be addressed separately by each RIR? Or is it better to consider a cross RIR Database/Registry solution? This is why I believe we should go for a simple Punycode option now and then start to consider the bigger picture and finally address difficult questions that have been brushed under the carpet for many years. cheersdenis co-chair DB-WG On Monday, 13 July 2020, 16:42:01 CEST, Nick Hilliard via db-wg <db-wg@ripe.net> wrote: George Michaelson via db-wg wrote on 10/07/2020 01:15:
Raw UTF-8 would work better here. It would permit the model to be extended naturally into multiple script models. I understand its inherently more complex than uplift to punycode of the domain elements in things, but the underlying problem in Whois and language goes beyond the specific domain-name context.
I guess I am saying "I agree with Gert and I think my community wants this too"
fundamentally yeah - it's a bit colonial to continue ignoring the reality that us-ascii is inappropriate for large chunks of the world. Nick
Hi, On Mon, Jul 13, 2020 at 04:49:16PM +0000, ripedenis--- via db-wg wrote:
This is why I believe we should go for a simple Punycode option now and then start to consider the bigger picture and finally address difficult questions that have been brushed under the carpet for many years.
I think nobody is disagreeing with you there - as long as we get going :-) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
I would be broadly supportive of a cross-RIR database/registry conversation. I think its long overdue. It's not an easy conversation, but I think it's a necessary one. it is also off-topic. So I won't say more, but having opened the door, I strongly urge you to continue opening this door. I believe the NRO would want us to explore this. From things said to me at large, I am sure the community at large wants us to explore this. They are very tired of information model and interface divergences here. -G On Tue, Jul 14, 2020 at 4:54 AM Gert Doering <gert@space.net> wrote:
Hi,
On Mon, Jul 13, 2020 at 04:49:16PM +0000, ripedenis--- via db-wg wrote:
This is why I believe we should go for a simple Punycode option now and then start to consider the bigger picture and finally address difficult questions that have been brushed under the carpet for many years.
I think nobody is disagreeing with you there - as long as we get going :-)
Gert Doering -- NetMaster -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
participants (7)
-
Benedikt Neuffer -
Edward Shryane -
George Michaelson -
Gert Doering -
Leo Vegoda -
Nick Hilliard -
ripedenis＠yahoo.co.uk