- db-wg - mailman.ripe.net

Updated Migration Plan to Remove MD5 Hashed Passwords from the RIPE Database
by Edward Shryane 14 Jan '26

14 Jan '26

Dear colleagues, The RIPE NCC database team published an updated plan in January to deprecate MD5 hashed passwords by the end of 2025: https://mailman.ripe.net/archives/list/db-wg@ripe.net/thread/NGCRQWJPF7MT24… Since then, we have been working towards this deadline: * Added support for API key and OAuth 2.0 authentication * Notified maintainers and removed inactive passwords in June (including any passwords not used since January 2024) * Notified maintainers by email who are actively using passwords in July, September, October and November * Added a warning to the database web query page that passwords are deprecated * Added a warning to Whois update responses that passwords are deprecated I presented at the DB-WG session at RIPE 91 that use of password authentication is still very high: 32% of all updates used password authentication, by about 150 maintainers. By last week, this has decreased to 17% of all updates by about 105 maintainers. There is still a risk that the database community may not be ready for the end of year deadline. Taking this into consideration, I propose the following updated plan for the end of year deadline: * At the beginning of January (e.g. Monday January 5th at midday CET), remove all passwords from the RIPE database, after notifying maintainers and the working group. * Allow maintainers to add a password back to their maintainer if they still really need to use one (e.g. for operational reasons). * In the following Whois release, around the end of January, remove support for passwords altogether, again after notifying maintainers and working group. This gives us a rollback plan in case there are maintainers that need some extra time, and still allows us to follow through with deprecating passwords. In the meantime, we will continue to monitor use of password authentication. We also want to hear from any maintainers who need assistance with the migration, we are happy to help. Please let us know your questions or comments. Regards Ed Shryane RIPE NCC

2 7

Database API Key Flag added to the LIR Portal Users Page
by Edward Shryane 08 Jan '26

08 Jan '26

Dear colleagues, I am pleased to announce that the RIPE NCC has implemented a feature in the LIR Portal to display a "Database API key" flag on the Users page, if the user has any API key(s) to make updates in the RIPE database. This flag is only visible to Admin users. Regards Ed Shryane RIPE NCC

1 0

Last call for discussion regarding NWI-2 and NWI-17
by David Tatlisu 06 Jan '26

06 Jan '26

Hi Everybody, At RIPE 91 I talked about how we would like to cancel NWI-2 and NWI-17, which both concern some variation of historical data in the RIPE database. NWI-2 concerns lifting some arbitrary limitations in the retrieval of historical data, as well as allowing the retrieval of deleted objects which have not been re-created. NWI-17 is significantly more complex, as it centers around implementing the Database Requirements Task Force Recommendations [1], and I suggest three possibilities for the future of this NWI: 1. Try to move NWI-17 forward by requesting a GDPR compliance report from the NCC 1. Since the RIPE NCC is the data controller GDPR compliance is technically solely their responsibility 2. Try to move this NWI forward by reducing the problem stated in the Database Requirements Task Force Recommendations by removing the special case for researchers getting wider access to data 3. Cancel NWI-17 Considering the discussions about both NWIs have died down over the last years, I would suggest we cancel both NWIs while keeping the option to re-open them in case interest grows. With this, I would like to cancel both NWI-2 and NWI-17 on January 5th assuming the working group does not want to keep them open. Please keep in mind that I do understand that these NWIs have not been created for the fun of it, and have good reasons behind them, but lack of discussion around these NWIs even considering several attempts to rejuvenate them also tells a story. [1]: https://www.ripe.net/community/tf/rdb-requirements-tf/database-requirements… https://www.ripe.net/community/tf/rdb-requirements-tf/database-requirements… Me talking about them at RIPE91: https://ripe91.ripe.net/programme/meeting-plan/sessions/38/R7WC3F/ Thank you for your feedback. David Tatlisu, On behalf of the Database WG Chairs. --- To me, in a personal capacity, closing them would be a formality as they have not had active discussions over the last several years, making them unofficially but effectively cancelled already.

3 3

inverse search help?
by Hank Nussbacher 18 Dec '25

18 Dec '25

I forgot how to do an inverse search to find my ASN in as-sets. So Google AI tells me: Yet: hank@nocvm:~$ whois -h whois.ripe.net -i members as378 % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See https://docs.db.ripe.net/terms-conditions.html % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. %ERROR:105: attribute is not searchable % % "members" is not an inverse searchable attribute. %ERROR:101: no entries found % % No entries found in source RIPE. % This query was served by the RIPE Database Query Service version 1.120 (DEXTER) What am I doing wrong? Thanks, Hank

6 6

Defining NWI-21
by David Tatlisu 16 Dec '25

16 Dec '25

Hi Everybody, Marco Schmidt started a thread discussing the addition of the "reg-nr:" attribute to organization objects. Summarizing it very briefly, it would make identifying legal entities easier, as their government-issued identification number would be available in the database. The Database team plans on including a URL to the responsible company register on the web frontend where available, while the WHOIS and RDAP will not include the URL. Marco already went through the effort of writing both a Problem Definition and a Solution Definition, which "fast-tracked" a few steps of the NWI process :p From what I was able to determine, the discussion on the working group did not lead to any change of either the Problem or Solution Definition. There were some concerns about potential privacy issues which, as far as I was able to tell, were able to be rectified to a sufficient degree as the new data is already public and potential edge-cases were brought to the attention of the RIPE-NCC. With this, I now declare consensus on the Problem Definition and have determined that this can continue using the NWI process. Please share any additional feedback for the Solution Definition until 22nd December. Considering the current state of the discussion, I think it's safe to say that the working group participants will have agreed on the Solution Definition after this date. With this, I thank all participants for their contributions to this NWI. Kind Regards David Tatlisu, On behalf of the Database WG Chairs. ### Copied from Marco's original e-Mail from 17th November Problem Statement: The RIPE Database should allow users to uniquely identify Internet Number Resource holders. Today, organisation objects linked to RIPE NCC co-maintained inetnum, inet6num, and aut-num objects include the validated legal organisation name and country code where the resource holder is legally registered. However, these attributes alone are not always sufficient to uniquely identify a legal entity, for three main reasons: 1. Identical names: In some jurisdictions, different companies can legally register with the same or very similar names. 2. Transliteration issues: In countries using non-Latin scripts, converting names from and into Latin characters can produce inconsistent or inaccurate results. 3. Data discrepancies: Differences between the validated legal information (org-name and country) and the contact details maintained by the resource holder (for example, a postal address in another country) can create confusion and make identification more difficult. Solution Definition: Introduce a new reg-nr: attribute for RIPE NCC co-maintained organisation objects, containing verified company registration numbers issued by national authorities. The RIPE NCC already holds this information for ~99% of resource holders that are legal entities. Publishing a unique and verifiable registration number will significantly improve the ability of RIPE Database users to accurately identify resource holders and cross-check them in national company registries. Only publicly available registration numbers of legal entities will be published. Natural persons remain explicitly out of scope.

3 2

Whois Release 1.120
by Edward Shryane 27 Nov '25

27 Nov '25

Dear colleagues, RIPE Database release 1.120 has been deployed to the Release Candidate environment for testing. We plan to deploy to production on Thursday 27th November. Whois release 1.120 contains the following changes : * Whois scope is now mandatory for OAuth 2.0 tokens * Added conditional attributes to object template (which depend on business rules) * Add warning in update response if API key is expiring soon * Redirect top-level IANA administrative blocks (i.e. top-level /8 allocations) to other RIRs in RDAP response * Update RDAP geofeed implementation with changes in RFC 9877 The full list of changes is visible in the source repository: https://github.com/RIPE-NCC/whois/compare/1c439eb5...6db089c The release notes are also in the repository : https://github.com/RIPE-NCC/whois/releases/tag/6db089c3 More information on the Release Candidate environment can be found on our website: https://apps.db.ripe.net/docs/Release-Notes/ The data in the Release Candidate environment is a dummified copy of production from 11th November. Please let us know if you find any issues with this release in the RC environment. Regards Ed Shryane RIPE NCC

1 1

Improving Identification of RIPE NCC Members and Independent Resource Holders by Publishing Company Registration Numbers
by Marco Schmidt 27 Nov '25

27 Nov '25

Dear colleagues, Following my presentation at the RIPE 91 Address Policy Working Group session, I’d like to propose adding a company registration number to the organisation object type. Problem Statement: The RIPE Database should allow users to uniquely identify Internet Number Resource holders. Today, organisation objects linked to RIPE NCC co-maintained inetnum, inet6num, and aut-num objects include the validated legal organisation name and country code where the resource holder is legally registered. However, these attributes alone are not always sufficient to uniquely identify a legal entity, for three main reasons: 1. Identical names: In some jurisdictions, different companies can legally register with the same or very similar names. 2. Transliteration issues: In countries using non-Latin scripts, converting names from and into Latin characters can produce inconsistent or inaccurate results. 3. Data discrepancies: Differences between the validated legal information (org-name and country) and the contact details maintained by the resource holder (for example, a postal address in another country) can create confusion and make identification more difficult. Solution Definition: Introduce a new reg-nr: attribute for RIPE NCC co-maintained organisation objects, containing verified company registration numbers issued by national authorities. The RIPE NCC already holds this information for ~99% of resource holders that are legal entities. Publishing a unique and verifiable registration number will significantly improve the ability of RIPE Database users to accurately identify resource holders and cross-check them in national company registries. Only publicly available registration numbers of legal entities will be published. Natural persons remain explicitly out of scope. Please let me know your feedback. Questions and comments are welcome. Regards Marco Schmidt Manager Registration Services RIPE NCC

15 32

RIPE90 proposal to deprecate the RIPE NONAUTH Database
by Edward Shryane 20 Nov '25

20 Nov '25

Dear colleagues, At RIPE90 I presented a proposal to deprecate the RIPE-NONAUTH database: https://ripe90.ripe.net/wp-content/uploads/presentations/120-RIPE90-DB-WG-O… (slide 20) The objects in the RIPE-NONAUTH database are not authoritative, and were created anonymously with a well-known password as out-of-region data in the RIPE IRR database. We don’t know who created this data or whether it is still valid. There are very few (< 100) updates per year, which suggests the data is not being maintained. The RIPE-NONAUTH database has only reduced in size by about 10% since it was created in 2018. The existing cleanup jobs and maintainers are not deleting much data. Ruediger Volk pointed out that ARIN had only very recently introduced their NONAUTH database, so it was a very short-term temporary source, and that does not predict anything about the longstanding data that has been split out into RIPE-NONAUTH. He suggested that the RIPE NCC analyse whether something that’s supposed to go away is still being used, or else there is a pretty big danger that someone is actually depending on it. I now present some analysis of the RIPE-NONAUTH database for review. Perhaps we should not retire the RIPE-NONAUTH database completely as we don't know how it is being used, but we could take action to further reduce its size. Your feedback is appreciated. Should RIPE-NONAUTH Objects Be Returned By Default? --------------------------------------------------- The RIPE-NONAUTH database is included by default in Whois queries. This means that any matching object in the RIPE-NONAUTH database is automatically returned in the Whois query response. That includes as-set, aut-num, route and route6 object types. For example, when querying for "AS2561", the matching aut-num object in the RIPE-NONAUTH database is returned. Additionally, *related* matching objects in the RIPE-NONAUTH database will also be returned by default. For example, when querying for the IPv4 prefix "200.30.0.0/18", the related route object "200.30.0.0/18AS5511" in the RIPE-NONAUTH database is returned. We found that RIPE-NONAUTH objects are returned only in a small number of cases (about 0.006% of all queries), but there is a risk that clients will inadvertently trust non-authoritative data if the "source:" attribute is not checked. As a workaround, clients can use the "-s RIPE" flag to only query the RIPE database. Should objects in the RIPE-NONAUTH database continue to be returned by default? Near Realtime Mirroring (NRTM) ------------------------------ Approximately 20% of NRTM requests query for updates to the NONAUTH database. Should we continue to support mirroring the NONAUTH database, considering the non-authoritative nature of the data and low rate of updates? Should RIPE-NONAUTH objects with an exact match in another RIR database be deleted? ----------------------------------------------------------------------------------- Approximately 31,930 out of 45,754 route(6) objects in the RIPE-NONAUTH database have a matching route(6) object (i.e. matching origin ASN and exactly matching or less-specific prefix) in another RIR’s IRR database. Approximately 13 out of 67 as-set objects in the RIPE-NONAUTH database have an exactly matching as-set in another RIR’s database. Approximately 1,840 out of 2,073 aut-num objects in the RIPE-NONAUTH database have an exactly matching aut-num object in another RIR’s database. Should we delete RIPE-NONAUTH objects which duplicate identically named objects in an authoritative RIR’s database? Should unrouted RIPE-NONAUTH route(6) objects be deleted? --------------------------------------------------------- Approximately 33,912 out of 44,647 RIPE-NONAUTH route(6) objects appear in the global routing table (as of 12th July). Should we remove any NONAUTH route(6) objects which are not announced? Do they serve any useful purpose? Regards Ed Shryane RIPE NCC

8 23

NWI-20: Solution definition and impact analysis
by Edward Shryane 20 Nov '25

20 Nov '25

Dear colleagues, As discussed at the DB-WG session at RIPE 91, following is a draft solution definition and impact analysis from the RIPE NCC for NWI-20: "adjusting contact method requirements and adding new methods". Please let me know any questions or comments. Regards Ed Shryane RIPE NCC --- Introduction ------------ Following discussion of the NWI proposal “adjusting contact method requirements and adding new methods” on the DB-WG mailing list [1], the Co-chairs declared the problem statement as NWI-20 and asked the RIPE NCC for further input on potential solutions. Following is a Solution Definition from the RIPE NCC including an impact analysis. Requirements ------------ The following requirements are proposed in NWI-20 [1]: * Align the contact method requirements between role and person objects used in admin-c and tech-c attributes. Make all such contact methods optional for the public RIPE Database as long as one is chosen. * Add support for new contact methods in the RIPE Database, including SIP (RFC 3969), Signal, Telegram, and WhatsApp. * Add support for RFC 8605 (ICANN Extensions for the Registration Data Access Protocol) and show the HTTPS intermediary and/or private URI where one is available. * E-mail is a mandatory attribute in role and person objects (additional requirement identified during discussion) This proposal is limited to admin-c and tech-c contact types. Existing RIPE Policy -------------------- The NWI-20 proposal is not a proposal to change policy requirements for contact methods, and has no impact on current RIPE policy. Current RIPE policy documents are listed on the RIPE NCC website [2]. Object Template Changes ----------------------- The RIPE NCC proposes the following changes to the object templates in the RIPE database to satisfy NWI-20 requirements: • The “e-mail” attribute becomes mandatory on person. • The “address” attribute becomes optional on both person and role. • The “phone” attribute becomes optional on person. • Add a new “contact:” as an optional attribute type on person, role, organisation, irt (see below). With these changes, the person object template becomes identical to the role template. E-mail Address is Mandatory in Administrative and Technical Contacts -------------------------------------------------------------------- The participants in the NWI discussion agreed that an e-mail address should be mandatory in “admin-c” and “tech-c” contacts. The “e-mail:” attribute is currently mandatory on organisation and role object types, but optional for person. We propose to change the “e-mail:” attribute to mandatory for person also. Creating or updating person objects will require at least one “e-mail:” attribute to be present. Address is Optional in Person and Role -------------------------------------- We propose to make the “address:” attribute optional in both person and role object types, to satisfy the requirement to make all contact types optional, so long as one is chosen. It will be up to the user to choose which of the available contact methods suits best their needs while ensuring that at least one contact method is available. Phone is Optional in Person --------------------------- We propose to make the “phone:” attribute optional in person to match the role type, to satisfy the requirement to make all contact types optional, so long as one is chosen. It will be up to the user to choose which of the available contact methods suits best their needs while ensuring that at least one contact method is available. Adding New Contact Types ------------------------ To support new contact types, we recommend adding a new “contact:” attribute type, that is optional and can appear multiple times on ORGANISATION, PERSON, ROLE and IRT object types. We will not change the definition of existing attributes already used as contacts. The RIPE NCC is not responsible for “contact:” attributes. All “contact:” attributes are maintained by the resource holder maintainer and are not managed or validated by the RIPE NCC. In particular it is the responsibility of the maintainer to ensure they have the right to insert the contact information in this attribute and ensure they will keep it correct and up-to-date. The syntax of a “contact:” attribute value is a URI. Any valid URI value will be accepted. If the specific application URI is recognised by Whois then it is further validated to be correct. We will add support for recognising more applications in the future. Initially, Whois will recognise and validate Whatsapp, Signal, Telegram and SIP contact URIs. Whatsapp A WhatsApp contact URI [3] uses the format https://wa.me/<number> or https://api.whatsapp.com/send?phone=<number>, where <number> is the full international phone number with country code, omitting any plus signs, parentheses, dashes, or leading zeros. You can also add a pre-filled message using ?text=urlencodedtext after the phone number. SIP A SIP contact URI [4] is a Session Initiation Protocol Uniform Resource Identifier used to identify a user or device on a SIP-based network, allowing for real-time communication sessions like voice and video calls. It follows a format similar to an email address, with the general syntax being sip:username@host[:port] Signal The Signal messaging app launched signal.me URls for this purpose back in 2021 [5]. It allows you to share a link like https://signal.me/#p/+447700900123 and have your signal client open up a chat with that person. Then, towards the end of 2022 they added support for their own sgnl scheme (although it doesn't appear to have been submitted as an IETF draft, and isn't listed on IANA). It has exactly the same layout as it's https sibling: sgnl://signal.me/#p/+447700900123. There is also support for usernames instead of the telephone number. Telegram A Telegram URI [6][7] can consist of any of the following formats : * https://t.me/share/url?url={url}&text={text} * https://telegram.me/share/url?url={url}&text={text} * tg://msg_url?url={url}&text={text} Adding New Contact Types to RDAP -------------------------------- A “contact:” attribute value will be represented in an RDAP entity object vCard “tel” element, as follows: * “type” element is set to both “voice” and “text”. * The “uri” element is set to the “contact:” attribute value. * “pref” is set according to the order of the “contact:” attribute in the object. According to RFC 6350 “vCard Format Specification”, section 6.4.1., it is expected that the “tel” value will be a “tel: URI scheme, but other schemes MAY be used. If a HTTP or HTTPS URI value is provided in the “contact:” attribute value, then we will add a contact vCard as defined in the Contact URI RDAP extension [8], as according to the RFC, at least one "mailto", "http", or "https" URI value MUST be provided for CONTACT-URI. The contact attribute type can be represented using the existing RDAP protocol so we do not need any new extension for it. Impact Analysis --------------- We foresee the following impacts on the RIPE database from these changes. * Creating person objects will require the “e-mail” attribute to be present. About 10,000 person objects are created monthly, by a few hundred maintainers. This change will cause the creation of person objects to fail if “e-mail” is missing. However, a descriptive error message in the update response will explain the cause of the failure, which can be used to resolve the issue. * Updating person objects will require the “e-mail” attribute to be present. There are about 2 million person objects in the database, and about half of them already have an “e-mail:” attribute. This change will cause updates of person objects to fail if “e-mail:” is missing. However, a descriptive error message in the update response will explain the cause of the failure, which can be used to resolve the issue. Also, about half of all person objects are never updated after they are created, so we expect a limited impact on existing objects. * Existing person objects may not conform to the new template. This can be mitigated by notifying maintainers of existing objects that the template has changed, so they can update objects accordingly. * Making mandatory attributes optional may cause some contact information not to be added and existing data to be removed. This information may be useful to other users. However, this may have the benefit of reducing the amount of unnecessary personal information in the database overall. Also it may reduce the amount of incorrect information just to satisfy the validation. There is no point adding contact information that is not useful. * Making an “admin-c” or “tech-c” reference to a person requires a mandatory contact. All contact methods besides the mandatory “e-mail” address will be optional so long as one is chosen. * A new, optional, “contact:” attribute will be added to person, role and organisation types. Client software that does not recognise this attribute should ignore it. However a “contact:” containing a telephone number should be considered equivalent to the “phone:” attribute. References ---------- 1. NWI-20 Proposal https://mailman.ripe.net/archives/list/db-wg@ripe.net/thread/6SIZ2AVFPD2ZXA… 2. RIPE Policies https://www.ripe.net/publications/docs/ripe-policies/ 3. Whatsapp “How to use Click to Chat” https://faq.whatsapp.com/5913398998672934 4. SIP URI Scheme https://en.wikipedia.org/wiki/SIP_URI_scheme 5. Signal URI Scheme https://shkspr.mobi/blog/2023/02/signals-newish-uri-scheme/ 6. Telegram URI Scheme https://stackoverflow.com/questions/56971172/telegram-uri-scheme-to-send-me… 7. Telegram Deep Links https://core.telegram.org/api/links 8. RFC 8605 (ICANN Extensions for the Registration Data Access Protocol) https://datatracker.ietf.org/doc/html/rfc8605

1 0

Proposal to Allow UTF-8 in “descr:” and “remarks” Attributes
by Edward Shryane 19 Nov '25

19 Nov '25

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/QEYKOWZBCVA6HN… 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-ri… 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-U… https://ripe90.ripe.net/wp-content/uploads/presentations/120-RIPE90-DB-WG-O… 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.

16 21