Appendix No. 1. Changes to Contact Object Validation Rules and Structure Status: Draft Version: 1.0 Publication Date: June 1, 2026 Owner: Kazakhstan Network Information Center (KazNIC) This document describes additional technical changes and EPP protocol extensions implemented by the KazNIC Registry. 1. Validation of Contact Object Attributes Additional requirements are introduced for field completion and formatting when creating () and updating () Contact objects. Mandatory Fields: - The name field is mandatory for individual persons. - The org field is mandatory for legal entities (organizations). Field Priority: If both the name and org fields are populated, the org field takes precedence, and the contact is classified as a legal entity. Character Encoding: All textual fields must be provided using Latin characters (transliteration), except for fields contained within the . Transliteration rules are defined in the files: [translit_ru.txt, translit_kk.txt]. 2. EPP Protocol Extension: "Contact Extension" An EPP extension named Contact Extension has been implemented to support the transmission of additional data. The extension allows inclusion of the Residence Details (residenceDetails) block within a Contact object. Purpose: To determine the legal status of the contact holder and enable identification within government information systems. Data Structure: The residenceDetails block contains: country of residence (e.g., KZ); externalIdType identifier type (e.g., BIN, IIN); externalIdValue identifier value. Documentation: The technical specification of the Contact Extension is provided in the file contact-ext-1.0.txt Examples of tax and civil identifiers for the top ten countries are provided in Top-10 Countries Identifier Reference Guide.txt Validation Rules: Validation of identifier format (externalIdType, externalIdValue) is performed only for residents of the Republic of Kazakhstan (country = KZ). For all other countries, identifier values are accepted in free format and are not subject to format validation beyond the supported reference values. 3. Restrictions for Contact Objects Acting as Registrants When a Contact object is assigned as the registrant of any domain name, additional data integrity controls apply: Mandatory Data: The Residence Details (residenceDetails) block is mandatory for any Contact object serving as a registrant. Immutable Fields: Once a Contact object has been assigned as a registrant, the following attributes become immutable: name, org, residenceDetails Error Handling: Any attempt to modify the above fields through the EPP command will result in the standard EPP error: 2306 (Data management policy violation) Modifiable Fields: The following fields remain available for modification: postal address, telephone number, email address Registrant Data Change Procedure: If changes to registrant identification data are required (name, org, or residenceDetails), a new Contact object must be created and subsequently assigned to the domain through a registrant change procedure (transfer of rights). 4. Testing and Validation All functional changes, validation rules, and protocol extensions described above have been deployed to the OT&E (Operational Test & Evaluation) EPP server. Availability: Registrars may begin updating and testing their software implementations. Recommendation: Before migrating to the production server, Registrars are strongly encouraged to perform end-to-end testing: from creating a contact with the residenceDetails extension to assigning that contact as a registrant.