Dear colleagues, As I presented at RIPE 89 and RIPE 90, I'd like to propose to allow UTF-8 encoded characters in "descr:" and "remarks:" attributes. Is there support for adding UTF-8 in the RIPE database? Please let me know your feedback. Regards Ed Shryane RIPE NCC Problem Definition ------------------ It is currently only possible to store Latin-1 encoded data in the RIPE database. This is an issue for the majority of the RIPE region whose native language is not supported by Latin-1. We should allow regional operators to add notices to their RIPE database objects in their native language, using UTF-8 encoded data, so long as this does not affect interoperability. Solution Definition ------------------- In order to allow operators across the RIPE region to add notices in their own local language, we will allow UTF-8 characters in the “descr:” and “remarks:” attributes only. This change reduces the risk of impact to operators, users and the RIPE NCC, and does not affect existing RIPE policy. We can extend support for UTF-8 in additional existing or new attributes in the future, once we have more operational experience with it, but for now, only “descr:” and “remarks:” will be supported. Background ---------- Some work has already been done towards internationalization of the RIPE database. For example, in April 2015, Piotr Strzyzewski suggested to the DB-WG to support UTF-8 in free-text attributes. "Proposal to allow UTF8 (April 2015)" https://mailman.ripe.net/archives/list/db-wg@ripe.net/thread/QEYKOWZBCVA6HNH... In May 2022, I published a RIPE Labs article on the impact analysis of supporting UTF-8 in the RIPE database. https://labs.ripe.net/author/ed_shryane/impact-analysis-for-utf-8-in-the-rip... At RIPE 89 and RIPE 90 I proposed to support UTF-8 in the RIPE database and asked for feedback. https://ripe89.ripe.net/wp-content/uploads/presentations/105-RIPE89-DB-WG-UT... https://ripe90.ripe.net/wp-content/uploads/presentations/120-RIPE90-DB-WG-Op... Impact Analysis --------------- Backwards Compatibility UTF-8 is backwards compatible with ASCII, in the same way as Latin-1. Any RPSL objects solely using ASCII will be compatible with UTF-8 encoding. Approximately 99% of all objects in the RIPE database only contain ASCII characters. Personal Data Users must not add personal data in “remarks:” or “descr:” attributes, as these attributes are not included in the daily limit accounting, are not validated as they contain free text, and are not filtered by default. This is already the case in the RIPE database and the introduction of UTF-8 encoding does not change this. Personal data with UTF-8 encoding is out of scope. Interoperability If interoperability is a concern (i.e. a notice must be readable by a wider community) then it is recommended that only ASCII values are used. Valid Codepoints Validate UTF-8 input with the IDNA 2008 standard to decide whether a Unicode codepoint is allowed (i.e. only allow protocol valid code points). This standard is used in the implementation of Internationalised Domain Names (IDNs). This allows for consistency (code points will be mapped to a specific set of characters) and improved security (using an inclusion model to only allow certain characters). Guidelines for the Implementation of Internationalized Domain Names https://www.icann.org/resources/pages/idn-guidelines-2011-09-02-en Transliteration Transliteration to Latin-1 is only done when necessary to match the default response encoding. Otherwise transliteration is not done (i.e. UTF-8 characters will be returned as-is). Impact on RIPE Database Services -------------------------------- Whois (Port 43) Query * The “descr:” and “remarks:” attributes are returned by default on port 43 query responses. * Port 43 will continue to use Latin-1 by default. If so, any UTF-8 characters outside the ASCII character set will be transliterated to Latin-1 or will be substituted with a “?” character. * The client can specify the “-Z utf-8” flag to change the response encoding to UTF-8, then no transliteration will be done. NRTMv3 (Port 4444) * The encoding used by NRTMv3 will continue to be Latin-1. As for port 43, any non Latin-1 characters will be substituted with a “?” character. NRTMv4 * No impact. RPSL objects will continue to be returned in UTF-8 encoding in snapshot and delta files. Whois REST API * No impact. The Whois REST API already supports UTF-8. RDAP * No impact. The RDAP protocol already supports UTF-8. Web Application * UTF-8 encoding is already supported on the query page. * The create and update page validation will be changed to allow UTF-8 characters in “descr:” and “remarks:” attributes. Mailupdates * No impact. UTF-8 encoding is supported. Syncupdates * No impact. UTF-8 encoding is supported. Daily Database Dump and Split Files * The encoding of the database dump and split files remains Latin-1. The “descr:” and “remarks:” attributes are included unfiltered. Any non-Latin-1 UTF-8 characters will be substituted with a “?” character. * We will provide a separate UTF-8 encoded database dump and split files, which will include “descr:” and “remarks:” attributes without substitutions. New LIR Application * No impact. Registry Team * No comments or conerns as changes are limited to descr and remarks attributes.
Edward Shryane wrote on 22/10/2025 06:59:
As I presented at RIPE 89 and RIPE 90, I'd like to propose to allow UTF-8 encoded characters in "descr:" and "remarks:" attributes.
Is there support for adding UTF-8 in the RIPE database? Please let me know your feedback.
yes, definitely. Gradual introduction sounds like a good plan. Nick
Is there support for adding UTF-8 in the RIPE database? Please let me know your feedback.
is this email from the 1990s? ランディ ブッシュ
Hi, On Wed, Oct 22, 2025 at 08:59:41AM +0300, Edward Shryane wrote:
As I presented at RIPE 89 and RIPE 90, I'd like to propose to allow UTF-8 encoded characters in "descr:" and "remarks:" attributes.
Is there support for adding UTF-8 in the RIPE database? Please let me know your feedback.
Support, as proposed, with whois output kept at Latin-1 unless a client signals "yes, I can handle UTF-8", and just using UTF-8 in the more modern protocols (RDAP, Web API, etc). Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Karin Schuler, Sebastian Cler 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, yes, RIPE database should support UTF-8. - Daniel On 10/22/25 7:59 AM, Edward Shryane wrote:
Dear colleagues,
As I presented at RIPE 89 and RIPE 90, I'd like to propose to allow UTF-8 encoded characters in "descr:" and "remarks:" attributes.
Is there support for adding UTF-8 in the RIPE database? Please let me know your feedback.
Regards Ed Shryane RIPE NCC
Problem Definition ------------------
It is currently only possible to store Latin-1 encoded data in the RIPE database. This is an issue for the majority of the RIPE region whose native language is not supported by Latin-1. We should allow regional operators to add notices to their RIPE database objects in their native language, using UTF-8 encoded data, so long as this does not affect interoperability.
Solution Definition -------------------
In order to allow operators across the RIPE region to add notices in their own local language, we will allow UTF-8 characters in the “descr:” and “remarks:” attributes only. This change reduces the risk of impact to operators, users and the RIPE NCC, and does not affect existing RIPE policy.
We can extend support for UTF-8 in additional existing or new attributes in the future, once we have more operational experience with it, but for now, only “descr:” and “remarks:” will be supported.
Background ----------
Some work has already been done towards internationalization of the RIPE database. For example, in April 2015, Piotr Strzyzewski suggested to the DB-WG to support UTF-8 in free-text attributes.
"Proposal to allow UTF8 (April 2015)" https://mailman.ripe.net/archives/list/db-wg@ripe.net/thread/QEYKOWZBCVA6HNH...
In May 2022, I published a RIPE Labs article on the impact analysis of supporting UTF-8 in the RIPE database. https://labs.ripe.net/author/ed_shryane/impact-analysis-for-utf-8-in-the-rip...
At RIPE 89 and RIPE 90 I proposed to support UTF-8 in the RIPE database and asked for feedback. https://ripe89.ripe.net/wp-content/uploads/presentations/105-RIPE89-DB-WG-UT... https://ripe90.ripe.net/wp-content/uploads/presentations/120-RIPE90-DB-WG-Op...
Impact Analysis ---------------
Backwards Compatibility UTF-8 is backwards compatible with ASCII, in the same way as Latin-1. Any RPSL objects solely using ASCII will be compatible with UTF-8 encoding. Approximately 99% of all objects in the RIPE database only contain ASCII characters.
Personal Data Users must not add personal data in “remarks:” or “descr:” attributes, as these attributes are not included in the daily limit accounting, are not validated as they contain free text, and are not filtered by default. This is already the case in the RIPE database and the introduction of UTF-8 encoding does not change this. Personal data with UTF-8 encoding is out of scope.
Interoperability If interoperability is a concern (i.e. a notice must be readable by a wider community) then it is recommended that only ASCII values are used.
Valid Codepoints Validate UTF-8 input with the IDNA 2008 standard to decide whether a Unicode codepoint is allowed (i.e. only allow protocol valid code points). This standard is used in the implementation of Internationalised Domain Names (IDNs). This allows for consistency (code points will be mapped to a specific set of characters) and improved security (using an inclusion model to only allow certain characters).
Guidelines for the Implementation of Internationalized Domain Names https://www.icann.org/resources/pages/idn-guidelines-2011-09-02-en
Transliteration Transliteration to Latin-1 is only done when necessary to match the default response encoding. Otherwise transliteration is not done (i.e. UTF-8 characters will be returned as-is).
Impact on RIPE Database Services --------------------------------
Whois (Port 43) Query * The “descr:” and “remarks:” attributes are returned by default on port 43 query responses. * Port 43 will continue to use Latin-1 by default. If so, any UTF-8 characters outside the ASCII character set will be transliterated to Latin-1 or will be substituted with a “?” character. * The client can specify the “-Z utf-8” flag to change the response encoding to UTF-8, then no transliteration will be done.
NRTMv3 (Port 4444) * The encoding used by NRTMv3 will continue to be Latin-1. As for port 43, any non Latin-1 characters will be substituted with a “?” character.
NRTMv4 * No impact. RPSL objects will continue to be returned in UTF-8 encoding in snapshot and delta files.
Whois REST API * No impact. The Whois REST API already supports UTF-8.
RDAP * No impact. The RDAP protocol already supports UTF-8.
Web Application * UTF-8 encoding is already supported on the query page. * The create and update page validation will be changed to allow UTF-8 characters in “descr:” and “remarks:” attributes.
Mailupdates * No impact. UTF-8 encoding is supported.
Syncupdates * No impact. UTF-8 encoding is supported.
Daily Database Dump and Split Files * The encoding of the database dump and split files remains Latin-1. The “descr:” and “remarks:” attributes are included unfiltered. Any non-Latin-1 UTF-8 characters will be substituted with a “?” character. * We will provide a separate UTF-8 encoded database dump and split files, which will include “descr:” and “remarks:” attributes without substitutions.
New LIR Application * No impact.
Registry Team * No comments or conerns as changes are limited to descr and remarks attributes.
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/db-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
Sounds great! I strongly advocate for UTF-8 support in the ripe database On Wed, Oct 22, 2025, 11:25 Daniel Suchy via db-wg <db-wg@ripe.net> wrote:
Hello, yes, RIPE database should support UTF-8.
- Daniel
On 10/22/25 7:59 AM, Edward Shryane wrote:
Dear colleagues,
As I presented at RIPE 89 and RIPE 90, I'd like to propose to allow UTF-8 encoded characters in "descr:" and "remarks:" attributes.
Is there support for adding UTF-8 in the RIPE database? Please let me know your feedback.
Regards Ed Shryane RIPE NCC
Problem Definition ------------------
It is currently only possible to store Latin-1 encoded data in the RIPE database. This is an issue for the majority of the RIPE region whose native language is not supported by Latin-1. We should allow regional operators to add notices to their RIPE database objects in their native language, using UTF-8 encoded data, so long as this does not affect interoperability.
Solution Definition -------------------
In order to allow operators across the RIPE region to add notices in their own local language, we will allow UTF-8 characters in the “descr:” and “remarks:” attributes only. This change reduces the risk of impact to operators, users and the RIPE NCC, and does not affect existing RIPE policy.
We can extend support for UTF-8 in additional existing or new attributes in the future, once we have more operational experience with it, but for now, only “descr:” and “remarks:” will be supported.
Background ----------
Some work has already been done towards internationalization of the RIPE database. For example, in April 2015, Piotr Strzyzewski suggested to the DB-WG to support UTF-8 in free-text attributes.
"Proposal to allow UTF8 (April 2015)"
https://mailman.ripe.net/archives/list/db-wg@ripe.net/thread/QEYKOWZBCVA6HNH...
In May 2022, I published a RIPE Labs article on the impact analysis of
supporting UTF-8 in the RIPE database.
https://labs.ripe.net/author/ed_shryane/impact-analysis-for-utf-8-in-the-rip...
At RIPE 89 and RIPE 90 I proposed to support UTF-8 in the RIPE database
and asked for feedback.
https://ripe89.ripe.net/wp-content/uploads/presentations/105-RIPE89-DB-WG-UT...
https://ripe90.ripe.net/wp-content/uploads/presentations/120-RIPE90-DB-WG-Op...
Impact Analysis ---------------
Backwards Compatibility UTF-8 is backwards compatible with ASCII, in the same way as Latin-1.
Any RPSL objects solely using ASCII will be compatible with UTF-8 encoding. Approximately 99% of all objects in the RIPE database only contain ASCII characters.
Personal Data Users must not add personal data in “remarks:” or “descr:” attributes,
as these attributes are not included in the daily limit accounting, are not validated as they contain free text, and are not filtered by default. This is already the case in the RIPE database and the introduction of UTF-8 encoding does not change this. Personal data with UTF-8 encoding is out of scope.
Interoperability If interoperability is a concern (i.e. a notice must be readable by a
wider community) then it is recommended that only ASCII values are used.
Valid Codepoints Validate UTF-8 input with the IDNA 2008 standard to decide whether a
Unicode codepoint is allowed (i.e. only allow protocol valid code points). This standard is used in the implementation of Internationalised Domain Names (IDNs). This allows for consistency (code points will be mapped to a specific set of characters) and improved security (using an inclusion model to only allow certain characters).
Guidelines for the Implementation of Internationalized Domain Names https://www.icann.org/resources/pages/idn-guidelines-2011-09-02-en
Transliteration Transliteration to Latin-1 is only done when necessary to match the
default response encoding. Otherwise transliteration is not done (i.e. UTF-8 characters will be returned as-is).
Impact on RIPE Database Services --------------------------------
Whois (Port 43) Query * The “descr:” and “remarks:” attributes are returned by default on port
43 query responses.
* Port 43 will continue to use Latin-1 by default. If so, any UTF-8 characters outside the ASCII character set will be transliterated to Latin-1 or will be substituted with a “?” character. * The client can specify the “-Z utf-8” flag to change the response encoding to UTF-8, then no transliteration will be done.
NRTMv3 (Port 4444) * The encoding used by NRTMv3 will continue to be Latin-1. As for port 43, any non Latin-1 characters will be substituted with a “?” character.
NRTMv4 * No impact. RPSL objects will continue to be returned in UTF-8 encoding in snapshot and delta files.
Whois REST API * No impact. The Whois REST API already supports UTF-8.
RDAP * No impact. The RDAP protocol already supports UTF-8.
Web Application * UTF-8 encoding is already supported on the query page. * The create and update page validation will be changed to allow UTF-8 characters in “descr:” and “remarks:” attributes.
Mailupdates * No impact. UTF-8 encoding is supported.
Syncupdates * No impact. UTF-8 encoding is supported.
Daily Database Dump and Split Files * The encoding of the database dump and split files remains Latin-1. The “descr:” and “remarks:” attributes are included unfiltered. Any non-Latin-1 UTF-8 characters will be substituted with a “?” character. * We will provide a separate UTF-8 encoded database dump and split files, which will include “descr:” and “remarks:” attributes without substitutions.
New LIR Application * No impact.
Registry Team * No comments or conerns as changes are limited to descr and remarks attributes.
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/db-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/db-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
Hi all, ++ support from me... Kind regards, -- Clément Cavadore On Wed, 2025-10-22 at 08:59 +0300, Edward Shryane wrote:
Dear colleagues,
As I presented at RIPE 89 and RIPE 90, I'd like to propose to allow UTF-8 encoded characters in "descr:" and "remarks:" attributes.
Is there support for adding UTF-8 in the RIPE database? Please let me know your feedback.
Regards Ed Shryane RIPE NCC
Problem Definition ------------------
It is currently only possible to store Latin-1 encoded data in the RIPE database. This is an issue for the majority of the RIPE region whose native language is not supported by Latin-1. We should allow regional operators to add notices to their RIPE database objects in their native language, using UTF-8 encoded data, so long as this does not affect interoperability.
Solution Definition -------------------
In order to allow operators across the RIPE region to add notices in their own local language, we will allow UTF-8 characters in the “descr:” and “remarks:” attributes only. This change reduces the risk of impact to operators, users and the RIPE NCC, and does not affect existing RIPE policy.
We can extend support for UTF-8 in additional existing or new attributes in the future, once we have more operational experience with it, but for now, only “descr:” and “remarks:” will be supported.
Background ----------
Some work has already been done towards internationalization of the RIPE database. For example, in April 2015, Piotr Strzyzewski suggested to the DB-WG to support UTF-8 in free-text attributes.
"Proposal to allow UTF8 (April 2015)" https://mailman.ripe.net/archives/list/db-wg@ripe.net/thread/QEYKOWZBCVA6HNH...
In May 2022, I published a RIPE Labs article on the impact analysis of supporting UTF-8 in the RIPE database. https://labs.ripe.net/author/ed_shryane/impact-analysis-for-utf-8-in-the-rip...
At RIPE 89 and RIPE 90 I proposed to support UTF-8 in the RIPE database and asked for feedback. https://ripe89.ripe.net/wp-content/uploads/presentations/105-RIPE89-DB-WG-UT... https://ripe90.ripe.net/wp-content/uploads/presentations/120-RIPE90-DB-WG-Op...
Impact Analysis ---------------
Backwards Compatibility UTF-8 is backwards compatible with ASCII, in the same way as Latin-1. Any RPSL objects solely using ASCII will be compatible with UTF-8 encoding. Approximately 99% of all objects in the RIPE database only contain ASCII characters.
Personal Data Users must not add personal data in “remarks:” or “descr:” attributes, as these attributes are not included in the daily limit accounting, are not validated as they contain free text, and are not filtered by default. This is already the case in the RIPE database and the introduction of UTF-8 encoding does not change this. Personal data with UTF-8 encoding is out of scope.
Interoperability If interoperability is a concern (i.e. a notice must be readable by a wider community) then it is recommended that only ASCII values are used.
Valid Codepoints Validate UTF-8 input with the IDNA 2008 standard to decide whether a Unicode codepoint is allowed (i.e. only allow protocol valid code points). This standard is used in the implementation of Internationalised Domain Names (IDNs). This allows for consistency (code points will be mapped to a specific set of characters) and improved security (using an inclusion model to only allow certain characters).
Guidelines for the Implementation of Internationalized Domain Names https://www.icann.org/resources/pages/idn-guidelines-2011-09-02-en
Transliteration Transliteration to Latin-1 is only done when necessary to match the default response encoding. Otherwise transliteration is not done (i.e. UTF-8 characters will be returned as-is).
Impact on RIPE Database Services --------------------------------
Whois (Port 43) Query * The “descr:” and “remarks:” attributes are returned by default on port 43 query responses. * Port 43 will continue to use Latin-1 by default. If so, any UTF-8 characters outside the ASCII character set will be transliterated to Latin-1 or will be substituted with a “?” character. * The client can specify the “-Z utf-8” flag to change the response encoding to UTF-8, then no transliteration will be done.
NRTMv3 (Port 4444) * The encoding used by NRTMv3 will continue to be Latin-1. As for port 43, any non Latin-1 characters will be substituted with a “?” character.
NRTMv4 * No impact. RPSL objects will continue to be returned in UTF-8 encoding in snapshot and delta files.
Whois REST API * No impact. The Whois REST API already supports UTF-8.
RDAP * No impact. The RDAP protocol already supports UTF-8.
Web Application * UTF-8 encoding is already supported on the query page. * The create and update page validation will be changed to allow UTF- 8 characters in “descr:” and “remarks:” attributes.
Mailupdates * No impact. UTF-8 encoding is supported.
Syncupdates * No impact. UTF-8 encoding is supported.
Daily Database Dump and Split Files * The encoding of the database dump and split files remains Latin-1. The “descr:” and “remarks:” attributes are included unfiltered. Any non-Latin-1 UTF-8 characters will be substituted with a “?” character. * We will provide a separate UTF-8 encoded database dump and split files, which will include “descr:” and “remarks:” attributes without substitutions.
New LIR Application * No impact.
Registry Team * No comments or conerns as changes are limited to descr and remarks attributes.
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/db-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
[speaking as myself, not as co-chair] I support this, and I like the planned limitations for now. We can always expand this in the future once we have more experience. -peter On 2025 Oct 22 (Wed) at 08:59:41 +0300 (+0300), Edward Shryane wrote: :Dear colleagues, : :As I presented at RIPE 89 and RIPE 90, I'd like to propose to allow UTF-8 encoded characters in "descr:" and "remarks:" attributes. : :Is there support for adding UTF-8 in the RIPE database? Please let me know your feedback. : :Regards :Ed Shryane :RIPE NCC : : :Problem Definition :------------------ : :It is currently only possible to store Latin-1 encoded data in the RIPE database. This is an issue for the majority of the RIPE region whose native language is not supported by Latin-1. We should allow regional operators to add notices to their RIPE database objects in their native language, using UTF-8 encoded data, so long as this does not affect interoperability. : :Solution Definition :------------------- : :In order to allow operators across the RIPE region to add notices in their own local language, we will allow UTF-8 characters in the “descr:” and “remarks:” attributes only. This change reduces the risk of impact to operators, users and the RIPE NCC, and does not affect existing RIPE policy. : :We can extend support for UTF-8 in additional existing or new attributes in the future, once we have more operational experience with it, but for now, only “descr:” and “remarks:” will be supported. : :Background :---------- : :Some work has already been done towards internationalization of the RIPE database. For example, in April 2015, Piotr Strzyzewski suggested to the DB-WG to support UTF-8 in free-text attributes. : :"Proposal to allow UTF8 (April 2015)" :https://mailman.ripe.net/archives/list/db-wg@ripe.net/thread/QEYKOWZBCVA6HNH... : :In May 2022, I published a RIPE Labs article on the impact analysis of supporting UTF-8 in the RIPE database. :https://labs.ripe.net/author/ed_shryane/impact-analysis-for-utf-8-in-the-rip... : :At RIPE 89 and RIPE 90 I proposed to support UTF-8 in the RIPE database and asked for feedback. :https://ripe89.ripe.net/wp-content/uploads/presentations/105-RIPE89-DB-WG-UT... :https://ripe90.ripe.net/wp-content/uploads/presentations/120-RIPE90-DB-WG-Op... : :Impact Analysis :--------------- : :Backwards Compatibility :UTF-8 is backwards compatible with ASCII, in the same way as Latin-1. Any RPSL objects solely using ASCII will be compatible with UTF-8 encoding. Approximately 99% of all objects in the RIPE database only contain ASCII characters. : :Personal Data :Users must not add personal data in “remarks:” or “descr:” attributes, as these attributes are not included in the daily limit accounting, are not validated as they contain free text, and are not filtered by default. This is already the case in the RIPE database and the introduction of UTF-8 encoding does not change this. Personal data with UTF-8 encoding is out of scope. : :Interoperability :If interoperability is a concern (i.e. a notice must be readable by a wider community) then it is recommended that only ASCII values are used. : :Valid Codepoints :Validate UTF-8 input with the IDNA 2008 standard to decide whether a Unicode codepoint is allowed (i.e. only allow protocol valid code points). This standard is used in the implementation of Internationalised Domain Names (IDNs). This allows for consistency (code points will be mapped to a specific set of characters) and improved security (using an inclusion model to only allow certain characters). : :Guidelines for the Implementation of Internationalized Domain Names :https://www.icann.org/resources/pages/idn-guidelines-2011-09-02-en : :Transliteration :Transliteration to Latin-1 is only done when necessary to match the default response encoding. Otherwise transliteration is not done (i.e. UTF-8 characters will be returned as-is). : :Impact on RIPE Database Services :-------------------------------- : :Whois (Port 43) Query :* The “descr:” and “remarks:” attributes are returned by default on port 43 query responses. :* Port 43 will continue to use Latin-1 by default. If so, any UTF-8 characters outside the ASCII character set will be transliterated to Latin-1 or will be substituted with a “?” character. :* The client can specify the “-Z utf-8” flag to change the response encoding to UTF-8, then no transliteration will be done. : :NRTMv3 (Port 4444) :* The encoding used by NRTMv3 will continue to be Latin-1. As for port 43, any non Latin-1 characters will be substituted with a “?” character. : :NRTMv4 :* No impact. RPSL objects will continue to be returned in UTF-8 encoding in snapshot and delta files. : :Whois REST API :* No impact. The Whois REST API already supports UTF-8. : :RDAP :* No impact. The RDAP protocol already supports UTF-8. : :Web Application :* UTF-8 encoding is already supported on the query page. :* The create and update page validation will be changed to allow UTF-8 characters in “descr:” and “remarks:” attributes. : :Mailupdates :* No impact. UTF-8 encoding is supported. : :Syncupdates :* No impact. UTF-8 encoding is supported. : :Daily Database Dump and Split Files :* The encoding of the database dump and split files remains Latin-1. The “descr:” and “remarks:” attributes are included unfiltered. Any non-Latin-1 UTF-8 characters will be substituted with a “?” character. :* We will provide a separate UTF-8 encoded database dump and split files, which will include “descr:” and “remarks:” attributes without substitutions. : :New LIR Application :* No impact. : :Registry Team :* No comments or conerns as changes are limited to descr and remarks attributes. :
Dear all,
Is there support for adding UTF-8 in the RIPE database? Please let me know your feedback.
I definitely support this, especially as I see that the proposal already deals with my immediate concerns (see below). Best regards, Janos
Regards Ed Shryane RIPE NCC
Whois (Port 43) Query * The “descr:” and “remarks:” attributes are returned by default on port 43 query responses. * Port 43 will continue to use Latin-1 by default. If so, any UTF-8 characters outside the ASCII character set will be transliterated to Latin-1 or will be substituted with a “?” character. * The client can specify the “-Z utf-8” flag to change the response encoding to UTF-8, then no transliteration will be done.
Ed, all, On Wed, Oct 22, 2025 at 08:59:41AM +0300, Edward Shryane wrote:
Is there support for adding UTF-8 in the RIPE database? Please let me know your feedback.
makes sense to me.
Valid Codepoints Validate UTF-8 input with the IDNA 2008 standard to decide whether a Unicode codepoint is allowed (i.e. only allow protocol valid code points). This standard is used in the implementation of Internationalised Domain Names (IDNs). This allows for consistency (code points will be mapped to a specific set of characters) and improved security (using an inclusion model to only allow certain characters).
limiting the code points is likely a good thing, finding the exact reference would benefit from a bit more thought, though. Later. Best Peter
On Wed, 22 Oct 2025 at 09:00, Edward Shryane <eshryane@ripe.net> wrote:
Dear colleagues,
As I presented at RIPE 89 and RIPE 90, I'd like to propose to allow UTF-8 encoded characters in "descr:" and "remarks:" attributes.
Is there support for adding UTF-8 in the RIPE database? Please let me know your feedback.
I support adding some support for UTF-8 as the first step on a path towards more UTF-8. [...]
Personal Data Users must not add personal data in “remarks:” or “descr:” attributes, as these attributes are not included in the daily limit accounting, are not validated as they contain free text, and are not filtered by default. This is already the case in the RIPE database and the introduction of UTF-8 encoding does not change this. Personal data with UTF-8 encoding is out of scope.
What happens if or when someone does include personal data here? Thanks, Leo
On 2025 Oct 22 (Wed) at 14:03:07 +0300 (+0300), Leo Vegoda wrote: :> Personal Data :> Users must not add personal data in “remarks:” or “descr:” attributes, as these attributes are not included in the daily limit accounting, are not validated as they contain free text, and are not filtered by default. This is already the case in the RIPE database and the introduction of UTF-8 encoding does not change this. Personal data with UTF-8 encoding is out of scope. : :What happens if or when someone does include personal data here? : :Thanks, : :Leo I believe this is something that we cannot enforce in the database, but merely advise users to not add this information. However, this is not changing from the pre-UTF-8 system. -peter -- Anyone who uses the phrase "easy as taking candy from a baby" has never tried taking candy from a baby. -- Robin Hood
Dear Ed, DB-WG, On Wed, Oct 22, 2025 at 08:59:41AM +0300, Edward Shryane wrote:
Dear colleagues,
As I presented at RIPE 89 and RIPE 90, I'd like to propose to allow UTF-8 encoded characters in "descr:" and "remarks:" attributes.
Is there support for adding UTF-8 in the RIPE database? Please let me know your feedback.
Yes, this sounds good. Best, Piotr -- Piotr Strzyżewski
I must point out the perfect irony of the subject's reply to this email turning the "smart quotes" into ?'s Latin-1 will truly never die it seems On Wed, 22 Oct 2025 at 13:32, Piotr Strzyzewski <piotr@internetsailor.net> wrote:
Dear Ed, DB-WG,
On Wed, Oct 22, 2025 at 08:59:41AM +0300, Edward Shryane wrote:
Dear colleagues,
As I presented at RIPE 89 and RIPE 90, I'd like to propose to allow UTF-8 encoded characters in "descr:" and "remarks:" attributes.
Is there support for adding UTF-8 in the RIPE database? Please let me know your feedback.
Yes, this sounds good.
Best, Piotr
-- Piotr Strzyżewski ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/db-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
Hi Working Group, Based on the existing comments, the Chairs have decided to put a 2 week deadline for additional comments. Please send your spooky replies by EOD October 31, and we can judge consensus then. Peter Hessler, On Behalf of the Database WG Chairs. On 2025 Oct 22 (Wed) at 08:59:41 +0300 (+0300), Edward Shryane wrote: :Dear colleagues, : :As I presented at RIPE 89 and RIPE 90, I'd like to propose to allow UTF-8 encoded characters in "descr:" and "remarks:" attributes. : :Is there support for adding UTF-8 in the RIPE database? Please let me know your feedback. : :Regards :Ed Shryane :RIPE NCC : : :Problem Definition :------------------ : :It is currently only possible to store Latin-1 encoded data in the RIPE database. This is an issue for the majority of the RIPE region whose native language is not supported by Latin-1. We should allow regional operators to add notices to their RIPE database objects in their native language, using UTF-8 encoded data, so long as this does not affect interoperability. : :Solution Definition :------------------- : :In order to allow operators across the RIPE region to add notices in their own local language, we will allow UTF-8 characters in the “descr:” and “remarks:” attributes only. This change reduces the risk of impact to operators, users and the RIPE NCC, and does not affect existing RIPE policy. : :We can extend support for UTF-8 in additional existing or new attributes in the future, once we have more operational experience with it, but for now, only “descr:” and “remarks:” will be supported. : :Background :---------- : :Some work has already been done towards internationalization of the RIPE database. For example, in April 2015, Piotr Strzyzewski suggested to the DB-WG to support UTF-8 in free-text attributes. : :"Proposal to allow UTF8 (April 2015)" :https://mailman.ripe.net/archives/list/db-wg@ripe.net/thread/QEYKOWZBCVA6HNH... : :In May 2022, I published a RIPE Labs article on the impact analysis of supporting UTF-8 in the RIPE database. :https://labs.ripe.net/author/ed_shryane/impact-analysis-for-utf-8-in-the-rip... : :At RIPE 89 and RIPE 90 I proposed to support UTF-8 in the RIPE database and asked for feedback. :https://ripe89.ripe.net/wp-content/uploads/presentations/105-RIPE89-DB-WG-UT... :https://ripe90.ripe.net/wp-content/uploads/presentations/120-RIPE90-DB-WG-Op... : :Impact Analysis :--------------- : :Backwards Compatibility :UTF-8 is backwards compatible with ASCII, in the same way as Latin-1. Any RPSL objects solely using ASCII will be compatible with UTF-8 encoding. Approximately 99% of all objects in the RIPE database only contain ASCII characters. : :Personal Data :Users must not add personal data in “remarks:” or “descr:” attributes, as these attributes are not included in the daily limit accounting, are not validated as they contain free text, and are not filtered by default. This is already the case in the RIPE database and the introduction of UTF-8 encoding does not change this. Personal data with UTF-8 encoding is out of scope. : :Interoperability :If interoperability is a concern (i.e. a notice must be readable by a wider community) then it is recommended that only ASCII values are used. : :Valid Codepoints :Validate UTF-8 input with the IDNA 2008 standard to decide whether a Unicode codepoint is allowed (i.e. only allow protocol valid code points). This standard is used in the implementation of Internationalised Domain Names (IDNs). This allows for consistency (code points will be mapped to a specific set of characters) and improved security (using an inclusion model to only allow certain characters). : :Guidelines for the Implementation of Internationalized Domain Names :https://www.icann.org/resources/pages/idn-guidelines-2011-09-02-en : :Transliteration :Transliteration to Latin-1 is only done when necessary to match the default response encoding. Otherwise transliteration is not done (i.e. UTF-8 characters will be returned as-is). : :Impact on RIPE Database Services :-------------------------------- : :Whois (Port 43) Query :* The “descr:” and “remarks:” attributes are returned by default on port 43 query responses. :* Port 43 will continue to use Latin-1 by default. If so, any UTF-8 characters outside the ASCII character set will be transliterated to Latin-1 or will be substituted with a “?” character. :* The client can specify the “-Z utf-8” flag to change the response encoding to UTF-8, then no transliteration will be done. : :NRTMv3 (Port 4444) :* The encoding used by NRTMv3 will continue to be Latin-1. As for port 43, any non Latin-1 characters will be substituted with a “?” character. : :NRTMv4 :* No impact. RPSL objects will continue to be returned in UTF-8 encoding in snapshot and delta files. : :Whois REST API :* No impact. The Whois REST API already supports UTF-8. : :RDAP :* No impact. The RDAP protocol already supports UTF-8. : :Web Application :* UTF-8 encoding is already supported on the query page. :* The create and update page validation will be changed to allow UTF-8 characters in “descr:” and “remarks:” attributes. : :Mailupdates :* No impact. UTF-8 encoding is supported. : :Syncupdates :* No impact. UTF-8 encoding is supported. : :Daily Database Dump and Split Files :* The encoding of the database dump and split files remains Latin-1. The “descr:” and “remarks:” attributes are included unfiltered. Any non-Latin-1 UTF-8 characters will be substituted with a “?” character. :* We will provide a separate UTF-8 encoded database dump and split files, which will include “descr:” and “remarks:” attributes without substitutions. : :New LIR Application :* No impact. : :Registry Team :* No comments or conerns as changes are limited to descr and remarks attributes.
Support from me - an obvious and required enhancement at this point! - Mick On 22/10/2025 08:59, Edward Shryane wrote:
Dear colleagues,
As I presented at RIPE 89 and RIPE 90, I'd like to propose to allow UTF-8 encoded characters in "descr:" and "remarks:" attributes.
Is there support for adding UTF-8 in the RIPE database? Please let me know your feedback.
-- Mick O’Donovan Senior Network Engineer HEAnet CLG Ireland's National Education and Research Network 3rd Floor, North Dock 2 | 93/94 North Wall Quay | Dublin D01 V8Y6 | Ireland +353 1 6609040 | mick.odonovan@heanet.ie | www.heanet.ie Registered in Ireland, No. 275301 | CRA No. 20036270
partecipanti (13)
-
Ben Cartwright-Cox -
Clement Cavadore -
Daniel Suchy -
Edward Shryane -
Gert Doering -
Janos Zsako -
Leo Vegoda -
Mick O'Donovan -
Nick Hilliard -
Peter Hessler -
Peter Koch -
Piotr Strzyzewski -
Randy Bush