RESTful Provisioning Protocol (RPP) Data Objects
draft-ietf-rpp-data-objects-02
| Document | Type | Active Internet-Draft (rpp WG) | |
|---|---|---|---|
| Authors | Paweł Kowalik , Maarten Wullink | ||
| Last updated | 2026-11-02 | ||
| Replaces | draft-kowalik-rpp-data-objects | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
GitHub Organization
GitHub Repository Mailing list discussion |
||
| Stream | WG state | WG Document | |
| Associated WG milestone |
|
||
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-rpp-data-objects-02
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:<specification-
identifier>:<type-name>. 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)|<-----------+
| +-----------------------------------+ |
| | | | |
| <update> | <renew> | <transfer |
| (4) | (5) | create> (6) |
| v v v |
| +-------------+ +-------------+ +--------------------+ |
| | status: | | status: | | status: | |
| |pendingUpdate| |pendingRenew | | pendingTransfer | |
| | (4) | | (5) | | (6)| |
| +-------------+ +-------------+ +--------------------+ |
| | | | |
| +----------------+--------------------+ |
| action completed (7) |
+--------------------------------------------------------------+
+-----------------------------------+
| status: ok / inactive (3)|
+-----------------------------------+
|
<delete> (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 <delete> label refers
to the Delete operation on the Domain Name Data Object. The <create>
and <update> 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
+----------------------------+ <delete> +-------------------------------+
| status: ok (1)|------------->| status: pendingDelete (3)|
| | | rgpRedemptionPeriod |
+----------------------------+ +-------------------------------+
^ ^ restore, no report | ^ | |
| | and report required (4)| | | No (9) |
| | Restore <create> | | | restore |
| | +------------------+ | | |
| | v | | v
| | +------------------+ | | +-----------------------+
| | | status: (6)| | | | status: (10)|
| | | pendingDelete |-----------------+ | | pendingDelete |
| | | rgpPendingRestore| report not (7) | | rgpPendingDelete |
| | +------------------+ received | +-----------------------+
| | (8) | | |
| | report received | | purge (11) |
| | Restore <update> | restore (5) | v
| +--------------------+ with report | +-----------------------+
| or not req. | | Purged (12)|
| Restore <create> | +-----------------------+
+----------------------------------------------+
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) |<---------+
| +-----------------------------------+ |
| | | |
| <update> (4) | <domain transfer> (5) | |
| v v |
| +--------------------+ +--------------------+ |
| | status: | | status: | |
| | pendingUpdate (4) | | pendingTransfer(5) | |
| +--------------------+ +--------------------+ |
| | | |
| +------------------------+ |
| action completed (6) |
+---------------------------------------------------------+
+-----------------------------------+
| status: ok (3) |
+-----------------------------------+
|
| <delete> (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) |<---------+
| +-----------------------------------+ |
| | | |
| <update> (4) | <transfer create> (5) | |
| v v |
| +--------------------+ +--------------------+ |
| | status: | | status: | |
| | pendingUpdate (4) | | pendingTransfer(5) | |
| +--------------------+ +--------------------+ |
| | | |
| +------------------------+ |
| action completed (6) |
+---------------------------------------------------------+
+-----------------------------------+
| status: ok (3) |
+-----------------------------------+
|
| <delete> (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, <https://datatracker.ietf.org/doc/html/
draft-ietf-rpp-architecture-01>.
[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,
<https://datatracker.ietf.org/doc/html/draft-wullink-rpp-
jscontact-profile>.
[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,
<https://www.rfc-editor.org/info/rfc791>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
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, <https://www.rfc-editor.org/info/rfc1738>.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
<https://www.rfc-editor.org/info/rfc2026>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>.
[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, <https://www.rfc-editor.org/info/rfc3553>.
[RFC3915] Hollenbeck, S., "Domain Registry Grace Period Mapping for
the Extensible Provisioning Protocol (EPP)", RFC 3915,
DOI 10.17487/RFC3915, October 2004,
<https://www.rfc-editor.org/info/rfc3915>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/info/rfc5322>.
[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
<https://www.rfc-editor.org/info/rfc5730>.
[RFC5732] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
Host Mapping", STD 69, RFC 5732, DOI 10.17487/RFC5732,
August 2009, <https://www.rfc-editor.org/info/rfc5732>.
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, <https://www.rfc-editor.org/info/rfc5733>.
[RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010,
<https://www.rfc-editor.org/info/rfc5890>.
[RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and
Internationalized Domain Names for Applications (IDNA)",
RFC 5892, DOI 10.17487/RFC5892, August 2010,
<https://www.rfc-editor.org/info/rfc5892>.
[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,
<https://www.rfc-editor.org/info/rfc5893>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952,
DOI 10.17487/RFC5952, August 2010,
<https://www.rfc-editor.org/info/rfc5952>.
[RFC6903] Snell, J., "Additional Link Relation Types", RFC 6903,
DOI 10.17487/RFC6903, March 2013,
<https://www.rfc-editor.org/info/rfc6903>.
[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,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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,
<https://www.rfc-editor.org/info/rfc8543>.
[RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
RFC 9499, DOI 10.17487/RFC9499, March 2024,
<https://www.rfc-editor.org/info/rfc9499>.
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,
<https://www.rfc-editor.org/info/rfc9553>.
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, <https://datatracker.ietf.org/doc/html/
draft-simmen-rpp-dns-data-01>.
[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,
<https://www.rfc-editor.org/info/rfc3596>.
[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,
<https://www.rfc-editor.org/info/rfc4034>.
[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,
<https://www.rfc-editor.org/info/rfc5910>.
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]