Network Working Group P. Kowalik Internet-Draft DENIC Intended status: Standards Track M. Wullink Expires: 3 September 2026 SIDN Labs 2 March 2026 RESTful Provisioning Protocol (RPP) Data Objects draft-kowalik-rpp-data-objects-03 Abstract This document defines data objects for the RESTful Provisioning Protocol (RPP) and sets up 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 foundational resources: domain names, contacts, and hosts. In accordance with the RPP architecture [I-D.kowalik-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 3 September 2026. 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. Please review these documents carefully, as they describe your rights Kowalik & Wullink Expires 3 September 2026 [Page 1] Internet-Draft RPP Data Objects March 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 5 2. Resource Definition Principles . . . . . . . . . . . . . . . 6 2.1. Primitive Data Types . . . . . . . . . . . . . . . . . . 6 2.1.1. String . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.2. Integer . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.3. Boolean . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.4. Decimal . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.5. Date . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.6. Timestamp . . . . . . . . . . . . . . . . . . . . . . 7 2.1.7. URL . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1.8. Binary . . . . . . . . . . . . . . . . . . . . . . . 7 2.1.9. Dictionary . . . . . . . . . . . . . . . . . . . . . 7 2.1.10. Object . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Data Element Abstraction . . . . . . . . . . . . . . . . 7 2.3. Extensibility . . . . . . . . . . . . . . . . . . . . . . 8 2.3.1. Standardised and Private Extensions . . . . . . . . . 8 2.3.2. Extension Points . . . . . . . . . . . . . . . . . . 8 2.4. Data Element Semantics . . . . . . . . . . . . . . . . . 9 2.5. Operations . . . . . . . . . . . . . . . . . . . . . . . 9 2.5.1. Authorisation . . . . . . . . . . . . . . . . . . . . 9 2.5.2. Uniform interface . . . . . . . . . . . . . . . . . . 10 2.5.2.1. Create . . . . . . . . . . . . . . . . . . . . . 10 2.5.2.2. Read . . . . . . . . . . . . . . . . . . . . . . 10 2.5.2.3. Update . . . . . . . . . . . . . . . . . . . . . 10 2.5.2.4. Delete . . . . . . . . . . . . . . . . . . . . . 10 2.5.3. Operations beyond uniform interface . . . . . . . . . 10 2.5.4. Transfer Operations . . . . . . . . . . . . . . . . . 11 2.5.5. Restore Operations . . . . . . . . . . . . . . . . . 11 2.5.5.1. Redemption Grace Period State Diagram . . . . . . 12 2.6. EPP Compatibility Profile . . . . . . . . . . . . . . . . 14 3. Common Data Types . . . . . . . . . . . . . . . . . . . . . . 14 3.1. Identifier . . . . . . . . . . . . . . . . . . . . . . . 14 3.2. Client Identifier . . . . . . . . . . . . . . . . . . . . 15 3.3. Phone Number . . . . . . . . . . . . . . . . . . . . . . 15 4. Associations . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1. Aggregation . . . . . . . . . . . . . . . . . . . . . . . 15 4.2. Composition . . . . . . . . . . . . . . . . . . . . . . . 16 4.3. Labelled Aggregation . . . . . . . . . . . . . . . . . . 17 4.4. Dictionary Aggregation . . . . . . . . . . . . . . . . . 18 4.5. Labelled Composition . . . . . . . . . . . . . . . . . . 19 Kowalik & Wullink Expires 3 September 2026 [Page 2] Internet-Draft RPP Data Objects March 2026 4.6. Dictionary Composition . . . . . . . . . . . . . . . . . 19 5. Component Objects . . . . . . . . . . . . . . . . . . . . . . 20 5.1. Period Object . . . . . . . . . . . . . . . . . . . . . . 20 5.2. Provisioning Metadata Object . . . . . . . . . . . . . . 20 5.3. Status Object . . . . . . . . . . . . . . . . . . . . . . 22 5.4. DNS Resource Record Object . . . . . . . . . . . . . . . 24 5.4.1. RDATA Structures in EPP Profile . . . . . . . . . . . 25 5.5. DNS Operational Controls Object . . . . . . . . . . . . . 26 5.6. DNS Data Object . . . . . . . . . . . . . . . . . . . . . 27 5.7. Authorisation Information Object . . . . . . . . . . . . 28 5.8. Postal Address Object . . . . . . . . . . . . . . . . . . 29 5.9. Postal Info Object . . . . . . . . . . . . . . . . . . . 30 5.10. Disclose Object . . . . . . . . . . . . . . . . . . . . . 31 5.11. Restore Report Object . . . . . . . . . . . . . . . . . . 31 6. Process Objects . . . . . . . . . . . . . . . . . . . . . . . 33 6.1. Transfer Process Object . . . . . . . . . . . . . . . . . 33 6.1.1. Operations . . . . . . . . . . . . . . . . . . . . . 34 6.1.1.1. Create (Transfer Request) . . . . . . . . . . . . 34 6.1.1.2. Read (Transfer Query) . . . . . . . . . . . . . . 35 6.1.1.3. Delete (Transfer Cancel) . . . . . . . . . . . . 35 6.1.1.4. Approve . . . . . . . . . . . . . . . . . . . . . 36 6.1.1.5. Reject . . . . . . . . . . . . . . . . . . . . . 36 6.2. Restore Process Object . . . . . . . . . . . . . . . . . 37 6.2.1. Operations . . . . . . . . . . . . . . . . . . . . . 38 6.2.1.1. Create (Restore Request) . . . . . . . . . . . . 38 6.2.1.2. Read (Restore Query) . . . . . . . . . . . . . . 38 6.2.1.3. Report . . . . . . . . . . . . . . . . . . . . . 39 7. Domain Name Data Object . . . . . . . . . . . . . . . . . . . 40 7.1. Object Description . . . . . . . . . . . . . . . . . . . 40 7.2. Data Elements . . . . . . . . . . . . . . . . . . . . . . 40 7.3. Operations . . . . . . . . . . . . . . . . . . . . . . . 43 7.3.1. Create Operation . . . . . . . . . . . . . . . . . . 43 7.3.2. Read Operation . . . . . . . . . . . . . . . . . . . 43 7.3.3. Update Operation . . . . . . . . . . . . . . . . . . 44 7.3.4. Delete Operation . . . . . . . . . . . . . . . . . . 45 7.3.5. Renew Operation . . . . . . . . . . . . . . . . . . . 45 7.3.6. Transfer Operations . . . . . . . . . . . . . . . . . 46 7.3.7. Restore Operations . . . . . . . . . . . . . . . . . 47 8. Contact Data Object . . . . . . . . . . . . . . . . . . . . . 47 8.1. Object Description . . . . . . . . . . . . . . . . . . . 47 8.2. Data Elements . . . . . . . . . . . . . . . . . . . . . . 47 8.3. Operations . . . . . . . . . . . . . . . . . . . . . . . 49 8.3.1. Create Operation . . . . . . . . . . . . . . . . . . 49 8.3.2. Read Operation . . . . . . . . . . . . . . . . . . . 50 8.3.3. Update Operation . . . . . . . . . . . . . . . . . . 50 8.3.4. Delete Operation . . . . . . . . . . . . . . . . . . 51 8.3.5. Transfer Operations . . . . . . . . . . . . . . . . . 51 9. Host Data Object . . . . . . . . . . . . . . . . . . . . . . 51 Kowalik & Wullink Expires 3 September 2026 [Page 3] Internet-Draft RPP Data Objects March 2026 9.1. Object Description . . . . . . . . . . . . . . . . . . . 51 9.2. Data Elements . . . . . . . . . . . . . . . . . . . . . . 51 9.3. Operations . . . . . . . . . . . . . . . . . . . . . . . 52 9.3.1. Create Operation . . . . . . . . . . . . . . . . . . 53 9.3.2. Read Operation . . . . . . . . . . . . . . . . . . . 53 9.3.3. Update Operation . . . . . . . . . . . . . . . . . . 53 9.3.4. Delete Operation . . . . . . . . . . . . . . . . . . 54 9.3.5. Restore Operations . . . . . . . . . . . . . . . . . 54 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 10.1. RPP Data Object Registry . . . . . . . . . . . . . . . . 54 10.1.1. Registration Policy . . . . . . . . . . . . . . . . 55 10.1.2. Registry Structure . . . . . . . . . . . . . . . . . 55 10.1.3. Initial Registrations . . . . . . . . . . . . . . . 56 11. Security Considerations . . . . . . . . . . . . . . . . . . . 76 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 77 13.1. Normative References . . . . . . . . . . . . . . . . . . 77 13.2. Informative References . . . . . . . . . . . . . . . . . 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 79 1. Introduction The RESTful Provisioning Protocol (RPP) defines a set of data objects used to represent and manage foundational registry resources, including domain names, contacts, and hosts. 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.kowalik-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. Kowalik & Wullink Expires 3 September 2026 [Page 4] Internet-Draft RPP Data Objects March 2026 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 that has a subordinate relationship to a superordinate domain name object. For example, host name "ns1.example.com" has a subordinate relationship to domain name "example.com". * Superordinate domain: A domain name object to which a host name object is subordinate. * 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. The following terms are defined and used in this document 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 Kowalik & Wullink Expires 3 September 2026 [Page 5] Internet-Draft RPP Data Objects March 2026 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. 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 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. Kowalik & Wullink Expires 3 September 2026 [Page 6] Internet-Draft RPP Data Objects March 2026 2.1.6. Timestamp Timestamp (Date and time attribute) values MUST be represented in Universal Coordinated Time (UTC) using the Gregorian calendar using 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 Aggregation Dictionary in that it maps String keys to primitive values rather than to Component or Resource Objects. 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.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. Kowalik & Wullink Expires 3 September 2026 [Page 7] Internet-Draft RPP Data Objects March 2026 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, and define new operations or extend the inputs and outputs of existing operations with additional transient data elements. 2.3.1. Standardised and Private Extensions RPP distinguishes between standardised and private extensions: * 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. * Extended operation inputs and outputs: Extensions MAY add new transient data elements to the inputs or outputs of existing operations. When an extension adds data elements or transient parameters to a core object or operation, these additions MUST NOT alter the semantics or constraints of existing core data elements. Kowalik & Wullink Expires 3 September 2026 [Page 8] Internet-Draft RPP Data Objects March 2026 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. * 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 - and 1+ for one or more * 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. - 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. 2.5. Operations For each data object a set of possible operations is defined together with their respective input and output data. 2.5.1. Authorisation For each operation authorisation requirements and operation behaviour is 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. Kowalik & Wullink Expires 3 September 2026 [Page 9] Internet-Draft RPP Data Objects March 2026 2.5.2. Uniform interface For the typical set of Create, Read, Update and Delete operations the following set of input and output data model is specified on top of additional transient input data, unless an operation for the specific object tells otherwise. 2.5.2.1. Create * Input: Object (create-only and read-write properties) * Output: Object (read-write and read-only properties) 2.5.2.2. Read * Input: Object identifier * Output: Object (read-write and read-only properties) 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. 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.5.2.3. Update * Input: Object identifier, Object changes (read-write properties) * Output: Object (read-write and read-only properties) 2.5.2.4. Delete * Input: Object identifier * Output: Object (read-write and read-only properties) or nothing 2.5.3. Operations beyond uniform interface For all other operations both input and output have to be fully specified. Kowalik & Wullink Expires 3 September 2026 [Page 10] Internet-Draft RPP Data Objects March 2026 2.5.4. 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. * 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 Owner Data Object the operation is created upon. | TODO: The server MUST notify the current sponsoring client of a | pending transfer request. The notification mechanism is not | defined in this document. | | TODO: Transfer-specific error conditions (object not eligible | for transfer, object pending transfer, object not pending | transfer) are not defined in this document. 2.5.5. 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 3 September 2026 [Page 11] Internet-Draft RPP Data Objects March 2026 * Restore Request: (REQUIRED) Initiates the recovery of an object in the redemptionPeriod 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 pendingRestore. * Restore Report: (OPTIONAL) Submits a report documenting the circumstances of the deletion and restoration, as required by registry policy. This corresponds to the Report 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 pendingRestore state. The Create operation MAY include the restore report inline 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 Owner Data Object the operation is created upon. 2.5.5.1. Redemption Grace Period State Diagram 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, RPP status labels are shown in the status field of the object. Standard EPP-origin status labels (e.g., ok, pendingDelete) are used alongside the RGP-specific labels defined in this document. The and labels refer to the Create and Report operations on the Restore Process Object, replacing the EPP extended command with op=request and op=report attributes. Kowalik & Wullink Expires 3 September 2026 [Page 12] Internet-Draft RPP Data Objects March 2026 | v (2) +----------------------------+ +-------------------------------+ | status: ok (1)|------------->| status: pendingDelete (3)| | | | redemptionPeriod | +----------------------------+ +-------------------------------+ ^ ^ restore, no report | ^ | | | | and report required (4)| | | No (9) | | | | | | restore | | | +------------------+ | | restore | | | v | | v | | +------------------+ | | +-----------------------+ | | | status: (6)| | | | status: (10)| | | | pendingDelete |-----------------+ | | pendingDelete | | | | pendingRestore | report not (7) | | rgpPendingDelete | | | +------------------+ received | +-----------------------+ | | (8) | | | | | report received | | purge (11) | | | | restore (5) | v | +--------------------+ with report | +-----------------------+ | or not req. | | Purged (12)| | | +-----------------------+ +----------------------------------------------+ 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 + redemptionPeriod 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 8 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 redemptionPeriod to its pre-deletion status (1), bypassing the pendingRestore state. 6. The object enters pendingDelete + pendingRestore 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 redemptionPeriod state (step 3). Kowalik & Wullink Expires 3 September 2026 [Page 13] Internet-Draft RPP Data Objects March 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. 2.6. 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. 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. 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. 3.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. Kowalik & Wullink Expires 3 September 2026 [Page 14] Internet-Draft RPP Data Objects March 2026 3.2. Client Identifier Client identifiers are character strings with a specified minimum length, a specified maximum length, and a specified format. Contact 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 modeled are 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. 3.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. 4. Associations RPP allows for different types of associations (relationship) 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: 4.1. Aggregation Notation: Aggregation[Type] A relation between two independent objects. Kowalik & Wullink Expires 3 September 2026 [Page 15] Internet-Draft RPP Data Objects March 2026 If the cardinality of target object is more than 1, this represents an ordered array. It MUST be assured that the same unchanged data is always inserted in the same order in order to allow stable reference by position to data elements. In case of data insertions, deletions or updates the remaining of the data SHALL preserve its order. Example aggregation having cardinality 1: +-------------------+ | (root parent) | |-------------------| | foo: | | | +----------+ | +-------- | [Object] | | | ... | | +----------+ +-------------------+ Example aggregation having cardinality >1: +-------------------+ | (root parent) | |-------------------| | foo: | | +-----[0] +----------+ | | | [Object] | | | | ... | | | +----------+ | +-----[1] +----------+ | | [Object] | | | ... | | +----------+ | ... | +-------------------+ 4.2. Composition Notation: Composition[Type] or Type A relation between an independent parent object and 1 or more dependent child object(s). If the cardinality of target object is more than 1, this represents an ordered array. It MUST be assured that the same unchanged data is always inserted in the same order in order to allow stable reference by position to data elements. In case of data insertions, deletions or updates the remaining of the data SHALL preserve its order. Kowalik & Wullink Expires 3 September 2026 [Page 16] Internet-Draft RPP Data Objects March 2026 Example composition having cardinality 1: +-------------------+ | (root) | |-------------------| | foo: | | | +-------+ | | +--| ... | | | +-------+ | +-------------------+ Example composition having cardinality >1: +-------------------+ | (root) | |-------------------| | foo: | | +-[0] +-------+ | | | | ... | | | | +-------+ | | +-[1] +-------+ | | | | ... | | | | +-------+ | | ... | +-------------------+ 4.3. Labelled Aggregation Notation: LabelledAggregation[Type] A relation between two independent object with 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: Kowalik & Wullink Expires 3 September 2026 [Page 17] Internet-Draft RPP Data Objects March 2026 +--------------------------------+ | (root) | |--------------------------------| | foo: | | | | | +---("label_A")---> +----------+ | | | [Object] | | | | ... | | | +----------+ | +---("label_B")---> +----------+ | | | [Object] | | | | ... | | | +----------+ | +---("label_A")---> +----------+ | | (labels repeat) | [Object] | | | | ... | | | +----------+ | ... | +--------------------------------+ 4.4. Dictionary Aggregation Notation: DictionaryAggregation[Type] A relation between two independent object with single text string attribute. Association labels MUST be unique allowing it to be used as 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 Aggregation: +--------------------------+ | (root) | |--------------------------| | foo: | | "key1" -> +-----------+ | | [Object] | | | ... | | +-----------+ | "key2" -> +-----------+ | | [Object] | | | ... | | +-----------+ | ... | +--------------------------+ Kowalik & Wullink Expires 3 September 2026 [Page 18] Internet-Draft RPP Data Objects March 2026 4.5. Labelled Composition Notation: LabelledComposition[Type] A relation between an independent parent object and a dependent child object with 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: +-------------------------------------+ | (root parent) | |-------------------------------------| | foo: | | | | | +---("label_A")---> +----------+ | | | | [Child] | | | | | ... | | | | +----------+ | | +---("label_B")---> +----------+ | | | | [Child] | | | | | ... | | | | +----------+ | | +---("label_A")---> +----------+ | | | (labels repeat) | [Child] | | | | | ... | | | | +----------+ | | ... | +-------------------------------------+ 4.6. Dictionary Composition Notation: DictionaryComposition[Type] A relation between an independent parent object and a dependent child object with single text string attribute. Only single association with the same label is allowed allowing it to be used as 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 3 September 2026 [Page 19] Internet-Draft RPP Data Objects March 2026 +--------------------------+ | (root) | |--------------------------| | foo: | | "key1" -> +---------+ | | | [Child] | | | | ... | | | +---------+ | | "key2" -> +---------+ | | | [Child] | | | | ... | | | +---------+ | | ... | +--------------------------+ 5. Component Objects This section defines the Component Objects used in this document. 5.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). 5.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 3 September 2026 [Page 20] Internet-Draft RPP Data Objects March 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 3 September 2026 [Page 21] Internet-Draft RPP Data Objects March 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. 5.3. Status Object * Name: Status Object * Identifier: status * Description: Represents one of the status values associated with a provisioning 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: + Exact list of allowed status labels depends on the provisioning object type. This enumeration can be expanded by extensions. + The status labels MUST use camel case notation and use only ASCII alphabetic characters. + Statuses MAY be of three categories: 1. those explicitly set by a server. Those MUST have "server" prefix 2. those explicitly set by a client. Those MUST have "client" prefix 3. those indirectly controlled by provisioning object lifecycle or business logic. Those MUST NOT use either "client" or "server" prefix. They MAY use another prefix or no prefix at all + The following additional status labels are defined for use with the Redemption Grace Period (RGP) feature. When the RGP feature is supported, these labels MAY be specified: Kowalik & Wullink Expires 3 September 2026 [Page 22] Internet-Draft RPP Data Objects March 2026 + addPeriod: The object is within the add grace period following initial registration. If the object is deleted during this period, the registry MAY provide a credit to the sponsoring client. + autoRenewPeriod: The object is within the auto-renew grace period following automatic renewal by the registry. If the object is deleted during this period, the registry MAY provide a credit to the sponsoring client. + renewPeriod: The object is within the renew grace period following an explicit renewal. If the object is deleted during this period, the registry MAY provide a credit to the sponsoring client. + transferPeriod: The object is within the transfer grace period following a successful transfer. If the object is deleted by the new sponsoring client during this period, the registry MAY provide a credit. + redemptionPeriod: A delete operation has been received and processed for the object, but the object has not yet been purged. A restore operation MAY be requested to abort the deletion. This status value MUST only appear alongside the standard pendingDelete status. + pendingRestore: A restore request has been accepted and the registry is waiting for a restore report from the sponsoring client. This status value MUST only appear alongside the standard pendingDelete status. + rgpPendingDelete: The redemption period has elapsed without a successful restore. The object has entered the purge processing state. This status value MUST only appear alongside the standard pendingDelete status. This label is used to distinguish the RGP-specific pending- delete sub-state from the broader EPP pendingDelete status. | TODO: find a better home for this list (own section + IANA | registry). Add standard domain statuses here as well (and | solve the issue of statuses not applicable to other object | types like client/serverHold). * Reason - Identifier: reason - Cardinality: 0-1 - Mutability: create-only - Data Type: String - Description: a human-readable text that describes the rationale for the status applied to the object. - Constraints: None * Due - Identifier: due Kowalik & Wullink Expires 3 September 2026 [Page 23] Internet-Draft RPP Data Objects March 2026 - Cardinality: 0-1 - Mutability: read-write - Data Type: Timestamp - 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. - Constraints: servers MAY restrict possibility to set or update this value by the client. | TBD: Idea - model status object as Labelled Composition using | "Label"? Con: Generic Constraints for Label will be repeated. 5.4. 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 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]. Kowalik & Wullink Expires 3 September 2026 [Page 24] Internet-Draft RPP Data Objects March 2026 + 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 lower case. + 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 5.4.1 for required structures in the EPP Compatibility Profile. 5.4.1. RDATA Structures in EPP Profile This section defines the RDATA field structures required for interoperability in the EPP Compatibility Profile. In EPP Compatibility Profile ([RFC5732]), the following RDATA structures MUST be supported: Kowalik & Wullink Expires 3 September 2026 [Page 25] Internet-Draft RPP Data Objects March 2026 * For NS records ([RFC1035], Section 3.3.11): nsdname (the fully qualified domain name of the name server). * 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. 5.5. 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 lower-case 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 lower case. + The values MUST be positive Integers. + The allowed value ranges MAY be constrained by server policy. Kowalik & Wullink Expires 3 September 2026 [Page 26] Internet-Draft RPP Data Objects March 2026 + 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 lower case. + 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. 5.6. 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: Composition[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. + In EPP Compatibility Profile with DNSSEC Extension [RFC5910], records of type DS and DNSKEY MUST be supported in addition to NS, A, and AAAA. Kowalik & Wullink Expires 3 September 2026 [Page 27] Internet-Draft RPP Data Objects March 2026 + 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) 5.7. Authorisation Information Object * Name: Authorisation Information * Identifier: authInfo * Description: Contains information used to authorise operations on a data object. It may hold different kind 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 base 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 password string, but also more complex values like public key certificates or tokens encoded as string are possible. o Constraints: + Authorisation Information object is immutable. If the information changes (for example password is updated) a new instance MUST be created. Kowalik & Wullink Expires 3 September 2026 [Page 28] Internet-Draft RPP Data Objects March 2026 + Depending on the method and server policy Authorisation Information MAY not be available for read or any other operation responding with this data element. 5.8. Postal Address Object * Name: Postal Address Object * Identifier: postalData * Description: Contains the components of a postal address. * Data Elements: - Street o Identifier: street o Cardinality: 0+ o Mutability: read-write o Data Type: String o Description: The contact's street address. o Constraints: Implementations MAY limit the maximum length of entries or character set. - City o Identifier: city o Cardinality: 0-1 o Mutability: read-write o Data Type: String o Description: The contact's city. o Constraints: + Implementations MAY limit the maximum length of entries or character set. + In EPP Compatibility Profile this data element MUST be provided. - State/Province o Identifier: sp o Cardinality: 0-1 o Mutability: read-write o Data Type: String o Description: The contact's state or province. o Constraints: Implementations MAY limit the maximum length of entries or character set. - Postal Code o Identifier: pc o Cardinality: 0-1 o Mutability: read-write o Data Type: String o Description: The contact's postal code. o Constraints: + Implementation MAY limit the maximum length of entries or character set. + The limitations MAY differ depending on Country Code (cc) data element. Kowalik & Wullink Expires 3 September 2026 [Page 29] Internet-Draft RPP Data Objects March 2026 - Country Code o Identifier: cc o Cardinality: 0-1 o Mutability: read-write o Data Type: String o Description: The contact's country code. o Constraints: + The value MUST be a two-character identifier from [ISO3166-1]. + In EPP Compatibility Profile this data element MUST be provided. 5.9. Postal Info Object * Name: Postal Info Object * Identifier: postalInfo * Description: Contains postal-address information in either internationalised or localised forms. * Data Elements: | TBC: Contact Type is not localised (shall be the same for | PERSON and ORG). Moving it level up would however detach it | from related/dependant fields Name/Organisation * Contact Type - Identifier: type - Cardinality: 0-1 - Mutability: read-write - Data Type: String - Description: Specifies whether the contact is and individual or an organisation. - Constraints: The value MUST be one of: "PERSON" (individual) or "ORG" (organisation). * Name - Identifier: name - Cardinality: 0-1 - Mutability: read-write - Data Type: String - Description: The name of the individual or role. - Constraints: o Implementations MAY limit the maximum length of entries or character set. o In EPP Compatibility Profile this data element MUST be provided. o The implementations MAY require this field if Contact Type (type) is set to "PERSON". * Organisation - Identifier: org Kowalik & Wullink Expires 3 September 2026 [Page 30] Internet-Draft RPP Data Objects March 2026 - Cardinality: 0-1 - Mutability: read-write - Data Type: String - Description: The name of the organisation. - Constraints: o Implementations MAY limit the maximum length of entries or character set. o The implementations MAY require this field if Contact Type (type) is set to "ORG". * Address - Identifier: addr - Cardinality: 0-1 - Mutability: read-write - Data Type: Postal Address Object - Description: The detailed postal address. - Constraints: In EPP Compatibility Profile this data element MUST be provided. 5.10. Disclose Object | TODO: Model Disclose in universal (extendible) way * Name: Disclose * Identifier: disclose * Description: TBD 5.11. 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 Kowalik & Wullink Expires 3 September 2026 [Page 31] Internet-Draft RPP Data Objects March 2026 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 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: 0+ o Mutability: read-write o Data Type: String o Description: Client statements required by the RGP process. o Constraints: At least one and at most two statements MUST be provided. 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 Kowalik & Wullink Expires 3 September 2026 [Page 32] Internet-Draft RPP Data Objects March 2026 o Data Type: String o Description: Any additional information needed to support the statements provided by the client. o Constraints: None. 6. Process Objects This section defines the Process Objects used in this document. 6.1. Transfer Process Object * Name: Transfer Process Object * Identifier: transferProcess * 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 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. Kowalik & Wullink Expires 3 September 2026 [Page 33] Internet-Draft RPP Data Objects March 2026 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 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) 6.1.1. Operations 6.1.1.1. Create (Transfer Request) * Identifier: create Kowalik & Wullink Expires 3 September 2026 [Page 34] Internet-Draft RPP Data Objects March 2026 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: - Owner Data Object reference - Transfer Process Object (create-only and read-write elements) * Output: Transfer Process Object 6.1.1.2. Read (Transfer Query) * Identifier: read 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. * Input: None * Output: Transfer Process Object 6.1.1.3. Delete (Transfer Cancel) * Identifier: delete The Delete operation allows the initiating client to cancel its own pending transfer request. * Authorisation: Kowalik & Wullink Expires 3 September 2026 [Page 35] Internet-Draft RPP Data Objects March 2026 - Only the initiating client (the client that originally requested the transfer). * Input: None * Output: Transfer Process Object or nothing 6.1.1.4. Approve * Identifier: approve 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: None * Output: Transfer Process Object 6.1.1.5. Reject * Identifier: reject 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 The following transient data elements are defined for this operation: * Reason - Identifier: reason - Cardinality: 0-1 - Data Type: String - Description: A human-readable text describing the rationale for rejecting the transfer request. Kowalik & Wullink Expires 3 September 2026 [Page 36] Internet-Draft RPP Data Objects March 2026 - Constraints: In EPP Compatibility Profile this data element MUST NOT be used * Output: Transfer Process Object 6.2. Restore Process Object * Name: Restore Process Object * Identifier: restoreProcess * 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. 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 redemptionPeriod state. Only present when the object is in pendingRestore state. Kowalik & Wullink Expires 3 September 2026 [Page 37] Internet-Draft RPP Data Objects March 2026 o Constraints: MUST NOT be present when restoreStatus is not "pendingRestore". 6.2.1. Operations 6.2.1.1. Create (Restore Request) * Identifier: create The Create operation initiates the recovery of an object in the redemptionPeriod state by creating a Restore Process Object. The server MUST reject this operation if the owning object is not in the redemptionPeriod state. * Input: Restore Process Object (create-only and read-write elements) * Output: Restore Process Object * Authorisation: - Only the sponsoring client is authorised to perform this operation. The following transient data elements are defined for this operation: * 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. - Constraints: o MUST NOT be provided if the server does not require a restore report. o In EPP Compatibility Profile, corresponds to op="request" (without report) or a combined op="request" followed immediately by op="report" as defined in [RFC3915]. 6.2.1.2. Read (Restore Query) * Identifier: read Kowalik & Wullink Expires 3 September 2026 [Page 38] Internet-Draft RPP Data Objects March 2026 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: Object Identifier * Output: Restore Process Object In EPP Compatibility Profile this operation is not supported. 6.2.1.3. Report * Identifier: report This operation is OPTIONAL, only for servers which support or require submission of a restore report. The Report operation submits the restore report required by the RGP process for an object in the pendingRestore state. 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 pendingRestore state. * Input: Object Identifier, Restore Report Object * Output: Restore Process Object * Authorisation: - Only the sponsoring client is authorised to perform this operation. The following transient data elements are defined for this operation: * 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: o In EPP Compatibility Profile, corresponds to op="report" as defined in [RFC3915]. Kowalik & Wullink Expires 3 September 2026 [Page 39] Internet-Draft RPP Data Objects March 2026 7. Domain Name Data Object 7.1. Object Description * Name: Domain Name Data Object * Identifier: domainName * Description: A Domain Name data object represents a domain name and contains the data required for its provisioning and management in the registry. 7.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: String - Description: The fully qualified name of the domain object. - Constraints: o The value MUST be a fully qualified domain name that conforms to the syntax described in [RFC1035]. 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 The trailing dot required when these names are stored in a DNS zone is implicit and MUST NOT be provided when exchanging host and domain names. * 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: 0+ - Mutability: read-only - Data Type: Status Object Kowalik & Wullink Expires 3 September 2026 [Page 40] Internet-Draft RPP Data Objects March 2026 - Description: The current status descriptors associated with the domain. - Constraints: o Possible combinations of Status Object Labels is specified in Section 2.3 of [RFC5731]. | TBC: IANA registry for statuses? * Registrant - Identifier: registrant - Cardinality: 0-1 - Mutability: read-write - Data Type: Contact 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 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 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 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] Kowalik & Wullink Expires 3 September 2026 [Page 41] Internet-Draft RPP Data Objects March 2026 - Description: A collection of nameservers associated with the domain. - Constraints: (None) * DNS Data - 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. * 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. Kowalik & Wullink Expires 3 September 2026 [Page 42] Internet-Draft RPP Data Objects March 2026 - Constraints: The value is set by the server and cannot be specified by the client. * Authorisation Information - Identifier: authInfo - Cardinality: 0-1 - Mutability: read-write - Data Type: Authorisation Information Object - Description: Authorisation information associated with the domain object. - Constraints: (None) 7.3. Operations 7.3.1. 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. In addition, the following transient data element is defined for this operation: * Registration Period - Identifier: period - Cardinality: 0-1 - Data Type: Period Object. - Description: The initial registration period for the domain name. This value is used by the server to calculate the initial expiryDate of the object. This element is not persisted as part of the object's state. 7.3.2. 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. Kowalik & Wullink Expires 3 September 2026 [Page 43] Internet-Draft RPP Data Objects March 2026 * 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 The following transient data elements are defined for this operation: * Hosts Filter - Identifier: hostsFilter - Cardinality: 0-1 - Data Type: String - Description: Controls which host information is returned with the object. - Constraints: The value MUST be one of "all", "del" (delegated), "sub" (subordinate), or "none". The default value is "all". 7.3.3. Update Operation 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 The following transient data elements are defined for this operation: * Urgent - Identifier: urgent - Cardinality: 0-1 - Data Type: Boolean - Description: Requests that the server operator process and implement the update with high priority. "High priority" is relative to standard server operator policies determined using an out-of-band mechanism. In EPP Compatibility Profile this corresponds to the "urgent" attribute of the element defined in [RFC5910]. The default value is false. - Constraints: o A server that does not support this parameter MUST return an error if it is set to true. o A server that supports this parameter but cannot fulfil a specific urgent request MUST return an error. Kowalik & Wullink Expires 3 September 2026 [Page 44] Internet-Draft RPP Data Objects March 2026 7.3.4. 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. 7.3.5. Renew Operation * Identifier: renew The Renew operation allows a client to extend the validity period of 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 * Input: Domain Name * Output: Full object (read-write and read-only properties), or a minimum set of properties affected by the operation (Expiry Date). The following transient data elements are defined for this operation: * Current Expiry Date - Identifier: currentExpiryDate - Cardinality: 1 - Data Type: Timestamp - Description: The current expiry date of the domain name. The server MUST validate this against the object's current expiryDate to prevent unintended duplicate renewals. * Renewal Period - Identifier: renewalPeriod Kowalik & Wullink Expires 3 September 2026 [Page 45] Internet-Draft RPP Data Objects March 2026 - Cardinality: 0-1 - Data Type: Period Object - 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. 7.3.6. Transfer Operations The Domain Name Data Object supports the common transfer operations defined in the Section 2.5.4. The transfer of a domain name changes the sponsoring client of the domain object. Transfer of a domain object MUST implicitly transfer all host 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. In addition to the common Transfer Process Object elements, the following object-specific create-only data element is defined and can be provided when creating a Transfer Process Object for a domain name: * Transfer Period - Identifier: transferPeriod - Cardinality: 0-1 - Mutability: create-only - Data Type: Period Object - 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. - Constraints: (None) In addition to the common Transfer Process Object elements, the following object-specific read-only data element is included in the output of domain transfer operations: * Expiry Date - Identifier: expiryDate - Cardinality: 0-1 - Mutability: read-only - Data Type: Timestamp - Description: The end of the domain object's registration period if the transfer caused or causes a change in the validity period. Kowalik & Wullink Expires 3 September 2026 [Page 46] Internet-Draft RPP Data Objects March 2026 Subordinate host objects MUST be transferred implicitly when the domain object is transferred. 7.3.7. Restore Operations The Domain Name Data Object supports the restore operations defined in the section. These operations are OPTIONAL and are only available when the RGP feature is supported. No domain-specific transient data elements extend the common restore operations beyond those defined in the Section 2.5.5. 8. Contact Data Object 8.1. Object Description * Name: Contact Data Object * Identifier: contact * Description: A Contact Data Object represents the social information for an individual or organisation associated with other objects. 8.2. Data Elements The following data elements are defined for the Domain Name 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) Kowalik & Wullink Expires 3 September 2026 [Page 47] Internet-Draft RPP Data Objects March 2026 * Status - Identifier: status - Cardinality: 0+ - Mutability: read-only - Data Type: Status Object - Description: The current status descriptors associated with the contact. - Constraints: o Possible combinations of Domain Status Labels is specified in Section 2.2 of [RFC5733] o The value MUST be one of the status tokens defined in the IANA registry for domain statuses. o The initial value list MAY be as defined in [RFC5733]. In this case the values MUST have the same semantics. * Postal Information - Identifier: postalInfo - Cardinality: 1-2 - Mutability: read-write - Data Type: DictionaryAggregation[Postal Info Object] o Label Description: type of contact data localisation o Label Constraints: Allowed values: "int" for "internationalised" all-ASCII version of an address and "loc" for localised forms with possible non-ASCII character sets. - Description: Contains postal-address information. - Constraints: There MUST be no more that 1 element of type "int" and one element of type "loc". * Voice Phone Number - Identifier: voice - Cardinality: 0+ - Mutability: read-write - Data Type: Phone Number - Description: Voice phone number associated with the contact - Constraints: (None) * Fax Phone Number - Identifier: fax - Cardinality: 0+ - Mutability: read-write - Data Type: Phone Number - Description: Fax number associated with the contact - Constraints: (None) Kowalik & Wullink Expires 3 September 2026 [Page 48] Internet-Draft RPP Data Objects March 2026 * E-mail - Identifier: email - Cardinality: 0+ - Mutability: read-write - Data Type: String. - Description: The contact's email address. - Constraints: Email address syntax is defined in [RFC5322]. * Authorisation Information - Identifier: authInfo - Cardinality: 0-1 - Mutability: read-write - Data Type: Authorisation Information - 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. | TBC: IANA registry for statuses? 8.3. Operations 8.3.1. Create Operation 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: Kowalik & Wullink Expires 3 September 2026 [Page 49] Internet-Draft RPP Data Objects March 2026 * Handle ID (id) * At least one Postal Information entry (postalInfo) containing a Name (name) and an Address (addr) with City (city) and Country Code (cc) * E-mail (email) * Authorisation Information (authInfo) 8.3.2. Read Operation 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. 8.3.3. Update Operation 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: * Status values that are client-manageable (prefixed with "client") MAY be added or removed. Kowalik & Wullink Expires 3 September 2026 [Page 50] Internet-Draft RPP Data Objects March 2026 * Postal Information, Voice Phone Number, Fax Phone Number, E-mail, Authorisation Information, and Disclose preferences MAY be changed. 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. 8.3.4. Delete Operation 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. 8.3.5. Transfer Operations The Contact Data Object supports the common transfer operations defined in the Section 2.5.4. The transfer of a contact changes the sponsoring client of the contact object. No object-specific transient data elements are defined for contact transfer operations beyond the common transfer data elements. 9. Host Data Object 9.1. Object Description * Name: Host Data Object * Identifier: host * Description: A Host Data Object represents a name server that provides DNS services for a domain name. 9.2. Data Elements The following data elements are defined for the Host Data Object. * Host Name Kowalik & Wullink Expires 3 September 2026 [Page 51] Internet-Draft RPP Data Objects March 2026 - Identifier: hostName - Cardinality: 1 - Mutability: read-write - Data Type: String - Description: Fully qualified name of a host. - Constraints: The value MUST be a syntactically valid host name. * 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: 0+ - Mutability: read-only - Data Type: Status Object - Description: The current status descriptors associated with the host. - Constraints: Possible combinations of Host Status Labels is specified in Section 2.3 of [RFC5732] * DNS Data - Identifier: dns - Cardinality: 0-1 - Mutability: read-write - Data Type: DNS Data Object - 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. 9.3. Operations Kowalik & Wullink Expires 3 September 2026 [Page 52] Internet-Draft RPP Data Objects March 2026 9.3.1. Create Operation 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. 9.3.2. Read Operation 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]. 9.3.3. Update Operation 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 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 name servers. Kowalik & Wullink Expires 3 September 2026 [Page 53] Internet-Draft RPP Data Objects March 2026 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. 9.3.4. Delete Operation 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. 9.3.5. Restore Operations The Host Data Object supports the restore operations defined in the Section 2.5.5. These operations are OPTIONAL and are only available when the RGP feature for Host Data Object is supported by the server. No domain-specific transient data elements extend the common restore operations beyond those defined in the Section 2.5.5. 10. IANA Considerations 10.1. RPP Data Object Registry 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. Kowalik & Wullink Expires 3 September 2026 [Page 54] Internet-Draft RPP Data Objects March 2026 10.1.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 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. 10.1.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), a brief description, and a reference to its defining specification. * 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. - A "Parameters" table listing all data elements that are provided as input to the operation but are not persisted as part of the object's state. 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, 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. Kowalik & Wullink Expires 3 September 2026 [Page 55] Internet-Draft RPP Data Objects March 2026 10.1.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 +============+=========+=====+============+=========+=============+ | 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 1 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 3 September 2026 [Page 56] Internet-Draft RPP Data Objects March 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 2 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 3 September 2026 [Page 57] Internet-Draft RPP Data Objects March 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 | | | | | | |lower-case | | | | | | |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 3 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 3 September 2026 [Page 58] Internet-Draft RPP Data Objects March 2026 +==========+========+=====+============+=============+==============+ |Element |Element |Card.| Mutability | Data Type | Description | |Identifier|Name | | | | | +==========+========+=====+============+=============+==============+ |records |Records |0+ | read-write | Composition | An array of | | | | | | [DNS | DNS | | | | | | Resource | resource | | | | | | Record | records | | | | | | Object] | associated | | | | | | | with the | | | | | | | provisioned | | | | | | | object. | +----------+--------+-----+------------+-------------+--------------+ |controls |Controls|0-1 | read-write | DNS | Operational | | | | | | Operational | control | | | | | | Controls | parameters | | | | | | Object | for the DNS | | | | | | | records. | +----------+--------+-----+------------+-------------+--------------+ Table 4 Object: authInfo Object Name: Authorisation Information Object Type: Component Description: Contains authorisation credentials for an operation. Reference: [This-ID] Data Elements Kowalik & Wullink Expires 3 September 2026 [Page 59] Internet-Draft RPP Data Objects March 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 | | | | | | | password | | | | | | | string, but | | | | | | | also more | | | | | | | complex | | | | | | | values like | | | | | | | public key | | | | | | | certificates | | | | | | | or tokens | | | | | | | encoded as | | | | | | | string are | | | | | | | possible. | +----------+-------------+-----+-----------+------+-----------------+ Table 5 Object: status Object Name: Status Object Object Type: Component Description: Represents one of the status values associated with the provisioning object. Reference: [This-ID] Data Elements Kowalik & Wullink Expires 3 September 2026 [Page 60] Internet-Draft RPP Data Objects March 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 6 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 3 September 2026 [Page 61] Internet-Draft RPP Data Objects March 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 7 Object: transferProcess Kowalik & Wullink Expires 3 September 2026 [Page 62] Internet-Draft RPP Data Objects March 2026 Object Name: Transfer Process Object Object Type: Process 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 | | | | | | |of the | | | | | | |client that| Kowalik & Wullink Expires 3 September 2026 [Page 63] Internet-Draft RPP Data Objects March 2026 | | | | | |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 8 Operations Operation: Create Operation Identifier: create Description: Initiates a transfer of a Domain Name resource by creating a Transfer Process Object. Transfer direction and gaining client are provided as create-only data elements. Parameters Kowalik & Wullink Expires 3 September 2026 [Page 64] Internet-Draft RPP Data Objects March 2026 +================+==========+=======+========+=====================+ | Identifier | Name | Card. | Data | Description | | | | | Type | | +================+==========+=======+========+=====================+ | transferPeriod | Transfer | 0-1 | period | The duration to add | | | Period | | | to the registration | | | | | | period upon | | | | | | transfer. | +----------------+----------+-------+--------+---------------------+ Table 9 Operation: Transfer Read Operation Identifier: read Description: Queries the status of a transfer of a Domain Name resource. Parameters: (None) Operation: Transfer Delete Operation Identifier: delete Description: Cancels a pending transfer of a Domain Name resource. Parameters: (None) Operation: Transfer Approve Operation Identifier: approve Description: Approves a pending transfer of a Domain Name resource. Parameters: (None) Operation: Transfer Reject Operation Identifier: reject (on Transfer Process Object) Description: Rejects a pending transfer of a Domain Name resource. Parameters Kowalik & Wullink Expires 3 September 2026 [Page 65] Internet-Draft RPP Data Objects March 2026 +============+========+=======+========+==========================+ | Identifier | Name | Card. | Data | Description | | | | | Type | | +============+========+=======+========+==========================+ | reason | Reason | 0-1 | String | A human-readable text | | | | | | describing the rationale | | | | | | for rejection. | +------------+--------+-------+--------+--------------------------+ Table 10 | TODO: IANA table: Postal Address Object TODO: IANA table: | Postal Info Object TODO: IANA table: Disclose Object Object: restoreProcess Object Name: Restore Process Object Object Type: Process 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 3 September 2026 [Page 66] Internet-Draft RPP Data Objects March 2026 +=============+=======+=====+==========+=========+=================+ |Element |Element|Card.|Mutability|Data Type|Description | |Identifier |Name | | | | | +=============+=======+=====+==========+=========+=================+ |restoreStatus|Restore|1 |read-only |String |The current state| | |Status | | | |of 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 | | |Date | | | |restore report | | | | | | |before the object| | | | | | |reverts to | | | | | | |redemptionPeriod.| | | | | | |Present only when| | | | | | |status is | | | | | | |pendingRestore. | +-------------+-------+-----+----------+---------+-----------------+ Table 11 Operations Operation: Restore Create Operation Identifier: create Description: Initiates recovery of a domain name in the redemptionPeriod state by creating a Restore Process Object. This operation is OPTIONAL and is only available when the RGP feature is supported. Kowalik & Wullink Expires 3 September 2026 [Page 67] Internet-Draft RPP Data Objects March 2026 Parameters +===============+=========+=======+===============+=================+ | Identifier | Name | Card. | Data Type | Description | +===============+=========+=======+===============+=================+ | restoreReport | Restore | 0-1 | Restore | An inline | | | Report | | Report Object | restore | | | | | | report. | +---------------+---------+-------+---------------+-----------------+ Table 12 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. Parameters: (None) Operation: Restore Report Operation Identifier: report Description: Submits the restore report for a domain name in the pendingRestore state. This operation is OPTIONAL and is only available when the RGP feature is supported and the server requires a restore report. Parameters +===============+=========+=======+===============+==============+ | Identifier | Name | Card. | Data Type | Description | +===============+=========+=======+===============+==============+ | restoreReport | Restore | 1 | Restore | The restore | | | Report | | Report Object | report to be | | | | | | submitted. | +---------------+---------+-------+---------------+--------------+ Table 13 Object: restoreReport Object Name: Restore Report Object Object Type: Component Kowalik & Wullink Expires 3 September 2026 [Page 68] Internet-Draft RPP Data Objects March 2026 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 | | | | | | |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 | Kowalik & Wullink Expires 3 September 2026 [Page 69] Internet-Draft RPP Data Objects March 2026 | | | | | |the server. | +-------------+------------+-----+----------+---------+-------------+ |restoreReason|Restore |0-1 |read-write|String |A brief | | |Reason | | | |explanation | | | | | | |of the | | | | | | |reason for | | | | | | |restoring | | | | | | |the object. | +-------------+------------+-----+----------+---------+-------------+ |statements |Statements |0+ |read-write|String |Mandatory | | | | | | |client | | | | | | |statements | | | | | | |required by | | | | | | |the RGP | | | | | | |process. At | | | | | | |least one | | | | | | |and at most | | | | | | |two | | | | | | |statements | | | | | | |MUST be | | | | | | |provided. | +-------------+------------+-----+----------+---------+-------------+ |other |Other |0-1 |read-write|String |Any | | | | | | |additional | | | | | | |information | | | | | | |needed to | | | | | | |support the | | | | | | |statements | | | | | | |provided by | | | | | | |the client. | +-------------+------------+-----+----------+---------+-------------+ Table 14 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 Kowalik & Wullink Expires 3 September 2026 [Page 70] Internet-Draft RPP Data Objects March 2026 +================+=============+=====+==========+===================+=============+ |Identifier |Name |Card.|Mutability|Data Type |Description | +================+=============+=====+==========+===================+=============+ |name |Name |1 |create- |String |The fully | | | | |only | |qualified | | | | | | |name of the | | | | | | |domain | | | | | | |object. | +----------------+-------------+-----+----------+-------------------+-------------+ |provMetadata |Provisioning |1 |read-only |Provisioning |Standard | | |Metadata | | |Metadata Object |metadata | | | | | | |about object | | | | | | |lifecycle and| | | | | | |ownership. | +----------------+-------------+-----+----------+-------------------+-------------+ |status |Status |0+ |read-only |Status Object |The current | | | | | | |status | | | | | | |descriptors | | | | | | |for the | | | | | | |domain. | +----------------+-------------+-----+----------+-------------------+-------------+ |registrant |Registrant |0-1 |read-write|Contact Object |The | | | | | | |registrant | | | | | | |contact ID. | +----------------+-------------+-----+----------+-------------------+-------------+ |contacts |Contacts |0+ |read-write|LabelledAggregation|Associated | | | | | |[Contact Object] |contact | | | | | | |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 | Kowalik & Wullink Expires 3 September 2026 [Page 71] Internet-Draft RPP Data Objects March 2026 | | | | | |timestamp. | +----------------+-------------+-----+----------+-------------------+-------------+ |authInfo |Authorisation|0-1 |read-write|authInfo |Authorisation| | |Info | | | |information | | | | | | |for the | | | | | | |object. | +----------------+-------------+-----+----------+-------------------+-------------+ Table 15 Operations Operation: Create Operation Identifier: create Description: Provisions a new Domain Name resource. Parameters +============+==============+=======+========+======================+ | Identifier | Name | Card. | Data | Description | | | | | Type | | +============+==============+=======+========+======================+ | period | Registration | 0-1 | period | The initial | | | Period | | | registration | | | | | | period for the | | | | | | domain name. | +------------+--------------+-------+--------+----------------------+ Table 16 Operation: Read Operation Identifier: read Description: Retrieves the data elements of a Domain Name resource. Parameters Kowalik & Wullink Expires 3 September 2026 [Page 72] Internet-Draft RPP Data Objects March 2026 +===============+===============+=======+==========+================+ | Identifier | Name | Card. | Data | Description | | | | | Type | | +===============+===============+=======+==========+================+ | hostsFilter | Hosts Filter | 0-1 | String | Controls | | | | | | which host | | | | | | information | | | | | | is returned. | +---------------+---------------+-------+----------+----------------+ | queryAuthInfo | Query | 0-1 | authInfo | Credentials | | | Authorisation | | | to authorise | | | Information | | | access to | | | | | | full object | | | | | | data. | +---------------+---------------+-------+----------+----------------+ Table 17 Operation: Update Description: Modifies the read-write data elements of a Domain Name resource. Parameters +============+========+=======+=========+========================+ | Identifier | Name | Card. | Data | Description | | | | | Type | | +============+========+=======+=========+========================+ | urgent | Urgent | 0-1 | Boolean | Requests high-priority | | | | | | processing of the | | | | | | update by the server. | +------------+--------+-------+---------+------------------------+ Table 18 Operation: Delete Operation Identifier: delete Description: Removes an existing Domain Name resource. Parameters: (None) Operation: Renew Operation Identifier: renew Kowalik & Wullink Expires 3 September 2026 [Page 73] Internet-Draft RPP Data Objects March 2026 Description: Extends the validity period of a Domain Name resource. Parameters +===================+=========+=======+===========+================+ | Identifier | Name | Card. | Data Type | Description | +===================+=========+=======+===========+================+ | currentExpiryDate | Current | 1 | Timestamp | The expected | | | Expiry | | | current expiry | | | Date | | | date, for | | | | | | validation. | +-------------------+---------+-------+-----------+----------------+ | renewalPeriod | Renewal | 0-1 | period | The duration | | | Period | | | to add to the | | | | | | registration | | | | | | period. | +-------------------+---------+-------+-----------+----------------+ Table 19 | TODO: IANA table: Contact Data Object Object: host Object Name: Host Data Object Object Type: Resource Description: Represents a name server that provides DNS services for a domain name. Reference: [This-ID] Data Elements Kowalik & Wullink Expires 3 September 2026 [Page 74] Internet-Draft RPP Data Objects March 2026 +============+============+=====+==========+============+===========+ |Identifier |Name |Card.|Mutability|Data Type |Description| +============+============+=====+==========+============+===========+ |hostName |Host Name |1 |read-write|String |Fully | | | | | | |qualified | | | | | | |name of a | | | | | | |host. | +------------+------------+-----+----------+------------+-----------+ |provMetadata|Provisioning|1 |read-only |Provisioning|Standard | | |Metadata | | |Metadata |metadata | | | | | |Object |about | | | | | | |object | | | | | | |lifecycle | | | | | | |and | | | | | | |ownership. | +------------+------------+-----+----------+------------+-----------+ |status |Status |0+ |read-only |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. | +------------+------------+-----+----------+------------+-----------+ Table 20 Operations Operation: Create Description: Provisions a new Host Data Object. Parameters: (None) Operation: Read Description: Retrieves the data elements of a Host Data Object. Parameters: (None) Operation: Update Kowalik & Wullink Expires 3 September 2026 [Page 75] Internet-Draft RPP Data Objects March 2026 Description: Modifies the attributes of a Host Data Object. Parameters: (None) Operation: Delete Description: Removes an existing Host Data Object. Parameters: (None) 11. Security Considerations | TODO: write security considerations, if any 12. Changes History 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 * 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 Kowalik & Wullink Expires 3 September 2026 [Page 76] Internet-Draft RPP Data Objects March 2026 draft-kowalik-rpp-data-objects -01 - -02 * ontology of allowed basic datatypes #4 * add examples of associations #31 13. References 13.1. Normative References [I-D.ietf-rpp-architecture] Kowalik, P. and M. Wullink, "RPP Architecture", Work in Progress, Internet-Draft, draft-ietf-rpp-architecture-01, 27 February 2026, . [I-D.kowalik-rpp-architecture] Kowalik, P. and M. Wullink, "RPP Architecture", Work in Progress, Internet-Draft, draft-kowalik-rpp-architecture- 03, 10 October 2025, . [ISO3166-1] International Organization for Standardization, "Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes", ISO Standard 3166, November 2000. [ITU.E164.2005] International Telecommunication Union, "The international public telecommunication numbering plan", ITU-T Recommendation E.164, February 2005. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, DOI 10.17487/RFC1738, December 1994, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Kowalik & Wullink Expires 3 September 2026 [Page 77] Internet-Draft RPP Data Objects March 2026 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC3915] Hollenbeck, S., "Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)", RFC 3915, DOI 10.17487/RFC3915, September 2004, . [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, . [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, . [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain Name Mapping", STD 69, RFC 5731, DOI 10.17487/RFC5731, August 2009, . [RFC5732] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Host Mapping", STD 69, RFC 5732, DOI 10.17487/RFC5732, August 2009, . [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733, August 2009, . [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 13.2. Informative References Kowalik & Wullink Expires 3 September 2026 [Page 78] Internet-Draft RPP Data Objects March 2026 [I-D.simmen-rpp-dns-data] Simmen, C. and P. Kowalik, "DNS data representation for use in RESTful Provisioning Protocol (RPP)", Work in Progress, Internet-Draft, draft-simmen-rpp-dns-data-01, 20 October 2025, . [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", STD 88, RFC 3596, DOI 10.17487/RFC3596, October 2003, . [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, . [RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)", RFC 5910, DOI 10.17487/RFC5910, May 2010, . Authors' Addresses Pawel Kowalik DENIC Email: pawel.kowalik@denic.de URI: https://denic.de/ Maarten Wullink SIDN Labs Email: maarten.wullink@sidn.nl URI: https://sidn.nl/ Kowalik & Wullink Expires 3 September 2026 [Page 79]