Network Working Group P. Kowalik Internet-Draft DENIC Intended status: Standards Track M. Wullink Expires: 6 May 2027 SIDN Labs 2 November 2026 RESTful Provisioning Protocol (RPP) Data Objects draft-ietf-rpp-data-objects-02 Abstract This document defines data objects for the RESTful Provisioning Protocol (RPP) and sets up the IANA RPP Data Object Registry to describe and catalogue them. Specifically, it details the logical structure, constraints, and protocol operations (including their inputs, outputs, and business logic) for registry resources: domain names, contacts, hosts, organisations, users, and messages, as well as the discovery and profile objects that describe server capabilities. In accordance with the RPP architecture, these definitions focus entirely on the semantics, remaining independent of any specific data representation or media type (e.g., JSON or XML). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 6 May 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Kowalik & Wullink Expires 6 May 2027 [Page 1] Internet-Draft RPP Data Objects November 2026 Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 7 2. Resource Definition Principles . . . . . . . . . . . . . . . 9 2.1. Primitive Data Types . . . . . . . . . . . . . . . . . . 9 2.1.1. String . . . . . . . . . . . . . . . . . . . . . . . 9 2.1.2. Integer . . . . . . . . . . . . . . . . . . . . . . . 9 2.1.3. Boolean . . . . . . . . . . . . . . . . . . . . . . . 10 2.1.4. Decimal . . . . . . . . . . . . . . . . . . . . . . . 10 2.1.5. Date . . . . . . . . . . . . . . . . . . . . . . . . 10 2.1.6. Timestamp . . . . . . . . . . . . . . . . . . . . . . 10 2.1.7. URL . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.1.8. Binary . . . . . . . . . . . . . . . . . . . . . . . 10 2.1.9. Dictionary . . . . . . . . . . . . . . . . . . . . . 10 2.1.10. Object . . . . . . . . . . . . . . . . . . . . . . . 11 2.1.11. Fully Qualified Domain Name (FQDN) . . . . . . . . . 11 2.2. Data Element Abstraction . . . . . . . . . . . . . . . . 11 2.3. Extensibility . . . . . . . . . . . . . . . . . . . . . . 11 2.3.1. Standardised and Private Extensions . . . . . . . . . 11 2.3.2. Extension Points . . . . . . . . . . . . . . . . . . 12 2.4. Data Element Semantics . . . . . . . . . . . . . . . . . 12 2.5. Inheritance . . . . . . . . . . . . . . . . . . . . . . . 14 2.6. Reserved Property Names . . . . . . . . . . . . . . . . . 15 2.7. Operations . . . . . . . . . . . . . . . . . . . . . . . 15 2.7.1. Authorisation . . . . . . . . . . . . . . . . . . . . 15 2.7.2. Operation Input and Output . . . . . . . . . . . . . 15 2.7.3. Include Elements . . . . . . . . . . . . . . . . . . 16 2.7.4. Uniform interface . . . . . . . . . . . . . . . . . . 17 2.7.4.1. Create . . . . . . . . . . . . . . . . . . . . . 17 2.7.4.2. Read . . . . . . . . . . . . . . . . . . . . . . 17 2.7.4.3. Query . . . . . . . . . . . . . . . . . . . . . . 18 2.7.4.4. Update . . . . . . . . . . . . . . . . . . . . . 18 2.7.4.5. Delete . . . . . . . . . . . . . . . . . . . . . 18 2.7.4.6. Availability . . . . . . . . . . . . . . . . . . 18 2.7.5. Offline Review . . . . . . . . . . . . . . . . . . . 19 2.7.6. Operations Beyond Uniform Interface . . . . . . . . . 19 2.7.7. Transfer Operations . . . . . . . . . . . . . . . . . 19 2.7.7.1. Transfer Messages . . . . . . . . . . . . . . . . 20 2.7.8. Restore Operations . . . . . . . . . . . . . . . . . 21 2.7.9. Renew Operations . . . . . . . . . . . . . . . . . . 22 2.8. EPP Compatibility Profile . . . . . . . . . . . . . . . . 22 Kowalik & Wullink Expires 6 May 2027 [Page 2] Internet-Draft RPP Data Objects November 2026 3. Internationalized Domain Names (IDN) . . . . . . . . . . . . 23 4. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.1. Inheritance . . . . . . . . . . . . . . . . . . . . . . . 24 5. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6. External Data Types . . . . . . . . . . . . . . . . . . . . . 25 6.1. Referencing External Data Types . . . . . . . . . . . . . 25 6.2. Versioning and Compatibility . . . . . . . . . . . . . . 25 6.3. JSContact . . . . . . . . . . . . . . . . . . . . . . . . 25 7. Common Data Types . . . . . . . . . . . . . . . . . . . . . . 26 7.1. Identifier . . . . . . . . . . . . . . . . . . . . . . . 26 7.2. Client Identifier . . . . . . . . . . . . . . . . . . . . 26 7.3. Phone Number . . . . . . . . . . . . . . . . . . . . . . 26 8. Associations . . . . . . . . . . . . . . . . . . . . . . . . 27 8.1. Aggregation . . . . . . . . . . . . . . . . . . . . . . . 27 8.2. Composition . . . . . . . . . . . . . . . . . . . . . . . 28 8.3. Labelled Aggregation . . . . . . . . . . . . . . . . . . 29 8.4. Dictionary Aggregation . . . . . . . . . . . . . . . . . 30 8.5. Labelled Composition . . . . . . . . . . . . . . . . . . 30 8.6. Dictionary Composition . . . . . . . . . . . . . . . . . 31 9. Component Objects . . . . . . . . . . . . . . . . . . . . . . 32 9.1. Period Object . . . . . . . . . . . . . . . . . . . . . . 32 9.2. Provisioning Metadata Object . . . . . . . . . . . . . . 32 9.3. Domain Name Status Object . . . . . . . . . . . . . . . . 34 9.3.1. Status Values . . . . . . . . . . . . . . . . . . . . 35 9.3.2. Allowed Transitions . . . . . . . . . . . . . . . . . 37 9.3.3. Pending Status Removal . . . . . . . . . . . . . . . 39 9.3.4. Status Exclusions . . . . . . . . . . . . . . . . . . 40 9.3.5. Redemption Grace Period . . . . . . . . . . . . . . . 40 9.3.5.1. Allowed Transitions . . . . . . . . . . . . . . . 42 9.4. Host Status Object . . . . . . . . . . . . . . . . . . . 44 9.4.1. Status Values . . . . . . . . . . . . . . . . . . . . 44 9.4.2. Allowed Transitions . . . . . . . . . . . . . . . . . 46 9.4.3. Pending Status Removal . . . . . . . . . . . . . . . 48 9.4.4. Status Exclusions . . . . . . . . . . . . . . . . . . 48 9.5. Contact Status Object . . . . . . . . . . . . . . . . . . 49 9.5.1. Status Values . . . . . . . . . . . . . . . . . . . . 49 9.5.2. Allowed Transitions . . . . . . . . . . . . . . . . . 51 9.5.3. Pending Status Removal . . . . . . . . . . . . . . . 53 9.5.4. Status Exclusions . . . . . . . . . . . . . . . . . . 53 9.6. Organisation Role Status Object . . . . . . . . . . . . . 54 9.6.1. Status Values . . . . . . . . . . . . . . . . . . . . 54 9.6.2. Allowed Transitions . . . . . . . . . . . . . . . . . 55 9.6.3. Status Exclusions . . . . . . . . . . . . . . . . . . 56 9.7. Organisation Status Object . . . . . . . . . . . . . . . 57 9.7.1. Status Values . . . . . . . . . . . . . . . . . . . . 57 9.7.2. Allowed Transitions . . . . . . . . . . . . . . . . . 59 9.7.3. Pending Status Removal . . . . . . . . . . . . . . . 61 9.7.4. Status Exclusions . . . . . . . . . . . . . . . . . . 61 Kowalik & Wullink Expires 6 May 2027 [Page 3] Internet-Draft RPP Data Objects November 2026 9.8. User Status Object . . . . . . . . . . . . . . . . . . . 62 9.8.1. Status Values . . . . . . . . . . . . . . . . . . . . 63 9.8.2. Allowed Transitions . . . . . . . . . . . . . . . . . 64 9.8.3. Pending Status Removal . . . . . . . . . . . . . . . 65 9.8.4. Status Exclusions . . . . . . . . . . . . . . . . . . 65 9.9. DNS Resource Record Object . . . . . . . . . . . . . . . 65 9.9.1. RDATA Structures in EPP Profile . . . . . . . . . . . 66 9.10. DNS Operational Controls Object . . . . . . . . . . . . . 67 9.11. DNS Data Object . . . . . . . . . . . . . . . . . . . . . 68 9.12. Authorisation Information Object . . . . . . . . . . . . 69 9.13. Disclose Object . . . . . . . . . . . . . . . . . . . . . 70 9.14. Restore Report Object . . . . . . . . . . . . . . . . . . 70 9.15. Organisation Role Object . . . . . . . . . . . . . . . . 71 9.16. Processes Object . . . . . . . . . . . . . . . . . . . . 72 9.17. Base Process Object . . . . . . . . . . . . . . . . . . . 73 9.18. Availability . . . . . . . . . . . . . . . . . . . . . . 74 9.18.1. Base Availability Object . . . . . . . . . . . . . . 74 9.18.2. Domain Name Availability Object . . . . . . . . . . 74 9.18.3. Contact Availability Object . . . . . . . . . . . . 75 9.18.4. Host Availability Object . . . . . . . . . . . . . . 75 9.19. Messages . . . . . . . . . . . . . . . . . . . . . . . . 75 9.19.1. Base Message Object . . . . . . . . . . . . . . . . 75 9.19.2. Review Response Object . . . . . . . . . . . . . . . 76 9.19.3. Transfer Request Message Object . . . . . . . . . . 77 9.19.4. Transfer Outcome Message Object . . . . . . . . . . 78 9.19.5. Expiration Deletion Message Object . . . . . . . . . 79 9.19.6. Auto-Renewal Message Object . . . . . . . . . . . . 80 9.19.7. Service Notice Message Object . . . . . . . . . . . 80 9.20. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 81 9.20.1. Version Object . . . . . . . . . . . . . . . . . . . 81 9.20.2. Environment Object . . . . . . . . . . . . . . . . . 81 9.20.3. Extension Object . . . . . . . . . . . . . . . . . . 82 9.20.4. IDN LGR Object . . . . . . . . . . . . . . . . . . . 83 9.20.5. Notice Object . . . . . . . . . . . . . . . . . . . 83 10. Process Objects . . . . . . . . . . . . . . . . . . . . . . . 84 10.1. Transfer Process Object . . . . . . . . . . . . . . . . 84 10.1.1. Operations . . . . . . . . . . . . . . . . . . . . . 86 10.1.1.1. Create (Transfer Request) . . . . . . . . . . . 86 10.1.1.2. Read (Transfer Query) . . . . . . . . . . . . . 86 10.1.1.3. Delete (Transfer Cancel) . . . . . . . . . . . . 87 10.1.1.4. Approve . . . . . . . . . . . . . . . . . . . . 87 10.1.1.5. Reject . . . . . . . . . . . . . . . . . . . . . 88 10.2. Restore Process Object . . . . . . . . . . . . . . . . . 88 10.2.1. Operations . . . . . . . . . . . . . . . . . . . . . 90 10.2.1.1. Create (Restore Request) . . . . . . . . . . . . 90 10.2.1.2. Read (Restore Query) . . . . . . . . . . . . . . 91 10.2.1.3. Update (Restore Report) . . . . . . . . . . . . 91 10.3. Renew Process Object . . . . . . . . . . . . . . . . . . 92 Kowalik & Wullink Expires 6 May 2027 [Page 4] Internet-Draft RPP Data Objects November 2026 10.3.1. Operations . . . . . . . . . . . . . . . . . . . . . 93 10.3.1.1. Create (Renew Request) . . . . . . . . . . . . . 93 10.4. Create Process Object . . . . . . . . . . . . . . . . . 93 10.4.1. Operations . . . . . . . . . . . . . . . . . . . . . 94 10.4.1.1. Create . . . . . . . . . . . . . . . . . . . . . 94 10.4.1.2. Read . . . . . . . . . . . . . . . . . . . . . . 94 11. Domain Name Data Object . . . . . . . . . . . . . . . . . . . 94 11.1. Object Description . . . . . . . . . . . . . . . . . . . 94 11.2. Data Elements . . . . . . . . . . . . . . . . . . . . . 95 11.3. Operations . . . . . . . . . . . . . . . . . . . . . . . 99 11.3.1. Availability Operation . . . . . . . . . . . . . . . 99 11.3.2. Create Operation . . . . . . . . . . . . . . . . . . 100 11.3.3. Read Operation . . . . . . . . . . . . . . . . . . . 101 11.3.4. Update Operation . . . . . . . . . . . . . . . . . . 102 11.3.5. Delete Operation . . . . . . . . . . . . . . . . . . 102 11.4. Processes . . . . . . . . . . . . . . . . . . . . . . . 102 11.4.1. Domain Create Process Object . . . . . . . . . . . . 103 11.4.1.1. Operations . . . . . . . . . . . . . . . . . . . 103 11.4.2. Domain Transfer Process Object . . . . . . . . . . . 104 11.4.2.1. Operations . . . . . . . . . . . . . . . . . . . 105 12. Contact Data Object . . . . . . . . . . . . . . . . . . . . . 105 12.1. Object Description . . . . . . . . . . . . . . . . . . . 105 12.2. Data Elements . . . . . . . . . . . . . . . . . . . . . 106 12.3. Operations . . . . . . . . . . . . . . . . . . . . . . . 108 12.3.1. Availability Operation . . . . . . . . . . . . . . . 108 12.3.2. Create Operation . . . . . . . . . . . . . . . . . . 108 12.3.3. Read Operation . . . . . . . . . . . . . . . . . . . 109 12.3.4. Update Operation . . . . . . . . . . . . . . . . . . 109 12.3.5. Delete Operation . . . . . . . . . . . . . . . . . . 110 12.4. Processes . . . . . . . . . . . . . . . . . . . . . . . 110 13. Host Data Object . . . . . . . . . . . . . . . . . . . . . . 110 13.1. Object Description . . . . . . . . . . . . . . . . . . . 110 13.2. Data Elements . . . . . . . . . . . . . . . . . . . . . 111 13.3. Operations . . . . . . . . . . . . . . . . . . . . . . . 112 13.3.1. Availability Operation . . . . . . . . . . . . . . . 112 13.3.2. Create Operation . . . . . . . . . . . . . . . . . . 113 13.3.3. Read Operation . . . . . . . . . . . . . . . . . . . 113 13.3.4. Update Operation . . . . . . . . . . . . . . . . . . 113 13.3.5. Delete Operation . . . . . . . . . . . . . . . . . . 114 13.4. Processes . . . . . . . . . . . . . . . . . . . . . . . 114 14. Organisation Data Object . . . . . . . . . . . . . . . . . . 115 14.1. Object Description . . . . . . . . . . . . . . . . . . . 115 14.2. Data Elements . . . . . . . . . . . . . . . . . . . . . 115 14.3. Operations . . . . . . . . . . . . . . . . . . . . . . . 118 14.3.1. Create Operation . . . . . . . . . . . . . . . . . . 118 14.3.2. Read Operation . . . . . . . . . . . . . . . . . . . 118 14.3.3. Update Operation . . . . . . . . . . . . . . . . . . 118 14.3.4. Delete Operation . . . . . . . . . . . . . . . . . . 119 Kowalik & Wullink Expires 6 May 2027 [Page 5] Internet-Draft RPP Data Objects November 2026 15. Message Data Object . . . . . . . . . . . . . . . . . . . . . 119 15.1. Object Description . . . . . . . . . . . . . . . . . . . 119 15.2. Data Elements . . . . . . . . . . . . . . . . . . . . . 120 15.3. Operations . . . . . . . . . . . . . . . . . . . . . . . 120 15.3.1. Create Operation . . . . . . . . . . . . . . . . . . 120 15.3.2. Read Operation . . . . . . . . . . . . . . . . . . . 121 15.3.3. Query Operation . . . . . . . . . . . . . . . . . . 121 15.3.4. Delete Operation . . . . . . . . . . . . . . . . . . 122 16. User Object . . . . . . . . . . . . . . . . . . . . . . . . . 122 16.1. Object Description . . . . . . . . . . . . . . . . . . . 122 16.2. Data Elements . . . . . . . . . . . . . . . . . . . . . 122 16.3. Operations . . . . . . . . . . . . . . . . . . . . . . . 123 16.3.1. Create Operation . . . . . . . . . . . . . . . . . . 123 16.3.2. Read Operation . . . . . . . . . . . . . . . . . . . 124 16.3.3. Update Operation . . . . . . . . . . . . . . . . . . 124 16.3.4. Delete Operation . . . . . . . . . . . . . . . . . . 124 17. Discovery Data Object . . . . . . . . . . . . . . . . . . . . 125 17.1. Object Description . . . . . . . . . . . . . . . . . . . 125 17.2. Data Elements . . . . . . . . . . . . . . . . . . . . . 125 17.3. Operations . . . . . . . . . . . . . . . . . . . . . . . 127 17.3.1. Read Operation . . . . . . . . . . . . . . . . . . . 127 18. Profile Data Object . . . . . . . . . . . . . . . . . . . . . 128 18.1. Object Description . . . . . . . . . . . . . . . . . . . 128 18.2. Data Elements . . . . . . . . . . . . . . . . . . . . . 128 18.3. Operations . . . . . . . . . . . . . . . . . . . . . . . 130 18.3.1. Read Operation . . . . . . . . . . . . . . . . . . . 130 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 130 19.1. RPP Registry Group . . . . . . . . . . . . . . . . . . . 131 19.2. RPP Data Object Registry . . . . . . . . . . . . . . . . 131 19.2.1. Registration Policy . . . . . . . . . . . . . . . . 131 19.2.2. Registry Structure . . . . . . . . . . . . . . . . . 131 19.2.3. Initial Registrations . . . . . . . . . . . . . . . 132 19.3. RPP User Role Values Registry . . . . . . . . . . . . . 197 19.4. RPP Domain Name Status Values Registry . . . . . . . . . 197 19.4.1. Initial Registrations . . . . . . . . . . . . . . . 198 19.5. RPP Host Status Values Registry . . . . . . . . . . . . 203 19.5.1. Initial Registrations . . . . . . . . . . . . . . . 204 19.6. RPP Contact Status Values Registry . . . . . . . . . . . 206 19.6.1. Initial Registrations . . . . . . . . . . . . . . . 207 19.7. RPP Organisation Role Status Values Registry . . . . . . 210 19.7.1. Initial Registrations . . . . . . . . . . . . . . . 210 19.8. RPP Organisation Status Values Registry . . . . . . . . 211 19.8.1. Initial Registrations . . . . . . . . . . . . . . . 212 19.9. RPP User Status Values Registry . . . . . . . . . . . . 215 19.9.1. Initial Registrations . . . . . . . . . . . . . . . 215 19.10. URN Sub-namespace for RPP (urn:ietf:params:rpp) . . . . 216 19.11. RPP Discovery Registry . . . . . . . . . . . . . . . . . 217 19.12. RPP Extension Registry . . . . . . . . . . . . . . . . . 217 Kowalik & Wullink Expires 6 May 2027 [Page 6] Internet-Draft RPP Data Objects November 2026 19.13. RPP Profile Registry . . . . . . . . . . . . . . . . . . 218 20. Security Considerations . . . . . . . . . . . . . . . . . . . 218 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 221 22.1. Normative References . . . . . . . . . . . . . . . . . . 221 22.2. Informative References . . . . . . . . . . . . . . . . . 224 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 224 1. Introduction The RESTful Provisioning Protocol (RPP) defines a set of data objects used to represent and manage registry resources, including domain names, contacts, hosts, organisations, users, and messages, as well as the discovery and profile objects that describe server capabilities. This initial list is not exhaustive; additional resource and component objects MAY be defined in future revisions or introduced via IANA registration to support new features and operational needs. In accordance with the RPP architecture [I-D.ietf-rpp-architecture], a core architectural principle is the clear distinction between the abstract data model and its concrete data representation. The data model defines the logical structure, relationships, and constraints of the objects, independent of formatting. The data representation defines how these abstract concepts are expressed in specific formats (e.g., JSON, XML, or YAML). This document focuses on the data model of RPP objects and operations on them, including the data model of operation inputs, outputs as well as the necessary business logic of state transitions. This separation of concerns ensures the protocol maintains a stable semantic foundation that can be consistently implemented across different media types and easily adapted to new representation formats. For instance, the model defines a contact's name as a required string type, but it remains agnostic as to whether that string is ultimately encoded as a JSON property or an XML element. 1.1. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. The following terms related to the relationship between host objects and domain objects are used as defined in Section 1.1 of [RFC5732]: Subordinate host A host name object is a subordinate host of a Kowalik & Wullink Expires 6 May 2027 [Page 7] Internet-Draft RPP Data Objects November 2026 domain when the host name consists of one or more labels followed by the name of that domain, for example, host ns1.domain.example is a subordinate host of domain domain.example. Superordinate domain A domain name object is the superordinate domain of a host when the name of the host consists of one or more labels followed by the name of that domain, for example, domain domain.example is the superordinate domain of host ns1.domain.example. Internal host A host whose name belongs to the namespace of the repository in which the host is being used for delegation purposes. External host A host whose name does not belong to the namespace of the repository in which the host is being used for delegation purposes. Object Authorisation Authorisation data related to the object beyond the default client-level authorisation accompanying the request, in order to authorise operations on the object. Typically it is a value related to or derived from an Authorisation Information Object provisioned with the object. Data Object A top-level provisioned resource object that has an independent lifecycle and identity in the registry. Data Objects carry data elements describing the resource and define the set of operations that can be performed on them. Component Object A reusable data structure that carries data only, with no operations of its own. Component Objects are embedded within Data Objects or other objects to avoid repetition of common data patterns. Process Object An object that represents a long-running or multi- step operation initiated on a Data Object. Process Objects carry operation-related state and data, and may define their own operations to interact with the process. They have no independent existence - their lifecycle is bound to the owning Data Object. Owner Data Object A Data Object which a process (represented as Process Object) was initiated upon and which owns this Process Object. Unique Identifier The data element of an object whose value uniquely identifies an instance of that object within its applicable scope. The scope is defined by the object: for a Data Object it is typically the server, whereas for a Process Object it is the Owner Data Object. An object definition names its Unique Identifier explicitly in the object preamble. Objects that have no independent identity, such as component objects embedded within another object, have no Unique Identifier. Input Data Element A data element that a client provides as input to a specific operation, in addition to the identifier or data elements of the object the operation targets, and that carries content the operation acts upon. An input data element is defined as part of the operation definition and is not part of the state Kowalik & Wullink Expires 6 May 2027 [Page 8] Internet-Draft RPP Data Objects November 2026 of the object. An input data element is described using the attributes defined in Section 2.4, except Direct Access, and Visibility, which do not apply. Parameter A data element that a client provides with an operation to control how the server performs the operation or which data it returns. Unlike an Input Data Element, a parameter does not carry content that the operation acts upon. A parameter is not part of the state of the object and is never returned as part of the object. A parameter is described using the same attributes as an Input Data Element, and its definition specifies the behaviour of the operation when the parameter is absent. Label Generation Ruleset (LGR) A set of rules defining the valid labels for a registry, including the permitted repertoire, contextual rules, and, where applicable, variant mappings. Also historically known as IDN tables. 2. Resource Definition Principles 2.1. Primitive Data Types RPP data elements use strict typing, meaning that each element must conform exactly to its declared primitive data type, and type violations MUST be treated as errors by implementations. The exact specifications for these types, including allowed ranges, encoding, and formatting, are determined by the representation format used (e.g., JSON, XML, CBOR). New RPP non-primitive data types based on existing primitive data types MAY be defined to support additional features. 2.1.1. String A String is a sequence of Unicode characters. Usages MAY impose additional constraints on string values, such as maximum length or allowed character sets, based on specific data element definitions. An example of a string is "host.example". 2.1.2. Integer An Integer is a whole number, positive or negative. Usages MAY impose additional constraints on integer values, such as minimum and maximum allowable values, based on specific data element definitions. An example of an integer is 42. Kowalik & Wullink Expires 6 May 2027 [Page 9] Internet-Draft RPP Data Objects November 2026 2.1.3. Boolean A Boolean represents a logical true or false value. An example of a boolean is true or false, but it MAY be different depending on the native encoding of boolean values in the representation. 2.1.4. Decimal A Decimal is a number providing an exact, base-10 representation of fractional values within a defined precision. Usage of this type MUST impose additional constraints on decimal values, such as precision or range, based on specific data element definitions. An example of a decimal is 3.14159. 2.1.5. Date A Date is a full-date calendar date as described in [RFC3339], an example of a date is 2025-10-27. 2.1.6. Timestamp Timestamp (Date and time attribute) values MUST be represented in Coordinated Universal Time (UTC) using the Gregorian calendar in date-time form as defined in [RFC3339]. In EPP Compatibility Profile upper case "T" and "Z" characters MUST be used. An example of a timestamp is 2025-10-27T09:42:51Z. 2.1.7. URL A Uniform Resource Locator (URL) as defined in [RFC1738]. An example of a URL is "https://host.example". 2.1.8. Binary Raw binary data, implementations MAY choose how to encode the binary data, for example as base64 or hexadecimal string. An example of binary data encoded as base64 is "UlBQIFNheXMgSGk=". 2.1.9. Dictionary Notation: Dictionary[Value Type] A Dictionary is a collection of key-value pairs where keys are unique Strings and values are of the specified primitive data type. Usages MUST define the constraints on allowed keys and values. A Dictionary differs from an Dictionary Aggregation in that it maps String keys to primitive values rather than to Component or Resource Objects. Kowalik & Wullink Expires 6 May 2027 [Page 10] Internet-Draft RPP Data Objects November 2026 2.1.10. Object An Object is a composite structure containing named properties. The set of allowed property names, their data types, and their constraints are determined by the data element definition that uses this type. Usages MUST specify the expected structure, including any required or optional properties. An Object differs from a Component Object in that it is defined inline as part of a data element rather than being a standalone reusable definition registered separately. 2.1.11. Fully Qualified Domain Name (FQDN) A String that represents a Fully Qualified Domain Name (FQDN) that conforms to the description included in section 2 of [RFC9499] and includes the following additional restrictions: * The trailing dot required when these names are stored in a DNS zone is implicit and MUST NOT be used in RPP, with the exception of the name element of the DNS Resource Record Object. * Internationalized domain names MUST be represented in ASCII Compatible Encoding (ACE) using the A-label, defined in Section 2.3.2.1 of [RFC5890] * Case-insensitive comparison MUST be used when comparing two FQDNs. * All representations generated by the server are to be in lowercase. 2.2. Data Element Abstraction Each data object is composed of logical data elements. A data element is a logical unit of information identified by a stable name, independent of its representation in any given media type. The definition for each element specifies its logical name, purpose, cardinality, data type, and constraints. The data type of a data element may also be a reference to another data object, using the target object's stable name. 2.3. Extensibility The RPP data model is designed to be extensible. Extensions MAY introduce new data objects, add new data elements or associations to existing objects, define new processes on existing or new data objects, and define new operations or extend the inputs and outputs of existing operations. 2.3.1. Standardised and Private Extensions RPP distinguishes between standardised and private extensions: Kowalik & Wullink Expires 6 May 2027 [Page 11] Internet-Draft RPP Data Objects November 2026 * Standardised extensions MUST be registered with IANA, as described in the IANA Considerations section of this document and in [I-D.ietf-rpp-architecture]. Registration ensures global uniqueness of extension identifiers and promotes interoperability across implementations. * Private (non-standardised) extensions MAY be defined for use within specific implementations or organisations. Private extensions are not required to be registered with IANA, but MUST still use unique identifiers that are unlikely to conflict with standardised extensions or other private extensions. The use of reverse domain notation as a prefix (e.g., org.example.rpp.myElement) is RECOMMENDED for private extension identifiers to avoid naming collisions. 2.3.2. Extension Points The following aspects of the data model are extensible: * New data objects: Additional resource or component objects MAY be defined by extensions and registered with IANA. * New data elements: Extensions MAY add new data elements to existing data objects. Such elements follow the same Data Element Semantics as core data elements. * New associations: Extensions MAY introduce new associations between existing or new objects. * New operations: Extensions MAY define entirely new operations on existing or new data objects. * New processes: Extensions MAY define new Process Objects and MAY declare that existing or new Data Objects support them. A new Process Object MUST extend the Base Process Object, either directly or through another Process Object. * Extended operation inputs and outputs: Extensions MAY add new data elements to the inputs or outputs of existing operations. When an extension adds data elements, input data elements, or parameters to a core object or operation, these additions MUST NOT alter the semantics or constraints of existing core data elements. 2.4. Data Element Semantics The definition of each data element within an object consists of the following attributes: * Name: A human-readable name for the data element. * Identifier: A machine-readable, unique identifier for the element, using camelCase notation. Kowalik & Wullink Expires 6 May 2027 [Page 12] Internet-Draft RPP Data Objects November 2026 * Cardinality: Specifies the number of times an element may appear. The notation is as follows: - 1 for exactly one - 0-1 for zero or one - 0+ for zero or more - 1+ for one or more - and X-Y for at least X and at most Y, where X and Y are non- negative integers, X is less than Y, and Y is greater than 1, e.g. 1-2 for one or two * Data Type: Defines the element's data structure, which can be a primitive type, a Common Data Type or a reference to another component object. * Description: Explains the purpose of the data element and any other relevant information. * Constraints: Provides specific validation rules or limitations on top of the data type itself, such as value ranges. * Mutability: Defines the lifecycle of the data element's value. It MUST be one of the following: - create-only: The element's value is provided during the object's creation and cannot be modified thereafter. After object's creation the element behaves like read-only element. - read-only: The element's value is managed by the server. It cannot be set or modified directly by the client, though it may change as a result of server-side operations. - read-write: The element's value can be set and modified by the client. * Direct Access: An optional flag indicating whether the associated object or objects are additionally exposed as an addressable sub- resource of the containing object. When set to true, the associated object or objects are exposed as a sub-resource that can be addressed independently of the containing object, in addition to their inline representation within it. When absent or set to false, the element is accessed only inline. The default value is false. A data element is required when the lower bound of its cardinality is greater than zero (1, 1+, or X-Y with X greater than 0); otherwise it is optional. The Direct Access flag is applicable only to a data element whose Data Type is an association (Aggregation, Composition, Labelled Aggregation, Dictionary Aggregation, Labelled Composition, or Dictionary Composition) with a Data Object, Component Object, or Process Object, of any cardinality. Where such a data element has a cardinality greater than 1, the associated object type MUST define a Unique Identifier, so that an individual associated object can be addressed unambiguously among the collection. * Visibility: An optional attribute indicating whether the data element is included in Kowalik & Wullink Expires 6 May 2027 [Page 13] Internet-Draft RPP Data Objects November 2026 operation output by default. It MUST be one of the following: * default: The element is included in the output of any operation returning the containing object, subject to authorisation and server policy. This value applies when the attribute is absent. * onDemand: The element is included in the output only when the client explicitly requests it using the Include Elements parameter (see Section 2.7.3), subject to authorisation and server policy. The Visibility attribute affects operation output only. It does not affect whether a client can provide the element as input. 2.5. Inheritance A Data Object, Component Object or Process Object (the "derived object") MAY inherit the data elements and operations of another object (the "base object"). Inheritance is denoted in the preamble of the derived object's definition using the Extends keyword, whose value is the name of the base object, for example: * Name: Domain Create Process Object * Identifier: domainCreateProcess * Extends: Create Process Object The following rules apply: * Single inheritance: an object MUST extend at most one base object. * Transitivity: the base object MAY itself extend another object. Inheritance is transitive, so a derived object inherits the data elements and operations of every ancestor in its chain. An object MUST NOT directly or indirectly extend itself. * Inherited content: a derived object has all data elements of its base object, including their cardinality, mutability, data type and constraints, and supports all operations of its base object. Inherited data elements and operations are not repeated in the derived object's definition. * Additions: a derived object MAY define additional data elements and operations. It MUST NOT define a data element whose identifier is already defined by any of its ancestors. A derived object MAY modify the inherited operation input and output data as needed. * Polymorphism: where a data element or operation refers to a base object, any object that directly or indirectly extends the base object MAY be used in its place. * Abstract objects: an object MAY be declared abstract using the Abstract keyword in the preamble of its definition, with the value true. When the Abstract keyword is absent or set to false, the object is not abstract. An abstract object serves only as a base object for its derived objects. Wherever a data element or Kowalik & Wullink Expires 6 May 2027 [Page 14] Internet-Draft RPP Data Objects November 2026 operation refers to an abstract object, an instance of a non- abstract object that directly or indirectly extends it is used in its place. A client MUST NOT provide, and a server MUST NOT return, an instance whose own type is an abstract object. The Abstract keyword is not inherited. 2.6. Reserved Property Names Data object definitions MUST NOT define properties whose names begin with the @ character. Names beginning with @ are reserved for use by representation specifications. This prohibition applies to all data object types: resource objects, component objects, and process objects. 2.7. Operations For each data object a set of possible operations is defined together with their respective input and output data. 2.7.1. Authorisation For each operation authorisation requirements and operation behaviour are specified. Wherever "Object Authorisation" is mentioned, it means that an operation MAY accept or require additional authorisation data related to the object beyond default client-level authorisation, or that an operation MAY result in different processing or response if such authorisation is provided. 2.7.2. Operation Input and Output The input and output of an operation are declared by the Input and Output attributes of the operation definition. The value of each attribute is either a literal (None) or a list of items, each of one of the following kinds: * Reference: a reference to the context of operation or process. It can contain either a literal value This Object for the object that defines the operation, or literal value Owner Data Object for the Owner Data Object of a Process Object. * Object: The name of the object type in the input or output. It can contain either the type or a literal value This Object for the object type that defines the operation, or literal value Owner Data Object for the type of Owner Data Object of a Process Object. It specifies an additional attribute: Kowalik & Wullink Expires 6 May 2027 [Page 15] Internet-Draft RPP Data Objects November 2026 - Cardinality: [OPTIONAL] the number of representations, in the notation defined in Section 2.4. The default value is 1. * Input Data Elements: the input data elements of the operation, listed in the same form as the Data Elements of an object: each entry is the Name of an input data element, followed by its attributes as defined in Section 2.4, except Mutability, Direct Access and Visibility. It is allowed in Input only, at most once. * Parameters: the parameters of the operation, listed in the same form as Input Data Elements. It is allowed in Input only, at most once. For example: * Input: * Reference: Owner Data Object * Object: Transfer Process Object * Output: * Object: Transfer Process Object 2.7.3. Include Elements The includeElements parameter is defined for every operation whose output contains one or more objects, including, but not limited to, the Uniform Interface operations and the operations of Process Objects. It allows a client to request specific data elements to be included in the operation output in addition to those included by default. Individual operation definitions do not repeat it. * Include Elements - Identifier: includeElements - Cardinality: 0-1 - Data Type: String - Description: A comma-separated list of Identifiers of data elements that the client requests to be included in the operation output. - Constraints: Each list item is the Identifier of a top-level data element of the object or objects returned by the operation. Data elements nested within component objects or other associated objects cannot be listed. Identifiers are case-sensitive. The list contains no whitespace. Kowalik & Wullink Expires 6 May 2027 [Page 16] Internet-Draft RPP Data Objects November 2026 A listed Identifier refers to the data element as a whole. For a data element with a cardinality of 0+, 1+, or X-Y, it refers to the entire collection of values, and individual values cannot be selected. For a data element whose Data Type is a component object or an association, it refers to the complete associated object or objects. The server processes this data element as follows: * If includeElements is absent, the server MUST NOT include any data element with onDemand Visibility in the output. * If a listed Identifier is not the Identifier of a top-level data element defined for the returned object, including data elements defined by extensions not supported by the server, the server MUST reject the request with an error. * For each listed Identifier, the server MUST include the referenced data element in the output if it is present on the object and the client is authorised to view it. Otherwise the element is omitted without an error. Listing a data element that is already included in the output by default has no effect. The parameter thereby remains applicable where an operation or a representation defines an output that omits some elements by default. 2.7.4. Uniform interface For the Create, Read, Query, Update and Delete operations of a Data Object, the following Input and Output apply, using the notation defined in Section 2.7.2. An operation definition that declares its own Input or Output attribute replaces the corresponding default. 2.7.4.1. Create * Input: - Object: This Object * Output: - Object: This Object 2.7.4.2. Read * Input: - Reference: This Object * Output: - Object: This Object Kowalik & Wullink Expires 6 May 2027 [Page 17] Internet-Draft RPP Data Objects November 2026 The output Object MAY vary depending on the identity of the querying client, use of Object Authorisation information, and server policy towards unauthorised clients. If the querying client is the sponsoring client, all available information MUST be returned, except data elements with onDemand Visibility not requested using includeElements (see Section 2.7.3). If the querying client is not the sponsoring client but the client provides valid Object Authorisation information, all available information SHOULD be returned, however some optional elements MAY be reserved to the sponsoring client only. If the querying client is not the sponsoring client and the client does not provide valid Object Authorisation information, server policy determines which OPTIONAL elements are returned, if any, or whether the entire request is rejected. 2.7.4.3. Query * Input: (None) * Output: - Object: This Object o Cardinality: 0+ 2.7.4.4. Update * Input: - Reference: This Object - Object: This Object * Output: - Object: This Object 2.7.4.5. Delete * Input: - Reference: This Object * Output: - Object: This Object o Cardinality: 0-1 2.7.4.6. Availability * Input: - Reference: This Object * Output: - Object: Base Availability Object Kowalik & Wullink Expires 6 May 2027 [Page 18] Internet-Draft RPP Data Objects November 2026 The Availability operation allows a client to determine whether the object identified by the Reference can be created using the Create operation at the time of the request. The referenced object does not need to exist. The operation does not create, reserve, or otherwise change the state of any object. A Data Object that supports the Availability operation declares as its Output an Availability Object that extends the Base Availability Object (see Section 9.18). Extensions MAY add parameters that further specify the check and data elements to the Availability Objects. 2.7.5. Offline Review RPP allows for offline review for operations that change the state of an object (Uniform Interface Create, Update, Delete, and the Renew and Transfer process operations) before the requested action is actually completed. In such situations, the response from the server MUST clearly indicate that the operation has been received, but that the requested action is pending. The state of the corresponding object MUST clearly reflect processing of the pending action, typically through a server-set pending status label (e.g. pendingCreate, pendingUpdate, pendingDelete, pendingRenew, pendingTransfer). The server MUST also notify the client when offline processing of the action has been completed, by sending a review-response message (see Section 5). 2.7.6. Operations Beyond Uniform Interface For all other operations both input and output have to be fully specified. 2.7.7. Transfer Operations Transfer operations manage the change of sponsorship of a provisioned object from one client (the sponsoring client) to another (the gaining client). They are specified once in this section as the transfer model is common across all transferable resource objects. Individual object definitions reference this section and specify any object-specific extensions to the common pattern. RPP supports two types of transfer: * Pull Transfer: Initiated by the gaining client. The gaining client MUST provide valid Object Authorisation to initiate the request. Kowalik & Wullink Expires 6 May 2027 [Page 19] Internet-Draft RPP Data Objects November 2026 * Push Transfer: Initiated by the sponsoring client, who designates a gaining client in the request. The transfer process MAY be immediate or follow a multi-step workflow depending on server policy. If the server implements immediate transfers, the Approve and Reject operations need not be supported; the server completes the transfer upon receipt of the Create operation. The server MAY implement local policies to prevent transfers from stalling and implement a form of automated transfer escalation, approval or cancellation when such a stalled process is recognised. All transfer operations act on or return the Transfer Process Object and are executed in the context of the Owner Data Object the operation is created upon. If the server does not directly approve a pull transfer request and the current sponsoring client first approve the transfer request, the server MUST wait for the sponsoring client's decision before proceeding. If the sponsoring client approves, the server completes the transfer; if the sponsoring client rejects, the server cancels the transfer. The server MUST send a transfer-request message to the sponsoring client. For a pending push transfer, the server MUST send a transfer-request message to the designated gaining client that must act on it. If the server directly approves a transfer, it MUST send a transfer-outcome message to the client managing the object before the transfer. When a transfer is resolved after the currently managing client's decision, the server MUST send a transfer-outcome message to the requesting client. 2.7.7.1. Transfer Messages The Pull Transfer Direct Approval Message Diagram (#fig-pull- transfer-direct-approval) illustrates the sequence of messages exchanged during a pull transfer with direct approval. The Pull Transfer Pending Approval Message Diagram (#fig-pull-transfer- pending-approval) illustrates the sequence of messages exchanged during a pull transfer that requires approval. The Push Transfer Message Diagram (#fig-push-transfer) illustrates the sequence of messages exchanged during a push transfer. For a pull transfer, the requesting client is the gaining client; for a push transfer, the requesting client is the sponsoring client. The messages in the diagrams are surrounded by square brackets to indicate message types. Pull transfer (direct approval): Kowalik & Wullink Expires 6 May 2027 [Page 20] Internet-Draft RPP Data Objects November 2026 Gaining Client Server Sponsoring Client | | | |--- transferCreate --->| | | | | | Direct approval | | |--- [transfer-outcome] -->| | | | Figure 1: Pull Transfer Direct Approval Message Pull transfer (pending approval): Gaining Client Server Sponsoring Client | | | |--- transferCreate ----->| | | | | | | | | Pending approval | | |--- [transfer-request] -->| | |<-- approve / reject -----| |<-- [transfer-outcome] --| | Figure 2: Pull Transfer Pending Approval Message Push transfer: Sponsoring Client Server Gaining Client | | | |--- transferCreate ----->| | | |--- [transfer-request] --->| | |<-- approve / reject ------| |<-- [transfer-outcome] --| | Figure 3: Push Transfer Message Diagram | TODO: Transfer-specific error conditions (object not eligible | for transfer, object pending transfer, object not pending | transfer) are not defined in this document. 2.7.8. Restore Operations Restore operations manage the recovery of an object that has entered the Redemption Grace Period (RGP). They are OPTIONAL and are only available when the RGP feature is supported by the server and MAY be supported only for a subset of Data Object types. The RGP process MAY involve two distinct steps: Kowalik & Wullink Expires 6 May 2027 [Page 21] Internet-Draft RPP Data Objects November 2026 * Restore Request: (REQUIRED) Initiates the recovery of an object in the rgpRedemptionPeriod state, signalling to the registry the intent to restore. This corresponds to the Create operation on the Restore Process Object. On success, the object transitions to rgpPendingRestore. * Restore Report: (OPTIONAL) Submits a report documenting the circumstances of the deletion and restoration, as required by registry policy. This corresponds to the Update operation on the Restore Process Object. On success, the object is returned to its pre-deletion status and all RGP status labels are removed. Whether a restore report is required after a restore request is a matter of server policy. If the server does not require a restore report, the object returns to its pre-deletion status immediately upon a successful Create operation, bypassing the rgpPendingRestore state. The Create operation MAY include the restore report, provided as the restoreReport data element, to complete both steps atomically in a single operation. All restore operations act on or return the Restore Process Object and are executed in the context of the Owner Data Object the operation is created upon. 2.7.9. Renew Operations Renew operations manage the validity period of a provisioned object. They are specified once in this section as the renewal model is common across all renewable resource objects. Individual object definitions reference this section and specify any object-specific extensions to the common pattern. 2.8. EPP Compatibility Profile RPP is designed to coexist with the Extensible Provisioning Protocol (EPP), often operating in parallel against a common backend provisioning system. While RPP is not inherently constrained by all of EPP's requirements, a specific set of rules is necessary to ensure seamless interoperability in such mixed environments. To address this, this document defines an "EPP Compatibility Profile". This profile specifies a set of additional constraints on RPP data objects and operations that a server MUST adhere to when supporting both RPP and EPP concurrently. Kowalik & Wullink Expires 6 May 2027 [Page 22] Internet-Draft RPP Data Objects November 2026 Throughout this document, all constraints that are part of this profile are explicitly marked with a reference to "EPP Compatibility Profile". Implementers of systems in a mixed EPP/RPP environment MUST follow these specific constraints in addition to the base RPP requirements. 3. Internationalized Domain Names (IDN) Internationalized Domain Names (IDN) are domain names that include one or more non-ASCII characters. IDNs are represented in the Domain Name System (DNS) using ASCII Compatible Encoding (ACE), commonly known as Punycode. This allows the DNS to handle Unicode domain names while maintaining compatibility with the existing ASCII-based infrastructure. 4. Profiles A profile is a named set of protocol features and versions that are used to define the compatibility and capabilities of RPP server implementations, allowing for better interoperability between different implementations. Using profiles helps to simplify the implementation and deployment of RPP by providing a clear and concise way for the client and server to communicate their capabilities and requirements. A profile is identified by a unique name and may be published as a standard profile in the IANA registry for RPP profiles, to promote interoperability and standardisation across implementations. Standard profile names MUST use the RPP URN namespace defined in this document, for example: urn:ietf:params:rpp:profile:{profile_name}. The profile name MUST be unique within the RPP URN namespace and SHOULD be descriptive of the features and versions included in the profile. A profile can also be defined as a private profile, which is not published in the IANA registry, but is used by specific server implementations only. A private profile can be defined by a server operator to specify the features and versions supported by their implementation. If the profile is not published in the IANA registry, then the server operator MUST ensure that the profile name is globally unique to avoid conflicts with other profiles, the use of reverse domain name notation is RECOMMENDED for private profiles to ensure uniqueness. Kowalik & Wullink Expires 6 May 2027 [Page 23] Internet-Draft RPP Data Objects November 2026 4.1. Inheritance A profile can include another profile, which is referred to as "inheriting" from that profile. When a profile inherits from another profile, it means that the features and versions defined in the inherited profile are also included in the inheriting profile. This allows for the creation of more complex profiles by building upon existing profiles. For example, a profile named "example-profile" could inherit from a base profile named "base-profile", which includes a set of common features and versions. The "example- profile" could then add additional features and versions on top of the ones defined in the base profile, or it can override some of the features and versions from the base profile. This allows for greater flexibility and modularity in defining profiles, as well as promoting reuse of common features and versions across different profiles. However, it is important to note that the use of inheritance in profiles can also make things more complicated, as it can create dependencies between profiles and make it harder to understand the features and versions included in a profile. Therefore, it is recommended to use inheritance with caution and to clearly document the relationships between profiles. The depth of inheritance MUST be limited to 1 to prevent excessive complexity, and profile designers MUST NOT create circular dependencies between profiles, where a profile inherits from itself directly. 5. Messages Messages are used to communicate events, requests, and responses between clients and the server. They provide a mechanism for notifying clients about changes in the state of objects, the outcome of operations, and other relevant information. For a message reporting completion of an offline review, the server MUST send a review-response message to each client involved in the transaction when the requested action has been completed and the pending status has been removed. The server can send transfer-outcome, expiration-deletion, and auto- renewal messages to clients affected by those events. The service- notice conveys operational information to all clients. Extensions should use the Base Message Object as the foundation for defining new message types for notifications of changes to Data Objects. Kowalik & Wullink Expires 6 May 2027 [Page 24] Internet-Draft RPP Data Objects November 2026 6. External Data Types The RPP object model is designed to be extensible and interoperable with existing standards. To reduce redundancy and improve consistency, RPP data objects MAY incorporate data types and structures defined in external specifications rather than redefining equivalent types within this specification. An external data type is any type, structure, or format that is normatively defined in a separate standards document and referenced by this specification. When an external data type is used, RPP implementations MUST conform to the semantics, constraints, and encoding rules defined in the originating specification. 6.1. Referencing External Data Types When this document or any RPP specification references an external data type, the reference MUST follow the requirements and guidelines for references described in [RFC2026]. The reference MUST include a clear description of the specific type or structure being used. For example, if referencing the JSContact format defined in [RFC9553], the reference should specify that the Card data type is being used. The reference MUST use the following format: External::. For example, External:RPP-JSContact- Profile:Card indicates that the Card type from the RPP JSContact Profile specification is being used. The syntax for the reference is defined using ABNF [RFC5234] as follows: identifier = "External:" TYPEID ":" TYPEID TYPEID = ALPHA *( ALPHA / DIGIT / "-" / "_" ) ( ALPHA / DIGIT ) 6.2. Versioning and Compatibility External data types are versioned by the specification that defines them. The RPP specifications are pinned to a single version of an external type. If a newer version updates the defining specification, the RPP specification MUST be updated to indicate explicit support. 6.3. JSContact This specification references the RPP JSContact Profile for RPP defined in [I-D.wullink-rpp-jscontact-profile] as an external specification for representing contact information. The JSContact Card data type defined in [RFC9553] MUST be used for the representation of contact information. When referring to this type the following values MUST be used in the Data Type reference Kowalik & Wullink Expires 6 May 2027 [Page 25] Internet-Draft RPP Data Objects November 2026 identifiers: specification-identifier: RPP-JSContact-Profile type-name: Card Data Type: External:RPP-JSContact-Profile:Card 7. Common Data Types This section defines new shared data types and structures that are re-used across multiple data object definitions and are based on the existing Primitive Data Types. 7.1. Identifier Identifiers are character strings with a specified minimum length, a specified maximum length, and a specified format outlined in Section 2.8 of [RFC5730]. Identifiers for certain object types MAY have additional constraints imposed either by server policy, object- specific specifications or both. 7.2. Client Identifier Client identifiers are character strings with a specified minimum length, a specified maximum length, and a specified format. Client identifiers use the "clIDType" client identifier syntax described in [RFC5730]. | TBC: do we need this or is it a relation with an entity/RFC8543 | organisation? If registrars are modelled as first class | objects (organisations), then clID is nothing else but a | reference to this organisation, so maybe no need to define | syntax separately on identifier level (or in other words it | would be defined on this object). R8.1 in the form of -02 RPP | requirements includes RFC8543. 7.3. Phone Number Telephone number syntax is derived from structures defined in [ITU.E164.2005]. Telephone numbers described in this specification are character strings that MUST begin with a plus sign ("+", ASCII value 0x002B), followed by a country code defined in [ITU.E164.2005], followed by a dot (".", ASCII value 0x002E), followed by a sequence of digits representing the telephone number. An optional "x" (ASCII value 0x0078) separator with additional digits representing extension information can be appended to the end of the value. Kowalik & Wullink Expires 6 May 2027 [Page 26] Internet-Draft RPP Data Objects November 2026 8. Associations RPP allows for different types of associations (relationships) between the objects. The association may be added between 2 objects with own independent lifecycle (UML aggregation) or in the relation when one object's existence and lifecycle is bound to the other parent/owner object (UML composition). In both cases, especially if the relation allows for cardinality higher than one on either side, the association may be assigned additional attributes, not being part of an object on either side of relation. In many cases such relation would be attributed with a single text string label, describing a role or a type of relation. Depending on the context this value might be unique, which allows using such label as a key in a dictionary. The following generic Association Types are defined for RPP: 8.1. Aggregation Notation: Aggregation[Type] A relation between two independent objects. If the cardinality of the target object is more than 1, this represents an unordered array. The target object of an aggregation MUST already exist when the association is created. The target object MAY be only partially visible to the client, or not visible at all, for example when it is managed by the server or by another client and the client only knows its identifier. Limited visibility of the target object does not prevent the client from using it in the association. This rule also applies to Labelled Aggregation and Dictionary Aggregation. Example aggregation having cardinality 1: +-------------------+ | (root parent) | |-------------------| | foo: | | | +----------+ | +-------- | [Object] | | | ... | | +----------+ +-------------------+ Example aggregation having cardinality >1: Kowalik & Wullink Expires 6 May 2027 [Page 27] Internet-Draft RPP Data Objects November 2026 +-------------------+ | (root parent) | |-------------------| | foo: | | +-----[0] +----------+ | | | [Object] | | | | ... | | | +----------+ | +-----[1] +----------+ | | [Object] | | | ... | | +----------+ | ... | +-------------------+ 8.2. Composition Notation: Type A relation between an independent parent object and 1 or more dependent child object(s). If the cardinality of the target object is more than 1, this represents an unordered array. Example composition having cardinality 1: +-------------------+ | (root) | |-------------------| | foo: | | | +-------+ | | +--| ... | | | +-------+ | +-------------------+ Example composition having cardinality >1: Kowalik & Wullink Expires 6 May 2027 [Page 28] Internet-Draft RPP Data Objects November 2026 +-------------------+ | (root) | |-------------------| | foo: | | +-[0] +-------+ | | | | ... | | | | +-------+ | | +-[1] +-------+ | | | | ... | | | | +-------+ | | ... | +-------------------+ 8.3. Labelled Aggregation Notation: LabelledAggregation[Type] A relation between two independent objects with a single text string attribute. Multiple associations with the same label are allowed and represent an unordered array. A type defining such association MUST define Label Description with semantics of the label and Label Constraints with constraints related to the label. Example labelled aggregation: +--------------------------------+ | (root) | |--------------------------------| | foo: | | | | | +---("label_A")---> +----------+ | | | [Object] | | | | ... | | | +----------+ | +---("label_B")---> +----------+ | | | [Object] | | | | ... | | | +----------+ | +---("label_A")---> +----------+ | | (labels repeat) | [Object] | | | | ... | | | +----------+ | ... | +--------------------------------+ Kowalik & Wullink Expires 6 May 2027 [Page 29] Internet-Draft RPP Data Objects November 2026 8.4. Dictionary Aggregation Notation: DictionaryAggregation[Type] A relation between two independent objects with a single text string attribute. Association labels MUST be unique, allowing them to be used as dictionary keys. A type defining such association MUST define Label Description with semantics of the label and Label Constraints with constraints related to the label. Example Dictionary Aggregation: +--------------------------+ | (root) | |--------------------------| | foo: | | "key1" -> +-----------+ | | [Object] | | | ... | | +-----------+ | "key2" -> +-----------+ | | [Object] | | | ... | | +-----------+ | ... | +--------------------------+ 8.5. Labelled Composition Notation: LabelledComposition[Type] A relation between an independent parent object and a dependent child object with a single text string attribute. Multiple associations with the same label are allowed. A type defining such association MUST define Label Description with semantics of the label and Label Constraints with constraints related to the label. Example Labelled Composition: Kowalik & Wullink Expires 6 May 2027 [Page 30] Internet-Draft RPP Data Objects November 2026 +-------------------------------------+ | (root parent) | |-------------------------------------| | foo: | | | | | +---("label_A")---> +----------+ | | | | [Child] | | | | | ... | | | | +----------+ | | +---("label_B")---> +----------+ | | | | [Child] | | | | | ... | | | | +----------+ | | +---("label_A")---> +----------+ | | | (labels repeat) | [Child] | | | | | ... | | | | +----------+ | | ... | +-------------------------------------+ 8.6. Dictionary Composition Notation: DictionaryComposition[Type] A relation between an independent parent object and a dependent child object with a single text string attribute. Only a single association with the same label is allowed, allowing it to be used as a dictionary key. A type defining such association MUST define Label Description with semantics of the label and Label Constraints with constraints related to the label. Example Dictionary Composition: Kowalik & Wullink Expires 6 May 2027 [Page 31] Internet-Draft RPP Data Objects November 2026 +--------------------------+ | (root) | |--------------------------| | foo: | | "key1" -> +---------+ | | | [Child] | | | | ... | | | +---------+ | | "key2" -> +---------+ | | | [Child] | | | | ... | | | +---------+ | | ... | +--------------------------+ 9. Component Objects This section defines the Component Objects used in this document. 9.1. Period Object * Name: Period Object * Identifier: period * Description: Represents a duration of time. * Data Elements: - Value o Identifier: value o Cardinality: 1 o Mutability: read-write o Data Type: Integer o Description: The numeric value of the period. o Constraints: The value MUST be from 1 to 99, inclusive. - Unit o Identifier: unit o Cardinality: 1 o Mutability: read-write o Data Type: String o Description: The unit of the period. o Constraints: The value MUST be one of: "y" (years) or "m" (months). 9.2. Provisioning Metadata Object * Name: Provisioning Metadata Object * Identifier: provMetadata * Description: Contains standard metadata about the lifecycle and ownership of a provisioned object. This metadata is common across all resource objects in the registry system. Kowalik & Wullink Expires 6 May 2027 [Page 32] Internet-Draft RPP Data Objects November 2026 * Data Elements: - Repository ID o Identifier: repositoryId o Cardinality: 0-1 o Mutability: read-only o Data Type: Identifier o Description: A server-assigned unique identifier for the object. o Constraints: In EPP Compatibility Profile this data element MUST be provided. - Sponsoring Client ID o Identifier: spClientId o Cardinality: 1 o Mutability: read-only o Data Type: Client Identifier o Description: The identifier of the client that is the current sponsor of the object. o Constraints: (None) - Creating Client ID o Identifier: crClientId o Cardinality: 0-1 o Mutability: read-only o Data Type: Client Identifier o Description: The identifier of the client that created the object. o Constraints: (None) - Creation Date o Identifier: crDate o Cardinality: 0-1 o Mutability: read-only o Data Type: Timestamp o Description: The date and time of object creation. o Constraints: The value is set by the server and cannot be specified by the client. - Updating Client ID o Identifier: upClientId o Cardinality: 0-1 o Mutability: read-only o Data Type: Client Identifier o Description: The identifier of the client that last updated the object. o Constraints: This element MUST NOT be present if the object has never been modified. - Update Date o Identifier: upDate o Cardinality: 0-1 o Mutability: read-only o Data Type: Timestamp Kowalik & Wullink Expires 6 May 2027 [Page 33] Internet-Draft RPP Data Objects November 2026 o Description: The date and time of the most recent object modification. o Constraints: This element MUST NOT be present if the object has never been modified. - Transfer Date o Identifier: trDate o Cardinality: 0-1 o Mutability: read-only o Data Type: Timestamp o Description: The date and time of the most recent successful object transfer. o Constraints: This element MUST NOT be provided if the object has never been transferred. 9.3. Domain Name Status Object * Name: Domain Name Status Object * Identifier: domainStatus * Description: Represents one of the status values associated with a Domain Name Data Object * Data Elements: - Label o Identifier: label o Cardinality: 1 o Mutability: create-only o Data Type: String o Description: machine-readable enum label of a status o Constraints: + Only status values defined in Domain Status Values (#domain-status-values) and Redemption Grace Period Status Values (#rgp-status-values) are allowed. - Reason o Identifier: reason o Cardinality: 0-1 o Mutability: create-only o Data Type: String o Description: a human-readable text that describes the rationale for the status applied to the object. o Constraints: (None) - Due o Identifier: due o Cardinality: 0-1 o Mutability: read-write o Data Type: Timestamp o Description: a timestamp, when this status is going to be removed automatically, or changed to other status. This field can be used to express lifecycle related information. Kowalik & Wullink Expires 6 May 2027 [Page 34] Internet-Draft RPP Data Objects November 2026 o Constraints: servers MAY restrict possibility to set or update this value by the client. 9.3.1. Status Values Status values that can be added or removed by a client are prefixed with "client". Corresponding status values that can be added or removed by a server are prefixed with "server". Status values that do not begin with either "client" or "server" are server-managed. Status values that begin with "rgp" are related to the Redemption Grace Period (RGP) and are also server-managed. A client MUST NOT alter status values set by the server. A server MAY alter or override status values set by a client, subject to local server policies. The Set By column identifies the entity that adds and removes each status value: client, server, or client, server for a value that the server manages and that a client can also manage where server policy permits. A server MUST assign at least one status value to the object. A client is not required to provide a status value when creating or updating the object. +==========================+========+==============================+ | Status Value | Set By | Description | +==========================+========+==============================+ | clientDeleteProhibited | client | Requests to delete the | | | | object MUST be rejected. | +--------------------------+--------+------------------------------+ | serverDeleteProhibited | server | Requests to delete the | | | | object MUST be rejected. | +--------------------------+--------+------------------------------+ | clientHold | client | DNS delegation information | | | | MUST NOT be published for | | | | the object. | +--------------------------+--------+------------------------------+ | serverHold | server | DNS delegation information | | | | MUST NOT be published for | | | | the object. | +--------------------------+--------+------------------------------+ | clientRenewProhibited | client | Requests to renew the object | | | | MUST be rejected. | +--------------------------+--------+------------------------------+ | serverRenewProhibited | server | Requests to renew the object | | | | MUST be rejected. | +--------------------------+--------+------------------------------+ | clientTransferProhibited | client | Requests to transfer the | | | | object MUST be rejected. | +--------------------------+--------+------------------------------+ Kowalik & Wullink Expires 6 May 2027 [Page 35] Internet-Draft RPP Data Objects November 2026 | serverTransferProhibited | server | Requests to transfer the | | | | object MUST be rejected. | +--------------------------+--------+------------------------------+ | clientUpdateProhibited | client | Requests to update the | | | | object (other than to remove | | | | this status) MUST be | | | | rejected. | +--------------------------+--------+------------------------------+ | serverUpdateProhibited | server | Requests to update the | | | | object (other than to remove | | | | this status) MUST be | | | | rejected. | +--------------------------+--------+------------------------------+ | inactive | server | Delegation information has | | | | not been associated with the | | | | object. This is the default | | | | status when a domain object | | | | is first created and there | | | | are no associated host | | | | objects for the DNS | | | | delegation. This status can | | | | also be set by the server | | | | when all host-object | | | | associations are removed. | +--------------------------+--------+------------------------------+ | ok | server | This is the normal status | | | | value for an object that has | | | | no pending operations or | | | | prohibitions. This value is | | | | set and removed by the | | | | server as other status | | | | values are added or removed. | +--------------------------+--------+------------------------------+ | pendingCreate | server | A transform command has been | | | | processed for the object, | | | | but the action has not been | | | | completed by the server. | | | | Server operators can delay | | | | action completion for a | | | | variety of reasons, such as | | | | to allow for human review or | | | | third-party action. | +--------------------------+--------+------------------------------+ | pendingDelete | server | A transform command has been | | | | processed for the object, | | | | but the action has not been | | | | completed by the server. | | | | Server operators can delay | Kowalik & Wullink Expires 6 May 2027 [Page 36] Internet-Draft RPP Data Objects November 2026 | | | action completion for a | | | | variety of reasons, such as | | | | to allow for human review or | | | | third-party action. | +--------------------------+--------+------------------------------+ | pendingRenew | server | A transform command has been | | | | processed for the object, | | | | but the action has not been | | | | completed by the server. | | | | Server operators can delay | | | | action completion for a | | | | variety of reasons, such as | | | | to allow for human review or | | | | third-party action. | +--------------------------+--------+------------------------------+ | pendingTransfer | server | A transform command has been | | | | processed for the object, | | | | but the action has not been | | | | completed by the server. | | | | Server operators can delay | | | | action completion for a | | | | variety of reasons, such as | | | | to allow for human review or | | | | third-party action. | +--------------------------+--------+------------------------------+ | pendingUpdate | server | A transform command has been | | | | processed for the object, | | | | but the action has not been | | | | completed by the server. | | | | Server operators can delay | | | | action completion for a | | | | variety of reasons, such as | | | | to allow for human review or | | | | third-party action. | +--------------------------+--------+------------------------------+ Table 1: Domain Name Status Values 9.3.2. Allowed Transitions The following diagram describes the allowed status transitions for a domain object, excluding the "rgp" status values, which follow the separate Redemption Grace Period State Diagram below. The clientHold, serverHold, clientDeleteProhibited, serverDeleteProhibited, clientRenewProhibited, serverRenewProhibited, clientTransferProhibited, serverTransferProhibited, clientUpdateProhibited, and serverUpdateProhibited status values are additive flags that MAY be combined with the states shown below Kowalik & Wullink Expires 6 May 2027 [Page 37] Internet-Draft RPP Data Objects November 2026 (subject to the Status Exclusions rules) and are not depicted as separate states; while present, the corresponding flag blocks the associated transition (delete, renew, transfer, or update, respectively) from being initiated. | v +-----------------------------------+ | status: pendingCreate (1)| +-----------------------------------+ | create action completed (2) v +-----------------------------------+ +----------->| status: ok / inactive (3)|<-----------+ | +-----------------------------------+ | | | | | | | | | (6) | | v v v | | +-------------+ +-------------+ +--------------------+ | | | status: | | status: | | status: | | | |pendingUpdate| |pendingRenew | | pendingTransfer | | | | (4) | | (5) | | (6)| | | +-------------+ +-------------+ +--------------------+ | | | | | | | +----------------+--------------------+ | | action completed (7) | +--------------------------------------------------------------+ +-----------------------------------+ | status: ok / inactive (3)| +-----------------------------------+ | (8) v +-----------------------------------+ | status: pendingDelete (8)| +-----------------------------------+ | | no RGP support (9) RGP support (9) v v +------------------+ +-----------------------------------+ | Deleted (purged) | | status: pendingDelete + | | (10) | | rgpRedemptionPeriod | +------------------+ | (see Redemption Grace Period | | State Diagram below) (10)| +-----------------------------------+ Kowalik & Wullink Expires 6 May 2027 [Page 38] Internet-Draft RPP Data Objects November 2026 Figure 4: Domain Object State Diagram State descriptions: 1. A create operation is received and processed. If the server defers completion, the object enters pendingCreate state. 2. The create action completes. The object transitions to ok if one or more nameservers are associated with the domain, or to inactive if none are associated. 3. The object is in normal operation, either as ok (nameservers associated) or inactive (no nameservers associated). The object toggles between these two sub-states as nameserver associations are added to or removed from the domain, independently of the transitions described below. 4. An update operation is received. If the server defers completion, the object enters pendingUpdate state. 5. A renew operation is received to extend the domain's registration period. If the server defers completion, the object enters pendingRenew state. 6. A transfer Create operation is received, initiating a transfer request. The object enters pendingTransfer state while the request awaits approval, rejection, or automated server action. 7. Once the pending update, renew, or transfer action completes, the corresponding pending status is removed and the object returns to its ok or inactive state, as determined by its current nameserver associations. 8. A delete operation is received and processed. The object enters pendingDelete state. 9. Whether RGP is supported for the domain determines the next transition upon completion of the pending delete action. 10. If RGP is not supported, the object is purged once the delete action completes. If RGP is supported, the object instead continues into the rgpRedemptionPeriod state, following the Redemption Grace Period State Diagram (#fig-rgp-state-diagram) below. 9.3.3. Pending Status Removal When the requested action has been completed, the pendingCreate, pendingDelete, pendingRenew, pendingTransfer, or pendingUpdate status value MUST be removed. All clients involved in the transaction MUST be notified using a service message that the action has been completed and that the status of the object has changed. Kowalik & Wullink Expires 6 May 2027 [Page 39] Internet-Draft RPP Data Objects November 2026 9.3.4. Status Exclusions +================================+===========================+ | Status Value | MUST NOT be combined with | +================================+===========================+ | ok | Any other status | +--------------------------------+---------------------------+ | pendingDelete | clientDeleteProhibited, | | | serverDeleteProhibited | +--------------------------------+---------------------------+ | pendingRenew | clientRenewProhibited, | | | serverRenewProhibited | +--------------------------------+---------------------------+ | pendingTransfer | clientTransferProhibited, | | | serverTransferProhibited | +--------------------------------+---------------------------+ | pendingUpdate | clientUpdateProhibited, | | | serverUpdateProhibited | +--------------------------------+---------------------------+ | pendingCreate, pendingDelete, | Each other (mutually | | pendingRenew, pendingTransfer, | exclusive) | | pendingUpdate | | +--------------------------------+---------------------------+ Table 2: Status Exclusions Other status combinations not expressly prohibited MAY be used. 9.3.5. Redemption Grace Period Status values that begin with "rgp" are related to the Redemption Grace Period (RGP) and are server-managed. The Set By column identifies the entity that adds and removes each status value: client, server, or client, server for a value that the server manages and that a client can also manage where server policy permits. +=====================+========+====================================+ | Status Value | Set By | Description | +=====================+========+====================================+ | rgpAddPeriod | server | This grace period is provided | | | | after the initial registration of | | | | a domain name. If the domain | | | | name is deleted by the registrar | | | | during this period, the registry | | | | provides a credit to the | | | | registrar for the cost of the | Kowalik & Wullink Expires 6 May 2027 [Page 40] Internet-Draft RPP Data Objects November 2026 | | | registration. | +---------------------+--------+------------------------------------+ | rgpAutoRenewPeriod | server | This grace period is provided | | | | after a domain name registration | | | | period expires and is extended | | | | (renewed) automatically by the | | | | registry. If the domain name is | | | | deleted by the registrar during | | | | this period, the registry | | | | provides a credit to the | | | | registrar for the cost of the | | | | renewal. | +---------------------+--------+------------------------------------+ | rgpRenewPeriod | server | This grace period is provided | | | | after a domain name registration | | | | period is explicitly extended | | | | (renewed) by the registrar. If | | | | the domain name is deleted by the | | | | registrar during this period, the | | | | registry provides a credit to the | | | | registrar for the cost of the | | | | renewal. | +---------------------+--------+------------------------------------+ | rgpTransferPeriod | server | This grace period is provided | | | | after the successful transfer of | | | | domain name registration | | | | sponsorship from one registrar to | | | | another registrar. If the domain | | | | name is deleted by the new | | | | sponsoring registrar during this | | | | period, the registry provides a | | | | credit to the registrar for the | | | | cost of the transfer. | +---------------------+--------+------------------------------------+ | rgpRedemptionPeriod | server | This status value is used to | | | | describe a domain for which a | | | | delete operation has been | | | | received, but the domain has not | | | | yet been purged because an | | | | opportunity exists to restore the | | | | domain and abort the deletion | | | | process. | +---------------------+--------+------------------------------------+ | rgpPendingRestore | server | This status value is used to | | | | describe a domain that is in the | | | | process of being restored after | | | | being in the rgpRedemptionPeriod | | | | state. | Kowalik & Wullink Expires 6 May 2027 [Page 41] Internet-Draft RPP Data Objects November 2026 +---------------------+--------+------------------------------------+ | rgpPendingDelete | server | This status value is used to | | | | describe a domain that has | | | | entered the purge processing | | | | state after completing the | | | | rgpRedemptionPeriod state. A | | | | domain in this status MUST also | | | | be in the pendingDelete status | | | | described above. | +---------------------+--------+------------------------------------+ Table 3: Redemption Grace Period Status Values 9.3.5.1. Allowed Transitions The following state diagram describes the object lifecycle when the Redemption Grace Period (RGP) feature is supported. It adapts the diagram from Section 2 of [RFC3915] to the RPP data model, using RPP status labels and operations instead of EPP command names. In the diagram below, each state box shows the values of the status data element of the Domain Name Data Object. The values ok and pendingDelete are defined in Section 9.3.1, and the values beginning with "rgp" are defined in Section 9.3.5. The label refers to the Delete operation on the Domain Name Data Object. The and labels refer to the Create operation (Section 10.2.1.1) and the Update operation (Section 10.2.1.3) of the Restore Process Object. Kowalik & Wullink Expires 6 May 2027 [Page 42] Internet-Draft RPP Data Objects November 2026 | (2) v Domain +----------------------------+ +-------------------------------+ | status: ok (1)|------------->| status: pendingDelete (3)| | | | rgpRedemptionPeriod | +----------------------------+ +-------------------------------+ ^ ^ restore, no report | ^ | | | | and report required (4)| | | No (9) | | | Restore | | | restore | | | +------------------+ | | | | | v | | v | | +------------------+ | | +-----------------------+ | | | status: (6)| | | | status: (10)| | | | pendingDelete |-----------------+ | | pendingDelete | | | | rgpPendingRestore| report not (7) | | rgpPendingDelete | | | +------------------+ received | +-----------------------+ | | (8) | | | | | report received | | purge (11) | | | Restore | restore (5) | v | +--------------------+ with report | +-----------------------+ | or not req. | | Purged (12)| | Restore | +-----------------------+ +----------------------------------------------+ Figure 5: Redemption Grace Period State Diagram State descriptions: 1. The object is in normal operation (ok or other status allowing a delete operation). 2. A delete operation is received and processed. 3. RGP begins. The object enters pendingDelete + rgpRedemptionPeriod state. The object remains here until a restore operation is requested or the redemption period elapses. 4. A restore Create operation is submitted. The registry accepts the request. Go to step 9 if the redemption period elapses before a restore is received (4a). 5. If the server does not require a restore report, the object returns to its pre-deletion status (1) immediately upon a successful Create operation. If the server requires a report but the client includes it inline in the Create operation, the server processes both atomically and the object transitions directly from rgpRedemptionPeriod to its pre-deletion status (1), bypassing the rgpPendingRestore state. 6. The object enters pendingDelete + rgpPendingRestore state. The registry awaits a restore report from the sponsoring client. 7. If no restore report is received within the registry-defined time, the object returns to rgpRedemptionPeriod state (step 3). Kowalik & Wullink Expires 6 May 2027 [Page 43] Internet-Draft RPP Data Objects November 2026 8. If a restore report is received and accepted, the object returns to its pre-deletion status and all RGP status labels are removed. 9. The redemption period elapses without a restore request being received. 10. The object enters pendingDelete + rgpPendingDelete state and awaits final purge processing. 11. The pending delete period elapses and the object is purged. 12. The object is purged and available for re-registration. | TBD: Idea - model status object as Labelled Composition using | "Label"? Con: Generic Constraints for Label will be repeated. 9.4. Host Status Object * Name: Host Status Object * Identifier: hostStatus * Description: Represents one of the status values associated with a Host Data Object * Data Elements: - Label o Identifier: label o Cardinality: 1 o Mutability: create-only o Data Type: String o Description: machine-readable enum label of a status o Constraints: + Only status values defined in Status Values (#host- status-values) are allowed. - Reason o Identifier: reason o Cardinality: 0-1 o Mutability: create-only o Data Type: String o Description: a human-readable text that describes the rationale for the status applied to the object. o Constraints: (None) 9.4.1. Status Values Status values that can be added or removed by a client are prefixed with "client". Corresponding status values that can be added or removed by a server are prefixed with "server". Status values that do not begin with either "client" or "server" are server-managed. A client MUST NOT alter status values set by the server. A server MAY alter or override status values set by a client, subject to local server policies. Kowalik & Wullink Expires 6 May 2027 [Page 44] Internet-Draft RPP Data Objects November 2026 The Set By column identifies the entity that adds and removes each status value: client, server, or client, server for a value that the server manages and that a client can also manage where server policy permits. A server MUST assign at least one status value to the object. A client is not required to provide a status value when creating or updating the object. +========================+========+==============================+ | Status Value | Set By | Description | +========================+========+==============================+ | clientDeleteProhibited | client | Requests to delete the | | | | object MUST be rejected. | +------------------------+--------+------------------------------+ | serverDeleteProhibited | server | Requests to delete the | | | | object MUST be rejected. | +------------------------+--------+------------------------------+ | clientUpdateProhibited | client | Requests to update the | | | | object (other than to remove | | | | this status) MUST be | | | | rejected. | +------------------------+--------+------------------------------+ | serverUpdateProhibited | server | Requests to update the | | | | object (other than to remove | | | | this status) MUST be | | | | rejected. | +------------------------+--------+------------------------------+ | linked | server | The host object has at least | | | | one active association with | | | | another object, such as a | | | | domain object. Servers | | | | SHOULD provide services to | | | | determine existing object | | | | associations. | +------------------------+--------+------------------------------+ | ok | server | This is the normal status | | | | value for an object that has | | | | no pending operations or | | | | prohibitions. This value is | | | | set and removed by the | | | | server as other status | | | | values are added or removed. | +------------------------+--------+------------------------------+ | pendingCreate | server | A transform command has been | | | | processed for the object, | | | | but the action has not been | | | | completed by the server. | | | | Server operators can delay | | | | action completion for a | Kowalik & Wullink Expires 6 May 2027 [Page 45] Internet-Draft RPP Data Objects November 2026 | | | variety of reasons, such as | | | | to allow for human review or | | | | third-party action. | +------------------------+--------+------------------------------+ | pendingDelete | server | A transform command has been | | | | processed for the object, | | | | but the action has not been | | | | completed by the server. | | | | Server operators can delay | | | | action completion for a | | | | variety of reasons, such as | | | | to allow for human review or | | | | third-party action. | +------------------------+--------+------------------------------+ | pendingTransfer | server | A transform command has been | | | | processed for the object's | | | | superordinate domain object | | | | (i.e. a transfer of the | | | | domain object is pending), | | | | but the action has not been | | | | completed by the server. | | | | Server operators can delay | | | | action completion for a | | | | variety of reasons, such as | | | | to allow for human review or | | | | third-party action. | +------------------------+--------+------------------------------+ | pendingUpdate | server | A transform command has been | | | | processed for the object, | | | | but the action has not been | | | | completed by the server. | | | | Server operators can delay | | | | action completion for a | | | | variety of reasons, such as | | | | to allow for human review or | | | | third-party action. | +------------------------+--------+------------------------------+ Table 4: Host Status Values 9.4.2. Allowed Transitions The following diagram describes the allowed status transitions for a host object, based on the status values defined in Section 2.3 of [RFC5732]. The clientDeleteProhibited, serverDeleteProhibited, clientUpdateProhibited, and serverUpdateProhibited status values are additive flags that MAY be combined with the states shown below (subject to the Status Exclusions rules) and are not depicted as Kowalik & Wullink Expires 6 May 2027 [Page 46] Internet-Draft RPP Data Objects November 2026 separate states; while present, the corresponding flag blocks the associated transition (delete or update, respectively) from being initiated. The linked status is set and removed by the server as associations with other objects are added or removed, independently of the transitions described below. | v +-----------------------------------+ | status: pendingCreate (1) | +-----------------------------------+ | create action completed (2) v +-----------------------------------+ +--------->| status: ok (3) |<---------+ | +-----------------------------------+ | | | | | | (4) | (5) | | | v v | | +--------------------+ +--------------------+ | | | status: | | status: | | | | pendingUpdate (4) | | pendingTransfer(5) | | | +--------------------+ +--------------------+ | | | | | | +------------------------+ | | action completed (6) | +---------------------------------------------------------+ +-----------------------------------+ | status: ok (3) | +-----------------------------------+ | | (7) v +-----------------------------------+ | status: pendingDelete (7) | +-----------------------------------+ | | delete action completed (8) v +------------------+ | Deleted (purged) | | (9) | +------------------+ Figure 6: Host Object State Diagram State descriptions: Kowalik & Wullink Expires 6 May 2027 [Page 47] Internet-Draft RPP Data Objects November 2026 1. A create operation is received and processed. If the server defers completion, the object enters pendingCreate state. 2. The create action completes and the pendingCreate status is removed. The object enters the ok state. 3. The object is in normal operation with the ok status. The linked status MAY accompany ok while the host has an active association with another object, such as a domain object. 4. An update operation is received. If the server defers completion, the object enters pendingUpdate state. 5. A transfer of the superordinate domain object is initiated. The server sets the pendingTransfer status on the subordinate host object while the domain transfer request is pending. This status is not set by a client. 6. Once the pending update or transfer action completes, the corresponding pending status is removed and the object returns to its ok state. 7. A delete operation is received and processed. The object enters pendingDelete state. 8. The pending delete action completes. 9. The object is purged. 9.4.3. Pending Status Removal When the requested action has been completed, the pendingCreate, pendingDelete, pendingTransfer, or pendingUpdate status value MUST be removed. All clients involved in the transaction MUST be notified using a service message that the action has been completed and that the status of the object has changed. 9.4.4. Status Exclusions +================================+==============================+ | Status Value | MUST NOT be combined with | +================================+==============================+ | ok | Any status other than linked | +--------------------------------+------------------------------+ | pendingDelete | clientDeleteProhibited, | | | serverDeleteProhibited | +--------------------------------+------------------------------+ | pendingUpdate | clientUpdateProhibited, | | | serverUpdateProhibited | +--------------------------------+------------------------------+ | pendingCreate, pendingDelete, | Each other (mutually | | pendingTransfer, pendingUpdate | exclusive) | +--------------------------------+------------------------------+ Table 5: Host Status Exclusions Kowalik & Wullink Expires 6 May 2027 [Page 48] Internet-Draft RPP Data Objects November 2026 The linked status MAY be combined with any status. Other status combinations not expressly prohibited MAY be used. 9.5. Contact Status Object * Name: Contact Status Object * Identifier: contactStatus * Description: Represents one of the status values associated with a Contact Data Object * Data Elements: - Label o Identifier: label o Cardinality: 1 o Mutability: create-only o Data Type: String o Description: machine-readable enum label of a status o Constraints: + Only status values defined in Status Values (#contact- status-values) are allowed. - Reason o Identifier: reason o Cardinality: 0-1 o Mutability: create-only o Data Type: String o Description: a human-readable text that describes the rationale for the status applied to the object. o Constraints: (None) 9.5.1. Status Values Status values that can be added or removed by a client are prefixed with "client". Corresponding status values that can be added or removed by a server are prefixed with "server". Status values that do not begin with either "client" or "server" are server-managed. A client MUST NOT alter status values set by the server. A server MAY alter or override status values set by a client, subject to local server policies. The Set By column identifies the entity that adds and removes each status value: client, server, or client, server for a value that the server manages and that a client can also manage where server policy permits. A server MUST assign at least one status value to the object. A client is not required to provide a status value when creating or updating the object. Kowalik & Wullink Expires 6 May 2027 [Page 49] Internet-Draft RPP Data Objects November 2026 +==========================+========+==============================+ | Status Value | Set By | Description | +==========================+========+==============================+ | clientDeleteProhibited | client | Requests to delete the | | | | object MUST be rejected. | +--------------------------+--------+------------------------------+ | serverDeleteProhibited | server | Requests to delete the | | | | object MUST be rejected. | +--------------------------+--------+------------------------------+ | clientTransferProhibited | client | Requests to transfer the | | | | object MUST be rejected. | +--------------------------+--------+------------------------------+ | serverTransferProhibited | server | Requests to transfer the | | | | object MUST be rejected. | +--------------------------+--------+------------------------------+ | clientUpdateProhibited | client | Requests to update the | | | | object (other than to remove | | | | this status) MUST be | | | | rejected. | +--------------------------+--------+------------------------------+ | serverUpdateProhibited | server | Requests to update the | | | | object (other than to remove | | | | this status) MUST be | | | | rejected. | +--------------------------+--------+------------------------------+ | linked | server | The contact object has at | | | | least one active association | | | | with another object, such as | | | | a domain object. Servers | | | | SHOULD provide services to | | | | determine existing object | | | | associations. | +--------------------------+--------+------------------------------+ | ok | server | This is the normal status | | | | value for an object that has | | | | no pending operations or | | | | prohibitions. This value is | | | | set and removed by the | | | | server as other status | | | | values are added or removed. | +--------------------------+--------+------------------------------+ | pendingCreate | server | A transform command has been | | | | processed for the object, | | | | but the action has not been | | | | completed by the server. | | | | Server operators can delay | | | | action completion for a | | | | variety of reasons, such as | Kowalik & Wullink Expires 6 May 2027 [Page 50] Internet-Draft RPP Data Objects November 2026 | | | to allow for human review or | | | | third-party action. | +--------------------------+--------+------------------------------+ | pendingDelete | server | A transform command has been | | | | processed for the object, | | | | but the action has not been | | | | completed by the server. | | | | Server operators can delay | | | | action completion for a | | | | variety of reasons, such as | | | | to allow for human review or | | | | third-party action. | +--------------------------+--------+------------------------------+ | pendingTransfer | server | A transform command has been | | | | processed for the object, | | | | but the action has not been | | | | completed by the server. | | | | Server operators can delay | | | | action completion for a | | | | variety of reasons, such as | | | | to allow for human review or | | | | third-party action. | +--------------------------+--------+------------------------------+ | pendingUpdate | server | A transform command has been | | | | processed for the object, | | | | but the action has not been | | | | completed by the server. | | | | Server operators can delay | | | | action completion for a | | | | variety of reasons, such as | | | | to allow for human review or | | | | third-party action. | +--------------------------+--------+------------------------------+ Table 6: Contact Status Values 9.5.2. Allowed Transitions The following diagram describes the allowed status transitions for a contact object, based on the status values defined in Section 2.2 of [RFC5733]. The clientDeleteProhibited, serverDeleteProhibited, clientTransferProhibited, serverTransferProhibited, clientUpdateProhibited, and serverUpdateProhibited status values are additive flags that MAY be combined with the states shown below (subject to the Status Exclusions rules) and are not depicted as separate states; while present, the corresponding flag blocks the associated transition (delete, transfer, or update, respectively) from being initiated. The linked status is set and removed by the Kowalik & Wullink Expires 6 May 2027 [Page 51] Internet-Draft RPP Data Objects November 2026 server as associations with other objects are added or removed, independently of the transitions described below. | v +-----------------------------------+ | status: pendingCreate (1) | +-----------------------------------+ | create action completed (2) v +-----------------------------------+ +--------->| status: ok (3) |<---------+ | +-----------------------------------+ | | | | | | (4) | (5) | | | v v | | +--------------------+ +--------------------+ | | | status: | | status: | | | | pendingUpdate (4) | | pendingTransfer(5) | | | +--------------------+ +--------------------+ | | | | | | +------------------------+ | | action completed (6) | +---------------------------------------------------------+ +-----------------------------------+ | status: ok (3) | +-----------------------------------+ | | (7) v +-----------------------------------+ | status: pendingDelete (7) | +-----------------------------------+ | | delete action completed (8) v +------------------+ | Deleted (purged) | | (9) | +------------------+ Figure 7: Contact Data Object State Diagram State descriptions: 1. A create operation is received and processed. If the server defers completion, the object enters pendingCreate state. Kowalik & Wullink Expires 6 May 2027 [Page 52] Internet-Draft RPP Data Objects November 2026 2. The create action completes and the pendingCreate status is removed. The object enters the ok state. 3. The object is in normal operation with the ok status. The linked status MAY accompany ok while the contact has an active association with another object, such as a domain object. 4. An update operation is received. If the server defers completion, the object enters pendingUpdate state. 5. A transfer Create operation is received for the contact, initiating a transfer request. The object enters pendingTransfer state while the request awaits approval, rejection, cancellation, or automated server action. 6. Once the pending update or transfer action completes, the corresponding pending status is removed and the object returns to its ok state. A transfer that is approved changes the sponsoring client of the contact. 7. A delete operation is received and processed. The object enters pendingDelete state. 8. The pending delete action completes. 9. The object is purged. 9.5.3. Pending Status Removal When the requested action has been completed, the pendingCreate, pendingDelete, pendingTransfer, or pendingUpdate status value MUST be removed. All clients involved in the transaction MUST be notified using a service message that the action has been completed and that the status of the object has changed. 9.5.4. Status Exclusions +================================+==============================+ | Status Value | MUST NOT be combined with | +================================+==============================+ | ok | Any status other than linked | +--------------------------------+------------------------------+ | pendingDelete | clientDeleteProhibited, | | | serverDeleteProhibited | +--------------------------------+------------------------------+ | pendingTransfer | clientTransferProhibited, | | | serverTransferProhibited | +--------------------------------+------------------------------+ | pendingUpdate | clientUpdateProhibited, | | | serverUpdateProhibited | +--------------------------------+------------------------------+ | pendingCreate, pendingDelete, | Each other (mutually | | pendingTransfer, pendingUpdate | exclusive) | +--------------------------------+------------------------------+ Kowalik & Wullink Expires 6 May 2027 [Page 53] Internet-Draft RPP Data Objects November 2026 Table 7: Contact Status Exclusions The linked status MAY be combined with any status. Other status combinations not expressly prohibited MAY be used. 9.6. Organisation Role Status Object * Name: Organisation Role Status Object * Identifier: organisationRoleStatus * Description: Represents one of the status values associated with an Organisation Role Object. A role SHOULD have at least one associated status value. * Data Elements: - Label o Identifier: label o Cardinality: 1 o Mutability: create-only o Data Type: String o Description: machine-readable enum label of a status o Constraints: + Only status values defined in Status Values (#organisation-role-status-values) are allowed. - Reason o Identifier: reason o Cardinality: 0-1 o Mutability: create-only o Data Type: String o Description: a human-readable text that describes the rationale for the status applied to the role. o Constraints: (None) 9.6.1. Status Values Status values that can be added or removed by a client are prefixed with "client". Corresponding status values that can be added or removed by a server are prefixed with "server". Status values that do not begin with either "client" or "server" are server-managed. The Set By column identifies the entity that adds and removes each status value: client, server, or client, server for a value that the server manages and that a client can also manage where server policy permits. Kowalik & Wullink Expires 6 May 2027 [Page 54] Internet-Draft RPP Data Objects November 2026 +======================+========+==================================+ | Status Value | Set By | Description | +======================+========+==================================+ | clientLinkProhibited | client | Requests to add new links to the | | | | role MUST be rejected. | +----------------------+--------+----------------------------------+ | serverLinkProhibited | server | Requests to add new links to the | | | | role MUST be rejected. | +----------------------+--------+----------------------------------+ | linked | server | The role has at least one active | | | | association with another object. | | | | This value is set and removed by | | | | the server and is not explicitly | | | | set by the client. | +----------------------+--------+----------------------------------+ | ok | server | This is the normal status value | | | | for a role that has no active | | | | prohibitions. This value is set | | | | and removed by the server as | | | | other status values are added or | | | | removed. | +----------------------+--------+----------------------------------+ Table 8: Organisation Role Status Values 9.6.2. Allowed Transitions The following diagram describes the allowed status transitions for an organisation role. The ok status is mutually exclusive with clientLinkProhibited and serverLinkProhibited, and the linked status MAY be combined with either ok or the link prohibition statuses (subject to the Status Exclusions rules). The linked status is set and removed by the server as associations with other objects are added or removed, independently of link prohibition changes, so the transitions in the top row apply equally to the bottom row. The clientLinkProhibited and serverLinkProhibited status values MAY be set at the same time. Kowalik & Wullink Expires 6 May 2027 [Page 55] Internet-Draft RPP Data Objects November 2026 | | role created (1) v +------------------------+ +------------------------+ | | | status: | | status: ok |---(2)----->| clientLinkProhibited | | |<----(3)----| and/or | | | | serverLinkProhibited | +------------------------+ +------------------------+ | ^ | ^ (4) | | (5) (4) | | (5) v | v | +------------------------+ +------------------------+ | | | status: linked, | | status: ok, linked |---(2)----->| clientLinkProhibited | | |<----(3)----| and/or | | | | serverLinkProhibited | +------------------------+ +------------------------+ Figure 8: Organisation Role State Diagram State descriptions: 1. A role is added to an organisation. The role starts with the ok status. 2. A clientLinkProhibited or serverLinkProhibited status is set, by the client or the server respectively, and the ok status is removed. Requests to add new links to the role MUST be rejected while a link prohibition is present. 3. The last link prohibition status is removed and the server sets the ok status. 4. The role gets its first active association with another object and the server sets the linked status. 5. The last active association of the role is removed and the server removes the linked status. 9.6.3. Status Exclusions +==============+==============================+ | Status Value | MUST NOT be combined with | +==============+==============================+ | ok | Any status other than linked | +--------------+------------------------------+ Table 9: Organisation Role Status Exclusions Other status combinations not expressly prohibited MAY be used. Kowalik & Wullink Expires 6 May 2027 [Page 56] Internet-Draft RPP Data Objects November 2026 9.7. Organisation Status Object * Name: Organisation Status Object * Identifier: organisationStatus * Description: Represents one of the status values associated with an Organisation Data Object, as defined in Section 3.4 of [RFC8543]. An Organisation Data Object MUST always have at least one associated status value. * Data Elements: - Label o Identifier: label o Cardinality: 1 o Mutability: create-only o Data Type: String o Description: machine-readable enum label of a status o Constraints: + Only status values defined in Status Values (#organisation-status-values) are allowed. - Reason o Identifier: reason o Cardinality: 0-1 o Mutability: create-only o Data Type: String o Description: a human-readable text that describes the rationale for the status applied to the object. o Constraints: (None) 9.7.1. Status Values Status values that can be added or removed by a client are prefixed with "client". Corresponding status values that can be added or removed by a server are prefixed with "server". The hold and terminated status values are server-managed when the organisation has no parent organisation and otherwise MAY be client-managed based on server policy. Other status values that do not begin with either "client" or "server" are server-managed. The Set By column identifies the entity that adds and removes each status value: client, server, or client, server for a value that the server manages and that a client can also manage where server policy permits. A server MUST assign at least one status value to the object. A client is not required to provide a status value when creating or updating the object. Kowalik & Wullink Expires 6 May 2027 [Page 57] Internet-Draft RPP Data Objects November 2026 +========================+=========+===============================+ | Status Value | Set By | Description | +========================+=========+===============================+ | ok | server | This is the normal status | | | | value for an object that has | | | | no pending operations or | | | | prohibitions. This value is | | | | set and removed by the server | | | | as other status values are | | | | added or removed. | +------------------------+---------+-------------------------------+ | hold | client, | Organisation transform | | | server | commands and new links MUST | | | | be rejected. | +------------------------+---------+-------------------------------+ | terminated | client, | The organisation has been | | | server | terminated and MUST NOT be | | | | linked. Organisation | | | | transform commands and new | | | | links MUST be rejected. | +------------------------+---------+-------------------------------+ | linked | server | The organisation object has | | | | at least one active | | | | association with another | | | | object. This value is not | | | | explicitly set by the client. | | | | Servers SHOULD provide | | | | services to determine | | | | existing object associations. | +------------------------+---------+-------------------------------+ | clientLinkProhibited | client | Requests to add new links to | | | | the organisation MUST be | | | | rejected. | +------------------------+---------+-------------------------------+ | serverLinkProhibited | server | Requests to add new links to | | | | the organisation MUST be | | | | rejected. | +------------------------+---------+-------------------------------+ | clientUpdateProhibited | client | Requests to update the object | | | | (other than to remove this | | | | status) MUST be rejected. | +------------------------+---------+-------------------------------+ | serverUpdateProhibited | server | Requests to update the object | | | | (other than to remove this | | | | status) MUST be rejected. | +------------------------+---------+-------------------------------+ | clientDeleteProhibited | client | Requests to delete the object | | | | MUST be rejected. | Kowalik & Wullink Expires 6 May 2027 [Page 58] Internet-Draft RPP Data Objects November 2026 +------------------------+---------+-------------------------------+ | serverDeleteProhibited | server | Requests to delete the object | | | | MUST be rejected. | +------------------------+---------+-------------------------------+ | pendingCreate | server | A transform command has been | | | | processed for the object, but | | | | the action has not been | | | | completed by the server. | | | | Server operators can delay | | | | action completion for a | | | | variety of reasons, such as | | | | to allow for human review or | | | | third-party action. | +------------------------+---------+-------------------------------+ | pendingUpdate | server | A transform command has been | | | | processed for the object, but | | | | the action has not been | | | | completed by the server. | | | | Server operators can delay | | | | action completion for a | | | | variety of reasons, such as | | | | to allow for human review or | | | | third-party action. | +------------------------+---------+-------------------------------+ | pendingDelete | server | A transform command has been | | | | processed for the object, but | | | | the action has not been | | | | completed by the server. | | | | Server operators can delay | | | | action completion for a | | | | variety of reasons, such as | | | | to allow for human review or | | | | third-party action. | +------------------------+---------+-------------------------------+ Table 10: Organisation Status Values 9.7.2. Allowed Transitions The following diagram describes the allowed status transitions for an organisation object. The linked, clientLinkProhibited, serverLinkProhibited, clientUpdateProhibited, serverUpdateProhibited, clientDeleteProhibited, and serverDeleteProhibited status values are additive flags that MAY be combined with the states shown below (subject to the Status Exclusions rules) and are not depicted as separate states; while present, the corresponding flag blocks the associated transition (new link, update, or delete, respectively) from being initiated. The linked status is set and removed by the Kowalik & Wullink Expires 6 May 2027 [Page 59] Internet-Draft RPP Data Objects November 2026 server as associations with other objects are added or removed, independently of the transitions described below. | v +----------------------------+ | status: pendingCreate (1) | +----------------------------+ | create action completed (2) v +--------------------------------------------------------+ | Operational state (3) - exactly one of: | | | | +------+ (4) +------+ | | | ok |----------------->| hold | | | | |<-----------------| | | | +------+ (5) +------+ | | | | | | | | | (6) | (6) | | v v | | +--------------------------------+ | | | terminated | | | +--------------------------------+ | | | +--------------------------------------------------------+ | ^ | ^ (7) | | (8) (9) | | (10) v | v | +---------------+ +---------------+ | pendingUpdate | | pendingDelete | +---------------+ +---------------+ | | delete completed (11) v +-----------+ | Purged | +-----------+ Figure 9: Organisation Object State Diagram State descriptions: 1. A create operation is received and processed. If the server defers completion, the object enters pendingCreate state. If the server completes the create immediately, the object enters the ok state directly. Kowalik & Wullink Expires 6 May 2027 [Page 60] Internet-Draft RPP Data Objects November 2026 2. The create action completes and the pendingCreate status is removed. The object enters the operational state (3), normally ok. 3. The object is in exactly one of the mutually exclusive operational states ok, hold, or terminated. The pending states (7) and (9) are entered from, and return to, this operational state. 4. A hold status is set. Organisation transform operations and new links MUST be rejected while the object is in hold. The hold status is set by the server, or by the client if the organisation has a parent organisation and server policy allows it. 5. The hold status is removed and the object returns to ok, by the same parties that are allowed to set it. 6. A terminated status is set, from either ok or hold, by the same parties that are allowed to set hold. A terminated organisation MUST NOT be linked, and organisation transform operations and new links MUST be rejected. Whether and how an object can leave the terminated state is subject to server policy. 7. An update operation is received. If the server defers completion, the object enters pendingUpdate state. 8. The pending update completes, the pendingUpdate status is removed, and the object returns to its operational state. 9. A delete operation is received. If the server defers completion, the object enters pendingDelete state. 10. The pending delete is rejected by the server, the pendingDelete status is removed, and the object returns to its operational state. 11. The pending delete completes and the object is purged. 9.7.3. Pending Status Removal When the requested action has been completed, the pendingCreate, pendingDelete, or pendingUpdate status value MUST be removed. All clients involved in the transaction MUST be notified using a service message that the action has been completed and that the status of the object has changed. 9.7.4. Status Exclusions +====================+==================================+ | Status Value | MUST NOT be combined with | +====================+==================================+ | pendingCreate, ok, | Each other (mutually exclusive); | | hold, terminated | an organisation MUST have | | | exactly one of these statuses | +--------------------+----------------------------------+ | ok | Any status other than linked | Kowalik & Wullink Expires 6 May 2027 [Page 61] Internet-Draft RPP Data Objects November 2026 +--------------------+----------------------------------+ | pendingDelete | clientDeleteProhibited, | | | serverDeleteProhibited | +--------------------+----------------------------------+ | pendingCreate, | Each other (mutually exclusive) | | pendingDelete, | | | pendingUpdate | | +--------------------+----------------------------------+ Table 11: Organisation Status Exclusions The linked status MAY be combined with clientLinkProhibited or serverLinkProhibited if new links must be prohibited. Other status combinations not expressly prohibited MAY be used. 9.8. User Status Object * Name: User Status Object * Identifier: userStatus * Description: Represents the status value associated with a User Data Object. A User Data Object MUST always have exactly one associated status value. * Data Elements: - Label o Identifier: label o Cardinality: 1 o Mutability: create-only o Data Type: String o Description: machine-readable enum label of a status o Constraints: + Only status values defined in Status Values (#user- status-values) are allowed. - Reason o Identifier: reason o Cardinality: 0-1 o Mutability: create-only o Data Type: String o Description: a human-readable text that describes the rationale for the status applied to the object. o Constraints: (None) Kowalik & Wullink Expires 6 May 2027 [Page 62] Internet-Draft RPP Data Objects November 2026 9.8.1. Status Values The pending status value is server-managed. The suspended and deactivated status values are server-managed and MAY additionally be client-managed by a client with permission to manage users in the owning organisation, based on server policy. The active status value is set and removed by the server as other status values are added or removed. The Set By column identifies the entity that adds and removes each status value: client, server, or client, server for a value that the server manages and that a client can also manage where server policy permits. A server MUST assign at least one status value to the object. A client is not required to provide a status value when creating or updating the object. +=============+=========+===========================================+ | Status | Set By | Description | | Value | | | +=============+=========+===========================================+ | active | server | This is the normal status value for a | | | | user that is permitted to | | | | authenticate and act within the | | | | permissions of its roles. | +-------------+---------+-------------------------------------------+ | pending | server | The user has been created, but | | | | activation has not been completed by | | | | the server. Server operators can | | | | delay activation for a variety of | | | | reasons, such as to allow for | | | | verification of the user's details or | | | | human review. Requests authenticated | | | | as the user MUST be rejected. | +-------------+---------+-------------------------------------------+ | suspended | client, | The user has been temporarily | | | server | suspended. Requests authenticated as | | | | the user MUST be rejected. | +-------------+---------+-------------------------------------------+ | deactivated | client, | The user has been deactivated. | | | server | Requests authenticated as the user | | | | MUST be rejected. | +-------------+---------+-------------------------------------------+ Table 12: User Status Values Kowalik & Wullink Expires 6 May 2027 [Page 63] Internet-Draft RPP Data Objects November 2026 9.8.2. Allowed Transitions The following diagram describes the allowed status transitions for a user object. | v +------------------------+ | status: pending (1) | +------------------------+ | activation completed (2) v +--------+ (3) +-----------+ | active |---------------->| suspended | | |<----------------| | +--------+ (4) +-----------+ | | | (5) | (5) v v +-------------------------------------+ | deactivated | +-------------------------------------+ | | delete completed (6) v +-----------+ | Purged | +-----------+ Figure 10: User Object State Diagram State descriptions: 1. A create operation is received and processed. If the server defers activation, the object enters the pending state. If the server activates the user immediately, the object enters the active state directly. 2. Activation completes and the pending status is replaced by active. 3. A suspended status is set, replacing active. 4. The suspended status is removed and the object returns to active, by the same parties that are allowed to set it. 5. A deactivated status is set, from either active or suspended. Whether and how an object can leave the deactivated state is subject to server policy. 6. A delete operation completes and the object is purged. A delete operation can be received in any state; only the transition from deactivated is depicted. Kowalik & Wullink Expires 6 May 2027 [Page 64] Internet-Draft RPP Data Objects November 2026 9.8.3. Pending Status Removal When activation has been completed, the pending status value MUST be replaced by active. The client that created the user MUST be notified using a service message that activation has been completed and that the status of the object has changed. 9.8.4. Status Exclusions +========================+=========================================+ | Status Value | MUST NOT be combined with | +========================+=========================================+ | active, pending, | Each other (mutually exclusive); a user | | suspended, deactivated | MUST have exactly one of these statuses | +------------------------+-----------------------------------------+ Table 13: User Status Exclusions 9.9. DNS Resource Record Object * Name: DNS Resource Record Object * Identifier: dnsRecord * Description: Represents a single DNS resource record. The structure follows the top-level format of a DNS resource record as described in Section 3.2.1 of [RFC1035], adapted for use in provisioning. The RDATA field is represented as a structured object whose fields depend on the record type, following the RDATA presentation format described by the corresponding RFC defining the record type. This approach is aligned with [I-D.simmen-rpp-dns-data]. * Data Elements: - Name o Identifier: name o Cardinality: 1 o Mutability: read-write o Data Type: String o Description: The owner name of the DNS entry. This MAY be the domain itself or a subordinate host name. o Constraints: + The value MUST be a syntactically valid DNS host name. + Absolute FQDNs (with trailing dot) and relative host names are allowed, as well as the "@" symbol representing the domain name itself. - Class o Identifier: class o Cardinality: 0-1 o Mutability: read-write o Data Type: String Kowalik & Wullink Expires 6 May 2027 [Page 65] Internet-Draft RPP Data Objects November 2026 o Description: The DNS resource record class. o Constraints: + If present, the value MUST be chosen from Section 3.2.4 (CLASS values) of [RFC1035]. + A client SHOULD omit this element. The server MUST assume "IN" as the default class and MAY decline other values. - Type o Identifier: type o Cardinality: 1 o Mutability: read-write o Data Type: String o Description: The DNS resource record type, indicating the format of the RDATA field. o Constraints: + The value MUST be a valid string representation of a resource record type as defined in [RFC1035] or other RFC describing the record type. + Allowed values MAY be constrained by server policies. For domain provisioning, the type would typically be constrained to the allowed parent-side entries. + Values MUST be converted to lowercase. + In EPP Compatibility Profile ([RFC5732]), the following record types MUST be supported: ns, a, and aaaa. + In EPP Compatibility Profile with DNSSEC Extension [RFC5910], the following record types MUST additionally be supported: ds and dnskey. - RDATA o Identifier: rdata o Cardinality: 1 o Mutability: read-write o Data Type: Object o Description: The actual payload data of the DNS record. The structure of this object depends on the record type and MUST follow the RDATA presentation format described by the corresponding RFC. Property names MUST be written in camelCase. All property values MUST be represented as Strings encoding the presentation format of the value. o Constraints: + The fields within RDATA MUST match the expected structure for the given record type. + See Section 9.9.1 for required structures in the EPP Compatibility Profile. 9.9.1. RDATA Structures in EPP Profile This section defines the RDATA field structures required for interoperability in the EPP Compatibility Profile. Kowalik & Wullink Expires 6 May 2027 [Page 66] Internet-Draft RPP Data Objects November 2026 In EPP Compatibility Profile ([RFC5732]), the following RDATA structures MUST be supported: * For NS records ([RFC1035], Section 3.3.11): nsdname (the fully qualified domain name of the nameserver). * For A records ([RFC1035], Section 3.4.1): address (the IPv4 address in dotted-decimal notation). * For AAAA records ([RFC3596], Section 2.2): address (the IPv6 address in text representation as defined in [RFC5952]). In EPP Compatibility Profile with DNSSEC Extension ([RFC5910]), the following RDATA structures MUST additionally be supported: * For DS records ([RFC4034], Section 5): keyTag (key tag value), algorithm (algorithm number), digestType (digest algorithm type), and digest (digest value). * For DNSKEY records ([RFC4034], Section 2): flags (flags field value), protocol (protocol field value), algorithm (algorithm number), and publicKey (encoded public key value). | TBC: Optional keyData inside dsData (RFC 5910 Section 4.1): In | the DS Data Interface, a DS record MAY optionally contain a | nested keyData element used for server-side validation of the | DS hash. The draft doesn't describe this pattern - a client | submitting a DS record with accompanying DNSKEY for validation. 9.10. DNS Operational Controls Object * Name: DNS Operational Controls Object * Identifier: dnsControls * Description: Contains operational control parameters that a client MAY use to influence server-side DNS behaviour for a set of DNS records. A server MAY ignore these values, e.g. for policy reasons. This structure is aligned with [I-D.simmen-rpp-dns-data]. * Data Elements: - TTL o Identifier: ttl o Cardinality: 0-1 o Mutability: read-write o Data Type: Dictionary[Integer] o Description: Controls the caching behaviour of DNS resource records. The dictionary is keyed by lowercase record type name, with values representing the TTL in seconds for that record type. o Constraints: + The keys MUST be valid DNS resource record type names in lowercase. Kowalik & Wullink Expires 6 May 2027 [Page 67] Internet-Draft RPP Data Objects November 2026 + The values MUST be positive Integers. + The allowed value ranges MAY be constrained by server policy. + A server MAY ignore client-specified TTL values and apply default or policy-defined values. - Maximum Signature Lifetime o Identifier: maxSigLifetime o Cardinality: 0-1 o Mutability: read-write o Data Type: Dictionary[Integer] o Description: Specifies a child's preference for the maximum number of seconds after signature generation when the parent's signature on signed DNS information should expire. The dictionary is keyed by lower-case record type name, with values representing the maximum signature lifetime in seconds for that record type. The value applies to the RRSIG resource record over the signed DNS RRset. See Section 3 of [RFC4034] for information on the RRSIG resource record. This corresponds to the maxSigLife concept from [RFC5910]. o Constraints: + The keys MUST be valid DNS resource record type names in lowercase. + The values MUST be positive Integers (minimum value of 1). + A server MAY ignore client-specified values and apply its own default signature expiration policy. 9.11. DNS Data Object * Name: DNS Data Object * Identifier: dnsData * Description: A container for DNS resource records and associated operational controls for a provisioned object. This structure groups DNS records together with control parameters that influence server-side DNS behaviour. The structure is aligned with [I-D.simmen-rpp-dns-data]. * Data Elements: - Records o Identifier: records o Cardinality: 0+ o Mutability: read-write o Data Type: DNS Resource Record Object o Description: An array of DNS resource records associated with the provisioned object. o Constraints: + Allowed record types MAY be constrained by server policy. Kowalik & Wullink Expires 6 May 2027 [Page 68] Internet-Draft RPP Data Objects November 2026 + In EPP Compatibility Profile with DNSSEC Extension [RFC5910], records of type DS and DNSKEY MUST be supported in addition to NS, A, and AAAA. + A server MUST support either DS or DNSKEY or both record types for DNSSEC provisioning. If provided with only DNSKEY, a server MUST calculate the DS record. If both record types are provided, a server MAY use the DNSKEY to validate the DS record. - Controls o Identifier: controls o Cardinality: 0-1 o Mutability: read-write o Data Type: DNS Operational Controls Object o Description: Operational control parameters for the DNS records. o Constraints: (None) 9.12. Authorisation Information Object * Name: Authorisation Information Object * Identifier: authInfo * Description: Contains information used to authorise operations on a data object. It may hold different kinds of authorisation information. * Data Elements: - Method o Identifier: method o Cardinality: 1 o Mutability: create-only o Data Type: String o Description: The identifier of the RPP authorisation method. o Constraints: + The value MUST be one of the values registered at IANA as defined in [I-D.draft-wullink-rpp-core]. + In EPP Compatibility Profile this value MUST be set to authinfo if standard password-based authorisation is used - Authorisation Information o Identifier: authdata o Cardinality: 1 o Mutability: create-only o Data Type: String o Description: The value of the authorisation information. It might be as simple as a password string, but also more complex values like public key certificates or tokens encoded as string are possible. o Constraints: Kowalik & Wullink Expires 6 May 2027 [Page 69] Internet-Draft RPP Data Objects November 2026 + Authorisation Information object is immutable. If the information changes (for example password is updated) a new instance MUST be created. + Depending on the method and server policy Authorisation Information MAY not be available for read or any other operation responding with this data element. 9.13. Disclose Object | TODO: Model Disclose in universal (extendible) way * Name: Disclose Object * Identifier: disclose * Description: TBD 9.14. Restore Report Object * Name: Restore Report Object * Identifier: restoreReport * Description: Contains the redemption grace period restore report submitted by the sponsoring client as required by the RGP process ([RFC3915]). A restore report documents the state of the object before and after deletion, provides the reason for restoration, and includes mandatory client statements. This object is OPTIONAL and is only required when the RGP feature is supported and a restore report is being submitted. * Data Elements: - Pre-Delete Data o Identifier: preData o Cardinality: 0-1 o Mutability: read-write o Data Type: String o Description: A copy of the registration data that existed for the object prior to the object being deleted. o Constraints: (None) - Post-Restore Data o Identifier: postData o Cardinality: 0-1 o Mutability: read-write o Data Type: String o Description: A copy of the registration data that exists for the object at the time the restore report is submitted. o Constraints: (None) - Delete Time o Identifier: deleteTime o Cardinality: 0-1 o Mutability: read-write o Data Type: Timestamp Kowalik & Wullink Expires 6 May 2027 [Page 70] Internet-Draft RPP Data Objects November 2026 o Description: The date and time when the object delete request was sent to the server. o Constraints: (None) - Restore Time o Identifier: restoreTime o Cardinality: 0-1 o Mutability: read-write o Data Type: Timestamp o Description: The date and time when the original restore request operation was sent to the server. o Constraints: + This element MAY be omitted when the restore report is submitted inline within the restore request in a single- step process. + In EPP Compatibility Profile this element MUST be present as defined in [RFC3915]. - Restore Reason o Identifier: restoreReason o Cardinality: 0-1 o Mutability: read-write o Data Type: String o Description: A brief explanation of the reason for restoring the object. o Constraints: (None) - Statements o Identifier: statements o Cardinality: 1-2 o Mutability: read-write o Data Type: String o Description: Client statements required by the RGP process. o Constraints: In EPP Compatibility Profile exactly two statements MUST be present as defined in [RFC3915]. - Other o Identifier: other o Cardinality: 0-1 o Mutability: read-write o Data Type: String o Description: Any additional information needed to support the statements provided by the client. o Constraints: (None) 9.15. Organisation Role Object * Name: Organisation Role Object * Identifier: organisationRole Kowalik & Wullink Expires 6 May 2027 [Page 71] Internet-Draft RPP Data Objects November 2026 * Description: Represents a role that an organisation has within the registry ecosystem. An organisation object MUST always have at least one associated role. A single organisation MAY have multiple roles with different role types. * Data Elements: - Role Identifier o Identifier: roleId o Cardinality: 0-1 o Mutability: read-write o Data Type: String o Description: A third-party-assigned identifier for the role, such as an IANA ID for registrars. o Constraints: (None) - Role Status o Identifier: status o Cardinality: 0+ o Mutability: read-write o Data Type: Organisation Role Status Object o Description: The status of this particular role. A role SHOULD have at least one associated status value. o Constraints: + Possible values and combinations are specified in Organisation Role Status Values (#organisation-role- status-values). | TBC: IANA registry for role types and statuses? must be compat | with EPP 9.16. Processes Object * Name: Processes Object * Identifier: processes * Description: A container grouping the Process Objects Section 10 currently or recently initiated on a Data Object. Each data element MUST be named after the identifier of a Process Object and MUST be of type Aggregation of that Process Object. The data elements below are the process types defined in this document. Extensions MUST add further data elements for the Process Objects they define. * Data Elements: - Transfer Processes o Identifier: transferProcess o Cardinality: 0+ o Mutability: read-only o Data Type: Aggregation[Transfer Process Object] o Direct Access: true o Description: The transfer processes initiated on the owning Data Object. Kowalik & Wullink Expires 6 May 2027 [Page 72] Internet-Draft RPP Data Objects November 2026 o Constraints: (None) - Renew Processes o Identifier: renewProcess o Cardinality: 0+ o Mutability: read-only o Data Type: Aggregation[Renew Process Object] o Direct Access: true o Description: The renew processes initiated on the owning Data Object. o Constraints: (None) - Restore Processes o Identifier: restoreProcess o Cardinality: 0+ o Mutability: read-only o Data Type: Aggregation[Restore Process Object] o Direct Access: true o Description: The restore processes initiated on the owning Data Object. o Constraints: (None) - Create Processes o Identifier: createProcess o Cardinality: 0+ o Mutability: read-only o Data Type: Aggregation[Create Process Object] o Direct Access: true o Description: The create processes initiated on the owning Data Object. o Constraints: (None) 9.17. Base Process Object * Name: Base Process Object * Identifier: baseProcess * Abstract: true * Description: Base structure for all Process Objects, containing the data elements common to every process. Each Process Object extends this object. * Data Elements: - Process ID o Identifier: processId o Cardinality: 0-1 o Mutability: read-only o Data Type: String o Description: A server-assigned identifier of the process instance, unique within the scope of the Owner Data Object. o Constraints: The value is set by the server and cannot be specified by the client. Kowalik & Wullink Expires 6 May 2027 [Page 73] Internet-Draft RPP Data Objects November 2026 9.18. Availability The Availability Objects define the output of the Availability operation (see Section 2.7.4.6). Each Data Object that supports the Availability operation defines its own Availability Object extending the Base Availability Object. Extensions add availability information, for example pricing, as data elements of these objects. 9.18.1. Base Availability Object * Name: Base Availability Object * Identifier: baseAvailability * Abstract: true * Description: Base structure for the result of an Availability operation, indicating whether the referenced object can be created. * Data Elements: - Available o Identifier: available o Cardinality: 1 o Mutability: read-only o Data Type: Boolean o Description: Indicates whether the referenced object can be created at the time the operation is completed. The value true means that the object can be created. It does not guarantee that a subsequent Create operation for the same object succeeds, as the state of the server can change between the two operations. The value false means that the object cannot be created. o Constraints: (None) - Reason o Identifier: reason o Cardinality: 0-1 o Mutability: read-only o Data Type: String o Description: Server-specific text explaining why the referenced object cannot be created. o Constraints: The element is present only when available is false. 9.18.2. Domain Name Availability Object * Name: Domain Name Availability Object * Identifier: domainNameAvailability * Extends: Base Availability Object * Description: The result of an Availability operation on a Domain Name Data Object. * Data Elements: (None) Kowalik & Wullink Expires 6 May 2027 [Page 74] Internet-Draft RPP Data Objects November 2026 9.18.3. Contact Availability Object * Name: Contact Availability Object * Identifier: contactAvailability * Extends: Base Availability Object * Description: The result of an Availability operation on a Contact Data Object. * Data Elements: (None) 9.18.4. Host Availability Object * Name: Host Availability Object * Identifier: hostAvailability * Extends: Base Availability Object * Description: The result of an Availability operation on a Host Data Object. * Data Elements: (None) 9.19. Messages The Message Components define the structure and data elements for all message objects used in the protocol. Each specific message type extends the Base Message Object to include additional data elements relevant to that message type. Any of the types defined in this section may be used for the data data element defined for the Message Data Object. 9.19.1. Base Message Object * Name: Base Message Object * Identifier: baseMessage * Abstract: true * Description: Base structure for all message objects, containing common data elements such as the object type and object identifier. * Data Elements: - Object Type o Identifier: objectType o Cardinality: 0-1 o Mutability: read-only o Data Type: String o Description: The object identifier of the object affected by the requested action (e.g., "domainName", "host", "contact"). o Constraints: + Must only be used when the objectId field is present. - Object Identifier o Identifier: objectId Kowalik & Wullink Expires 6 May 2027 [Page 75] Internet-Draft RPP Data Objects November 2026 o Cardinality: 0-1 o Mutability: read-only o Data Type: String o Description: The unique identifier of the object affected by the requested operation. o Constraints: + Must be a valid unique identifier for the object type specified in the objectType field. + For "domainName" and "host" the objectId must be a valid fully qualified domain name (FQDN). + For "contact" the objectId must be a valid contact identifier. + When the message is not related to a specific object, the objectId field may be empty. 9.19.2. Review Response Object The Review Response Object defines the data elements for returning the result of an offline review. Offline review is optional for the create, update, delete, transfer, renew and restore actions, where the server may want to perform an offline review before completing the requested action. * Name: Review Response Object * Identifier: reviewResponseMessage * Extends: Base Message Object * Description: Notification of the result of an offline review of a requested operation. * Data Elements: - Approval Result o Identifier: approved o Cardinality: 1 o Mutability: read-only o Data Type: Boolean o Description: Whether the requested action was approved and completed. o Constraints: false means the action was denied and not performed. - Client Transaction ID o Identifier: clientTransactionId o Cardinality: 0-1 o Mutability: read-only o Data Type: String o Description: The client transaction identifier from the original request, if supplied. o Constraints: (None) - Server Transaction ID o Identifier: serverTransactionId Kowalik & Wullink Expires 6 May 2027 [Page 76] Internet-Draft RPP Data Objects November 2026 o Cardinality: 1 o Mutability: read-only o Data Type: String o Description: The server transaction identifier returned for the original request. o Constraints: (None) - Completion Date o Identifier: completionDate o Cardinality: 1 o Mutability: read-only o Data Type: Timestamp o Description: The date and time when review of the requested action was completed. o Constraints: (None) - Message o Identifier: message o Cardinality: 1 o Mutability: read-only o Data Type: String o Description: Human-readable message associated with the review response. o Constraints: (None) - Process o Identifier: process o Cardinality: 0-1 o Mutability: read-only o Data Type: Base Process Object o Description: The process whose operation was subject to the offline review. o Constraints: Present when the reviewed operation was performed through a Process Object (create, renew, transfer, or restore) and the server exposes that Process Object; absent otherwise, including for update and delete operations. 9.19.3. Transfer Request Message Object * Name: Transfer Request Message Object * Identifier: transferRequestMessage * Extends: Base Message Object * Description: Notification for losing client of started transfer request, where the client expected to act on the pending transfer request. * Data Elements: - Transfer Status o Identifier: status o Cardinality: 1 o Mutability: read-only Kowalik & Wullink Expires 6 May 2027 [Page 77] Internet-Draft RPP Data Objects November 2026 o Data Type: String o Description: The current state of the transfer request. o Constraints: The value MUST be pending. - Request Date o Identifier: requestDate o Cardinality: 1 o Mutability: read-only o Data Type: Timestamp o Description: The date and time the transfer was requested. o Constraints: (None) - Action Date o Identifier: actionDate o Cardinality: 0-1 o Mutability: read-only o Data Type: Timestamp o Description: The deadline for responding before the server takes an automated action. o Constraints: + The action date MUST be later than the request date and is subject to server policy. - Process o Identifier: process o Cardinality: 0-1 o Mutability: read-only o Data Type: Transfer Process Object o Description: The transfer process the message pertains to. o Constraints: Absent if the server does not expose the Transfer Process Object. 9.19.4. Transfer Outcome Message Object * Name: Transfer Outcome Message Object * Identifier: transferOutcomeMessage * Extends: Base Message Object * Description: Notification for a client affected by the completion of a transfer request. * Data Elements: - Transfer Status o Identifier: trStatus o Cardinality: 1 o Mutability: read-only o Data Type: String o Description: The final state of the transfer request. o Constraints: The value MUST be one of clientApproved, clientCancelled, clientRejected, serverApproved, or serverCancelled. - Request Date o Identifier: requestDate Kowalik & Wullink Expires 6 May 2027 [Page 78] Internet-Draft RPP Data Objects November 2026 o Cardinality: 1 o Mutability: read-only o Data Type: Timestamp o Description: The date and time the transfer was requested. o Constraints: (None) - Action Date o Identifier: actionDate o Cardinality: 1 o Mutability: read-only o Data Type: Timestamp o Description: The date and time the transfer request was resolved. o Constraints: (None) - Expiry Date o Identifier: expiryDate o Cardinality: 0-1 o Mutability: read-only o Data Type: Timestamp o Description: The end of the object's validity period if the operation causes a change in the validity period. o Constraints: (None) - Process o Identifier: process o Cardinality: 0-1 o Mutability: read-only o Data Type: Transfer Process Object o Description: The transfer process the message pertains to. o Constraints: Absent if the server does not expose the Transfer Process Object. 9.19.5. Expiration Deletion Message Object * Name: Expiration Deletion Message Object * Identifier: expirationDeletionMessage * Extends: Base Message Object * Description: Notification for the sponsoring client that an object was deleted following expiration. * Data Elements: - Deletion Date o Identifier: deletionDate o Cardinality: 1 o Mutability: read-only o Data Type: Timestamp o Description: The date and time the server deleted the object. o Constraints: (None) Kowalik & Wullink Expires 6 May 2027 [Page 79] Internet-Draft RPP Data Objects November 2026 9.19.6. Auto-Renewal Message Object * Name: Auto-Renewal Message Object * Identifier: autoRenewalMessage * Extends: Base Message Object * Description: Notification for the sponsoring client that the server automatically renewed an object. * Data Elements: - Renewal Date o Identifier: renewalDate o Cardinality: 1 o Mutability: read-only o Data Type: Timestamp o Description: The date and time the server renewed the object. o Constraints: (None) - Expiry Date o Identifier: expiryDate o Cardinality: 1 o Mutability: read-only o Data Type: Timestamp o Description: The new expiration date of the object. o Constraints: (None) 9.19.7. Service Notice Message Object The Service Notice Message Object is not linked to a specific object or process and can be used to convey general information to the client. * Name: Service Notice Message Object * Identifier: serviceNoticeMessage * Extends: Base Message Object * Description: Generic text-based message containing information not covered by any other message type. * Data Elements: - Message o Identifier: message o Cardinality: 1 o Mutability: read-only o Data Type: String o Description: Human-readable service information for the receiving organisation. o Constraints: + The server MUST NOT misuse this field by using it for transmitting structured data or machine-readable information. Kowalik & Wullink Expires 6 May 2027 [Page 80] Internet-Draft RPP Data Objects November 2026 *TODO* Complete the Service Notice Message Object definition, do we need it at all? 9.20. Discovery 9.20.1. Version Object * Name: Discovery Version Object * Identifier: discoveryVersion * Description: Describes a version of RPP supported by the server. * Data Elements: - Version o Identifier: version o Cardinality: 1 o Mutability: read-only o Data Type: String o Description: The RPP version, for example "1.0". o Constraints: The value MUST use the Semantic Versioning format. - Base URL o Identifier: baseUrl o Cardinality: 1 o Mutability: read-only o Data Type: URL o Description: The base URL specific for the version, used as a prefix for all endpoint URL templates. o Constraints: (None) 9.20.2. Environment Object * Name: Discovery Environment Object * Identifier: discoveryEnvironment * Description: Describes the environment of the RPP server. * Data Elements: - Name o Identifier: name o Cardinality: 1 o Mutability: read-only o Data Type: String o Description: The name of the RPP server, for example "rpp.example". o Constraints: (None) - Status o Identifier: status o Cardinality: 1 o Mutability: read-only o Data Type: String Kowalik & Wullink Expires 6 May 2027 [Page 81] Internet-Draft RPP Data Objects November 2026 o Description: The operational status of the RPP server, for example "production", "test", or "development". o Constraints: (None) 9.20.3. Extension Object * Name: Extension Object * Identifier: extension * Description: Describes an extension supported by the server. * Data Elements: - Name o Identifier: name o Cardinality: 1 o Mutability: read-only o Data Type: String o Description: A short name for the extension, for example "registry fee extension". o Constraints: (None) - Extension ID o Identifier: id o Cardinality: 1 o Mutability: read-only o Data Type: String o Description: A unique URN identifier for the extension, for example "urn:ietf:params:rpp:extension:registry-fee". o Constraints: (None) - Version o Identifier: version o Cardinality: 1 o Mutability: read-only o Data Type: String o Description: The version of the extension that is supported or required for the profile, for example "1.0". o Constraints: (None) - URL o Identifier: url o Cardinality: 1 o Mutability: read-only o Data Type: URL o Description: The location of the extension specification. o Constraints: + For standard extensions, the value MUST be the URL of the extension in the IANA registry. + For private extensions, the value MUST be the URL of the extension specification. The domain name used in the URL MUST resolve and the URL MUST be accessible to the client. Kowalik & Wullink Expires 6 May 2027 [Page 82] Internet-Draft RPP Data Objects November 2026 9.20.4. IDN LGR Object * Name: Discovery IDN LGR Object * Identifier: discoveryIdnLgr * Description: Describes a Label Generation Ruleset (LGR) supported by the server for internationalized domain names. * Data Elements: - TLDs o Identifier: tld o Cardinality: 1+ o Mutability: read-only o Data Type: String o Description: The top-level domains (TLDs) to which the LGR applies. o Constraints: (None) - Name o Identifier: name o Cardinality: 1 o Mutability: read-only o Data Type: String o Description: The IANA-registered name of the LGR. o Constraints: The value MUST be a valid LGR name as listed in the IANA IDN Tables registry [IDN-Tables]. - URL o Identifier: url o Cardinality: 1 o Mutability: read-only o Data Type: URL o Description: The location of the LGR specification in the IANA IDN Tables registry [IDN-Tables]. o Constraints: (None) - Default o Identifier: default o Cardinality: 1 o Mutability: read-only o Data Type: Boolean o Description: Indicates whether this LGR is the default for the specified TLDs. o Constraints: (None) 9.20.5. Notice Object * Name: Discovery Notice Object * Identifier: discoveryNotice * Description: Describes a notice from the server operator. * Data Elements: - Publication Time o Identifier: pubTime Kowalik & Wullink Expires 6 May 2027 [Page 83] Internet-Draft RPP Data Objects November 2026 o Cardinality: 1 o Mutability: read-only o Data Type: Timestamp o Description: The publication time of the notice. o Constraints: (None) - Text o Identifier: text o Cardinality: 1 o Mutability: read-only o Data Type: String o Description: A human-readable description of the notice. o Constraints: (None) 10. Process Objects This section defines the Process Objects used in this document. Each Process Object extends the Base Process Object Section 9.17 and therefore carries its OPTIONAL Process ID data element. 10.1. Transfer Process Object * Name: Transfer Process Object * Identifier: transferProcess * Unique Identifier: processId * Extends: Base Process Object * Description: Represents a transfer request for a provisioned object. Creating this object initiates a transfer. The object supports approve and reject as additional operations, and delete as the cancel operation. Reading the object returns the current transfer status. * Data Elements: - Transfer Direction o Identifier: transferDir o Cardinality: 0-1 o Mutability: create-only o Data Type: String o Description: Indicates whether the transfer is a "pull" or "push" transfer. Per policy, servers usually support only one model. If omitted, server policy determines the default. o Constraints: The value MUST be one of: "pull" (initiated by the gaining client) or "push" (initiated by the sponsoring client). - Gaining Client ID o Identifier: gainingClientId o Cardinality: 0-1 o Mutability: create-only Kowalik & Wullink Expires 6 May 2027 [Page 84] Internet-Draft RPP Data Objects November 2026 o Data Type: Client Identifier o Description: The identifier of the designated gaining client. This element is REQUIRED for push transfers and MUST NOT be provided for pull transfers. o Constraints: (None) - Transfer Status o Identifier: trStatus o Cardinality: 1 o Mutability: read-only o Data Type: String o Description: The state of the transfer request. o Constraints: The value MUST be one of: "pending", "clientApproved", "clientCancelled", "clientRejected", "serverApproved", "serverCancelled". - Requesting Client ID o Identifier: reqClientId o Cardinality: 1 o Mutability: read-only o Data Type: Client Identifier o Description: The identifier of the client that initiated the transfer request. o Constraints: (None) - Request Date o Identifier: requestDate o Cardinality: 1 o Mutability: read-only o Data Type: Timestamp o Description: The date and time that the transfer was requested. o Constraints: (None) - Acting Client ID o Identifier: actClientId o Cardinality: 1 o Mutability: read-only o Data Type: Client Identifier o Description: For a pending pull transfer, the identifier of the sponsoring client that SHOULD act upon the request. For a pending push transfer, the identifier of the designated gaining client that SHOULD act upon the request. For all other statuses, the identifier of the client that took the indicated action. o Constraints: (None) - Action Date o Identifier: actionDate o Cardinality: 1 o Mutability: read-only o Data Type: Timestamp Kowalik & Wullink Expires 6 May 2027 [Page 85] Internet-Draft RPP Data Objects November 2026 o Description: For a pending request, the date and time by which a response is required before an automated response action SHOULD be taken by the server. For all other statuses, the date and time when the request was completed. o Constraints: (None) 10.1.1. Operations 10.1.1.1. Create (Transfer Request) * Identifier: transferCreate The Create operation initiates a transfer by creating a Transfer Process Object associated with the provisioned object. The transfer direction and gaining client (for push transfers) are provided as create-only data elements of the Transfer Process Object. * Authorisation: - Pull transfer: o The requesting client (gaining client) MUST provide valid Object Authorisation. - Push transfer: o Only the sponsoring client is authorised to initiate a push transfer. * Input: - Reference: Owner Data Object - Object: Transfer Process Object * Output: - Object: Transfer Process Object 10.1.1.2. Read (Transfer Query) * Identifier: transferRead The Read operation allows a client to determine the real-time status of a pending or recently completed transfer request. * Authorisation: - This operation MUST be accessible to both the sponsoring client and the gaining client. - Server policy determines whether other clients may query transfer status and what information is returned. Kowalik & Wullink Expires 6 May 2027 [Page 86] Internet-Draft RPP Data Objects November 2026 * Input: - Reference: This Object * Output: - Object: Transfer Process Object 10.1.1.3. Delete (Transfer Cancel) * Identifier: transferDelete The Delete operation allows the initiating client to cancel its own pending transfer request. * Authorisation: - Only the initiating client (the client that originally requested the transfer). * Input: - Reference: This Object * Output: - Object: Transfer Process Object o Cardinality: 0-1 10.1.1.4. Approve * Identifier: transferApprove The Approve operation allows the appropriate client to accept a pending transfer request. * Authorisation: - Pull transfer: o only the sponsoring client - Push transfer: o only the designated gaining client * Input: - Reference: This Object * Output: Kowalik & Wullink Expires 6 May 2027 [Page 87] Internet-Draft RPP Data Objects November 2026 - Object: Transfer Process Object 10.1.1.5. Reject * Identifier: transferReject The Reject operation allows the appropriate client to decline a pending transfer request. * Authorisation: - Pull transfer: o only the sponsoring client - Push transfer: o only the designated gaining client * Input: - Reference: This Object - Input Data Elements: o Reason + Identifier: reason + Cardinality: 0-1 + Data Type: String + Description: A human-readable text describing the rationale for rejecting the transfer request. + Constraints: In EPP Compatibility Profile this data element MUST NOT be used * Output: - Object: Transfer Process Object 10.2. Restore Process Object * Name: Restore Process Object * Identifier: restoreProcess * Unique Identifier: processId * Extends: Base Process Object * Description: Represents the current state of a restore request for an object that has entered the Redemption Grace Period (RGP). * Data Elements: - Restore Status o Identifier: restoreStatus o Cardinality: 1 o Mutability: read-only o Data Type: String o Description: The current state of the restore process. Kowalik & Wullink Expires 6 May 2027 [Page 88] Internet-Draft RPP Data Objects November 2026 o Constraints: The value MUST be one of: "pendingRestore", "restored", "rgpPendingDelete" - Request Date o Identifier: requestDate o Cardinality: 0-1 o Mutability: read-only o Data Type: Timestamp o Description: The date and time when the restore request was submitted. o Constraints: MUST NOT be present if no restore request has been submitted yet. - Report Date o Identifier: reportDate o Cardinality: 0-1 o Mutability: read-only o Data Type: Timestamp o Description: The date and time when the most recent restore report was accepted by the server. o Constraints: MUST NOT be present if no restore report has been accepted yet. - Report Due Date o Identifier: reportDueDate o Cardinality: 0-1 o Mutability: read-only o Data Type: Timestamp o Description: The date and time by which a restore report must be submitted before the object reverts to rgpRedemptionPeriod state. Only present when the object is in rgpPendingRestore state. o Constraints: MUST NOT be present when restoreStatus is not "pendingRestore". - Restore Report o Identifier: restoreReport o Cardinality: 0-1 o Mutability: read-write o Data Type: Restore Report Object o Visibility: onDemand o Description: The restore report submitted by the sponsoring client as required by the RGP process. A client MAY provide it in the Create operation, so that the restore request and the report are processed atomically, or in a later Update operation while the object is in rgpPendingRestore state. A report provided in an Update operation replaces any previously submitted report. o Constraints: + MUST NOT be provided if the server does not require a restore report. Kowalik & Wullink Expires 6 May 2027 [Page 89] Internet-Draft RPP Data Objects November 2026 + In EPP Compatibility Profile, the restore report is write-only: the server does not return it in the output of any operation, because [RFC3915] provides no means to retrieve a submitted report. + In EPP Compatibility Profile, providing this element in the Create operation corresponds to op="report", omitting it corresponds to op="request", and providing it in the Update operation corresponds to op="report" as defined in [RFC3915]. 10.2.1. Operations 10.2.1.1. Create (Restore Request) * Identifier: create The Create operation initiates the recovery of an object in the rgpRedemptionPeriod state by creating a Restore Process Object. The server MUST reject this operation if the owning object is not in the rgpRedemptionPeriod state. If the server requires a restore report and restoreReport is absent, the object transitions to rgpPendingRestore state awaiting a subsequent Update operation. Otherwise the restore is completed immediately. * Authorisation: - Only the sponsoring client is authorised to perform this operation. * Input: - Reference: Owner Data Object - Object: Restore Process Object - Input Data Elements: o Restore Report + Identifier: restoreReport + Cardinality: 0-1 + Data Type: Restore Report Object + Description: An OPTIONAL inline restore report. If provided, the server processes the request and the report atomically. If the server does not require a restore report, this element MUST NOT be present and the restore is completed immediately. If the server requires a report and this element is absent, the object transitions to pendingRestore state awaiting a subsequent Report operation. Kowalik & Wullink Expires 6 May 2027 [Page 90] Internet-Draft RPP Data Objects November 2026 + Constraints: + MUST NOT be provided if the server does not require a restore report. + In EPP Compatibility Profile, corresponds to op="request" (without report) or a combined op="request" followed immediately by op="report" as defined in [RFC3915]. * Output: - Object: Restore Process Object 10.2.1.2. Read (Restore Query) * Identifier: read The Read operation allows the sponsoring client to retrieve the current state of the RGP process for an object. * Authorisation: - Only the sponsoring client is authorised to perform this operation. * Input: - Reference: This Object * Output: - Object: Restore Process Object In EPP Compatibility Profile this operation is not supported. 10.2.1.3. Update (Restore Report) * Identifier: update This operation is OPTIONAL, only for servers which support or require submission of a restore report. The Update operation submits the restore report required by the RGP process for an object in the rgpPendingRestore state. Since restoreReport is the only read-write data element of the Restore Process Object, the client MUST provide it in this operation. A report MAY be submitted more than once if corrections are required. The server MUST reject this operation if the object is not in the rgpPendingRestore state. Kowalik & Wullink Expires 6 May 2027 [Page 91] Internet-Draft RPP Data Objects November 2026 * Authorisation: - Only the sponsoring client is authorised to perform this operation. * Input: - Reference: This Object - Input Data Elements: o Restore Report + Identifier: restoreReport + Cardinality: 1 + Data Type: Restore Report Object + Description: The restore report to be submitted as part of the RGP process. + Constraints: + In EPP Compatibility Profile, corresponds to op="report" as defined in [RFC3915]. * Output: - Object: Restore Process Object 10.3. Renew Process Object * Name: Renew Process Object * Identifier: renewProcess * Unique Identifier: processId * Extends: Base Process Object * Description: Represents a renew request for a provisioned object. Creating this object initiates a renewal process that extends the registration period of the object. Reading this object returns the new expiry date if the renewal has been completed. * Data Elements: - Expiry Date o Identifier: expiryDate o Cardinality: 0-1 o Mutability: create-only o Data Type: Timestamp o Description: The current expiry date of the object. The server MUST validate this against the object's current expiryDate to prevent unintended duplicate renewals. - Renewal Period o Identifier: renewalPeriod o Cardinality: 0-1 o Mutability: create-only o Data Type: Period Object Kowalik & Wullink Expires 6 May 2027 [Page 92] Internet-Draft RPP Data Objects November 2026 o Description: The duration to be added to the object's registration period. This value is used by the server to calculate the new expiryDate. The default value MAY be defined by server policy. The number of units available MAY be subject to limits imposed by the server. 10.3.1. Operations 10.3.1.1. Create (Renew Request) * Identifier: renewCreate The renew operation extends the validity period of an existing object by creating a Renew Process Object. * Input: - Reference: Owner Data Object - Object: Renew Process Object * Output: - Object: Renew Process Object * Authorisation: - Only the sponsoring client is authorised to perform this operation. 10.4. Create Process Object * Name: Create Process Object * Identifier: createProcess * Unique Identifier: processId * Extends: Base Process Object * Description: Represents the process initiated when a resource creation operation is performed. It carries creation-specific inputs that are consumed during the creation operation and are not stored as persistent attributes of the created resource object. * Data Elements: (None) Beyond the data elements of the Base Process Object, the generic Create Process Object defines no additional data elements. Individual object definitions extend it with object-specific creation inputs (such as the Domain Create Process Object Section 11.4.1, which adds the registration period). Kowalik & Wullink Expires 6 May 2027 [Page 93] Internet-Draft RPP Data Objects November 2026 10.4.1. Operations 10.4.1.1. Create * Identifier: create The Create operation is invoked implicitly as a side effect of the resource object create operation and is never invoked directly. It carries the creation-specific inputs consumed during the creation of the owning resource object. * Input: - Object: Create Process Object * Output: - Object: Create Process Object * Authorisation: - Inherited from the resource object create operation that initiates this process. 10.4.1.2. Read * Identifier: read The Read operation retrieves the result or status of the creation, if the server exposes the process resource. * Input: - Reference: This Object * Output: - Object: Create Process Object * Authorisation: - Only the sponsoring client is authorised to perform this operation. 11. Domain Name Data Object 11.1. Object Description Kowalik & Wullink Expires 6 May 2027 [Page 94] Internet-Draft RPP Data Objects November 2026 * Name: Domain Name Data Object * Identifier: domainName * Unique Identifier: name * Description: A Domain Name data object represents a domain name and contains the data required for its provisioning and management in the registry. 11.2. Data Elements The following data elements are defined for the Domain Name Data Object. * Name - Identifier: name - Cardinality: 1 - Mutability: create-only - Data Type: Fully Qualified Domain Name - Description: The fully qualified name of the domain object. - Constraints: o A server MAY restrict allowable domain names to a particular top-level domain, second-level domain, or other domain for which the server is authoritative. o If the domain name is an internationalized domain name (IDN), the value MUST be a valid ACE-encoded string representing the Unicode Name (uName). * Unicode Name - Identifier: uName - Cardinality: 0-1 - Mutability: create-only - Data Type: String - Description: The fully qualified name of the domain using the Unicode character set. - Constraints: o The value MUST be a fully qualified domain name in Unicode Normalization Form C (NFC) as defined in [UNICODE.NFC]. o The server MUST validate the Unicode Name using the procedure described in section 4.2 of [RFC5891]. o Every code point in the value MUST be classified as a candidate for inclusion by the rules defined in [RFC5892]. o If the value contains a code point from a script with Right- to-Left directionality, the value MUST satisfy the Bidi Rule defined in [RFC5893]. Kowalik & Wullink Expires 6 May 2027 [Page 95] Internet-Draft RPP Data Objects November 2026 o The Unicode (U-label) form of the domain name, when converted according to the procedures defined in Section 2.3.2.4 of [RFC5890], MUST be equal to the corresponding A-label representation. o Any code point valid under IDNA2003 but disallowed under IDNA2008 MUST NOT be allowed in the Unicode Name (uName). * LGR - Identifier: lgr - Cardinality: 0-1 - Mutability: create-only - Data Type: String - Description: The name of the Label Generation Ruleset (LGR) containing the valid code points used for the Unicode Name (uName). - Constraints: o MUST NOT be empty when the Unicode Name (uName) is provided. o MUST be a valid LGR name registered in the IANA IDN Tables registry [IDN-Tables]. * Provisioning Metadata - Identifier: provMetadata - Cardinality: 1 - Mutability: read-only - Data Type: Provisioning Metadata Object - Description: Standard metadata about the object's lifecycle and ownership. - Constraints: (None) * Status - Identifier: status - Cardinality: 1+ - Mutability: read-write - Data Type: Domain Name Status Object - Description: The current status descriptors associated with the domain. - Constraints: o Possible combinations of Status Object Labels are specified in Section 9.3. * Registrant - Identifier: registrant - Cardinality: 0-1 - Mutability: read-write Kowalik & Wullink Expires 6 May 2027 [Page 96] Internet-Draft RPP Data Objects November 2026 - Data Type: Aggregation[Contact Data Object] - Description: The contact object associated with the domain as the registrant. - Constraints: o The relation MUST correspond to a valid Contact Data Object known to the server. o Servers MAY restrict association of a Contact Data Object of a different sponsoring client. | TBC: leave registrant here or move it to contacts with a type? * Contacts - Identifier: contacts - Cardinality: 0+ - Mutability: read-write - Data Type: LabelledAggregation[Contact Data Object] o Label Description: The role of the associated contact. o Label Constraints: + List of supported roles is defined by server policy + In the EPP Compatibility Profile, the value MUST be one of: "admin", "billing", or "tech" - Description: A collection of other contact objects associated with the domain object. - Constraints: o Each associated contact MUST correspond to a valid Contact Data Object known to the server before it can be associated with the domain. o Maximum number of associated contacts (per role) MAY be restricted by server policy | TBC: IANA registry for contact role label? * Nameservers - Identifier: nameservers - Cardinality: 0+ - Mutability: read-write - Data Type: Aggregation[Host Data Object] - Description: A collection of nameservers associated with the domain. - Constraints: o A Host Data Object MUST be known to the server before it can be associated with the domain. o MUST not be used when 1 or more DNS Data entries are specified through the DNS Data element. * DNS Data Kowalik & Wullink Expires 6 May 2027 [Page 97] Internet-Draft RPP Data Objects November 2026 - Identifier: dns - Cardinality: 0-1 - Mutability: read-write - Data Type: DNS Data Object - Description: DNS resource records and operational controls related to the domain name. This structure follows the unified DNS data model defined in [I-D.simmen-rpp-dns-data], providing a single container for all DNS-related provisioning data including delegation, DNSSEC, and other record types. - Constraints: o The type of the record entries MAY be constrained by the server policy. Typically the values would be limited to allowed parent-side resource record types. o In EPP Compatibility Profile, a server MUST support NS, A, and AAAA record types for delegation, and with DNSSEC Extension [RFC5910] a server MUST additionally support DS and/or DNSKEY record types. o The names of DNS entries MUST be the domain name itself or subordinate to the domain name and MUST NOT be below zone cut in case of present delegation. o A server MAY forbid use of NS/A/AAAA record types if the server only supports host object model through Nameserver property defining those records. o MUST not be used when 1 or more nameservers are specified through the Nameserver element. * Subordinate Hosts - Identifier: subordinateHosts - Cardinality: 0+ - Mutability: read-only - Data Type: Aggregation[Host Data Object] - Description: A collection of subordinate host objects that exist under this domain. - Constraints: (None) * Expiry Date - Identifier: expiryDate - Cardinality: 0-1 - Mutability: read-only - Data Type: Timestamp - Description: The date and time identifying the end of the domain object's registration period. - Constraints: The value is set by the server and cannot be specified by the client. * Authorisation Information Kowalik & Wullink Expires 6 May 2027 [Page 98] Internet-Draft RPP Data Objects November 2026 - Identifier: authInfo - Cardinality: 0-1 - Mutability: read-write - Data Type: Authorisation Information Object - Visibility: onDemand - Description: Authorisation information associated with the domain object. - Constraints: o This element MUST only be returned if the querying client is the sponsoring client or if the client supplied valid Object Authorisation with the operation. * Processes - Identifier: processes - Cardinality: 0-1 - Mutability: read-only - Data Type: Processes Object - Direct Access: true - Description: The Process Objects currently or recently initiated on the domain object. - Constraints: (None) 11.3. Operations 11.3.1. Availability Operation * Identifier: availability The Availability operation allows a client to determine whether a Domain Name resource with the given name can be created. The operation has no input data elements and takes no object representation as input. The client identifies the resource by its Reference only, i.e. only the Unique Identifier (Name) is taken into consideration. * Authorisation: - Any authenticated client is authorised to perform this operation. * Input: - Reference: This Object - Parameters: o Unicode Name + Identifier: uName Kowalik & Wullink Expires 6 May 2027 [Page 99] Internet-Draft RPP Data Objects November 2026 + Cardinality: 0-1 + Data Type: String + Description: The Unicode Name (uName) of the domain name for which availability is determined. If the parameter is absent, the server determines availability from the referenced domain name only. + Constraints: + The value MUST satisfy the constraints of the Unicode Name data element of the Domain Name Data Object. + If the value does not map to the referenced domain name, the server MUST return an error indicating the mismatch. o LGR + Identifier: lgr + Cardinality: 0-1 + Data Type: String + Description: The name of the Label Generation Ruleset (LGR) against which the server determines availability of the domain name. If the parameter is absent, the server uses its default LGR for the top-level domain, as indicated by the Discovery IDN LGR Object. + Constraints: + The value MUST be a valid LGR name registered in the IANA IDN Tables registry [IDN-Tables]. + If the domain name contains a code point not available in the specified LGR, the server MUST return an error indicating the invalid code point. * Output: - Object: Domain Name Availability Object 11.3.2. Create Operation * Identifier: create The Create operation allows a client to provision a new Domain Name resource. The operation accepts as input all create-only and read- write data elements defined for the Domain Name Data Object. * Authorisation: - Generally each client is authorised to create new domain objects becoming a sponsoring client. This can be however constrained by the server policy in many ways, i.e. by applying rate limiting, billing-related constraints or compliance locks. * Input: Kowalik & Wullink Expires 6 May 2027 [Page 100] Internet-Draft RPP Data Objects November 2026 - Object: This Object - Object: Domain Create Process Object The Create operation implicitly initiates the Domain Create Process Object Section 11.4.1, which carries the creation-specific inputs that are consumed during creation and not persisted as part of the domain object's state. The server MUST validate the name using the procedure described in section 4.2 of [RFC5891]. If the validation of the IDN name failed because it contained a code point not available in the specified IDN table, the server MUST return an error indicating the invalid code point. If the name does not map to the provided Unicode Name (uName), the server MUST respond with an appropriate error indicating the mismatch. 11.3.3. Read Operation * Identifier: read The Read operation allows a client to retrieve the data elements of a Domain Name resource. The server's response MAY vary depending on client authorisation and server policy. * Authorisation: - Sponsoring client: o Full object - Other client: o Without Object Authorisation: + Limited object (non-confidential properties) or operation denied o With Object Authorisation: + Full object, however some properties only authorised to the sponsoring client MAY be redacted according to server policy * Input: - Reference: This Object - Parameters: o Hosts Filter + Identifier: hostsFilter + Cardinality: 0-1 + Data Type: String + Description: Controls which host information is returned with the object. Kowalik & Wullink Expires 6 May 2027 [Page 101] Internet-Draft RPP Data Objects November 2026 + Constraints: The value MUST be one of "all", "del" (delegated), "sub" (subordinate), or "none". The default value is "all". 11.3.4. Update Operation * Identifier: update The Update operation allows a client to modify the read-write data elements of an existing Domain Name resource. * Authorisation: - Only sponsoring client is authorised to perform this operation At least one change to a read-write data element MUST be provided, unless the operation is extended. The registrant and the Authorisation Information MAY be removed. Contacts, nameservers, and the registrant to be added MUST be known to the server. 11.3.5. Delete Operation * Identifier: delete The Delete operation allows a client to remove an existing Domain Name resource. The operation targets a specific data object identified by its name. * Authorisation: - Only sponsoring client is authorised to perform this operation The server SHOULD reject a delete request if subordinate host objects are associated with the domain name. The error response SHOULD indicate the related subordinate host objects. 11.4. Processes The Domain Name Data Object supports the following Process Objects Section 10 unmodified: * Renew Process * Restore Process - Constraints: OPTIONAL; available only when the RGP feature is supported. Kowalik & Wullink Expires 6 May 2027 [Page 102] Internet-Draft RPP Data Objects November 2026 The Domain Name Data Object supports the following Process Objects extended by an object-specific definition: * Domain Create Process Section 11.4.1 * Domain Transfer Process Section 11.4.2 11.4.1. Domain Create Process Object * Name: Domain Create Process Object * Identifier: domainCreateProcess * Extends: Create Process Object * Unique Identifier: processId * Description: The domain-specific Create Process Object Section 10.4. It is implicitly initiated by the Domain Name Data Object create operation and carries the domain creation-specific inputs, namely the requested initial registration period, that are consumed during creation and not persisted as part of the domain object's state. * Data Elements: - Period o Identifier: period o Cardinality: 0-1 o Mutability: create-only o Data Type: Period Object o Description: The initial registration period for the domain name. This value is used by the server to calculate the initial expiryDate of the object. o Constraints: The default value MAY be defined by server policy. The number of units available MAY be subject to limits imposed by the server. 11.4.1.1. Operations 11.4.1.1.1. Create * Identifier: create The Create operation is invoked implicitly as a side effect of the Domain Name Data Object create operation and is never invoked directly. It carries the registration period consumed during domain creation. * Input: - Object: Domain Create Process Object * Output: - Object: Domain Create Process Object Kowalik & Wullink Expires 6 May 2027 [Page 103] Internet-Draft RPP Data Objects November 2026 * Authorisation: - Inherited from the Domain Name Data Object create operation that initiates this process. 11.4.1.1.2. Read * Identifier: read The Read operation retrieves the result or status of the domain creation, if the server exposes the process resource. * Input: - Reference: This Object * Output: - Object: Domain Create Process Object * Authorisation: - Only the sponsoring client is authorised to perform this operation. 11.4.2. Domain Transfer Process Object * Name: Domain Transfer Process Object * Identifier: domainTransferProcess * Extends: Transfer Process Object * Unique Identifier: processId * Description: The domain-specific Transfer Process Object Section 2.7.7. It carries the domain-specific transfer inputs and outputs (the requested transfer period and the resulting expiry date) that extend the common transfer process. * Data Elements: - Expiry Date o Identifier: expiryDate o Cardinality: 0-1 o Mutability: read-only o Data Type: Timestamp o Description: The end of the domain object's registration period if the transfer caused or causes a change in the validity period. o Constraints: (None) - Transfer Period o Identifier: transferPeriod o Cardinality: 0-1 Kowalik & Wullink Expires 6 May 2027 [Page 104] Internet-Draft RPP Data Objects November 2026 o Mutability: create-only o Data Type: Period Object o Description: The number of units to be added to the registration period of the domain object upon successful completion of the transfer. The number of units available MAY be subject to limits imposed by the server. o Constraints: + In EPP Compatibility Profile, Transfer Period cannot be read from the Transfer Process Object Transfer of a Domain Name Data Object MUST implicitly transfer all Host Data Objects that are subordinate to the domain object. For example, if domain object "example.com" is transferred and host object "ns1.example.com" exists, the host object MUST be transferred as part of the "example.com" transfer process. Actions that do not preserve the relationship between a domain object and its subordinate host objects MUST be disallowed. 11.4.2.1. Operations 11.4.2.1.1. Create * Identifier: transferCreate The Create operation initiates a transfer of the Domain Name Data Object by creating a Domain Transfer Process Object, extending the common Transfer Create Operation Section 10.1.1.1. * Input: - Reference: Owner Data Object - Object: Domain Transfer Process Object * Output: - Object: Domain Transfer Process Object * Authorisation: as defined in Section 10.1.1.1. 12. Contact Data Object 12.1. Object Description * Name: Contact Data Object * Identifier: contact * Unique Identifier: id Kowalik & Wullink Expires 6 May 2027 [Page 105] Internet-Draft RPP Data Objects November 2026 * Description: A Contact Data Object represents the contact information for an individual or organisation associated with other objects. 12.2. Data Elements The following data elements are defined for the Contact Data Object. * Handle ID - Identifier: id - Cardinality: 1 - Mutability: create-only - Data Type: Identifier - Description: External unique identifier of the contact object. - Constraints: o This value MUST be supported to be provided by the client. o Servers MAY support server-side generation of this value. * Provisioning Metadata - Identifier: provMetadata - Cardinality: 1 - Mutability: read-only - Data Type: Provisioning Metadata Object - Description: Standard metadata about the object's lifecycle and ownership. - Constraints: (None) * Status - Identifier: status - Cardinality: 1+ - Mutability: read-write - Data Type: Contact Status Object - Description: Status descriptors associated with the contact. - Constraints: o Possible combinations of Contact Status Labels are specified in Contact Status Values (#contact-status-values). * Contact Information - Identifier: contactInfo - Cardinality: 1 - Mutability: read-write - Data Type: External:RPP-JSContact-Profile:Card - Description: Contains contact information. - Constraints: Kowalik & Wullink Expires 6 May 2027 [Page 106] Internet-Draft RPP Data Objects November 2026 o In EPP Compatibility Profile, at most one internationalised and one localised form of the contact information are provided. The internationalised form MUST be represented in a subset of UTF-8 that can be represented in the 7-bit US- ASCII character set, while the localised form MAY be represented in unrestricted UTF-8. o In EPP Compatibility Profile, a postal address consists of up to three street lines, a city, an OPTIONAL state or province, an OPTIONAL postal code, and a country code that is a two-character identifier as specified in ISO 3166-1. o In EPP Compatibility Profile, telephone numbers MUST begin with a plus sign ("+"), followed by a country code defined in ITU-T E.164, followed by a dot ("."), followed by a sequence of digits, and MAY note an extension. Email addresses MUST conform to the syntax defined in [RFC5322]. * Authorisation Information - Identifier: authInfo - Cardinality: 0-1 - Mutability: read-write - Data Type: Authorisation Information Object - Visibility: onDemand - Description: Authorisation information associated with the contact object. - Constraints: (None) * Disclose - Identifier: disclose - Cardinality: 0-1 - Mutability: read-write - Data Type: Disclose Object - Description: Identifies elements that require exceptional server-operator handling to allow or restrict disclosure to third parties. - Constraints: o A server MUST reject any transaction that requests disclosure practices that do not conform to the server's announced data-collection policy. * Processes - Identifier: processes - Cardinality: 0-1 - Mutability: read-only - Data Type: Processes Object - Direct Access: true Kowalik & Wullink Expires 6 May 2027 [Page 107] Internet-Draft RPP Data Objects November 2026 - Description: The Process Objects currently or recently initiated on the contact object. - Constraints: (None) | TBC: IANA registry for statuses? 12.3. Operations 12.3.1. Availability Operation * Identifier: availability The Availability operation allows a client to determine whether a Contact resource with the given Handle ID can be created. The operation has no input data elements and takes no object representation as input. The client identifies the resource by its Reference only, i.e. only the Unique Identifier (Handle ID) is taken into consideration. * Authorisation: - Any authenticated client is authorised to perform this operation. * Output: - Object: Contact Availability Object 12.3.2. Create Operation * Identifier: create The Create operation allows a client to provision a new Contact resource. The operation accepts as input all create-only and read- write data elements defined for the Contact Data Object. * Authorisation: - Generally each client is authorised to create new contact objects becoming a sponsoring client. This can be however constrained by the server policy, e.g. by applying rate limiting or compliance locks. In EPP Compatibility Profile, the following data elements MUST be provided: * Handle ID (id) Kowalik & Wullink Expires 6 May 2027 [Page 108] Internet-Draft RPP Data Objects November 2026 * At least one Contact Information entry (contactInfo) containing a Name (name) and an Address (addr) with City (city) and Country Code (cc) * Email (email) * Authorisation Information (authInfo) 12.3.3. Read Operation * Identifier: read The Read operation allows a client to retrieve the data elements of a Contact resource. The server's response MAY vary depending on client authorisation and server policy. * Authorisation: - Sponsoring client: o Full object - Other client: o Without Object Authorisation: + Limited object (non-confidential properties) or operation denied o With Object Authorisation: + Full object, however some properties only authorised to the sponsoring client MAY be redacted according to server policy Authorisation Information (authInfo) MUST NOT be provided in the response if the querying client is not the current sponsoring client. When constructing the response, the server MUST respect the disclosure policies defined by the Disclose Object (disclose), whether set by the server operator's default data-collection policy or by the sponsoring client for the contact. Data elements marked for non-disclosure MUST NOT be included in responses to unauthorised clients. 12.3.4. Update Operation * Identifier: update The Update operation allows a client to modify the attributes of an existing Contact resource. * Authorisation: - Only sponsoring client is authorised to perform this operation The following aspects of the contact object MAY be modified: Kowalik & Wullink Expires 6 May 2027 [Page 109] Internet-Draft RPP Data Objects November 2026 * Status values that are client-manageable (prefixed with "client") MAY be added or removed. * Contact Information, Voice Phone Number, Fax Phone Number, Email, Authorisation Information, and Disclose preferences MAY be changed. At least one change MUST be provided, unless the operation is extended. 12.3.5. Delete Operation * Identifier: delete The Delete operation allows a client to remove an existing Contact resource. The operation targets a specific data object identified by its Handle ID. * Authorisation: - Only sponsoring client is authorised to perform this operation The server SHOULD reject a delete request if the contact object is associated with other known objects (e.g., domain names). An associated contact SHOULD NOT be deleted until associations with other known objects have been broken. The error response SHOULD indicate the existing object associations. 12.4. Processes The Contact Data Object supports the following Process Objects Section 10 unmodified: * Transfer Process The Contact Data Object supports no Process Objects extended by an object-specific definition. 13. Host Data Object 13.1. Object Description * Name: Host Data Object * Identifier: host * Unique Identifier: hostName * Description: A Host Data Object represents a nameserver that provides DNS services for a domain name. Kowalik & Wullink Expires 6 May 2027 [Page 110] Internet-Draft RPP Data Objects November 2026 13.2. Data Elements The following data elements are defined for the Host Data Object. * Host Name - Identifier: hostName - Cardinality: 1 - Mutability: read-write - Data Type: Fully Qualified Domain Name - Description: Fully qualified name of a host. - Constraints: o An Internal host MUST be treated as a subordinate host when it is used as a nameserver for a domain other than its superordinate domain. o Actions that do not preserve the relationship between a host object and its superordinate domain object MUST be disallowed. * Provisioning Metadata - Identifier: provMetadata - Cardinality: 1 - Mutability: read-only - Data Type: Provisioning Metadata Object - Description: Standard metadata about the object's lifecycle and ownership. - Constraints: (None) * Status - Identifier: status - Cardinality: 1+ - Mutability: read-write - Data Type: Host Status Object - Description: The current status descriptors associated with the host. - Constraints: Possible combinations of Host Status Labels are specified in Host Status Values (#host-status-values) * DNS Data - Identifier: dns - Cardinality: 0-1 - Mutability: read-write - Data Type: DNS Data Object Kowalik & Wullink Expires 6 May 2027 [Page 111] Internet-Draft RPP Data Objects November 2026 - Description: DNS resource records and operational controls related to the host. This structure follows the unified DNS data model defined in [I-D.simmen-rpp-dns-data]. - Constraints: o The names of DNS entries MUST be the host name itself or subordinate to the host name. o In EPP Compatibility Profile the record entries MUST be limited to A and AAAA entries for IPv4 and IPv6 glue records respectively. o In EPP Compatibility Profile, IPv4 addresses MUST conform to [RFC0791] and IPv6 addresses MUST conform to [RFC4291]. A server MAY reject IP addresses that have not been allocated for public use by IANA. * Processes - Identifier: processes - Cardinality: 0-1 - Mutability: read-only - Data Type: Processes Object - Direct Access: true - Description: The Process Objects currently or recently initiated on the host object. - Constraints: (None) 13.3. Operations 13.3.1. Availability Operation * Identifier: availability The Availability operation allows a client to determine whether a Host Data Object with the given host name can be created. The operation has no input data elements and takes no object representation as input. The client identifies the resource by its Reference only, i.e. only the Unique Identifier (Host Name) is taken into consideration. * Authorisation: - Any authenticated client is authorised to perform this operation. * Output: - Object: Host Availability Object Kowalik & Wullink Expires 6 May 2027 [Page 112] Internet-Draft RPP Data Objects November 2026 13.3.2. Create Operation * Identifier: create The Create operation allows a client to provision a new Host Data Object. The operation accepts as input all create-only and read- write data elements defined for the Host Data Object. * Authorisation: - Generally each client is authorised to create new host objects becoming a sponsoring client. This can be however constrained by the server policy, e.g. by applying rate limiting or compliance locks. If the host name exists in a namespace for which the server is authoritative, then the superordinate domain of the host MUST be known to the server before the host object can be created. In EPP Compatibility Profile, IP addresses are REQUIRED only as needed to produce DNS glue records. If the host name exists in a namespace for which the server is authoritative and is subordinate to an existing domain, IP addresses SHOULD be provided. If the host name is external to the server's namespace, IP addresses are not required by the DNS and MAY be omitted. 13.3.3. Read Operation * Identifier: read The Read operation allows a client to retrieve the data elements of a Host Data Object. * Authorisation: - Any client is authorised to retrieve the full object. In EPP Compatibility Profile, host objects do not carry authorisation information and there is no distinction based on client identity as described in Section 3.1.2 of [RFC5732]. 13.3.4. Update Operation * Identifier: update The Update operation allows a client to modify the attributes of an existing Host Data Object. The operation targets a specific data object identified by its host name. * Authorisation: - Only sponsoring client is authorised to perform this operation Kowalik & Wullink Expires 6 May 2027 [Page 113] Internet-Draft RPP Data Objects November 2026 Host name changes MAY require the addition or removal of IP addresses to be accepted by the server. IP address association MAY be subject to server policies for provisioning hosts as nameservers. The IP address restrictions described for the Create operation apply to updates as well. At least one change to a data element MUST be provided, unless the operation is extended. Host name changes can have an impact on associated objects that refer to the host object. A Host Name change SHOULD NOT require additional updates of associated objects to preserve existing associations, with one exception: changing an External host object that has associations with objects that are sponsored by a different client. Attempts to update such hosts directly MUST fail. The change can be provisioned by creating a new External host with a new name and any needed new attributes, and subsequently updating the other objects sponsored by the client. 13.3.5. Delete Operation * Identifier: delete The Delete operation allows a client to remove an existing Host Data Object. The operation targets a specific data object identified by its host name. * Authorisation: - Only sponsoring client is authorised to perform this operation The server SHOULD reject a delete request if the host object is associated with any other object, such as a domain name object. Deleting a host object without first breaking existing associations can cause DNS resolution failure for domain objects that refer to the deleted host object. | TODO: consider RFC 9874 / BCP 244 for host deletions practices The error response SHOULD indicate the related associated objects. 13.4. Processes The Host Data Object supports the following Process Objects Section 10 unmodified: * Transfer Process Kowalik & Wullink Expires 6 May 2027 [Page 114] Internet-Draft RPP Data Objects November 2026 - Constraints: Host objects MUST NOT be transferred directly. They are transferred implicitly when their superordinate domain object is transferred. The Host Data Object supports no Process Objects Section 10 extended by an object-specific definition. 14. Organisation Data Object 14.1. Object Description * Name: Organisation Data Object * Identifier: organisation * Unique Identifier: id * Description: An Organisation Data Object represents an entity, such as a registrar or reseller that is involved in the domain registration process. This object is based on the EPP Organisation Mapping defined in [RFC8543]. 14.2. Data Elements The following data elements are defined for the Organisation Data Object. * Organisation ID - Identifier: id - Cardinality: 1 - Mutability: create-only - Data Type: Identifier - Description: A server-unique identifier for the organisation object. - Constraints: o This value MUST be supported to be provided by the client. o Servers MAY support server-side generation of this value. * Provisioning Metadata - Identifier: provMetadata - Cardinality: 1 - Mutability: read-only - Data Type: Provisioning Metadata Object - Description: Standard metadata about the object's lifecycle and ownership. - Constraints: (None) * Status Kowalik & Wullink Expires 6 May 2027 [Page 115] Internet-Draft RPP Data Objects November 2026 - Identifier: status - Cardinality: 1+ - Mutability: read-write - Data Type: Organisation Status Object - Description: The current operational status descriptors associated with the organisation. An organisation object MUST always have at least one associated status value. - Constraints: o Possible combinations of Organisation Status Labels are specified in Organisation Status Values (#organisation- status-values). o A client MUST NOT alter server status values set by the server itself. * Roles - Identifier: roles - Cardinality: 1+ - Mutability: read-write - Data Type: DictionaryComposition[Organisation Role Object] o Label Description: type of role o Label Constraints: The value MUST be one of the role types registered in the IANA "EPP Organisation Role Values" registry as defined in Section 7.3 of [RFC8543]. Initial values include registrar, reseller, privacyproxy, and dns- operator. - Description: One or more roles describing the relationship the organisation has within the registry ecosystem. An organisation object MUST always have at least one associated role. - Constraints: o An organisation MAY have multiple roles with different role types. o Role types are registered in the IANA "EPP Organisation Role Values" registry as defined in Section 7.3 of [RFC8543]. Initial values include registrar, reseller, privacyproxy, and dns-operator. * Parent Organisation - Identifier: parent - Cardinality: 0-1 - Mutability: read-write - Data Type: Aggregation[Organisation Data Object] - Description: The parent organisation in a hierarchical organisation structure (e.g., a reseller's parent registrar). - Constraints: Kowalik & Wullink Expires 6 May 2027 [Page 116] Internet-Draft RPP Data Objects November 2026 o Loops MUST be prohibited. If organisation A has organisation B as its parent, organisation B MUST NOT have organisation A as its parent, directly or transitively. * Contact Information - Identifier: contactInfo - Cardinality: 0-1 - Mutability: read-write - Data Type: External:RPP-JSContact-Profile:Card - Description: Contact information for the organisation. * Contacts - Identifier: contacts - Cardinality: 0+ - Mutability: read-write - Data Type: LabelledAggregation[Contact Data Object] o Label Description: type of contact o Label Constraints: The value MUST be one of the contact types registered in the IANA "EPP Organisation Contact Types" registry as defined in Section 7.4 of [RFC8543]. Initial values include admin, tech, billing, abuse, and custom. - Description: Identifiers of contact objects associated with the organisation. - Constraints: o Contact object identifiers MUST be known to the server before the contact can be associated. | TODO: how handle the "custom" contact type? * Users - Identifier: users - Cardinality: 0+ - Mutability: read-write - Data Type: LabelledAggregation[User Data Object] o Label Description: RBAC role of the user o Label Constraints: The value MUST be one of the role types registered in the IANA "RPP User Role Values" registry. - Direct Access: true - Description: One or more RBAC roles assigned to the user. - Constraints: o Each role value MUST be a non-empty string. o Allowed role values MAY be constrained by server policy. * Processes Kowalik & Wullink Expires 6 May 2027 [Page 117] Internet-Draft RPP Data Objects November 2026 - Identifier: processes - Cardinality: 0-1 - Mutability: read-only - Data Type: Processes Object - Direct Access: true - Description: The Process Objects currently or recently initiated on the organisation object. - Constraints: (None) | TODO: define an IANA registry for user roles? 14.3. Operations 14.3.1. Create Operation * Identifier: create The Create operation allows a client to provision a new Organisation Data Object. The operation accepts as input all create-only and read-write data elements defined for the Organisation Data Object. * Authorisation: - Generally only registry clients are authorised to create new organisation objects. An organisation object MUST include at least one role on creation. The server MAY defer completing the action and return a pendingCreate status if human or third-party review is required. 14.3.2. Read Operation * Identifier: read The Read operation allows a client to retrieve the data elements of an Organisation Data Object. * Authorisation: - Any client is authorised to retrieve organisation object information. The server MAY restrict the information returned based on client identity and server policy. 14.3.3. Update Operation * Identifier: update The Update operation allows a client to modify the attributes of an existing Organisation Data Object. Kowalik & Wullink Expires 6 May 2027 [Page 118] Internet-Draft RPP Data Objects November 2026 * Authorisation: - Generally only registry clients are authorised to update organisation objects. The following aspects of the organisation object MAY be modified: * Contacts MAY be added or removed. * Roles MAY be added or removed. * Status values that are client-manageable (prefixed with "client") MAY be added or removed. * Parent Organisation ID and Contact Information MAY be changed. * Users MAY be added or removed. A client MUST NOT add, delete, or alter values for statuses managed by the server (prefixed with "server"). A server MAY add, delete, or alter status values set by a client, subject to server policy. 14.3.4. Delete Operation * Identifier: delete The Delete operation allows a client to remove an existing Organisation Data Object. The operation targets a specific data object identified by its Organisation ID. * Authorisation: - Generally only registry clients are authorised to delete organisation objects. An organisation object MUST NOT be deleted if it is associated with other known objects (e.g., domain names, contacts, or child organisations). The server MUST reject such a delete request and notify the client that object relationships exist. The error response SHOULD indicate the related associated objects. 15. Message Data Object 15.1. Object Description * Name: Message Data Object * Identifier: message * Unique Identifier: id * Description: A Message Data Object represents a message which is inserted in the message queue of an organisation and retrieved by clients associated with that organisation. Kowalik & Wullink Expires 6 May 2027 [Page 119] Internet-Draft RPP Data Objects November 2026 15.2. Data Elements The following data elements are defined for the Message Data Object. * Message ID - Identifier: id - Cardinality: 1 - Mutability: read-only - Data Type: Identifier - Description: A server-unique identifier for the message object. - Constraints: (None) * Creation Date - Identifier: creationDate - Cardinality: 1 - Mutability: read-only - Data Type: Timestamp - Description: The date and time when the message object was created and inserted into the queue. - Constraints: The value is set by the server. * Status - Identifier: status - Cardinality: 1 - Mutability: read-only - Data Type: String - Description: The current lifecycle status of the message object. - Constraints: o Possible values: queued, delivered and removed * Data - Identifier: data - Cardinality: 1 - Mutability: create-only - Data Type: Base Message Object - Description: The data related to a specific message type, such as a transfer request or a review response. - Constraints: (None) 15.3. Operations 15.3.1. Create Operation Kowalik & Wullink Expires 6 May 2027 [Page 120] Internet-Draft RPP Data Objects November 2026 * Identifier: create The Create operation allows a server to insert a new message into the queue for a registrar. The operation accepts as input all create- only and read-write data elements defined for the Message Data Object. * Authorisation: - Only the server is authorised to create new message objects. 15.3.2. Read Operation * Identifier: read The Read operation allows a client to retrieve the data elements of a Message Data Object. * Authorisation: - Any client is authorised to retrieve message object information. The server MAY restrict the information returned based on client identity and server policy. Organisation ID (owner) MUST NOT be provided in the response, since a client can only ever retrieve messages linked to its own organisation. 15.3.3. Query Operation * Identifier: query The Query operation allows a client to retrieve a collection of Message Data Object instances based on specified criteria. * Authorisation: - Any client is authorised to retrieve message object information. The server MAY restrict the information returned based on client identity and server policy. * Input: - Parameters: o Message Type + Identifier: type + Cardinality: 0-1 + Data Type: String + Description: The type of the message to use as a filter when retrieving message objects. Kowalik & Wullink Expires 6 May 2027 [Page 121] Internet-Draft RPP Data Objects November 2026 + Constraints: + The type value MUST be a valid identifier for an RPP message component (e.g. reviewResponse). 15.3.4. Delete Operation * Identifier: delete The Delete operation allows a client to remove an existing Message Data Object. The operation targets a specific data object identified by its Message ID. * Authorisation: - Generally clients are authorised to delete message objects linked to the organisation the client belongs to. 16. User Object 16.1. Object Description * Name: User Data Object * Identifier: user * Unique Identifier: id * Description: Represents a user linked to an Organisation Object. Each user carries a set of RBAC roles that define the user's permissions within the context of the owning Organisation Object. The lifecycle of a User Object is bound to its Organisation Object. 16.2. Data Elements The following data elements are defined for the User Data Object. * User Identifier - Identifier: id - Cardinality: 1 - Mutability: create-only - Data Type: Identifier - Description: A unique identifier for the user - Constraints: MUST be globally unique in the server scope * Details - Identifier: details - Cardinality: 1 - Mutability: read-write - Data Type: External:RPP-JSContact-Profile:Card - Description: The details of the user, such as name, email, and phone number - Constraints: (None) Kowalik & Wullink Expires 6 May 2027 [Page 122] Internet-Draft RPP Data Objects November 2026 * Description - Identifier: description - Cardinality: 0-1 - Mutability: read-write - Data Type: String - Description: A description of the user - Constraints: (None) * Status - Identifier: status - Cardinality: 1 - Mutability: read-write - Data Type: User Status Object - Description: The current status of the user. - Constraints: o Allowed status values and transitions are specified in User Status Values (#user-status-values). o A client MUST NOT alter server status values set by the server itself. * Organisation - Identifier: organisation - Cardinality: 1 - Mutability: read-only - Data Type: Aggregation[Organisation Data Object] - Description: A reference to the owner organisation object. - Constraints: (None) * Processes - Identifier: processes - Cardinality: 0-1 - Mutability: read-only - Data Type: Processes Object - Direct Access: true - Description: The Process Objects currently or recently initiated on the user object. - Constraints: (None) | TODO: what other data elements should be included for the User | Data Object? 16.3. Operations 16.3.1. Create Operation * Identifier: create The Create operation creates a new user, which is associated with an existing Organisation Object. The operation accepts as input all create-only and read-write data elements of the User Object. Kowalik & Wullink Expires 6 May 2027 [Page 123] Internet-Draft RPP Data Objects November 2026 * Authorisation: - Client can only create users in the context of the organisation linked to the client, and only if the client has the necessary permissions to create users in that organisation. 16.3.2. Read Operation * Identifier: read The Read operation retrieves the data of a specific User Object. * Authorisation: - Client can only read users in the context of the organisation linked to the client, and only if the client has the necessary permissions to read users in that organisation. 16.3.3. Update Operation * Identifier: update The Update operation modifies the read-write data elements. * Authorisation: - Client can only update users in the context of the organisation linked to the client, and only if the client has the necessary permissions to update users in that organisation. 16.3.4. Delete Operation * Identifier: delete The Delete operation removes a specific User Object. * Authorisation: - Client can only delete users in the context of the organisation linked to the client, and only if the client has the necessary permissions to delete users in that organisation. The server MUST reject this operation if the target User Object is the last user of the owning organisation that is permitted to manage users. User Objects are deleted together with their owning Organisation Object. Kowalik & Wullink Expires 6 May 2027 [Page 124] Internet-Draft RPP Data Objects November 2026 17. Discovery Data Object 17.1. Object Description * Name: Discovery Data Object * Identifier: discovery * Unique Identifier: (None) * Description: A Discovery Data Object describes the capabilities of an RPP server, such as the supported versions, TLDs, extensions, profiles, resource collections, authentication methods and endpoints. The server provides a single Discovery Data Object, which is therefore not identified by a Unique Identifier. 17.2. Data Elements The following data elements are defined for the Discovery Data Object. * Versions - Identifier: versions - Cardinality: 1+ - Mutability: read-only - Data Type: Discovery Version Object - Description: The versions of RPP supported by the server. - Constraints: An operator that supports more than one incompatible version MUST deploy them on distinct base URLs and announce each of them. * Environment - Identifier: environment - Cardinality: 1 - Mutability: read-only - Data Type: Discovery Environment Object - Description: Information about the RPP server. - Constraints: (None) * TLDs - Identifier: tlds - Cardinality: 1+ - Mutability: read-only - Data Type: String - Description: The TLDs supported by the server, for example "example" or "org". - Constraints: (None) Kowalik & Wullink Expires 6 May 2027 [Page 125] Internet-Draft RPP Data Objects November 2026 * Extensions - Identifier: extensions - Cardinality: 0+ - Mutability: read-only - Data Type: Extension Object - Description: The extensions supported by the server. - Constraints: The server MUST include the version of each extension. * Profiles - Identifier: profiles - Cardinality: 0+ - Mutability: read-only - Data Type: String - Description: The names of the profiles supported by the server. * Objects - Identifier: objects - Cardinality: 1+ - Mutability: read-only - Data Type: String - Description: The list of identifiers of data objects supported by the server - Constraints: (None) * Date and Time - Identifier: datetime - Cardinality: 1 - Mutability: read-only - Data Type: Timestamp - Description: The current date and time of the server. - Constraints: The value MUST be expressed in UTC using the Z suffix, for example 2026-06-01T10:00:00Z, and MUST NOT use a numeric UTC offset or any other time zone. * Links - Identifier: links - Cardinality: 0+ - Mutability: read-only - Data Type: LabelledAggregation[String] o Label Description: The relation type of the link. o Label Constraints: The value MUST be a link relation type registered in the IANA "Link Relation" registry. Kowalik & Wullink Expires 6 May 2027 [Page 126] Internet-Draft RPP Data Objects November 2026 - Description: Links to documents related to the use of RPP with the server, such as policies and terms. Each value is the location of a linked document, labelled with its relation type. - Constraints: o Each value MUST be an absolute URL using the HTTPS scheme. o The document MUST be accessible to the client without authentication. o A server SHOULD provide a link for each of the privacy- policy and terms-of-service relation types, defined in [RFC6903]. * IDN LGRs - Identifier: idnLgr - Cardinality: 0+ - Mutability: read-only - Data Type: Discovery IDN LGR Object - Description: The Label Generation Rulesets (LGRs) supported by the server. - Constraints: (None) * Notices - Identifier: notices - Cardinality: 0+ - Mutability: read-only - Data Type: Discovery Notice Object - Description: Notices from the server operator. - Constraints: (None) - Description: The objects allowed for provisioning operations, for example "domainName", "host" or "contact". - Constraints: The values MUST be valid object identifiers as defined in the RPP Data Object Registry. 17.3. Operations 17.3.1. Read Operation * Identifier: read The Read operation allows a client to retrieve the Discovery Data Object. It is the only operation supported for this object. * Input: (None) * Authorisation: Kowalik & Wullink Expires 6 May 2027 [Page 127] Internet-Draft RPP Data Objects November 2026 - Any client is authorised to perform this operation. The operation MUST be available without authentication, so that a client can retrieve it before authenticating with the server. 18. Profile Data Object 18.1. Object Description * Name: Profile Data Object * Identifier: profile * Unique Identifier: name * Description: A Profile Data Object represents a named set of protocol features and versions that defines the compatibility and capabilities of RPP server implementations. A profile is published by the server, and a client can retrieve it to determine which features, objects and extensions it can use. 18.2. Data Elements The following data elements are defined for the Profile Data Object. All data elements are managed by the server. * Name - Identifier: name - Cardinality: 1 - Mutability: read-only - Data Type: String - Description: A unique name that identifies the profile. - Constraints: o The name of a standard profile, which is published in the IANA registry for RPP profiles, MUST use the RPP URN namespace, for example urn:ietf:params:rpp:profile:{profile_name}, and MUST be unique within that namespace. It SHOULD be descriptive of the features and versions included in the profile. o The name of a private profile, which is not published in the IANA registry, MUST be globally unique. The use of reverse domain name notation is RECOMMENDED. * Description - Identifier: description - Cardinality: 1 - Mutability: read-only - Data Type: String - Description: A human-readable description of the profile and its intended use. Kowalik & Wullink Expires 6 May 2027 [Page 128] Internet-Draft RPP Data Objects November 2026 - Constraints: (None) * Version - Identifier: version - Cardinality: 1 - Mutability: read-only - Data Type: String - Description: The version of the profile. - Constraints: (None) * RPP Version - Identifier: rppVersion - Cardinality: 1 - Mutability: read-only - Data Type: String - Description: The minimum version of the RPP protocol that is supported or required for the profile. - Constraints: (None) * Objects - Identifier: objects - Cardinality: 1+ - Mutability: read-only - Data Type: String - Description: The list of identifiers of data objects supported by the server - Constraints: (None) * Extensions - Identifier: extensions - Cardinality: 0+ - Mutability: read-only - Data Type: Extension Object - Description: The extensions, including their names and versions, that are supported or required for the profile. - Constraints: o A profile MUST NOT list the same extension name more than once. o The server MUST support all extensions listed in the profile. * Base Profile - Identifier: baseProfile Kowalik & Wullink Expires 6 May 2027 [Page 129] Internet-Draft RPP Data Objects November 2026 - Cardinality: 0-1 - Mutability: read-only - Data Type: Aggregation[Profile Data Object] - Description: A base profile that is extended by this profile. The features and versions of the base profile are included in this profile, which MAY add to them or override them, for example the version of an extension. - Constraints: o The base profile MUST be published in the IANA registry for RPP profiles, or be made available to the client using other means. o The depth of inheritance MUST be limited to 1: the base profile MUST NOT itself have a base profile. o A profile MUST NOT be its own base profile. * Default Profile - Identifier: defaultProfile - Cardinality: 1 - Mutability: read-only - Data Type: Boolean - Description: The default profile that is used when no specific profile is requested by the client. - Constraints: o The default profile MUST be published in the IANA registry for RPP profiles, or be made available to the client using other means. o Only one profile MUST be designated as the default profile. 18.3. Operations 18.3.1. Read Operation * Identifier: read The Read operation allows a client to retrieve the Profile Data Object identified by its name. It is the only operation supported for this object. * Authorisation: - Any authenticated client is authorised to perform this operation. 19. IANA Considerations Kowalik & Wullink Expires 6 May 2027 [Page 130] Internet-Draft RPP Data Objects November 2026 19.1. RPP Registry Group The IANA is requested to create a new registry group for RPP, this will be used to group together all the RPP-related registries such as those for discovery URLs, extensions and profiles. Name of the registry: RESTful Provisioning Protocol (RPP) Reference: This Document IANA Registry Reference: TODO 19.2. RPP Data Object Registry Name of the registry: RPP Data Object Registry Registry group: RESTful Provisioning Protocol (RPP) Registration procedure: Specification Required This document establishes the "RESTful Provisioning Protocol (RPP) Data Object Registry". This registry serves as a catalogue of all data objects, component objects, data elements, and operations used within RPP. 19.2.1. Registration Policy The policy for adding new objects, data elements, or operations to this registry is "Specification Required" [RFC8126]. Standardised RPP extensions that introduce new data objects, add data elements to existing objects, or define new operations, operation input data elements, or operation parameters MUST register these additions in this registry. Each such registration MUST reference the specification that defines the extension. Private (non-standardised) extensions are not required to register in this registry. 19.2.2. Registry Structure The registry is organised as a collection of Object definitions. Each Object definition MUST include: * A header containing the Object Identifier, Object Name, Object Type (Resource, Process or Component), the identifier of the object it extends (if any), a brief description, and a reference to its defining specification. Kowalik & Wullink Expires 6 May 2027 [Page 131] Internet-Draft RPP Data Objects November 2026 * A "Data Elements" table listing all persisted data elements associated with the object. Each entry MUST specify the element's Identifier, Name, Cardinality, Mutability, Data Type, description, and a reference to the specification that defines it. * An "Operations" section (applicable only for Object Types Resource or Process). For each operation, the registry MUST provide: - The Operation's Name, a description, and a reference to the specification that defines it. - An "Input Data Elements" table listing all input data elements of the operation. Each entry MUST specify the input data element's Identifier, Name, Cardinality, Data Type, description, and a reference to the specification that defines it. - A "Parameters" table listing all parameters of the operation. Each entry MUST specify the parameter's Identifier, Name, Cardinality, Data Type, description, and a reference to the specification that defines it. Extensions MAY add new data elements, operations, operation input data elements, or operation parameters to existing Object definitions in the registry. Each such addition MUST reference the extension specification that introduces it, allowing implementations to distinguish core protocol elements from extension-defined elements. 19.2.3. Initial Registrations The initial contents of the RPP Data Object Registry are defined below. Object: period Object Name: Period Object Object Type: Component Description: Represents a duration of time. Reference: [This-ID] Data Elements Kowalik & Wullink Expires 6 May 2027 [Page 132] Internet-Draft RPP Data Objects November 2026 +============+=========+=====+============+=========+=============+ | Element | Element |Card.| Mutability | Data | Description | | Identifier | Name | | | Type | | +============+=========+=====+============+=========+=============+ | value | Value |1 | read-write | Integer | The numeric | | | | | | | value of | | | | | | | the period. | +------------+---------+-----+------------+---------+-------------+ | unit | Unit |1 | read-write | String | The unit of | | | | | | | the period. | +------------+---------+-----+------------+---------+-------------+ Table 14 Object: dnsRecord Object Name: DNS Resource Record Object Object Type: Component Description: Represents a single DNS resource record. Reference: [This-ID] Data Elements Kowalik & Wullink Expires 6 May 2027 [Page 133] Internet-Draft RPP Data Objects November 2026 +============+=========+=======+============+========+==============+ | Element | Element | Card. | Mutability | Data | Description | | Identifier | Name | | | Type | | +============+=========+=======+============+========+==============+ | name | Name | 1 | read-write | String | The owner | | | | | | | name of the | | | | | | | DNS entry. | +------------+---------+-------+------------+--------+--------------+ | class | Class | 0-1 | read-write | String | The DNS | | | | | | | resource | | | | | | | record | | | | | | | class. | +------------+---------+-------+------------+--------+--------------+ | type | Type | 1 | read-write | String | The DNS | | | | | | | resource | | | | | | | record | | | | | | | type, | | | | | | | indicating | | | | | | | the format | | | | | | | of the | | | | | | | RDATA | | | | | | | field. | +------------+---------+-------+------------+--------+--------------+ | rdata | RDATA | 1 | read-write | Object | The actual | | | | | | | payload | | | | | | | data of the | | | | | | | DNS record. | | | | | | | Structure | | | | | | | depends on | | | | | | | the record | | | | | | | type. | +------------+---------+-------+------------+--------+--------------+ Table 15 Object: dnsControls Object Name: DNS Operational Controls Object Object Type: Component Description: Contains operational control parameters that a client MAY use to influence server-side DNS behaviour for a set of DNS records. Reference: [This-ID] Data Elements Kowalik & Wullink Expires 6 May 2027 [Page 134] Internet-Draft RPP Data Objects November 2026 +================+=========+=====+==========+==========+============+ | Element |Element |Card.|Mutability|Data Type |Description | | Identifier |Name | | | | | +================+=========+=====+==========+==========+============+ | ttl |TTL |0-1 |read-write|Dictionary|Controls | | | | | |[Integer] |the caching | | | | | | |behaviour | | | | | | |of DNS | | | | | | |resource | | | | | | |records, | | | | | | |keyed by | | | | | | |lowercase | | | | | | |record type | | | | | | |name. | +----------------+---------+-----+----------+----------+------------+ | maxSigLifetime |Maximum |0-1 |read-write|Dictionary|Maximum | | |Signature| | |[Integer] |number of | | |Lifetime | | | |seconds | | | | | | |after | | | | | | |signature | | | | | | |generation | | | | | | |when the | | | | | | |parent's | | | | | | |signature | | | | | | |on signed | | | | | | |DNS data | | | | | | |should | | | | | | |expire, | | | | | | |keyed by | | | | | | |lower-case | | | | | | |record type | | | | | | |name. | +----------------+---------+-----+----------+----------+------------+ Table 16 Object: dnsData Object Name: DNS Data Object Object Type: Component Description: A container for DNS resource records and associated operational controls for a provisioned object. Reference: [This-ID] Data Elements Kowalik & Wullink Expires 6 May 2027 [Page 135] Internet-Draft RPP Data Objects November 2026 +==========+========+=====+============+=============+==============+ |Element |Element |Card.| Mutability | Data Type | Description | |Identifier|Name | | | | | +==========+========+=====+============+=============+==============+ |records |Records |0+ | read-write | DNS | An array of | | | | | | Resource | DNS | | | | | | Record | resource | | | | | | Object | records | | | | | | | associated | | | | | | | with the | | | | | | | provisioned | | | | | | | object. | +----------+--------+-----+------------+-------------+--------------+ |controls |Controls|0-1 | read-write | DNS | Operational | | | | | | Operational | control | | | | | | Controls | parameters | | | | | | Object | for the DNS | | | | | | | records. | +----------+--------+-----+------------+-------------+--------------+ Table 17 Object: authInfo Object Name: Authorisation Information Object Object Type: Component Description: Contains authorisation credentials for an operation. Reference: [This-ID] Data Elements Kowalik & Wullink Expires 6 May 2027 [Page 136] Internet-Draft RPP Data Objects November 2026 +==========+=============+=====+===========+======+=================+ |Element |Element Name |Card.|Mutability |Data | Description | |Identifier| | | |Type | | +==========+=============+=====+===========+======+=================+ |method |Method |1 |create-only|String| The | | | | | | | identifier of | | | | | | | the RPP | | | | | | | authorisation | | | | | | | method. | +----------+-------------+-----+-----------+------+-----------------+ |authdata |Authorisation|1 |create-only|String| The value of | | |Information | | | | the | | | | | | | authorisation | | | | | | | information. | | | | | | | It might be | | | | | | | as simple as | | | | | | | a password | | | | | | | string, but | | | | | | | also more | | | | | | | complex | | | | | | | values like | | | | | | | public key | | | | | | | certificates | | | | | | | or tokens | | | | | | | encoded as | | | | | | | string are | | | | | | | possible. | +----------+-------------+-----+-----------+------+-----------------+ Table 18 Object: domainStatus Object Name: Domain Name Status Object Object Type: Component Description: Represents one of the status values associated with a Domain Name Data Object Reference: [This-ID] Data Elements Kowalik & Wullink Expires 6 May 2027 [Page 137] Internet-Draft RPP Data Objects November 2026 +==========+=======+=====+===========+=========+===================+ |Element |Element|Card.|Mutability |Data Type| Description | |Identifier|Name | | | | | +==========+=======+=====+===========+=========+===================+ |label |Label |1 |create-only|String | machine-readable | | | | | | | enum label of a | | | | | | | status | +----------+-------+-----+-----------+---------+-------------------+ |reason |Reason |0-1 |create-only|String | a human-readable | | | | | | | text that | | | | | | | describes the | | | | | | | rationale for the | | | | | | | status applied to | | | | | | | the object. | +----------+-------+-----+-----------+---------+-------------------+ |due |Due |0-1 |read-write |Timestamp| a timestamp, when | | | | | | | this status is | | | | | | | going to be | | | | | | | removed | | | | | | | automatically, or | | | | | | | changed to other | | | | | | | status. This | | | | | | | field can be used | | | | | | | to express | | | | | | | lifecycle related | | | | | | | information. | +----------+-------+-----+-----------+---------+-------------------+ Table 19 Object: hostStatus Object Name: Host Status Object Object Type: Component Description: Represents one of the status values associated with a Host Data Object Reference: [This-ID] Data Elements Kowalik & Wullink Expires 6 May 2027 [Page 138] Internet-Draft RPP Data Objects November 2026 +============+=======+=====+=============+======+===================+ | Element |Element|Card.| Mutability |Data | Description | | Identifier |Name | | |Type | | +============+=======+=====+=============+======+===================+ | label |Label |1 | create-only |String| machine-readable | | | | | | | enum label of a | | | | | | | status | +------------+-------+-----+-------------+------+-------------------+ | reason |Reason |0-1 | create-only |String| a human-readable | | | | | | | text that | | | | | | | describes the | | | | | | | rationale for | | | | | | | the status | | | | | | | applied to the | | | | | | | object. | +------------+-------+-----+-------------+------+-------------------+ Table 20 Object: contactStatus Object Name: Contact Status Object Object Type: Component Description: Represents one of the status values associated with a Contact Data Object Reference: [This-ID] Data Elements Kowalik & Wullink Expires 6 May 2027 [Page 139] Internet-Draft RPP Data Objects November 2026 +============+=======+=====+=============+======+===================+ | Element |Element|Card.| Mutability |Data | Description | | Identifier |Name | | |Type | | +============+=======+=====+=============+======+===================+ | label |Label |1 | create-only |String| machine-readable | | | | | | | enum label of a | | | | | | | status | +------------+-------+-----+-------------+------+-------------------+ | reason |Reason |0-1 | create-only |String| a human-readable | | | | | | | text that | | | | | | | describes the | | | | | | | rationale for | | | | | | | the status | | | | | | | applied to the | | | | | | | object. | +------------+-------+-----+-------------+------+-------------------+ Table 21 Object: organisationRoleStatus Object Name: Organisation Role Status Object Object Type: Component Description: Represents one of the status values associated with an Organisation Role Object. A role SHOULD have at least one associated status value. Reference: [This-ID] Data Elements Kowalik & Wullink Expires 6 May 2027 [Page 140] Internet-Draft RPP Data Objects November 2026 +============+=======+=====+=============+======+===================+ | Element |Element|Card.| Mutability |Data | Description | | Identifier |Name | | |Type | | +============+=======+=====+=============+======+===================+ | label |Label |1 | create-only |String| machine-readable | | | | | | | enum label of a | | | | | | | status | +------------+-------+-----+-------------+------+-------------------+ | reason |Reason |0-1 | create-only |String| a human-readable | | | | | | | text that | | | | | | | describes the | | | | | | | rationale for | | | | | | | the status | | | | | | | applied to the | | | | | | | role. | +------------+-------+-----+-------------+------+-------------------+ Table 22 Object: organisationStatus Object Name: Organisation Status Object Object Type: Component Description: Represents one of the status values associated with an Organisation Data Object, as defined in Section 3.4 of [RFC8543]. An Organisation Data Object MUST always have at least one associated status value. Reference: [This-ID] Data Elements Kowalik & Wullink Expires 6 May 2027 [Page 141] Internet-Draft RPP Data Objects November 2026 +============+=======+=====+=============+======+===================+ | Element |Element|Card.| Mutability |Data | Description | | Identifier |Name | | |Type | | +============+=======+=====+=============+======+===================+ | label |Label |1 | create-only |String| machine-readable | | | | | | | enum label of a | | | | | | | status | +------------+-------+-----+-------------+------+-------------------+ | reason |Reason |0-1 | create-only |String| a human-readable | | | | | | | text that | | | | | | | describes the | | | | | | | rationale for | | | | | | | the status | | | | | | | applied to the | | | | | | | object. | +------------+-------+-----+-------------+------+-------------------+ Table 23 Object: userStatus Object Name: User Status Object Object Type: Component Description: Represents the status value associated with a User Data Object. A User Data Object MUST always have exactly one associated status value. Reference: [This-ID] Data Elements Kowalik & Wullink Expires 6 May 2027 [Page 142] Internet-Draft RPP Data Objects November 2026 +============+=======+=====+=============+======+===================+ | Element |Element|Card.| Mutability |Data | Description | | Identifier |Name | | |Type | | +============+=======+=====+=============+======+===================+ | label |Label |1 | create-only |String| machine-readable | | | | | | | enum label of a | | | | | | | status | +------------+-------+-----+-------------+------+-------------------+ | reason |Reason |0-1 | create-only |String| a human-readable | | | | | | | text that | | | | | | | describes the | | | | | | | rationale for | | | | | | | the status | | | | | | | applied to the | | | | | | | object. | +------------+-------+-----+-------------+------+-------------------+ Table 24 Object: provMetadata Object Name: Provisioning Metadata Object Object Type: Component Description: Contains standard metadata about the lifecycle and ownership of a provisioned object. Reference: [This-ID] Data Elements Kowalik & Wullink Expires 6 May 2027 [Page 143] Internet-Draft RPP Data Objects November 2026 +============+==========+=====+==========+==========+===============+ |Element |Element |Card.|Mutability|Data Type |Description | |Identifier |Name | | | | | +============+==========+=====+==========+==========+===============+ |repositoryId|Repository|0-1 |read-only |Identifier|A server- | | |ID | | | |assigned unique| | | | | | |identifier for | | | | | | |the object. | +------------+----------+-----+----------+----------+---------------+ |spClientId |Sponsoring|1 |read-only |Client |The identifier | | |Client ID | | |Identifier|of the client | | | | | | |that is the | | | | | | |current sponsor| | | | | | |of the object. | +------------+----------+-----+----------+----------+---------------+ |crClientId |Creating |0-1 |read-only |Client |The identifier | | |Client ID | | |Identifier|of the client | | | | | | |that created | | | | | | |the object. | +------------+----------+-----+----------+----------+---------------+ |crDate |Creation |0-1 |read-only |Timestamp |The date and | | |Date | | | |time of object | | | | | | |creation. | +------------+----------+-----+----------+----------+---------------+ |upClientId |Updating |0-1 |read-only |Client |The identifier | | |Client ID | | |Identifier|of the client | | | | | | |that last | | | | | | |updated the | | | | | | |object. | +------------+----------+-----+----------+----------+---------------+ |upDate |Update |0-1 |read-only |Timestamp |The date and | | |Date | | | |time of the | | | | | | |most recent | | | | | | |object | | | | | | |modification. | +------------+----------+-----+----------+----------+---------------+ |trDate |Transfer |0-1 |read-only |Timestamp |The date and | | |Date | | | |time of the | | | | | | |most recent | | | | | | |successful | | | | | | |object | | | | | | |transfer. | +------------+----------+-----+----------+----------+---------------+ Table 25 Object: processes Kowalik & Wullink Expires 6 May 2027 [Page 144] Internet-Draft RPP Data Objects November 2026 Object Name: Processes Object Object Type: Component Description: A container grouping the Process Objects currently or recently initiated on a Data Object, structured as a dictionary keyed by process type where each element holds an unordered array of Process Objects of that type. The set of process-type data elements is extensible; extensions MAY register additional process-type elements. Reference: [This-ID] Data Elements Kowalik & Wullink Expires 6 May 2027 [Page 145] Internet-Draft RPP Data Objects November 2026 +===============+=========+=====+==========+===========+============+ |Element |Element |Card.|Mutability|Data Type |Description | |Identifier |Name | | | | | +===============+=========+=====+==========+===========+============+ |transferProcess|Transfer |0+ |read-only |Aggregation|The | | |Processes| | |[Transfer |transfer | | | | | |Process |processes | | | | | |Object] |initiated | | | | | | |on the | | | | | | |owning Data | | | | | | |Object. | +---------------+---------+-----+----------+-----------+------------+ |renewProcess |Renew |0+ |read-only |Aggregation|The renew | | |Processes| | |[Renew |processes | | | | | |Process |initiated | | | | | |Object] |on the | | | | | | |owning Data | | | | | | |Object. | +---------------+---------+-----+----------+-----------+------------+ |restoreProcess |Restore |0+ |read-only |Aggregation|The restore | | |Processes| | |[Restore |processes | | | | | |Process |initiated | | | | | |Object] |on the | | | | | | |owning Data | | | | | | |Object. | +---------------+---------+-----+----------+-----------+------------+ |createProcess |Create |0+ |read-only |Aggregation|The create | | |Processes| | |[Create |processes | | | | | |Process |initiated | | | | | |Object] |on the | | | | | | |owning Data | | | | | | |Object. | +---------------+---------+-----+----------+-----------+------------+ Table 26 Object: baseProcess Object Name: Base Process Object Object Type: Component Description: Base structure for all Process Objects, containing the data elements common to every process. Reference: [This-ID] Data Elements Kowalik & Wullink Expires 6 May 2027 [Page 146] Internet-Draft RPP Data Objects November 2026 +============+=========+=====+============+======+==================+ | Element | Element |Card.| Mutability |Data | Description | | Identifier | Name | | |Type | | +============+=========+=====+============+======+==================+ | processId | Process |0-1 | read-only |String| A server- | | | ID | | | | assigned | | | | | | | identifier of | | | | | | | the process | | | | | | | instance, | | | | | | | unique within | | | | | | | the Owner Data | | | | | | | Object. | +------------+---------+-----+------------+------+------------------+ Table 27 Object: baseAvailability Object Name: Base Availability Object Object Type: Component Description: Base structure for the result of an Availability operation, indicating whether the referenced object can be created. Reference: [This-ID] Data Elements Kowalik & Wullink Expires 6 May 2027 [Page 147] Internet-Draft RPP Data Objects November 2026 +==========+=========+=====+============+=======+===================+ |Element |Element |Card.| Mutability |Data | Description | |Identifier|Name | | |Type | | +==========+=========+=====+============+=======+===================+ |available |Available|1 | read-only |Boolean| Indicates | | | | | | | whether the | | | | | | | referenced | | | | | | | object can be | | | | | | | created at the | | | | | | | time the | | | | | | | operation is | | | | | | | completed. | +----------+---------+-----+------------+-------+-------------------+ |reason |Reason |0-1 | read-only |String | Server-specific | | | | | | | text explaining | | | | | | | why the | | | | | | | referenced | | | | | | | object cannot | | | | | | | be created. | +----------+---------+-----+------------+-------+-------------------+ Table 28 Object: domainNameAvailability Object Name: Domain Name Availability Object Object Type: Component Extends: baseAvailability Description: The result of an Availability operation on a Domain Name Data Object. Reference: [This-ID] Data Elements: (None) Object: contactAvailability Object Name: Contact Availability Object Object Type: Component Extends: baseAvailability Description: The result of an Availability operation on a Contact Data Object. Kowalik & Wullink Expires 6 May 2027 [Page 148] Internet-Draft RPP Data Objects November 2026 Reference: [This-ID] Data Elements: (None) Object: hostAvailability Object Name: Host Availability Object Object Type: Component Extends: baseAvailability Description: The result of an Availability operation on a Host Data Object. Reference: [This-ID] Data Elements: (None) Object: baseMessage Object Name: Base Message Object Object Type: Component Description: Base structure for all message objects, containing common data elements such as the object type and object identifier. Reference: [This-ID] Data Elements Kowalik & Wullink Expires 6 May 2027 [Page 149] Internet-Draft RPP Data Objects November 2026 +============+============+=====+============+======+===============+ | Element | Element |Card.| Mutability |Data | Description | | Identifier | Name | | |Type | | +============+============+=====+============+======+===============+ | objectType | Object |0-1 | read-only |String| The object | | | Type | | | | identifier | | | | | | | of the | | | | | | | object | | | | | | | affected by | | | | | | | the | | | | | | | requested | | | | | | | action. | +------------+------------+-----+------------+------+---------------+ | objectId | Object |0-1 | read-only |String| The unique | | | Identifier | | | | identifier | | | | | | | of the | | | | | | | object | | | | | | | affected by | | | | | | | the | | | | | | | requested | | | | | | | operation. | +------------+------------+-----+------------+------+---------------+ Table 29 Object: reviewResponseMessage Object Name: Review Response Object Object Type: Component Extends: baseMessage Description: Notification of the result of an offline review of a requested operation. Reference: [This-ID] Data Elements +===================+===========+=====+==========+=========+===========+ |Element Identifier |Element |Card.|Mutability|Data Type|Description| | |Name | | | | | +===================+===========+=====+==========+=========+===========+ |approved |Approval |1 |read-only |Boolean |Whether the| | |Result | | | |requested | | | | | | |action was | | | | | | |approved | Kowalik & Wullink Expires 6 May 2027 [Page 150] Internet-Draft RPP Data Objects November 2026 | | | | | |and | | | | | | |completed. | +-------------------+-----------+-----+----------+---------+-----------+ |clientTransactionId|Client |0-1 |read-only |String |The client | | |Transaction| | | |transaction| | |ID | | | |identifier | | | | | | |from the | | | | | | |original | | | | | | |request, if| | | | | | |supplied. | +-------------------+-----------+-----+----------+---------+-----------+ |serverTransactionId|Server |1 |read-only |String |The server | | |Transaction| | | |transaction| | |ID | | | |identifier | | | | | | |returned | | | | | | |for the | | | | | | |original | | | | | | |request. | +-------------------+-----------+-----+----------+---------+-----------+ |completionDate |Completion |1 |read-only |Timestamp|The date | | |Date | | | |and time | | | | | | |when review| | | | | | |of the | | | | | | |requested | | | | | | |action was | | | | | | |completed. | +-------------------+-----------+-----+----------+---------+-----------+ |message |Message |1 |read-only |String |Human- | | | | | | |readable | | | | | | |message | | | | | | |associated | | | | | | |with the | | | | | | |review | | | | | | |response. | +-------------------+-----------+-----+----------+---------+-----------+ |process |Process |0-1 |read-only |Base |The process| | | | | |Process |whose | | | | | |Object |operation | | | | | | |was subject| | | | | | |to the | | | | | | |offline | | | | | | |review. | +-------------------+-----------+-----+----------+---------+-----------+ Table 30 Object: transferRequestMessage Kowalik & Wullink Expires 6 May 2027 [Page 151] Internet-Draft RPP Data Objects November 2026 Object Name: Transfer Request Message Object Object Type: Component Extends: baseMessage Description: Notification for losing client of started transfer request, where the client expected to act on the pending transfer request. Reference: [This-ID] Data Elements +=============+========+=====+============+=========+==============+ | Element |Element |Card.| Mutability |Data Type| Description | | Identifier |Name | | | | | +=============+========+=====+============+=========+==============+ | status |Transfer|1 | read-only |String | The current | | |Status | | | | state of the | | | | | | | transfer | | | | | | | request. | +-------------+--------+-----+------------+---------+--------------+ | requestDate |Request |1 | read-only |Timestamp| The date and | | |Date | | | | time the | | | | | | | transfer was | | | | | | | requested. | +-------------+--------+-----+------------+---------+--------------+ | actionDate |Action |0-1 | read-only |Timestamp| The deadline | | |Date | | | | for | | | | | | | responding | | | | | | | before the | | | | | | | server takes | | | | | | | an automated | | | | | | | action. | +-------------+--------+-----+------------+---------+--------------+ | process |Process |0-1 | read-only |Transfer | The transfer | | | | | |Process | process the | | | | | |Object | message | | | | | | | pertains to. | +-------------+--------+-----+------------+---------+--------------+ Table 31 Object: transferOutcomeMessage Object Name: Transfer Outcome Message Object Kowalik & Wullink Expires 6 May 2027 [Page 152] Internet-Draft RPP Data Objects November 2026 Object Type: Component Extends: baseMessage Description: Notification for a client affected by the completion of a transfer request. Reference: [This-ID] Data Elements Kowalik & Wullink Expires 6 May 2027 [Page 153] Internet-Draft RPP Data Objects November 2026 +=============+========+=====+============+=========+===============+ | Element |Element |Card.| Mutability |Data Type| Description | | Identifier |Name | | | | | +=============+========+=====+============+=========+===============+ | trStatus |Transfer|1 | read-only |String | The final | | |Status | | | | state of the | | | | | | | transfer | | | | | | | request. | +-------------+--------+-----+------------+---------+---------------+ | requestDate |Request |1 | read-only |Timestamp| The date and | | |Date | | | | time the | | | | | | | transfer was | | | | | | | requested. | +-------------+--------+-----+------------+---------+---------------+ | actionDate |Action |1 | read-only |Timestamp| The date and | | |Date | | | | time the | | | | | | | transfer | | | | | | | request was | | | | | | | resolved. | +-------------+--------+-----+------------+---------+---------------+ | expiryDate |Expiry |0-1 | read-only |Timestamp| The end of | | |Date | | | | the object's | | | | | | | validity | | | | | | | period if | | | | | | | the | | | | | | | operation | | | | | | | causes a | | | | | | | change in | | | | | | | the validity | | | | | | | period. | +-------------+--------+-----+------------+---------+---------------+ | process |Process |0-1 | read-only |Transfer | The transfer | | | | | |Process | process the | | | | | |Object | message | | | | | | | pertains to. | +-------------+--------+-----+------------+---------+---------------+ Table 32 Object: expirationDeletionMessage Object Name: Expiration Deletion Message Object Object Type: Component Extends: baseMessage Kowalik & Wullink Expires 6 May 2027 [Page 154] Internet-Draft RPP Data Objects November 2026 Description: Notification for the sponsoring client that an object was deleted following expiration. Reference: [This-ID] Data Elements +==============+========+=====+============+=========+=============+ | Element |Element |Card.| Mutability |Data Type| Description | | Identifier |Name | | | | | +==============+========+=====+============+=========+=============+ | deletionDate |Deletion|1 | read-only |Timestamp| The date | | |Date | | | | and time | | | | | | | the server | | | | | | | deleted the | | | | | | | object. | +--------------+--------+-----+------------+---------+-------------+ Table 33 Object: autoRenewalMessage Object Name: Auto-Renewal Message Object Object Type: Component Extends: baseMessage Description: Notification for the sponsoring client that the server automatically renewed an object. Reference: [This-ID] Data Elements Kowalik & Wullink Expires 6 May 2027 [Page 155] Internet-Draft RPP Data Objects November 2026 +=============+=======+=====+============+===========+=============+ | Element |Element|Card.| Mutability | Data Type | Description | | Identifier |Name | | | | | +=============+=======+=====+============+===========+=============+ | renewalDate |Renewal|1 | read-only | Timestamp | The date | | |Date | | | | and time | | | | | | | the server | | | | | | | renewed the | | | | | | | object. | +-------------+-------+-----+------------+-----------+-------------+ | expiryDate |Expiry |1 | read-only | Timestamp | The new | | |Date | | | | expiration | | | | | | | date of the | | | | | | | object. | +-------------+-------+-----+------------+-----------+-------------+ Table 34 Object: serviceNoticeMessage Object Name: Service Notice Message Object Object Type: Component Extends: baseMessage Description: Generic text-based message containing information not covered by any other message type. Reference: [This-ID] Data Elements +============+=========+=====+============+======+=================+ | Element | Element |Card.| Mutability |Data | Description | | Identifier | Name | | |Type | | +============+=========+=====+============+======+=================+ | message | Message |1 | read-only |String| Human-readable | | | | | | | service | | | | | | | information for | | | | | | | the receiving | | | | | | | organisation. | +------------+---------+-----+------------+------+-----------------+ Table 35 Object: transferProcess Kowalik & Wullink Expires 6 May 2027 [Page 156] Internet-Draft RPP Data Objects November 2026 Object Name: Transfer Process Object Object Type: Process Extends: baseProcess Description: Represents a transfer request for a provisioned object. Creating this object initiates the transfer. Approve and Reject are additional operations; Delete corresponds to cancel. Reference: [This-ID] Data Elements +===============+==========+=====+===========+==========+===========+ |Element |Element |Card.|Mutability |Data Type |Description| |Identifier |Name | | | | | +===============+==========+=====+===========+==========+===========+ |transferDir |Transfer |0-1 |create-only|String |The | | |Direction | | | |direction | | | | | | |of the | | | | | | |transfer | | | | | | |("pull" or | | | | | | |"push"). | | | | | | |If omitted,| | | | | | |server | | | | | | |policy | | | | | | |determines | | | | | | |default. | +---------------+----------+-----+-----------+----------+-----------+ |gainingClientId|Gaining |0-1 |create-only|Client |The | | |Client ID | | |Identifier|designated | | | | | | |gaining | | | | | | |client. | | | | | | |REQUIRED | | | | | | |for push | | | | | | |transfers; | | | | | | |MUST NOT be| | | | | | |provided | | | | | | |for pull. | +---------------+----------+-----+-----------+----------+-----------+ |trStatus |Transfer |1 |read-only |String |The state | | |Status | | | |of the | | | | | | |transfer | | | | | | |request. | +---------------+----------+-----+-----------+----------+-----------+ |reqClientId |Requesting|1 |read-only |Client |The | | |Client ID | | |Identifier|identifier | Kowalik & Wullink Expires 6 May 2027 [Page 157] Internet-Draft RPP Data Objects November 2026 | | | | | |of the | | | | | | |client that| | | | | | |initiated | | | | | | |the | | | | | | |transfer | | | | | | |request. | +---------------+----------+-----+-----------+----------+-----------+ |requestDate |Request |1 |read-only |Timestamp |The date | | |Date | | | |and time | | | | | | |that the | | | | | | |transfer | | | | | | |was | | | | | | |requested. | +---------------+----------+-----+-----------+----------+-----------+ |actClientId |Acting |1 |read-only |Client |The | | |Client ID | | |Identifier|identifier | | | | | | |of the | | | | | | |client that| | | | | | |should or | | | | | | |did act on | | | | | | |the | | | | | | |request. | +---------------+----------+-----+-----------+----------+-----------+ |actionDate |Action |1 |read-only |Timestamp |The | | |Date | | | |response | | | | | | |deadline | | | | | | |(if | | | | | | |pending) or| | | | | | |completion | | | | | | |date. | +---------------+----------+-----+-----------+----------+-----------+ Table 36 Operations Operation: Create Operation Identifier: transferCreate Description: Initiates a transfer of a provisioned object by creating a Transfer Process Object. Input Data Elements: (None) Parameters: (None) Operation: Transfer Read Kowalik & Wullink Expires 6 May 2027 [Page 158] Internet-Draft RPP Data Objects November 2026 Operation Identifier: transferRead Description: Queries the status of a transfer of a provisioned object. Input Data Elements: (None) Parameters: (None) Operation: Transfer Delete Operation Identifier: transferDelete Description: Cancels a pending transfer of a provisioned object. Input Data Elements: (None) Parameters: (None) Operation: Transfer Approve Operation Identifier: transferApprove Description: Approves a pending transfer of a provisioned object. Input Data Elements: (None) Parameters: (None) Operation: Transfer Reject Operation Identifier: transferReject (on Transfer Process Object) Description: Rejects a pending transfer of a provisioned object. Input Data Elements +============+========+=======+========+==========================+ | Identifier | Name | Card. | Data | Description | | | | | Type | | +============+========+=======+========+==========================+ | reason | Reason | 0-1 | String | A human-readable text | | | | | | describing the rationale | | | | | | for rejection. | +------------+--------+-------+--------+--------------------------+ Table 37 Kowalik & Wullink Expires 6 May 2027 [Page 159] Internet-Draft RPP Data Objects November 2026 Parameters: (None) Object: renewProcess Object Name: Renew Process Object Object Type: Process Extends: baseProcess Description: Represents a renewal request for a provisioned object. Creating this object initiates the renewal. Reference: [This-ID] Data Elements Kowalik & Wullink Expires 6 May 2027 [Page 160] Internet-Draft RPP Data Objects November 2026 +===============+=======+=====+===========+=========+===============+ | Element |Element|Card.|Mutability |Data Type| Description | | Identifier |Name | | | | | +===============+=======+=====+===========+=========+===============+ | expiryDate |Expiry |0-1 |create-only|Timestamp| The expiry | | |Date | | | | date of the | | | | | | | object after | | | | | | | the renewal | | | | | | | is | | | | | | | completed. | +---------------+-------+-----+-----------+---------+---------------+ | renewalPeriod |Renewal|0-1 |create-only|Period | The duration | | |Period | | |Object | to be added | | | | | | | to the | | | | | | | object's | | | | | | | registration | | | | | | | period. | | | | | | | This value | | | | | | | is used by | | | | | | | the server | | | | | | | to calculate | | | | | | | the new | | | | | | | expiryDate. | | | | | | | The default | | | | | | | value MAY be | | | | | | | defined by | | | | | | | server | | | | | | | policy. The | | | | | | | number of | | | | | | | units | | | | | | | available | | | | | | | MAY be | | | | | | | subject to | | | | | | | limits | | | | | | | imposed by | | | | | | | the server. | +---------------+-------+-----+-----------+---------+---------------+ Table 38 Operations Operation: Create Operation Identifier: renewCreate Description: Initiates a renewal of a provisioned object by creating a Renew Process Object. Kowalik & Wullink Expires 6 May 2027 [Page 161] Internet-Draft RPP Data Objects November 2026 Input Data Elements: (None) Parameters: (None) Object: createProcess Object Name: Create Process Object Object Type: Process Extends: baseProcess Description: Represents the process initiated when a resource creation operation is performed. Carries creation-specific inputs that are consumed during creation and not stored as persistent attributes of the created resource object. Reference: [This-ID] Data Elements: (None) Operations Operation: Create Operation Identifier: create Description: Invoked implicitly as a side effect of the resource object create operation; never invoked directly. Carries creation- specific inputs consumed during creation of the owning resource object. Input Data Elements: (None) Parameters: (None) Operation: Read Operation Identifier: read Description: Retrieves the result or status of the creation, if the server exposes the process resource. Input Data Elements: (None) Parameters: (None) Object: domainCreateProcess Kowalik & Wullink Expires 6 May 2027 [Page 162] Internet-Draft RPP Data Objects November 2026 Object Name: Domain Create Process Object Object Type: Process Extends: baseProcess Description: The Create Process Object specific to the Domain Name Data Object. Implicitly initiated by the domain create operation; carries the requested initial registration period consumed during creation and not persisted as part of the domain object's state. Reference: [This-ID] Data Elements +============+=========+=====+=============+========+==============+ | Element | Element |Card.| Mutability | Data | Description | | Identifier | Name | | | Type | | +============+=========+=====+=============+========+==============+ | period | Period |0-1 | create-only | Period | The initial | | | | | | Object | registration | | | | | | | period for | | | | | | | the domain | | | | | | | name. | +------------+---------+-----+-------------+--------+--------------+ Table 39 Operations Operation: Create Operation Identifier: create Description: Invoked implicitly as a side effect of the Domain Name Data Object create operation; never invoked directly. Carries the registration period consumed during domain creation. Input Data Elements: (None) Parameters: (None) Operation: Read Operation Identifier: read Description: Retrieves the result or status of the domain creation, if the server exposes the process resource. Kowalik & Wullink Expires 6 May 2027 [Page 163] Internet-Draft RPP Data Objects November 2026 Input Data Elements: (None) Parameters: (None) Object: domainTransferProcess Object Name: Domain Transfer Process Object Object Type: Process Description: The Transfer Process Object specific to the Domain Name Data Object. Carries the domain-specific transfer inputs and outputs, namely the requested transfer period and the resulting expiry date, that extend the common transfer process. Reference: [This-ID] Data Elements Kowalik & Wullink Expires 6 May 2027 [Page 164] Internet-Draft RPP Data Objects November 2026 +================+========+=====+===========+=========+=============+ | Element |Element |Card.|Mutability |Data Type|Description | | Identifier |Name | | | | | +================+========+=====+===========+=========+=============+ | expiryDate |Expiry |0-1 |read-only |Timestamp|The end of | | |Date | | | |the domain | | | | | | |object's | | | | | | |registration | | | | | | |period if | | | | | | |the transfer | | | | | | |caused or | | | | | | |causes a | | | | | | |change in | | | | | | |the validity | | | | | | |period. | +----------------+--------+-----+-----------+---------+-------------+ | transferPeriod |Transfer|0-1 |create-only|Period |The number | | |Period | | |Object |of units to | | | | | | |be added to | | | | | | |the | | | | | | |registration | | | | | | |period of | | | | | | |the domain | | | | | | |object upon | | | | | | |successful | | | | | | |completion | | | | | | |of the | | | | | | |transfer. | | | | | | |The number | | | | | | |of units | | | | | | |available | | | | | | |MAY be | | | | | | |subject to | | | | | | |limits | | | | | | |imposed by | | | | | | |the server. | +----------------+--------+-----+-----------+---------+-------------+ Table 40 Operations Operation: Create Operation Identifier: transferCreate Description: Initiates a transfer of a Domain Name Data Object by creating a Domain Transfer Process Object. Kowalik & Wullink Expires 6 May 2027 [Page 165] Internet-Draft RPP Data Objects November 2026 Input Data Elements: (None) Parameters: (None) Object: disclose Object Name: Disclose Object Object Type: Component Description: TBD Reference: [This-ID] Data Elements +============+=========+=======+============+======+=============+ | Element | Element | Card. | Mutability | Data | Description | | Identifier | Name | | | Type | | +============+=========+=======+============+======+=============+ +------------+---------+-------+------------+------+-------------+ Table 41 Object: restoreProcess Object Name: Restore Process Object Object Type: Process Extends: baseProcess Description: Represents the current state of a restore request for an object that has entered the Redemption Grace Period (RGP). Returned as output of all restore operations. This object is OPTIONAL and is only used when the RGP feature is supported. Reference: [This-ID] Data Elements Kowalik & Wullink Expires 6 May 2027 [Page 166] Internet-Draft RPP Data Objects November 2026 +=============+=======+=====+==========+=========+====================+ |Element |Element|Card.|Mutability|Data Type|Description | |Identifier |Name | | | | | +=============+=======+=====+==========+=========+====================+ |restoreStatus|Restore|1 |read-only |String |The current state of| | |Status | | | |the restore process.| +-------------+-------+-----+----------+---------+--------------------+ |requestDate |Request|0-1 |read-only |Timestamp|The date and time | | |Date | | | |when the restore | | | | | | |request was | | | | | | |submitted. Absent | | | | | | |if no request has | | | | | | |been submitted. | +-------------+-------+-----+----------+---------+--------------------+ |reportDate |Report |0-1 |read-only |Timestamp|The date and time | | |Date | | | |when the most recent| | | | | | |restore report was | | | | | | |accepted. Absent if| | | | | | |no report has been | | | | | | |accepted. | +-------------+-------+-----+----------+---------+--------------------+ |reportDueDate|Report |0-1 |read-only |Timestamp|The deadline for | | |Due | | | |submitting a restore| | |Date | | | |report before the | | | | | | |object reverts to | | | | | | |rgpRedemptionPeriod.| | | | | | |Present only when | | | | | | |status is | | | | | | |rgpPendingRestore. | +-------------+-------+-----+----------+---------+--------------------+ |restoreReport|Restore|0-1 |read-write|Restore |The restore report | | |Report | | |Report |submitted as | | | | | |Object |required by the RGP | | | | | | |process. | +-------------+-------+-----+----------+---------+--------------------+ Table 42 Operations Operation: Restore Create Operation Identifier: create Description: Initiates recovery of a domain name in the rgpRedemptionPeriod state by creating a Restore Process Object. This operation is OPTIONAL and is only available when the RGP feature is supported. Kowalik & Wullink Expires 6 May 2027 [Page 167] Internet-Draft RPP Data Objects November 2026 Input Data Elements +===============+=========+=======+=========+=======================+ | Identifier | Name | Card. | Data | Description | | | | | Type | | +===============+=========+=======+=========+=======================+ | restoreReport | Restore | 0-1 | Restore | An OPTIONAL inline | | | Report | | Report | restore report. If | | | | | Object | provided, the server | | | | | | processes the | | | | | | request and the | | | | | | report atomically. | | | | | | If the server does | | | | | | not require a | | | | | | restore report, this | | | | | | element MUST NOT be | | | | | | present and the | | | | | | restore is completed | | | | | | immediately. If the | | | | | | server requires a | | | | | | report and this | | | | | | element is absent, | | | | | | the object | | | | | | transitions to | | | | | | pendingRestore state | | | | | | awaiting a | | | | | | subsequent Report | | | | | | operation. | +---------------+---------+-------+---------+-----------------------+ Table 43 Parameters: (None) Operation: Restore Read Operation Identifier: read (on Restore Process Object) Description: Retrieves the current state of the RGP restore process for a domain name. This operation is OPTIONAL and is only available when the RGP feature is supported. Input Data Elements: (None) Parameters: (None) Operation: Restore Update Kowalik & Wullink Expires 6 May 2027 [Page 168] Internet-Draft RPP Data Objects November 2026 Operation Identifier: update Description: Submits or replaces the restore report for a domain name in the rgpPendingRestore state. This operation is OPTIONAL and is only available when the RGP feature is supported and the server requires a restore report. Input Data Elements +===============+=========+=======+=========+=======================+ | Identifier | Name | Card. | Data | Description | | | | | Type | | +===============+=========+=======+=========+=======================+ | restoreReport | Restore | 1 | Restore | The restore report | | | Report | | Report | to be submitted as | | | | | Object | part of the RGP | | | | | | process. | +---------------+---------+-------+---------+-----------------------+ Table 44 Parameters: (None) Object: restoreReport Object Name: Restore Report Object Object Type: Component Description: Contains the redemption grace period restore report submitted by the sponsoring client as required by the RGP process. This object is OPTIONAL and is only used when the RGP feature is supported and a restore report is required by server policy. Reference: [This-ID] Data Elements +=============+============+=====+==========+=========+=============+ |Element |Element Name|Card.|Mutability|Data Type|Description | |Identifier | | | | | | +=============+============+=====+==========+=========+=============+ |preData |Pre-Delete |0-1 |read-write|String |A copy of | | |Data | | | |the | | | | | | |registration | | | | | | |data that | | | | | | |existed for | | | | | | |the object | Kowalik & Wullink Expires 6 May 2027 [Page 169] Internet-Draft RPP Data Objects November 2026 | | | | | |prior to | | | | | | |deletion. | +-------------+------------+-----+----------+---------+-------------+ |postData |Post-Restore|0-1 |read-write|String |A copy of | | |Data | | | |the | | | | | | |registration | | | | | | |data that | | | | | | |exists for | | | | | | |the object | | | | | | |at the time | | | | | | |the restore | | | | | | |report is | | | | | | |submitted. | +-------------+------------+-----+----------+---------+-------------+ |deleteTime |Delete Time |0-1 |read-write|Timestamp|The date and | | | | | | |time when | | | | | | |the object | | | | | | |delete | | | | | | |request was | | | | | | |sent to the | | | | | | |server. | +-------------+------------+-----+----------+---------+-------------+ |restoreTime |Restore Time|0-1 |read-write|Timestamp|The date and | | | | | | |time when | | | | | | |the original | | | | | | |restore | | | | | | |request | | | | | | |operation | | | | | | |was sent to | | | | | | |the server. | +-------------+------------+-----+----------+---------+-------------+ |restoreReason|Restore |0-1 |read-write|String |A brief | | |Reason | | | |explanation | | | | | | |of the | | | | | | |reason for | | | | | | |restoring | | | | | | |the object. | +-------------+------------+-----+----------+---------+-------------+ |statements |Statements |1-2 |read-write|String |Mandatory | | | | | | |client | | | | | | |statements | | | | | | |required by | | | | | | |the RGP | | | | | | |process. | +-------------+------------+-----+----------+---------+-------------+ |other |Other |0-1 |read-write|String |Any | | | | | | |additional | | | | | | |information | Kowalik & Wullink Expires 6 May 2027 [Page 170] Internet-Draft RPP Data Objects November 2026 | | | | | |needed to | | | | | | |support the | | | | | | |statements | | | | | | |provided by | | | | | | |the client. | +-------------+------------+-----+----------+---------+-------------+ Table 45 Object: domainName Object Name: Domain Name Data Object Object Type: Resource Description: Represents a domain name and its associated data. Reference: [This-ID] Data Elements +================+=============+=====+==========+===================+=============+ |Identifier |Name |Card.|Mutability|Data Type |Description | +================+=============+=====+==========+===================+=============+ |name |Name |1 |create- |Fully Qualified |The fully | | | | |only |Domain Name |qualified | | | | | | |name of the | | | | | | |domain | | | | | | |object. | +----------------+-------------+-----+----------+-------------------+-------------+ |uName |Unicode Name |0-1 |create- |String |The fully | | | | |only | |qualified | | | | | | |name of the | | | | | | |domain using | | | | | | |the Unicode | | | | | | |character | | | | | | |set. | +----------------+-------------+-----+----------+-------------------+-------------+ |lgr |LGR |0-1 |create- |String |The name of | | | | |only | |the Label | | | | | | |Generation | | | | | | |Ruleset (LGR)| | | | | | |containing | | | | | | |the valid | | | | | | |code points | | | | | | |used for the | | | | | | |Unicode Name | | | | | | |(uName). | Kowalik & Wullink Expires 6 May 2027 [Page 171] Internet-Draft RPP Data Objects November 2026 +----------------+-------------+-----+----------+-------------------+-------------+ |provMetadata |Provisioning |1 |read-only |Provisioning |Standard | | |Metadata | | |Metadata Object |metadata | | | | | | |about object | | | | | | |lifecycle and| | | | | | |ownership. | +----------------+-------------+-----+----------+-------------------+-------------+ |status |Status |1+ |read-write|Domain Name Status |The current | | | | | |Object |status | | | | | | |descriptors | | | | | | |for the | | | | | | |domain. | +----------------+-------------+-----+----------+-------------------+-------------+ |registrant |Registrant |0-1 |read-write|Aggregation[Contact|The | | | | | |Data Object] |registrant | | | | | | |contact ID. | +----------------+-------------+-----+----------+-------------------+-------------+ |contacts |Contacts |0+ |read-write|LabelledAggregation|Associated | | | | | |[Contact Data |contact | | | | | |Object] |objects. | +----------------+-------------+-----+----------+-------------------+-------------+ |nameservers |Nameservers |0+ |read-write|Aggregation [Host |A collection | | | | | |Data Object] |of | | | | | | |nameservers | | | | | | |associated | | | | | | |with the | | | | | | |domain. | +----------------+-------------+-----+----------+-------------------+-------------+ |dns |DNS Data |0-1 |read-write|DNS Data Object |DNS resource | | | | | | |records and | | | | | | |operational | | | | | | |controls | | | | | | |related to | | | | | | |the domain | | | | | | |name. | +----------------+-------------+-----+----------+-------------------+-------------+ |subordinateHosts|Subordinate |0+ |read-only |Aggregation [Host |Subordinate | | |Hosts | | |Data Object] |host names. | +----------------+-------------+-----+----------+-------------------+-------------+ |expiryDate |Expiry Date |0-1 |read-only |Timestamp |Expiry | | | | | | |timestamp. | +----------------+-------------+-----+----------+-------------------+-------------+ |authInfo |Authorisation|0-1 |read-write|Authorisation |Authorisation| | |Information | | |Information Object |information | | | | | | |for the | | | | | | |object. | +----------------+-------------+-----+----------+-------------------+-------------+ |processes |Processes |0-1 |read-only |Processes Object |Process | Kowalik & Wullink Expires 6 May 2027 [Page 172] Internet-Draft RPP Data Objects November 2026 | | | | | |Objects | | | | | | |initiated on | | | | | | |the domain | | | | | | |object. | +----------------+-------------+-----+----------+-------------------+-------------+ Table 46 Operations Operation: Availability Operation Identifier: availability Description: Determines whether a Domain Name resource can be created. Input Data Elements: (None) Parameters +============+=========+=======+========+=====================+ | Identifier | Name | Card. | Data | Description | | | | | Type | | +============+=========+=======+========+=====================+ | uName | Unicode | 0-1 | String | The Unicode Name of | | | Name | | | the domain name for | | | | | | which availability | | | | | | is determined. | +------------+---------+-------+--------+---------------------+ | lgr | LGR | 0-1 | String | The LGR against | | | | | | which availability | | | | | | of the domain name | | | | | | is determined. | +------------+---------+-------+--------+---------------------+ Table 47 Operation: Create Operation Identifier: create Description: Provisions a new Domain Name resource. Input Data Elements: (None) Parameters: (None) Kowalik & Wullink Expires 6 May 2027 [Page 173] Internet-Draft RPP Data Objects November 2026 Operation: Read Operation Identifier: read Description: Retrieves the data elements of a Domain Name resource. Input Data Elements: (None) Parameters +=============+========+=======+========+==========================+ | Identifier | Name | Card. | Data | Description | | | | | Type | | +=============+========+=======+========+==========================+ | hostsFilter | Hosts | 0-1 | String | Controls which host | | | Filter | | | information is returned. | +-------------+--------+-------+--------+--------------------------+ Table 48 Operation: Update Description: Modifies the read-write data elements of a Domain Name resource. Input Data Elements: (None) Parameters: (None) Operation: Delete Operation Identifier: delete Description: Removes an existing Domain Name resource. Input Data Elements: (None) Parameters: (None) Object: contact Object Name: Contact Data Object Object Type: Resource Description: A Contact Data Object represents the contact information for an individual or organisation associated with other objects. Kowalik & Wullink Expires 6 May 2027 [Page 174] Internet-Draft RPP Data Objects November 2026 Reference: [This-ID] Data Elements +============+=============+=====+==========+=============+=============+ |Identifier |Name |Card.|Mutability|Data Type |Description | +============+=============+=====+==========+=============+=============+ |id |Handle ID |1 |create- |Identifier |External | | | | |only | |unique | | | | | | |identifier of| | | | | | |the contact | | | | | | |object. | +------------+-------------+-----+----------+-------------+-------------+ |provMetadata|Provisioning |1 |read-only |Provisioning |Standard | | |Metadata | | |Metadata |metadata | | | | | |Object |about the | | | | | | |object's | | | | | | |lifecycle and| | | | | | |ownership. | +------------+-------------+-----+----------+-------------+-------------+ |status |Status |1+ |read-write|Contact |Status | | | | | |Status Object|descriptors | | | | | | |associated | | | | | | |with the | | | | | | |contact. | +------------+-------------+-----+----------+-------------+-------------+ |contactInfo |Contact |1 |read-write|External:RPP-|JSContact | | |Information | | |JSContact- |Card | | | | | |Profile:Card |information. | +------------+-------------+-----+----------+-------------+-------------+ |authInfo |Authorisation|0-1 |read-write|Authorisation|Authorisation| | |Information | | |Information |information | | | | | |Object |associated | | | | | | |with the | | | | | | |contact | | | | | | |object. | +------------+-------------+-----+----------+-------------+-------------+ |disclose |Disclose |0-1 |read-write|Disclose |Identifies | | | | | |Object |elements that| | | | | | |require | | | | | | |exceptional | | | | | | |server- | | | | | | |operator | | | | | | |handling to | | | | | | |allow or | | | | | | |restrict | | | | | | |disclosure to| | | | | | |third | Kowalik & Wullink Expires 6 May 2027 [Page 175] Internet-Draft RPP Data Objects November 2026 | | | | | |parties. | +------------+-------------+-----+----------+-------------+-------------+ |processes |Processes |0-1 |read-only |Processes |Process | | | | | |Object |Objects | | | | | | |initiated on | | | | | | |the contact | | | | | | |object. | +------------+-------------+-----+----------+-------------+-------------+ Table 49 Operations Operation: Availability Operation Identifier: availability Description: Determines whether a Contact resource can be created. Input Data Elements: (None) Parameters: (None) Operation: Create Operation Operation Identifier: create Description: The Create operation allows a client to provision a new Contact resource. The operation accepts as input all create-only and read-write data elements defined for the Contact Data Object. Input Data Elements: (None) Parameters: (None) Operation: Read Operation Operation Identifier: read Description: The Read operation allows a client to retrieve the data elements of a Contact resource. The server's response MAY vary depending on client authorisation and server policy. Input Data Elements: (None) Parameters: (None) Operation: Update Operation Kowalik & Wullink Expires 6 May 2027 [Page 176] Internet-Draft RPP Data Objects November 2026 Operation Identifier: update Description: The Update operation allows a client to modify the attributes of an existing Contact resource. Input Data Elements: (None) Parameters: (None) Operation: Delete Operation Operation Identifier: delete Description: The Delete operation allows a client to remove an existing Contact resource. The operation targets a specific data object identified by its Handle ID. Input Data Elements: (None) Parameters: (None) Object: host Object Name: Host Data Object Object Type: Resource Description: Represents a nameserver that provides DNS services for a domain name. Reference: [This-ID] Data Elements Kowalik & Wullink Expires 6 May 2027 [Page 177] Internet-Draft RPP Data Objects November 2026 +============+============+=====+==========+============+===========+ |Identifier |Name |Card.|Mutability|Data Type |Description| +============+============+=====+==========+============+===========+ |hostName |Host Name |1 |read-write|Fully |Fully | | | | | |Qualified |qualified | | | | | |Domain Name |name of a | | | | | | |host. | +------------+------------+-----+----------+------------+-----------+ |provMetadata|Provisioning|1 |read-only |Provisioning|Standard | | |Metadata | | |Metadata |metadata | | | | | |Object |about | | | | | | |object | | | | | | |lifecycle | | | | | | |and | | | | | | |ownership. | +------------+------------+-----+----------+------------+-----------+ |status |Status |1+ |read-write|Host Status |The current| | | | | |Object |status | | | | | | |descriptors| | | | | | |for the | | | | | | |host. | +------------+------------+-----+----------+------------+-----------+ |dns |DNS Data |0-1 |read-write|DNS Data |DNS | | | | | |Object |resource | | | | | | |records and| | | | | | |operational| | | | | | |controls | | | | | | |related to | | | | | | |the host. | +------------+------------+-----+----------+------------+-----------+ |processes |Processes |0-1 |read-only |Processes |Process | | | | | |Object |Objects | | | | | | |initiated | | | | | | |on the host| | | | | | |object. | +------------+------------+-----+----------+------------+-----------+ Table 50 Operations Operation: Availability Operation Identifier: availability Description: Determines whether a Host Data Object can be created. Input Data Elements: (None) Kowalik & Wullink Expires 6 May 2027 [Page 178] Internet-Draft RPP Data Objects November 2026 Parameters: (None) Operation: Create Description: Provisions a new Host Data Object. Input Data Elements: (None) Parameters: (None) Operation: Read Description: Retrieves the data elements of a Host Data Object. Input Data Elements: (None) Parameters: (None) Operation: Update Description: Modifies the attributes of a Host Data Object. Input Data Elements: (None) Parameters: (None) Operation: Delete Description: Removes an existing Host Data Object. Input Data Elements: (None) Parameters: (None) Object: organisationRole Object Name: Organisation Role Object Object Type: Component Description: Represents a role that an organisation has within the registry ecosystem, as defined in Section 3.2 of [RFC8543]. An organisation object MUST always have at least one associated role. Reference: [This-ID] Data Elements Kowalik & Wullink Expires 6 May 2027 [Page 179] Internet-Draft RPP Data Objects November 2026 +==========+==========+=====+==========+==============+=============+ |Element |Element |Card.|Mutability| Data Type | Description | |Identifier|Name | | | | | +==========+==========+=====+==========+==============+=============+ |status |Role |0+ |read-write| Organisation | The status | | |Status | | | Role Status | of this | | | | | | Object | role. | +----------+----------+-----+----------+--------------+-------------+ |roleId |Role |0-1 |read-write| String | A third- | | |Identifier| | | | party- | | | | | | | assigned | | | | | | | identifier | | | | | | | for this | | | | | | | role, such | | | | | | | as an IANA | | | | | | | registrar | | | | | | | ID. | +----------+----------+-----+----------+--------------+-------------+ Table 51 Object: organisation Object Name: Organisation Data Object Object Type: Resource Description: Represents an entity, such as a registrar, reseller, DNS service operator, or privacy proxy, involved in the domain registration process. Based on the EPP Organisation Mapping defined in [RFC8543]. Reference: [This-ID] Data Elements +============+============+=====+==========+===========================+==============+ |Identifier |Name |Card.|Mutability|Data Type |Description | +============+============+=====+==========+===========================+==============+ |id |Organisation|1 |create- |Identifier |A server- | | |ID | |only | |unique | | | | | | |identifier for| | | | | | |the | | | | | | |organisation | | | | | | |object. | +------------+------------+-----+----------+---------------------------+--------------+ |provMetadata|Provisioning|1 |read-only |Provisioning Metadata |Standard | | |Metadata | | |Object |metadata about| Kowalik & Wullink Expires 6 May 2027 [Page 180] Internet-Draft RPP Data Objects November 2026 | | | | | |the object's | | | | | | |lifecycle and | | | | | | |ownership. | +------------+------------+-----+----------+---------------------------+--------------+ |status |Status |1+ |read-write|Organisation Status Object |The current | | | | | | |operational | | | | | | |status | | | | | | |descriptors | | | | | | |for the | | | | | | |organisation. | +------------+------------+-----+----------+---------------------------+--------------+ |roles |Roles |1+ |read-write|DictionaryComposition |One or more | | | | | |[Organisation Role Object] |roles | | | | | | |describing the| | | | | | |organisation's| | | | | | |relationship | | | | | | |within the | | | | | | |registry | | | | | | |ecosystem. | +------------+------------+-----+----------+---------------------------+--------------+ |parent |Parent |0-1 |read-write|Aggregation [Organisation |The parent | | |Organisation| | |Data Object] |organisation | | | | | | |in a | | | | | | |hierarchical | | | | | | |organisation | | | | | | |structure. | +------------+------------+-----+----------+---------------------------+--------------+ |contactInfo |Contact |0-1 |read-write|External:RPP-JSContact- |Contact | | |Information | | |Profile:Card |information. | +------------+------------+-----+----------+---------------------------+--------------+ |contacts |Contacts |0+ |read-write|LabelledAggregation[Contact|Identifiers of| | | | | |Data Object] |contact | | | | | | |objects | | | | | | |associated | | | | | | |with the | | | | | | |organisation. | +------------+------------+-----+----------+---------------------------+--------------+ |users |Users |0+ |read-write|LabelledAggregation [User |Identifiers of| | | | | |Data Object] |user objects | | | | | | |associated | | | | | | |with the | | | | | | |organisation. | +------------+------------+-----+----------+---------------------------+--------------+ |processes |Processes |0-1 |read-only |Processes Object |Process | | | | | | |Objects | | | | | | |initiated on | | | | | | |the | | | | | | |organisation | Kowalik & Wullink Expires 6 May 2027 [Page 181] Internet-Draft RPP Data Objects November 2026 | | | | | |object. | +------------+------------+-----+----------+---------------------------+--------------+ Table 52 Operations Operation: Create Operation Identifier: create Description: Provisions a new Organisation Data Object. Input Data Elements: (None) Parameters: (None) Operation: Read Operation Identifier: read Description: Retrieves the data elements of an Organisation Data Object. Input Data Elements: (None) Parameters: (None) Operation: Update Operation Identifier: update Description: Modifies the attributes of an existing Organisation Data Object. Input Data Elements: (None) Parameters: (None) Operation: Delete Operation Identifier: delete Description: Removes an existing Organisation Data Object. Input Data Elements: (None) Parameters: (None) Kowalik & Wullink Expires 6 May 2027 [Page 182] Internet-Draft RPP Data Objects November 2026 Object: message Object Name: Message Data Object Object Type: Resource Description: Represents a message placed into an organisation's queue by the server and retrieved by the client. Reference: [This-ID] Data Elements Kowalik & Wullink Expires 6 May 2027 [Page 183] Internet-Draft RPP Data Objects November 2026 +============+========+=====+===========+==========+================+ |Identifier |Name |Card.|Mutability |Data Type | Description | +============+========+=====+===========+==========+================+ |id |Message |1 |read-only |Identifier| A server- | | |ID | | | | unique | | | | | | | identifier | | | | | | | for the | | | | | | | message | | | | | | | object. | +------------+--------+-----+-----------+----------+----------------+ |creationDate|Creation|1 |read-only |Timestamp | The date and | | |Date | | | | time when the | | | | | | | message | | | | | | | object was | | | | | | | created and | | | | | | | inserted into | | | | | | | the queue. | +------------+--------+-----+-----------+----------+----------------+ |status |Status |1 |read-only |String | The current | | | | | | | lifecycle | | | | | | | status of the | | | | | | | message | | | | | | | object | | | | | | | (queued, | | | | | | | delivered, | | | | | | | removed). | +------------+--------+-----+-----------+----------+----------------+ |data |Data |1 |create-only|Base | The data | | | | | |Message | related to a | | | | | |Object | specific | | | | | | | message, such | | | | | | | as a transfer | | | | | | | request or a | | | | | | | review | | | | | | | response. | +------------+--------+-----+-----------+----------+----------------+ Table 53 Operations Operation: Create Operation Identifier: create Description: Inserts a new message into the queue for an organisation. Kowalik & Wullink Expires 6 May 2027 [Page 184] Internet-Draft RPP Data Objects November 2026 Input Data Elements: (None) Parameters: (None) Operation: Read Operation Identifier: read Description: Retrieves the data elements of one or more Message Data Objects. Input Data Elements: (None) Parameters: (None) Operation: Query Operation Identifier: query Description: Retrieves zero or more Message Data Objects, optionally filtered by the specified parameters. Input Data Elements: (None) Parameters +============+=========+=======+========+========================+ | Identifier | Name | Card. | Data | Description | | | | | Type | | +============+=========+=======+========+========================+ | type | Message | 0-1 | String | The type of the | | | Type | | | message to use as a | | | | | | filter when retrieving | | | | | | message objects. | +------------+---------+-------+--------+------------------------+ Table 54 Operation: Delete Operation Identifier: delete Description: Removes a specific Message Data Object. Input Data Elements: (None) Parameters: (None) Kowalik & Wullink Expires 6 May 2027 [Page 185] Internet-Draft RPP Data Objects November 2026 Object: user Object Name: User Data Object Object Type: Resource Description: Represents a user linked to an Organisation Data Object. Each user carries a set of RBAC roles that define the user's permissions within the context of the owning organisation. The lifecycle of a User Object is bound to its Organisation Object. Reference: [This-ID] Data Elements Kowalik & Wullink Expires 6 May 2027 [Page 186] Internet-Draft RPP Data Objects November 2026 +============+============+=====+==========+=============+============+ |Identifier |Name |Card.|Mutability|Data Type |Description | +============+============+=====+==========+=============+============+ |id |User |1 |create- |Identifier |A unique | | |Identifier | |only | |identifier | | | | | | |for the | | | | | | |user. MUST | | | | | | |be globally | | | | | | |unique in | | | | | | |the server | | | | | | |scope. | +------------+------------+-----+----------+-------------+------------+ |details |Details |1 |read-write|External:RPP-|The details | | | | | |JSContact- |of the user.| | | | | |Profile:Card | | +------------+------------+-----+----------+-------------+------------+ |status |Status |1 |read-write|User Status |The current | | | | | |Object |status of | | | | | | |the user. | +------------+------------+-----+----------+-------------+------------+ |processes |Processes |0-1 |read-only |Processes |Process | | | | | |Object |Objects | | | | | | |initiated on| | | | | | |the user | | | | | | |object. | +------------+------------+-----+----------+-------------+------------+ |description |Description |0-1 |read-write|String |A | | | | | | |description | | | | | | |of the user | +------------+------------+-----+----------+-------------+------------+ |organisation|Organisation|1 |read-only |Aggregation |A reference | | | | | |[Organisation|to the owner| | | | | |Data Object] |organisation| | | | | | |object. | +------------+------------+-----+----------+-------------+------------+ Table 55 Operations Operation: Create Operation Identifier: create Description: Creates a new User Object. Input Data Elements: (None) Kowalik & Wullink Expires 6 May 2027 [Page 187] Internet-Draft RPP Data Objects November 2026 Parameters: (None) Operation: Read Operation Identifier: read Description: Retrieves the data elements of a specific User Object. Input Data Elements: (None) Parameters: (None) Operation: Update Operation Identifier: update Description: Modifies the read-write data elements (e.g., roles) of a specific User Object. Input Data Elements: (None) Parameters: (None) Operation: Delete Operation Identifier: delete Description: Removes a specific User Object. Input Data Elements: (None) Parameters: (None) Object: profile Object Name: Profile Data Object Object Type: Resource Description: Represents a named set of protocol features and versions that defines the compatibility and capabilities of RPP server implementations. Reference: [This-ID] Data Elements Kowalik & Wullink Expires 6 May 2027 [Page 188] Internet-Draft RPP Data Objects November 2026 +==============+===========+=====+==========+===========+============+ |Identifier |Name |Card.|Mutability|Data Type |Description | +==============+===========+=====+==========+===========+============+ |name |Name |1 |read-only |String |A unique | | | | | | |name that | | | | | | |identifies | | | | | | |the profile.| +--------------+-----------+-----+----------+-----------+------------+ |description |Description|1 |read-only |String |A human- | | | | | | |readable | | | | | | |description | | | | | | |of the | | | | | | |profile and | | | | | | |its intended| | | | | | |use. | +--------------+-----------+-----+----------+-----------+------------+ |version |Version |1 |read-only |String |The version | | | | | | |of the | | | | | | |profile. | +--------------+-----------+-----+----------+-----------+------------+ |rppVersion |RPP Version|1 |read-only |String |The minimum | | | | | | |version of | | | | | | |the RPP | | | | | | |protocol | | | | | | |that is | | | | | | |supported or| | | | | | |required for| | | | | | |the profile.| +--------------+-----------+-----+----------+-----------+------------+ |objects |Objects |1+ |read-only |String |The objects | | | | | | |allowed for | | | | | | |provisioning| | | | | | |operations. | +--------------+-----------+-----+----------+-----------+------------+ |extensions |Extensions |0+ |read-only |Extension |The | | | | | |Object |extensions, | | | | | | |including | | | | | | |their names | | | | | | |and | | | | | | |versions, | | | | | | |that are | | | | | | |supported or| | | | | | |required for| | | | | | |the profile.| +--------------+-----------+-----+----------+-----------+------------+ |baseProfile |Base |0-1 |read-only |Aggregation|A base | | |Profile | | |[Profile |profile that| | | | | |Data |is extended | Kowalik & Wullink Expires 6 May 2027 [Page 189] Internet-Draft RPP Data Objects November 2026 | | | | |Object] |by this | | | | | | |profile. | +--------------+-----------+-----+----------+-----------+------------+ |defaultProfile|Default |1 |read-only |Boolean |Indicates | | |Profile | | | |whether this| | | | | | |profile is | | | | | | |the default | | | | | | |profile. | +--------------+-----------+-----+----------+-----------+------------+ Table 56 Operations Operation: Read Operation Identifier: read Description: Retrieves the Profile Data Object identified by its name. Input Data Elements: (None) Parameters: (None) Object: discoveryVersion Object Name: Discovery Version Object Object Type: Component Description: Describes a version of RPP supported by the server. Reference: [This-ID] Data Elements Kowalik & Wullink Expires 6 May 2027 [Page 190] Internet-Draft RPP Data Objects November 2026 +============+=========+=======+============+========+==============+ | Element | Element | Card. | Mutability | Data | Description | | Identifier | Name | | | Type | | +============+=========+=======+============+========+==============+ | version | Version | 1 | read-only | String | The RPP | | | | | | | version, | | | | | | | for example | | | | | | | "1.0". | +------------+---------+-------+------------+--------+--------------+ | baseUrl | Base | 1 | read-only | URL | The base | | | URL | | | | URL | | | | | | | specific | | | | | | | for the | | | | | | | version, | | | | | | | used as a | | | | | | | prefix for | | | | | | | all | | | | | | | endpoint | | | | | | | URL | | | | | | | templates. | +------------+---------+-------+------------+--------+--------------+ Table 57 Object: discoveryEnvironment Object Name: Discovery Environment Object Object Type: Component Description: Describes the environment of the RPP server. Reference: [This-ID] Data Elements Kowalik & Wullink Expires 6 May 2027 [Page 191] Internet-Draft RPP Data Objects November 2026 +============+=========+=======+============+========+=============+ | Element | Element | Card. | Mutability | Data | Description | | Identifier | Name | | | Type | | +============+=========+=======+============+========+=============+ | name | Name | 1 | read-only | String | The name of | | | | | | | the RPP | | | | | | | server. | +------------+---------+-------+------------+--------+-------------+ | status | Status | 1 | read-only | String | The | | | | | | | operational | | | | | | | status of | | | | | | | the RPP | | | | | | | server. | +------------+---------+-------+------------+--------+-------------+ Table 58 Object: extension Object Name: Extension Object Object Type: Component Description: Describes an extension supported by the server. Reference: [This-ID] Data Elements Kowalik & Wullink Expires 6 May 2027 [Page 192] Internet-Draft RPP Data Objects November 2026 +============+=========+=====+============+======+================+ | Element |Element |Card.| Mutability |Data | Description | | Identifier |Name | | |Type | | +============+=========+=====+============+======+================+ | name |Name |1 | read-only |String| A short name | | | | | | | for the | | | | | | | extension. | +------------+---------+-----+------------+------+----------------+ | id |Extension|1 | read-only |String| A unique URN | | |ID | | | | identifier for | | | | | | | the extension. | +------------+---------+-----+------------+------+----------------+ | version |Version |1 | read-only |String| The version of | | | | | | | the extension | | | | | | | supported by | | | | | | | the server. | +------------+---------+-----+------------+------+----------------+ | url |URL |1 | read-only |URL | The location | | | | | | | of the | | | | | | | extension | | | | | | | specification. | +------------+---------+-----+------------+------+----------------+ Table 59 Object: discoveryIdnLgr Object Name: Discovery IDN LGR Object Object Type: Component Description: Describes a Label Generation Ruleset (LGR) supported by the server for internationalized domain names. Reference: [This-ID] Data Elements Kowalik & Wullink Expires 6 May 2027 [Page 193] Internet-Draft RPP Data Objects November 2026 +============+=======+=====+============+=======+===================+ | Element |Element|Card.| Mutability |Data | Description | | Identifier |Name | | |Type | | +============+=======+=====+============+=======+===================+ | tld |TLDs |1+ | read-only |String | The top-level | | | | | | | domains to | | | | | | | which the LGR | | | | | | | applies. | +------------+-------+-----+------------+-------+-------------------+ | name |Name |1 | read-only |String | The IANA- | | | | | | | registered name | | | | | | | of the LGR. | +------------+-------+-----+------------+-------+-------------------+ | url |URL |1 | read-only |URL | The location of | | | | | | | the LGR | | | | | | | specification. | +------------+-------+-----+------------+-------+-------------------+ | default |Default|1 | read-only |Boolean| Indicates | | | | | | | whether this | | | | | | | LGR is the | | | | | | | default for the | | | | | | | specified TLDs. | +------------+-------+-----+------------+-------+-------------------+ Table 60 Object: discoveryNotice Object Name: Discovery Notice Object Object Type: Component Description: Describes a notice from the server operator. Reference: [This-ID] Data Elements Kowalik & Wullink Expires 6 May 2027 [Page 194] Internet-Draft RPP Data Objects November 2026 +==========+===========+=====+==========+=========+=================+ |Element |Element |Card.|Mutability|Data Type| Description | |Identifier|Name | | | | | +==========+===========+=====+==========+=========+=================+ |pubTime |Publication|1 |read-only |Timestamp| The | | |Time | | | | publication | | | | | | | time of the | | | | | | | notice. | +----------+-----------+-----+----------+---------+-----------------+ |text |Text |1 |read-only |String | A human- | | | | | | | readable | | | | | | | description of | | | | | | | the notice. | +----------+-----------+-----+----------+---------+-----------------+ Table 61 Object: discovery Object Name: Discovery Data Object Object Type: Resource Description: Describes the capabilities of an RPP server. Reference: [This-ID] Data Elements +===========+===========+=====+==========+===================+===========+ |Identifier |Name |Card.|Mutability|Data Type |Description| +===========+===========+=====+==========+===================+===========+ |versions |Versions |1+ |read-only |Discovery Version |The | | | | | |Object |versions of| | | | | | |RPP | | | | | | |supported | | | | | | |by the | | | | | | |server. | +-----------+-----------+-----+----------+-------------------+-----------+ |environment|Environment|1 |read-only |Discovery |Information| | | | | |Environment Object |about the | | | | | | |RPP server.| +-----------+-----------+-----+----------+-------------------+-----------+ |tlds |TLDs |1+ |read-only |String |The TLDs | | | | | | |supported | | | | | | |by the | | | | | | |server. | +-----------+-----------+-----+----------+-------------------+-----------+ Kowalik & Wullink Expires 6 May 2027 [Page 195] Internet-Draft RPP Data Objects November 2026 |extensions |Extensions |0+ |read-only |Extension Object |The | | | | | | |extensions | | | | | | |supported | | | | | | |by the | | | | | | |server. | +-----------+-----------+-----+----------+-------------------+-----------+ |profiles |Profiles |0+ |read-only |String |The | | | | | | |profiles | | | | | | |supported | | | | | | |by the | | | | | | |server. | +-----------+-----------+-----+----------+-------------------+-----------+ |objects |Objects |1+ |read-only |String |The | | | | | | |resource | | | | | | |collections| | | | | | |supported | | | | | | |by the | | | | | | |server. | +-----------+-----------+-----+----------+-------------------+-----------+ |datetime |Date and |1 |read-only |Timestamp |The current| | |Time | | | |date and | | | | | | |time of the| | | | | | |server. | +-----------+-----------+-----+----------+-------------------+-----------+ |links |Links |0+ |read-only |LabelledAggregation|Links to | | | | | |[String] |documents | | | | | | |related to | | | | | | |the use of | | | | | | |RPP with | | | | | | |the server,| | | | | | |labelled | | | | | | |with a | | | | | | |relation | | | | | | |type | | | | | | |registered | | | | | | |in the IANA| | | | | | |"Link | | | | | | |Relation | | | | | | |Types" | | | | | | |registry. | +-----------+-----------+-----+----------+-------------------+-----------+ |idnLgr |IDN LGRs |0+ |read-only |Discovery IDN LGR |The Label | | | | | |Object |Generation | | | | | | |Rulesets | | | | | | |supported | | | | | | |by the | | | | | | |server. | +-----------+-----------+-----+----------+-------------------+-----------+ Kowalik & Wullink Expires 6 May 2027 [Page 196] Internet-Draft RPP Data Objects November 2026 |notices |Notices |0+ |read-only |Discovery Notice |Notices | | | | | |Object |from the | | | | | | |server | | | | | | |operator. | +-----------+-----------+-----+----------+-------------------+-----------+ Table 62 Operations Operation: Read Operation Identifier: read Description: Retrieves the Discovery Data Object. Input Data Elements: (None) Parameters: (None) 19.3. RPP User Role Values Registry This document establishes the "RESTful Provisioning Protocol (RPP) User Role Values Registry". This registry serves as a catalogue of all user role values used within RPP. Name of the registry: RPP User Role Values Registry group: RESTful Provisioning Protocol (RPP) Registration procedure: Expert Review Fields to be registered: * name: The name of the user role, for example "RPP example role". * url: The URL for the user role specification, for example "https://www.iana.org/assignments/rpp-user-roles/rpp-example-role- 1.0" (https://www.iana.org/assignments/rpp-user-roles/rpp-example- role-1.0"). * permission: The permission level associated with the user role, for example "read-only", "read-write", or "admin". * description: A human-readable description of the user role and its intended use. 19.4. RPP Domain Name Status Values Registry This document establishes the "RESTful Provisioning Protocol (RPP) Domain Name Status Values Registry". Kowalik & Wullink Expires 6 May 2027 [Page 197] Internet-Draft RPP Data Objects November 2026 Name of the registry: RPP Domain Name Status Values Registry group: RESTful Provisioning Protocol (RPP) Registration procedure: Specification Required Fields to be registered: * value: The machine-readable status label, for example "clientDeleteProhibited". * description: A human-readable description of the status and the conditions under which it applies. * set-by: The entity that adds and removes the status value: "client", "server", or "client, server" for a value that the server manages and that a client can also manage where server policy permits. * reference: A reference to the specification that defines the status value. 19.4.1. Initial Registrations The initial registrations for the RPP Domain Name Status Values registry are the status values defined in Table 1, reproduced below with their reference. +==========================+======+=======================+=========+ | Value |Set By| Description |Reference| +==========================+======+=======================+=========+ | clientDeleteProhibited |client| Requests to delete |[This-ID]| | | | the object MUST be | | | | | rejected. | | +--------------------------+------+-----------------------+---------+ | serverDeleteProhibited |server| Requests to delete |[This-ID]| | | | the object MUST be | | | | | rejected. | | +--------------------------+------+-----------------------+---------+ | clientHold |client| DNS delegation |[This-ID]| | | | information MUST NOT | | | | | be published for the | | | | | object. | | +--------------------------+------+-----------------------+---------+ | serverHold |server| DNS delegation |[This-ID]| | | | information MUST NOT | | | | | be published for the | | | | | object. | | +--------------------------+------+-----------------------+---------+ | clientRenewProhibited |client| Requests to renew |[This-ID]| | | | the object MUST be | | | | | rejected. | | +--------------------------+------+-----------------------+---------+ Kowalik & Wullink Expires 6 May 2027 [Page 198] Internet-Draft RPP Data Objects November 2026 | serverRenewProhibited |server| Requests to renew |[This-ID]| | | | the object MUST be | | | | | rejected. | | +--------------------------+------+-----------------------+---------+ | clientTransferProhibited |client| Requests to transfer |[This-ID]| | | | the object MUST be | | | | | rejected. | | +--------------------------+------+-----------------------+---------+ | serverTransferProhibited |server| Requests to transfer |[This-ID]| | | | the object MUST be | | | | | rejected. | | +--------------------------+------+-----------------------+---------+ | clientUpdateProhibited |client| Requests to update |[This-ID]| | | | the object (other | | | | | than to remove this | | | | | status) MUST be | | | | | rejected. | | +--------------------------+------+-----------------------+---------+ | serverUpdateProhibited |server| Requests to update |[This-ID]| | | | the object (other | | | | | than to remove this | | | | | status) MUST be | | | | | rejected. | | +--------------------------+------+-----------------------+---------+ | inactive |server| Delegation |[This-ID]| | | | information has not | | | | | been associated with | | | | | the object. This is | | | | | the default status | | | | | when a domain object | | | | | is first created and | | | | | there are no | | | | | associated host | | | | | objects for the DNS | | | | | delegation. This | | | | | status can also be | | | | | set by the server | | | | | when all host-object | | | | | associations are | | | | | removed. | | +--------------------------+------+-----------------------+---------+ | ok |server| This is the normal |[This-ID]| | | | status value for an | | | | | object that has no | | | | | pending operations | | | | | or prohibitions. | | | | | This value is set | | | | | and removed by the | | Kowalik & Wullink Expires 6 May 2027 [Page 199] Internet-Draft RPP Data Objects November 2026 | | | server as other | | | | | status values are | | | | | added or removed. | | +--------------------------+------+-----------------------+---------+ | pendingCreate |server| A transform command |[This-ID]| | | | has been processed | | | | | for the object, but | | | | | the action has not | | | | | been completed by | | | | | the server. Server | | | | | operators can delay | | | | | action completion | | | | | for a variety of | | | | | reasons, such as to | | | | | allow for human | | | | | review or third- | | | | | party action. | | +--------------------------+------+-----------------------+---------+ | pendingDelete |server| A transform command |[This-ID]| | | | has been processed | | | | | for the object, but | | | | | the action has not | | | | | been completed by | | | | | the server. Server | | | | | operators can delay | | | | | action completion | | | | | for a variety of | | | | | reasons, such as to | | | | | allow for human | | | | | review or third- | | | | | party action. | | +--------------------------+------+-----------------------+---------+ | pendingRenew |server| A transform command |[This-ID]| | | | has been processed | | | | | for the object, but | | | | | the action has not | | | | | been completed by | | | | | the server. Server | | | | | operators can delay | | | | | action completion | | | | | for a variety of | | | | | reasons, such as to | | | | | allow for human | | | | | review or third- | | | | | party action. | | +--------------------------+------+-----------------------+---------+ | pendingTransfer |server| A transform command |[This-ID]| | | | has been processed | | Kowalik & Wullink Expires 6 May 2027 [Page 200] Internet-Draft RPP Data Objects November 2026 | | | for the object, but | | | | | the action has not | | | | | been completed by | | | | | the server. Server | | | | | operators can delay | | | | | action completion | | | | | for a variety of | | | | | reasons, such as to | | | | | allow for human | | | | | review or third- | | | | | party action. | | +--------------------------+------+-----------------------+---------+ | pendingUpdate |server| A transform command |[This-ID]| | | | has been processed | | | | | for the object, but | | | | | the action has not | | | | | been completed by | | | | | the server. Server | | | | | operators can delay | | | | | action completion | | | | | for a variety of | | | | | reasons, such as to | | | | | allow for human | | | | | review or third- | | | | | party action. | | +--------------------------+------+-----------------------+---------+ | rgpAddPeriod |server| This grace period is |[This-ID]| | | | provided after the | | | | | initial registration | | | | | of a domain name. | | | | | If the domain name | | | | | is deleted by the | | | | | registrar during | | | | | this period, the | | | | | registry provides a | | | | | credit to the | | | | | registrar for the | | | | | cost of the | | | | | registration. | | +--------------------------+------+-----------------------+---------+ | rgpAutoRenewPeriod |server| This grace period is |[This-ID]| | | | provided after a | | | | | domain name | | | | | registration period | | | | | expires and is | | | | | extended (renewed) | | | | | automatically by the | | | | | registry. If the | | Kowalik & Wullink Expires 6 May 2027 [Page 201] Internet-Draft RPP Data Objects November 2026 | | | domain name is | | | | | deleted by the | | | | | registrar during | | | | | this period, the | | | | | registry provides a | | | | | credit to the | | | | | registrar for the | | | | | cost of the renewal. | | +--------------------------+------+-----------------------+---------+ | rgpRenewPeriod |server| This grace period is |[This-ID]| | | | provided after a | | | | | domain name | | | | | registration period | | | | | is explicitly | | | | | extended (renewed) | | | | | by the registrar. | | | | | If the domain name | | | | | is deleted by the | | | | | registrar during | | | | | this period, the | | | | | registry provides a | | | | | credit to the | | | | | registrar for the | | | | | cost of the renewal. | | +--------------------------+------+-----------------------+---------+ | rgpTransferPeriod |server| This grace period is |[This-ID]| | | | provided after the | | | | | successful transfer | | | | | of domain name | | | | | registration | | | | | sponsorship from one | | | | | registrar to another | | | | | registrar. If the | | | | | domain name is | | | | | deleted by the new | | | | | sponsoring registrar | | | | | during this period, | | | | | the registry | | | | | provides a credit to | | | | | the registrar for | | | | | the cost of the | | | | | transfer. | | +--------------------------+------+-----------------------+---------+ | rgpRedemptionPeriod |server| This status value is |[This-ID]| | | | used to describe a | | | | | domain for which a | | | | | delete operation has | | | | | been received, but | | Kowalik & Wullink Expires 6 May 2027 [Page 202] Internet-Draft RPP Data Objects November 2026 | | | the domain has not | | | | | yet been purged | | | | | because an | | | | | opportunity exists | | | | | to restore the | | | | | domain and abort the | | | | | deletion process. | | +--------------------------+------+-----------------------+---------+ | rgpPendingRestore |server| This status value is |[This-ID]| | | | used to describe a | | | | | domain that is in | | | | | the process of being | | | | | restored after being | | | | | in the | | | | | rgpRedemptionPeriod | | | | | state. | | +--------------------------+------+-----------------------+---------+ | rgpPendingDelete |server| This status value is |[This-ID]| | | | used to describe a | | | | | domain that has | | | | | entered the purge | | | | | processing state | | | | | after completing the | | | | | rgpRedemptionPeriod | | | | | state. A domain in | | | | | this status MUST | | | | | also be in the | | | | | pendingDelete status | | | | | described above. | | +--------------------------+------+-----------------------+---------+ Table 63: Initial RPP Domain Name Status Values Registrations 19.5. RPP Host Status Values Registry This document establishes the "RESTful Provisioning Protocol (RPP) Host Status Values Registry". Name of the registry: RPP Host Status Values Registry group: RESTful Provisioning Protocol (RPP) Registration procedure: Specification Required Fields to be registered: * value: The machine-readable status label, for example "clientDeleteProhibited". * description: A human-readable description of the status and the conditions under which it applies. Kowalik & Wullink Expires 6 May 2027 [Page 203] Internet-Draft RPP Data Objects November 2026 * set-by: The entity that adds and removes the status value: "client", "server", or "client, server" for a value that the server manages and that a client can also manage where server policy permits. * reference: A reference to the specification that defines the status value. 19.5.1. Initial Registrations The initial registrations for the RPP Host Status Values registry are the status values defined in Table 4, reproduced below with their reference. +========================+========+=====================+===========+ | Value | Set By | Description | Reference | +========================+========+=====================+===========+ | clientDeleteProhibited | client | Requests to delete | [This-ID] | | | | the object MUST be | | | | | rejected. | | +------------------------+--------+---------------------+-----------+ | serverDeleteProhibited | server | Requests to delete | [This-ID] | | | | the object MUST be | | | | | rejected. | | +------------------------+--------+---------------------+-----------+ | clientUpdateProhibited | client | Requests to update | [This-ID] | | | | the object (other | | | | | than to remove | | | | | this status) MUST | | | | | be rejected. | | +------------------------+--------+---------------------+-----------+ | serverUpdateProhibited | server | Requests to update | [This-ID] | | | | the object (other | | | | | than to remove | | | | | this status) MUST | | | | | be rejected. | | +------------------------+--------+---------------------+-----------+ | linked | server | The host object | [This-ID] | | | | has at least one | | | | | active association | | | | | with another | | | | | object, such as a | | | | | domain object. | | | | | Servers SHOULD | | | | | provide services | | | | | to determine | | | | | existing object | | | | | associations. | | +------------------------+--------+---------------------+-----------+ Kowalik & Wullink Expires 6 May 2027 [Page 204] Internet-Draft RPP Data Objects November 2026 | ok | server | This is the normal | [This-ID] | | | | status value for | | | | | an object that has | | | | | no pending | | | | | operations or | | | | | prohibitions. | | | | | This value is set | | | | | and removed by the | | | | | server as other | | | | | status values are | | | | | added or removed. | | +------------------------+--------+---------------------+-----------+ | pendingCreate | server | A transform | [This-ID] | | | | command has been | | | | | processed for the | | | | | object, but the | | | | | action has not | | | | | been completed by | | | | | the server. | | | | | Server operators | | | | | can delay action | | | | | completion for a | | | | | variety of | | | | | reasons, such as | | | | | to allow for human | | | | | review or third- | | | | | party action. | | +------------------------+--------+---------------------+-----------+ | pendingDelete | server | A transform | [This-ID] | | | | command has been | | | | | processed for the | | | | | object, but the | | | | | action has not | | | | | been completed by | | | | | the server. | | | | | Server operators | | | | | can delay action | | | | | completion for a | | | | | variety of | | | | | reasons, such as | | | | | to allow for human | | | | | review or third- | | | | | party action. | | +------------------------+--------+---------------------+-----------+ | pendingTransfer | server | A transform | [This-ID] | | | | command has been | | | | | processed for the | | | | | object's | | Kowalik & Wullink Expires 6 May 2027 [Page 205] Internet-Draft RPP Data Objects November 2026 | | | superordinate | | | | | domain object | | | | | (i.e. a transfer | | | | | of the domain | | | | | object is | | | | | pending), but the | | | | | action has not | | | | | been completed by | | | | | the server. | | | | | Server operators | | | | | can delay action | | | | | completion for a | | | | | variety of | | | | | reasons, such as | | | | | to allow for human | | | | | review or third- | | | | | party action. | | +------------------------+--------+---------------------+-----------+ | pendingUpdate | server | A transform | [This-ID] | | | | command has been | | | | | processed for the | | | | | object, but the | | | | | action has not | | | | | been completed by | | | | | the server. | | | | | Server operators | | | | | can delay action | | | | | completion for a | | | | | variety of | | | | | reasons, such as | | | | | to allow for human | | | | | review or third- | | | | | party action. | | +------------------------+--------+---------------------+-----------+ Table 64: Initial RPP Host Status Values Registrations 19.6. RPP Contact Status Values Registry This document establishes the "RESTful Provisioning Protocol (RPP) Contact Status Values Registry". Name of the registry: RPP Contact Status Values Registry group: RESTful Provisioning Protocol (RPP) Registration procedure: Specification Required Fields to be registered: Kowalik & Wullink Expires 6 May 2027 [Page 206] Internet-Draft RPP Data Objects November 2026 * value: The machine-readable status label, for example "clientDeleteProhibited". * description: A human-readable description of the status and the conditions under which it applies. * set-by: The entity that adds and removes the status value: "client", "server", or "client, server" for a value that the server manages and that a client can also manage where server policy permits. * reference: A reference to the specification that defines the status value. 19.6.1. Initial Registrations The initial registrations for the RPP Contact Status Values registry are the status values defined in Table 6, reproduced below with their reference. +==========================+========+===================+===========+ | Value | Set By | Description | Reference | +==========================+========+===================+===========+ | clientDeleteProhibited | client | Requests to | [This-ID] | | | | delete the | | | | | object MUST be | | | | | rejected. | | +--------------------------+--------+-------------------+-----------+ | serverDeleteProhibited | server | Requests to | [This-ID] | | | | delete the | | | | | object MUST be | | | | | rejected. | | +--------------------------+--------+-------------------+-----------+ | clientTransferProhibited | client | Requests to | [This-ID] | | | | transfer the | | | | | object MUST be | | | | | rejected. | | +--------------------------+--------+-------------------+-----------+ | serverTransferProhibited | server | Requests to | [This-ID] | | | | transfer the | | | | | object MUST be | | | | | rejected. | | +--------------------------+--------+-------------------+-----------+ | clientUpdateProhibited | client | Requests to | [This-ID] | | | | update the | | | | | object (other | | | | | than to remove | | | | | this status) | | | | | MUST be | | | | | rejected. | | +--------------------------+--------+-------------------+-----------+ Kowalik & Wullink Expires 6 May 2027 [Page 207] Internet-Draft RPP Data Objects November 2026 | serverUpdateProhibited | server | Requests to | [This-ID] | | | | update the | | | | | object (other | | | | | than to remove | | | | | this status) | | | | | MUST be | | | | | rejected. | | +--------------------------+--------+-------------------+-----------+ | linked | server | The contact | [This-ID] | | | | object has at | | | | | least one active | | | | | association with | | | | | another object, | | | | | such as a domain | | | | | object. Servers | | | | | SHOULD provide | | | | | services to | | | | | determine | | | | | existing object | | | | | associations. | | +--------------------------+--------+-------------------+-----------+ | ok | server | This is the | [This-ID] | | | | normal status | | | | | value for an | | | | | object that has | | | | | no pending | | | | | operations or | | | | | prohibitions. | | | | | This value is | | | | | set and removed | | | | | by the server as | | | | | other status | | | | | values are added | | | | | or removed. | | +--------------------------+--------+-------------------+-----------+ | pendingCreate | server | A transform | [This-ID] | | | | command has been | | | | | processed for | | | | | the object, but | | | | | the action has | | | | | not been | | | | | completed by the | | | | | server. Server | | | | | operators can | | | | | delay action | | | | | completion for a | | | | | variety of | | | | | reasons, such as | | Kowalik & Wullink Expires 6 May 2027 [Page 208] Internet-Draft RPP Data Objects November 2026 | | | to allow for | | | | | human review or | | | | | third-party | | | | | action. | | +--------------------------+--------+-------------------+-----------+ | pendingDelete | server | A transform | [This-ID] | | | | command has been | | | | | processed for | | | | | the object, but | | | | | the action has | | | | | not been | | | | | completed by the | | | | | server. Server | | | | | operators can | | | | | delay action | | | | | completion for a | | | | | variety of | | | | | reasons, such as | | | | | to allow for | | | | | human review or | | | | | third-party | | | | | action. | | +--------------------------+--------+-------------------+-----------+ | pendingTransfer | server | A transform | [This-ID] | | | | command has been | | | | | processed for | | | | | the object, but | | | | | the action has | | | | | not been | | | | | completed by the | | | | | server. Server | | | | | operators can | | | | | delay action | | | | | completion for a | | | | | variety of | | | | | reasons, such as | | | | | to allow for | | | | | human review or | | | | | third-party | | | | | action. | | +--------------------------+--------+-------------------+-----------+ | pendingUpdate | server | A transform | [This-ID] | | | | command has been | | | | | processed for | | | | | the object, but | | | | | the action has | | | | | not been | | | | | completed by the | | Kowalik & Wullink Expires 6 May 2027 [Page 209] Internet-Draft RPP Data Objects November 2026 | | | server. Server | | | | | operators can | | | | | delay action | | | | | completion for a | | | | | variety of | | | | | reasons, such as | | | | | to allow for | | | | | human review or | | | | | third-party | | | | | action. | | +--------------------------+--------+-------------------+-----------+ Table 65: Initial RPP Contact Status Values Registrations 19.7. RPP Organisation Role Status Values Registry This document establishes the "RESTful Provisioning Protocol (RPP) Organisation Role Status Values Registry". Name of the registry: RPP Organisation Role Status Values Registry group: RESTful Provisioning Protocol (RPP) Registration procedure: Specification Required Fields to be registered: * value: The machine-readable status label, for example "clientLinkProhibited". * description: A human-readable description of the status and the conditions under which it applies. * set-by: The entity that adds and removes the status value: "client", "server", or "client, server" for a value that the server manages and that a client can also manage where server policy permits. * reference: A reference to the specification that defines the status value. 19.7.1. Initial Registrations The initial registrations for the RPP Organisation Role Status Values registry are the status values defined in Table 8, reproduced below with their reference. Kowalik & Wullink Expires 6 May 2027 [Page 210] Internet-Draft RPP Data Objects November 2026 +======================+========+=======================+===========+ | Value | Set By | Description | Reference | +======================+========+=======================+===========+ | clientLinkProhibited | client | Requests to add new | [This-ID] | | | | links to the role | | | | | MUST be rejected. | | +----------------------+--------+-----------------------+-----------+ | serverLinkProhibited | server | Requests to add new | [This-ID] | | | | links to the role | | | | | MUST be rejected. | | +----------------------+--------+-----------------------+-----------+ | linked | server | The role has at | [This-ID] | | | | least one active | | | | | association with | | | | | another object. | | | | | This value is set | | | | | and removed by the | | | | | server and is not | | | | | explicitly set by | | | | | the client. | | +----------------------+--------+-----------------------+-----------+ | ok | server | This is the normal | [This-ID] | | | | status value for a | | | | | role that has no | | | | | active prohibitions. | | | | | This value is set | | | | | and removed by the | | | | | server as other | | | | | status values are | | | | | added or removed. | | +----------------------+--------+-----------------------+-----------+ Table 66: Initial RPP Organisation Role Status Values Registrations 19.8. RPP Organisation Status Values Registry This document establishes the "RESTful Provisioning Protocol (RPP) Organisation Status Values Registry". Name of the registry: RPP Organisation Status Values Registry group: RESTful Provisioning Protocol (RPP) Registration procedure: Specification Required Fields to be registered: * value: The machine-readable status label, for example "clientDeleteProhibited". Kowalik & Wullink Expires 6 May 2027 [Page 211] Internet-Draft RPP Data Objects November 2026 * description: A human-readable description of the status and the conditions under which it applies. * set-by: The entity that adds and removes the status value: "client", "server", or "client, server" for a value that the server manages and that a client can also manage where server policy permits. * reference: A reference to the specification that defines the status value. 19.8.1. Initial Registrations The initial registrations for the RPP Organisation Status Values registry are the status values defined in Table 10, reproduced below with their reference. +========================+=========+====================+===========+ | Value | Set By | Description | Reference | +========================+=========+====================+===========+ | ok | server | This is the | [This-ID] | | | | normal status | | | | | value for an | | | | | object that has | | | | | no pending | | | | | operations or | | | | | prohibitions. | | | | | This value is set | | | | | and removed by | | | | | the server as | | | | | other status | | | | | values are added | | | | | or removed. | | +------------------------+---------+--------------------+-----------+ | hold | client, | Organisation | [This-ID] | | | server | transform | | | | | commands and new | | | | | links MUST be | | | | | rejected. | | +------------------------+---------+--------------------+-----------+ | terminated | client, | The organisation | [This-ID] | | | server | has been | | | | | terminated and | | | | | MUST NOT be | | | | | linked. | | | | | Organisation | | | | | transform | | | | | commands and new | | | | | links MUST be | | | | | rejected. | | Kowalik & Wullink Expires 6 May 2027 [Page 212] Internet-Draft RPP Data Objects November 2026 +------------------------+---------+--------------------+-----------+ | linked | server | The organisation | [This-ID] | | | | object has at | | | | | least one active | | | | | association with | | | | | another object. | | | | | This value is not | | | | | explicitly set by | | | | | the client. | | | | | Servers SHOULD | | | | | provide services | | | | | to determine | | | | | existing object | | | | | associations. | | +------------------------+---------+--------------------+-----------+ | clientLinkProhibited | client | Requests to add | [This-ID] | | | | new links to the | | | | | organisation MUST | | | | | be rejected. | | +------------------------+---------+--------------------+-----------+ | serverLinkProhibited | server | Requests to add | [This-ID] | | | | new links to the | | | | | organisation MUST | | | | | be rejected. | | +------------------------+---------+--------------------+-----------+ | clientUpdateProhibited | client | Requests to | [This-ID] | | | | update the object | | | | | (other than to | | | | | remove this | | | | | status) MUST be | | | | | rejected. | | +------------------------+---------+--------------------+-----------+ | serverUpdateProhibited | server | Requests to | [This-ID] | | | | update the object | | | | | (other than to | | | | | remove this | | | | | status) MUST be | | | | | rejected. | | +------------------------+---------+--------------------+-----------+ | clientDeleteProhibited | client | Requests to | [This-ID] | | | | delete the object | | | | | MUST be rejected. | | +------------------------+---------+--------------------+-----------+ | serverDeleteProhibited | server | Requests to | [This-ID] | | | | delete the object | | | | | MUST be rejected. | | +------------------------+---------+--------------------+-----------+ | pendingCreate | server | A transform | [This-ID] | Kowalik & Wullink Expires 6 May 2027 [Page 213] Internet-Draft RPP Data Objects November 2026 | | | command has been | | | | | processed for the | | | | | object, but the | | | | | action has not | | | | | been completed by | | | | | the server. | | | | | Server operators | | | | | can delay action | | | | | completion for a | | | | | variety of | | | | | reasons, such as | | | | | to allow for | | | | | human review or | | | | | third-party | | | | | action. | | +------------------------+---------+--------------------+-----------+ | pendingUpdate | server | A transform | [This-ID] | | | | command has been | | | | | processed for the | | | | | object, but the | | | | | action has not | | | | | been completed by | | | | | the server. | | | | | Server operators | | | | | can delay action | | | | | completion for a | | | | | variety of | | | | | reasons, such as | | | | | to allow for | | | | | human review or | | | | | third-party | | | | | action. | | +------------------------+---------+--------------------+-----------+ | pendingDelete | server | A transform | [This-ID] | | | | command has been | | | | | processed for the | | | | | object, but the | | | | | action has not | | | | | been completed by | | | | | the server. | | | | | Server operators | | | | | can delay action | | | | | completion for a | | | | | variety of | | | | | reasons, such as | | | | | to allow for | | | | | human review or | | | | | third-party | | Kowalik & Wullink Expires 6 May 2027 [Page 214] Internet-Draft RPP Data Objects November 2026 | | | action. | | +------------------------+---------+--------------------+-----------+ Table 67: Initial RPP Organisation Status Values Registrations 19.9. RPP User Status Values Registry This document establishes the "RESTful Provisioning Protocol (RPP) User Status Values Registry". Name of the registry: RPP User Status Values Registry group: RESTful Provisioning Protocol (RPP) Registration procedure: Specification Required Fields to be registered: * value: The machine-readable status label, for example "suspended". * description: A human-readable description of the status and the conditions under which it applies. * set-by: The entity that adds and removes the status value: "client", "server", or "client, server" for a value that the server manages and that a client can also manage where server policy permits. * reference: A reference to the specification that defines the status value. 19.9.1. Initial Registrations The initial registrations for the RPP User Status Values registry are the status values defined in Table 12, reproduced below with their reference. Kowalik & Wullink Expires 6 May 2027 [Page 215] Internet-Draft RPP Data Objects November 2026 +=============+=========+===============================+===========+ | Value | Set By | Description | Reference | +=============+=========+===============================+===========+ | active | server | This is the normal status | [This-ID] | | | | value for a user that is | | | | | permitted to authenticate | | | | | and act within the | | | | | permissions of its roles. | | +-------------+---------+-------------------------------+-----------+ | pending | server | The user has been created, | [This-ID] | | | | but activation has not | | | | | been completed by the | | | | | server. Server operators | | | | | can delay activation for a | | | | | variety of reasons, such | | | | | as to allow for | | | | | verification of the user's | | | | | details or human review. | | | | | Requests authenticated as | | | | | the user MUST be rejected. | | +-------------+---------+-------------------------------+-----------+ | suspended | client, | The user has been | [This-ID] | | | server | temporarily suspended. | | | | | Requests authenticated as | | | | | the user MUST be rejected. | | +-------------+---------+-------------------------------+-----------+ | deactivated | client, | The user has been | [This-ID] | | | server | deactivated. Requests | | | | | authenticated as the user | | | | | MUST be rejected. | | +-------------+---------+-------------------------------+-----------+ Table 68: Initial RPP User Status Values Registrations 19.10. URN Sub-namespace for RPP (urn:ietf:params:rpp) The IANA is requested to add the following value to the "IETF URN Sub-namespace for Registered Protocol Parameter Identifiers" registry, following the template in [RFC3553]: TODO: add filled in template, if we decide to use URN for profile identification, for example "urn:ietf:params:rpp:profile:example-profile" Registry name: rpp Specification: This Document Repository: ? Index value: ? Kowalik & Wullink Expires 6 May 2027 [Page 216] Internet-Draft RPP Data Objects November 2026 19.11. RPP Discovery Registry The IANA is requested to create a new registry for RPP discovery URLs, this registry will be used to register the well-known URLs for RPP discovery endpoints, used by RPP clients to discover the capabilities of an RPP server. Name of the registry: RPP Discovery URLs Registry group: RESTful Provisioning Protocol (RPP) Registration procedure: Expert Review Fields to be registered: * tld: The top-level domain (TLD) for which the discovery URL is applicable, for example "example". * url: The URL for the discovery endpoint, for example "https://rpp.example/.well-known/rpp.json" (https://rpp.example/.well-known/rpp.json"). * description: A human-readable description of the discovery URL and its intended use. 19.12. RPP Extension Registry The IANA is requested to create a new registry for RPP extensions, this registry will be used to register standardised extensions to the RPP protocol. Extensions are defined as additional features or capabilities that can be added to the base RPP protocol, for example support for additional resource types, additional operations or additional authentication methods. Name of the registry: RPP Extensions Registry group: RESTful Provisioning Protocol (RPP) Registration procedure: Expert Review Fields to be registered: * name: The name of the extension, for example "RPP example extension". * version: The version of the extension, for example "1.0". * url: The URL for the extension specification, for example "https://www.iana.org/assignments/rpp-extensions/rpp-example- extension" (https://www.iana.org/assignments/rpp-extensions/rpp- example-extension"). * description: A human-readable description of the extension and its intended use. Kowalik & Wullink Expires 6 May 2027 [Page 217] Internet-Draft RPP Data Objects November 2026 19.13. RPP Profile Registry The IANA is requested to create a new registry for RPP profiles, this registry will be used to register standardised profiles for the RPP protocol. Profiles are defined as specific configurations of the RPP protocol that are designed to meet the needs of specific use cases or environments, for example an EPP compatibility profile that defines a set of RPP features and behaviours that are compatible with the Extensible Provisioning Protocol (EPP) [RFC5730]. Name of the registry: RPP Profiles Registry group: RESTful Provisioning Protocol (RPP) Registration procedure: Expert Review Fields to be registered: * name: The name of the profile, for example "EPP compatibility profile". * id: A unique URN identifier for the profile, for example "urn:ietf:params:rpp:profile:epp-compatibility". * version: The version of the profile, for example "1.0". * url: The URL for the profile specification, for example "https://www.iana.org/assignments/rpp-profiles/epp-compatibility- profile" (https://www.iana.org/assignments/rpp-profiles/epp- compatibility-profile"). * description: A human-readable description of the profile and its intended use. 20. Security Considerations | TODO: write security considerations, if any 21. Changes History draft-ietf-rpp-data-objects -01 - -02 * added Availability operation to the Uniform Interface and to the Domain Name, Contact and Host Data Objects #46 * add Abstract keyword to flag objects used only as base objects; Base Process Object and Base Message Object declared abstract #188 * clarified the Processes a Data Object supports or extends, and allowed extensions to define new processes * moved restore report from operation input to read-write element of Restore Process Object and replaced Report operation with Update * added a Status Object per Data Object, including the User Status Object, with status values, allowed transitions, and IANA registries, replacing the inline user status definition #118 Kowalik & Wullink Expires 6 May 2027 [Page 218] Internet-Draft RPP Data Objects November 2026 * fixed User Object delete operation constraint that prevented any user from being deleted * added X-Y bounded cardinality notation and set cardinality of Restore Report statements to 1-2 #183 * defined a structured notation for operation input and output, with input data elements and parameters (replacing transient data elements) inside the Input attribute, and split IANA operation tables into "Input Data Elements" and "Parameters" #147 * moved process data element from Base Message Object to Review Response, Transfer Request and Transfer Outcome message objects, using specific process types where possible; registered all message objects in IANA #179 * create-only definition clarified about reading #80 * moved requests for IANA registrations to here, from rpp-core document #151 * added Profile Data Object, including the Default Profile element #140 #155 * added Discovery Data Object, with links labelled by IANA link relation types #136 #137 * added Visibility data element attribute and generic includeElements parameter. Set authInfo of domain and contact to onDemand visibility #57 * added "Inheritance" section to describe how objects can use inheritance #134 * removed the urgent parameter from the update operation for Domain Object #52 * removed all mandatory ordering requirements for arrays, making them unordered #30 * added support for IDN (Internationalized Domain Names) #124 * added Message Data Object and new Uniform Interface "Query" operation #116 * removed the redefined processId data element from the Domain Transfer Process Object * added Set By column and set-by registry field for status values, and required the server to assign at least one status value #186 * renamed Authorisation Information and Disclose component objects to "Authorisation Information Object" and "Disclose Object" to match their references * updated document metadata, and Abstract and Introduction scope * editorial fixes to spelling, hyphenation, capitalisation, and terminology consistency draft-ietf-rpp-data-objects -00 - -01 * Added Organisation, Organisation Role and User Objects, based on RFC8543 (Issue #25) * Added Renew Process Object and operations (Issue #76) Kowalik & Wullink Expires 6 May 2027 [Page 219] Internet-Draft RPP Data Objects November 2026 * reserve property names beginning with @ for representation specifications #89 * add generic Create Process Object and Domain Create Process Object carrying the registration period #89 * add optional processId to all Process Objects #89 * add extensible Processes Object component and processes element to all Data Objects #89 * declare the unique identifier element explicitly in every object preamble #89 * add "Direct Access" flag exposing association data elements as addressable sub-resources #89 * editorial pass: fix spelling, grammar, subject-verb agreement, missing articles, cross-reference wording, and copy-paste object names * Add External Data Types section and JSContact (Issue #83) * restructure object processes: per-object "Processes" sections, process objects extending generic ones, add Domain Transfer Process Object, with IANA updates #119 draft-kowalik-rpp-data-objects-04 - draft-ietf-rpp-data-objects-00 * RPP working group adoption draft-kowalik-rpp-data-objects -03 - -04 * correct "postalInfo" to be DictionaryComposition not DictionaryAggregation * Added missing IANA tables for Contact, Postal Address and Postal Info. Added missing Operations. Added missing operation identifiers. Fixes #17, #18, #19, #20, #21. draft-kowalik-rpp-data-objects -02 - -03 * add Object and Dictionary[Value Type] primitive data types * change "Aggregation/Composition Dictionary" to "Dictionary Aggregation/Composition" (Issue #32) * describe operations for contacts #15 * describe operations for hosts #16 * add Domain Update operation with urgent transient parameter from [RFC5910] * add identifiers to all operations * abstract common provisioning metadata into reusable component object * define common RGP/restore process and Restore Process Object * define common transfer operations and Transfer Process Object with support for pull and push transfers #23 * add domain-specific transfer operations with implicit renewal and subordinate host transfer Kowalik & Wullink Expires 6 May 2027 [Page 220] Internet-Draft RPP Data Objects November 2026 * add host/domain relationship terminology from RFC 5732 * restructure DNS data model aligned with draft-simmen-rpp-dns-data- 01: redefine DNS Resource Record Object, add DNS Operational Controls Object, add DNS Data Object; update Domain, Host, and Nameserver objects to use it * add DNSSEC support based on [RFC5910]: DS and DNSKEY record types with structured RDATA fields * add NS, A, and AAAA RDATA structures and record type constraints to EPP compatibility profile for DNS Resource Record Object * expand extensibility section with standardised/private extension mechanisms, extension points, and operation extensibility * update IANA registration policy and registry structure to accommodate extension registrations draft-kowalik-rpp-data-objects -01 - -02 * ontology of allowed basic datatypes #4 * add examples of associations #31 22. References 22.1. Normative References [I-D.ietf-rpp-architecture] Kowalik, P. and M. Wullink, "RPP Architecture", Work in Progress, Internet-Draft, draft-ietf-rpp-architecture-01, 27 February 2026, . [I-D.wullink-rpp-jscontact-profile] Wullink, M. and P. Kowalik, "JSContact Profile for the RESTful Provisioning Protocol (RPP)", Work in Progress, Internet-Draft, draft-wullink-rpp-jscontact-profile, 2026, . [ITU.E164.2005] International Telecommunication Union, "The international public telecommunication numbering plan", ITU-T Recommendation E.164, February 2005. [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC791, September 1981, . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . Kowalik & Wullink Expires 6 May 2027 [Page 221] Internet-Draft RPP Data Objects November 2026 [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, DOI 10.17487/RFC1738, December 1994, . [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June 2003, . [RFC3915] Hollenbeck, S., "Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)", RFC 3915, DOI 10.17487/RFC3915, October 2004, . [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, . [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, . [RFC5732] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Host Mapping", STD 69, RFC 5732, DOI 10.17487/RFC5732, August 2009, . Kowalik & Wullink Expires 6 May 2027 [Page 222] Internet-Draft RPP Data Objects November 2026 [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733, August 2009, . [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, . [RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)", RFC 5892, DOI 10.17487/RFC5892, August 2010, . [RFC5893] Alvestrand, H., Ed. and C. Karp, "Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)", RFC 5893, DOI 10.17487/RFC5893, August 2010, . [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, . [RFC6903] Snell, J., "Additional Link Relation Types", RFC 6903, DOI 10.17487/RFC6903, March 2013, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8543] Zhou, L., Kong, N., Yao, J., Gould, J., and G. Zhou, "Extensible Provisioning Protocol (EPP) Organization Mapping", RFC 8543, DOI 10.17487/RFC8543, March 2019, . [RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219, RFC 9499, DOI 10.17487/RFC9499, March 2024, . Kowalik & Wullink Expires 6 May 2027 [Page 223] Internet-Draft RPP Data Objects November 2026 [RFC9553] Stepanek, R. and M. Loffredo, "JSContact: A JSON Representation of Contact Data", RFC 9553, DOI 10.17487/RFC9553, May 2024, . 22.2. Informative References [I-D.simmen-rpp-dns-data] Simmen, C. and P. Kowalik, "DNS data representation for use in RESTful Provisioning Protocol (RPP)", Work in Progress, Internet-Draft, draft-simmen-rpp-dns-data-01, 20 October 2025, . [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", STD 88, RFC 3596, DOI 10.17487/RFC3596, October 2003, . [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, . [RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)", RFC 5910, DOI 10.17487/RFC5910, May 2010, . Authors' Addresses Pawel Kowalik DENIC Email: pawel.kowalik@denic.de URI: https://denic.de/ Maarten Wullink SIDN Labs Email: maarten.wullink@sidn.nl URI: https://sidn.nl/ Kowalik & Wullink Expires 6 May 2027 [Page 224]