Network Working Group M. Wullink Internet-Draft SIDN Labs Intended status: Standards Track P. Kowalik Expires: 7 January 2027 DENIC 6 July 2026 JSON for RESTful Provisioning Protocol (RPP) draft-ietf-rpp-json-00 Abstract This document defines the rules for representing the RESTful Provisioning Protocol (RPP) data objects, as defined in [I-D.ietf-rpp-data-objects], using the JavaScript Object Notation (JSON) Data Interchange Format [RFC8259]. It specifies how RPP primitive types, common data types, component objects, resource objects, and associations are mapped to JSON and JSON Schema, and provides normative JSON Schema definitions and worked examples for domain name, contact, and host data objects. 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 7 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components Wullink & Kowalik Expires 7 January 2027 [Page 1] Internet-Draft JSON for RPP July 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Conventions Used in This Document . . . . . . . . . . . . . . 6 4. JSON Representation Rules . . . . . . . . . . . . . . . . . . 7 4.1. Primitive Type Mappings . . . . . . . . . . . . . . . . . 7 4.2. Cardinality Rules . . . . . . . . . . . . . . . . . . . . 8 4.3. Mutability Rules . . . . . . . . . . . . . . . . . . . . 10 4.4. Association Rules . . . . . . . . . . . . . . . . . . . . 10 4.4.1. Labelled associations . . . . . . . . . . . . . . . . 10 4.4.2. Aggregation . . . . . . . . . . . . . . . . . . . . . 11 4.4.3. Composition . . . . . . . . . . . . . . . . . . . . . 11 4.4.4. Labelled Aggregation . . . . . . . . . . . . . . . . 12 4.4.5. Dictionary Aggregation . . . . . . . . . . . . . . . 13 4.4.6. Labelled Composition . . . . . . . . . . . . . . . . 14 4.4.7. Dictionary Composition . . . . . . . . . . . . . . . 14 4.5. Object Identifier Rules . . . . . . . . . . . . . . . . . 15 4.6. External Type Embedding Rules . . . . . . . . . . . . . . 15 4.7. Process Data Embedding Rules . . . . . . . . . . . . . . 16 4.8. JSON Schema Definition Rules . . . . . . . . . . . . . . 16 4.8.1. RPP Profiles and Validation . . . . . . . . . . . . . 18 5. Update Rules . . . . . . . . . . . . . . . . . . . . . . . . 18 5.1. Full . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.2. Partial . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.3. Schema . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.3.1. Examples . . . . . . . . . . . . . . . . . . . . . . 21 6. JSON Schema Definitions . . . . . . . . . . . . . . . . . . . 23 6.1. Common Data Types Schemas . . . . . . . . . . . . . . . . 23 6.1.1. Identifier . . . . . . . . . . . . . . . . . . . . . 24 6.1.2. Client Identifier . . . . . . . . . . . . . . . . . . 24 6.1.3. Phone Number . . . . . . . . . . . . . . . . . . . . 25 6.2. Component Objects Schemas . . . . . . . . . . . . . . . . 25 6.2.1. Period Object . . . . . . . . . . . . . . . . . . . . 25 6.2.2. Provisioning Metadata Object . . . . . . . . . . . . 26 6.2.3. Status Object . . . . . . . . . . . . . . . . . . . . 26 6.2.4. DNS Resource Record Object . . . . . . . . . . . . . 27 6.2.5. DNS Operational Controls Object . . . . . . . . . . . 28 6.2.6. DNS Data Object . . . . . . . . . . . . . . . . . . . 29 6.2.7. Authorization Information Object . . . . . . . . . . 30 6.2.8. JSContact Card Object . . . . . . . . . . . . . . . . 31 6.2.9. Restore Report Object . . . . . . . . . . . . . . . . 33 6.2.10. Organisation Role Object . . . . . . . . . . . . . . 34 Wullink & Kowalik Expires 7 January 2027 [Page 2] Internet-Draft JSON for RPP July 2026 6.2.11. Processes Object . . . . . . . . . . . . . . . . . . 35 6.3. Process Object Schemas . . . . . . . . . . . . . . . . . 36 6.3.1. Create Process Object . . . . . . . . . . . . . . . . 36 6.3.2. Renew Process Object . . . . . . . . . . . . . . . . 37 6.3.3. Transfer Process Object . . . . . . . . . . . . . . . 38 6.3.3.1. Create . . . . . . . . . . . . . . . . . . . . . 38 6.3.3.2. Read . . . . . . . . . . . . . . . . . . . . . . 39 6.3.3.3. Approve . . . . . . . . . . . . . . . . . . . . . 40 6.3.3.4. Cancel . . . . . . . . . . . . . . . . . . . . . 41 6.3.3.5. Reject . . . . . . . . . . . . . . . . . . . . . 41 6.3.4. Restore Process Object . . . . . . . . . . . . . . . 41 6.4. Domain Name Data Object . . . . . . . . . . . . . . . . . 42 6.4.1. Create . . . . . . . . . . . . . . . . . . . . . . . 43 6.4.2. Read . . . . . . . . . . . . . . . . . . . . . . . . 45 6.4.3. Update . . . . . . . . . . . . . . . . . . . . . . . 47 6.4.4. Renew . . . . . . . . . . . . . . . . . . . . . . . . 47 6.4.5. Transfer . . . . . . . . . . . . . . . . . . . . . . 48 6.4.6. Reference . . . . . . . . . . . . . . . . . . . . . . 50 6.5. Contact Data Object . . . . . . . . . . . . . . . . . . . 50 6.5.1. JSContact Profile for RPP . . . . . . . . . . . . . . 51 6.5.2. Create . . . . . . . . . . . . . . . . . . . . . . . 51 6.5.3. Read . . . . . . . . . . . . . . . . . . . . . . . . 51 6.5.4. Update . . . . . . . . . . . . . . . . . . . . . . . 52 6.5.5. Transfer . . . . . . . . . . . . . . . . . . . . . . 53 6.5.6. Reference . . . . . . . . . . . . . . . . . . . . . . 53 6.6. Host Data Object . . . . . . . . . . . . . . . . . . . . 53 6.6.1. Create . . . . . . . . . . . . . . . . . . . . . . . 53 6.6.2. Read . . . . . . . . . . . . . . . . . . . . . . . . 54 6.6.3. Update . . . . . . . . . . . . . . . . . . . . . . . 54 6.6.4. Reference . . . . . . . . . . . . . . . . . . . . . . 55 6.7. Organisation Data Object . . . . . . . . . . . . . . . . 55 6.7.1. Create . . . . . . . . . . . . . . . . . . . . . . . 55 6.7.2. Read . . . . . . . . . . . . . . . . . . . . . . . . 56 6.7.3. Update . . . . . . . . . . . . . . . . . . . . . . . 57 6.7.4. Reference . . . . . . . . . . . . . . . . . . . . . . 59 6.8. User Data Object . . . . . . . . . . . . . . . . . . . . 59 6.8.1. Create . . . . . . . . . . . . . . . . . . . . . . . 59 6.8.2. Read . . . . . . . . . . . . . . . . . . . . . . . . 60 6.8.3. Update . . . . . . . . . . . . . . . . . . . . . . . 61 6.8.4. Reference . . . . . . . . . . . . . . . . . . . . . . 62 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 62 7.1. Domain Name . . . . . . . . . . . . . . . . . . . . . . . 63 7.1.1. Create . . . . . . . . . . . . . . . . . . . . . . . 63 7.1.2. Create Process Data . . . . . . . . . . . . . . . . . 64 7.1.3. Read . . . . . . . . . . . . . . . . . . . . . . . . 64 7.1.4. Update . . . . . . . . . . . . . . . . . . . . . . . 66 7.1.5. Delete . . . . . . . . . . . . . . . . . . . . . . . 66 7.1.6. Renew . . . . . . . . . . . . . . . . . . . . . . . . 67 Wullink & Kowalik Expires 7 January 2027 [Page 3] Internet-Draft JSON for RPP July 2026 7.1.7. Transfer Request . . . . . . . . . . . . . . . . . . 67 7.1.8. Transfer Query . . . . . . . . . . . . . . . . . . . 68 7.1.9. Transfer Approve . . . . . . . . . . . . . . . . . . 68 7.1.10. Transfer Cancel . . . . . . . . . . . . . . . . . . . 69 7.1.11. Transfer Reject . . . . . . . . . . . . . . . . . . . 69 7.1.12. Restore Request . . . . . . . . . . . . . . . . . . . 69 7.1.13. Restore Report . . . . . . . . . . . . . . . . . . . 70 7.1.14. Restore Query . . . . . . . . . . . . . . . . . . . . 71 7.2. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 71 7.2.1. Create . . . . . . . . . . . . . . . . . . . . . . . 71 7.2.2. Read . . . . . . . . . . . . . . . . . . . . . . . . 74 7.2.3. Update . . . . . . . . . . . . . . . . . . . . . . . 75 7.2.4. Delete . . . . . . . . . . . . . . . . . . . . . . . 76 7.2.5. Transfer Request . . . . . . . . . . . . . . . . . . 77 7.2.6. Transfer Query . . . . . . . . . . . . . . . . . . . 77 7.2.7. Transfer Cancel / Approve . . . . . . . . . . . . . . 77 7.2.8. Transfer Reject . . . . . . . . . . . . . . . . . . . 78 7.3. Host . . . . . . . . . . . . . . . . . . . . . . . . . . 78 7.3.1. Create . . . . . . . . . . . . . . . . . . . . . . . 78 7.3.2. Read . . . . . . . . . . . . . . . . . . . . . . . . 79 7.3.3. Update . . . . . . . . . . . . . . . . . . . . . . . 80 7.3.4. Delete . . . . . . . . . . . . . . . . . . . . . . . 81 7.3.5. Restore Request . . . . . . . . . . . . . . . . . . . 81 7.3.6. Restore Report . . . . . . . . . . . . . . . . . . . 82 7.3.7. Restore Query . . . . . . . . . . . . . . . . . . . . 83 7.4. Organisation . . . . . . . . . . . . . . . . . . . . . . 83 7.4.1. Create . . . . . . . . . . . . . . . . . . . . . . . 83 7.4.2. Read . . . . . . . . . . . . . . . . . . . . . . . . 86 7.4.3. Update . . . . . . . . . . . . . . . . . . . . . . . 87 7.4.4. Delete . . . . . . . . . . . . . . . . . . . . . . . 87 7.4.5. Reference . . . . . . . . . . . . . . . . . . . . . . 87 7.5. User . . . . . . . . . . . . . . . . . . . . . . . . . . 88 7.5.1. Create . . . . . . . . . . . . . . . . . . . . . . . 88 7.5.2. Read . . . . . . . . . . . . . . . . . . . . . . . . 88 7.5.3. Update . . . . . . . . . . . . . . . . . . . . . . . 88 7.5.4. Delete . . . . . . . . . . . . . . . . . . . . . . . 89 7.5.5. Reference . . . . . . . . . . . . . . . . . . . . . . 89 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 89 9. Internationalization Considerations . . . . . . . . . . . . . 89 10. Security Considerations . . . . . . . . . . . . . . . . . . . 89 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 89 12. Change History . . . . . . . . . . . . . . . . . . . . . . . 89 12.1. Version draft-wullink-rpp-json-02 to draft-ietf-rpp-json-00 . . . . . . . . . . . . . . . . . 89 12.2. Version 01 to 02 . . . . . . . . . . . . . . . . . . . . 90 12.3. Version 00 to 01 . . . . . . . . . . . . . . . . . . . . 90 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 90 13.1. Normative References . . . . . . . . . . . . . . . . . . 90 Wullink & Kowalik Expires 7 January 2027 [Page 4] Internet-Draft JSON for RPP July 2026 13.2. Informative References . . . . . . . . . . . . . . . . . 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 92 1. Introduction The RESTful Provisioning Protocol (RPP) defines a set of data objects for managing foundational registry resources including domain names, contacts, and hosts. The data model is defined in [I-D.ietf-rpp-data-objects] independently of any particular representation format. This document defines the JSON [RFC8259] representation of those data objects. JSON has emerged as the de facto standard data format for modern RESTful APIs. Its widespread adoption across tools, libraries, and developer communities makes it well suited as the primary representation format for RPP. This document provides the normative rules and JSON Schema definitions required for implementations to produce and consume RPP messages in JSON. The separation between the abstract data model and its concrete JSON representation ensures that the protocol's semantic foundation remains stable while enabling the adoption of JSON across diverse deployment environments. 1.1. Motivation The RESTful Provisioning Protocol (RPP) introduces a new provisioning mechanism that aligns more closely with modern cloud infrastructure, enhancing the scalability of server deployments. While RESTful protocols do not mandate a specific media type for resource description, the widespread adoption of JSON in web services has established it as the de facto standard for modern APIs. The increasing availability of tools, software libraries, and a skilled workforce has led several registries to adopt JSON for data exchange within their API ecosystems. Registries supporting JSON can offer a unified API ecosystem that extends beyond domain name and IP address provisioning, maintaining a consistent technology stack, data formats, and developer experience. JSON's syntax, known for its straightforwardness and minimal verbosity, significantly eases the tasks of writing, reading, and maintaining code. This simplicity is especially advantageous for the rapid comprehension and integration of provisioning APIs. The lightweight nature of JSON can result in faster processing and data transfers, a critical aspect in high-volume transaction environments such as domain registration. Enhanced API response times can lead to more efficient domain lookups, registrations, and Wullink & Kowalik Expires 7 January 2027 [Page 5] Internet-Draft JSON for RPP July 2026 updates. JSON parsing is typically fast and well-supported by standard libraries, contributing to improved system performance amid frequent interactions between RPP clients and servers. However, the absence of a standardized JSON format for domain provisioning has led to the emergence of TLD-specific implementations that lack interoperability, increasing the development effort required for integration. Similarly, at the registrar level, the absence of standards has resulted in numerous incompatible API implementations provided to clients and resellers. Standardizing a JSON format for domain provisioning within the RPP framework could mitigate these challenges, reducing fragmentation and simplifying integration efforts across the domain registration industry. 2. Terminology In this document, the following terminology is used. RPP Data Objects - The abstract data model definitions for domain name, contact, and host resources, as specified in [I-D.ietf-rpp-data-objects]. RESTful Provisioning Protocol - A RESTful protocol for provisioning heterogeneous database objects. JSON Schema - A vocabulary that allows annotation and validation of JSON documents, as described in [JSON-SCHEMA]. EPP Compatibility Profile - A set of additional constraints defined in [I-D.ietf-rpp-data-objects] that a server MUST adhere to when supporting both RPP and EPP concurrently. 3. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. JSON is case sensitive. Unless stated otherwise, JSON specifications and examples provided in this document MUST be interpreted in the character case presented. The examples in this document assume that request and response messages are properly formatted JSON documents. Indentation and white space in examples are provided only to illustrate element relationships and for improving readability, and are not REQUIRED features of the protocol. Wullink & Kowalik Expires 7 January 2027 [Page 6] Internet-Draft JSON for RPP July 2026 All JSON Schema definitions in this document use JSON Schema draft 2020-12 [JSON-SCHEMA], and where not provided with a $schema keyword, the following default applies: "$schema": "https://json-schema.org/draft/2020-12/schema" 4. JSON Representation Rules This section defines the normative rules for representing the RPP data model in JSON. The data model is specified in [I-D.ietf-rpp-data-objects], which defines all primitive types, common data types, component objects, resource objects, and associations independently of any concrete representation format. The rules in this section specify how those abstract definitions map to JSON and JSON Schema version 2020-12. 4.1. Primitive Type Mappings RPP primitive types MUST be represented in JSON as follows: Wullink & Kowalik Expires 7 January 2027 [Page 7] Internet-Draft JSON for RPP July 2026 +===========+=========+======================================+ | RPP | JSON | Notes | | Primitive | Type | | | Type | | | +===========+=========+======================================+ | String | string | Unicode character sequence | +-----------+---------+--------------------------------------+ | Integer | number | Whole number, positive or negative | +-----------+---------+--------------------------------------+ | Boolean | boolean | true or false | +-----------+---------+--------------------------------------+ | Decimal | string | Base-10 fractional value with exact | | | | representation within a defined | | | | precision. Number is encoded into | | | | string same as "number" in [RFC8259] | | | | without exponent part "ext". | +-----------+---------+--------------------------------------+ | Date | string | Full-date as per [RFC3339], e.g. | | | | "2025-10-27" | +-----------+---------+--------------------------------------+ | Timestamp | string | Date-time in UTC as per [RFC3339], | | | | e.g. "2025-10-27T09:42:51Z" | +-----------+---------+--------------------------------------+ | URL | string | Uniform Resource Locator as per | | | | [RFC1738] | +-----------+---------+--------------------------------------+ | Binary | string | Base64-encoded binary data | +-----------+---------+--------------------------------------+ Table 1 4.2. Cardinality Rules The cardinality of each data element in the RPP data model MUST be represented as follows in JSON: Rule 1: A data element with cardinality 1 (exactly one) MUST be represented as a JSON property and MUST be present in the containing JSON object. The element MUST be listed under required in the corresponding JSON Schema. { "type": "object", "properties": { "name": { "type": "string" } }, "required": ["name"] } Wullink & Kowalik Expires 7 January 2027 [Page 8] Internet-Draft JSON for RPP July 2026 Rule 2: A data element with cardinality 0-1 (zero or one) MUST be represented as an optional JSON property. The element MUST NOT be listed under required in the corresponding JSON Schema. When absent, the element MUST be omitted from the JSON object (not represented as null). { "type": "object", "properties": { "expiryDate": { "type": "string", "format": "date-time" } } } Rule 3: A data element with cardinality 0+ (zero or more) MUST be represented as an optional JSON array. When no values are present, the property MUST be omitted or represented as an empty array. { "type": "object", "properties": { "status": { "type": "array", "items": { "$ref": "#/$defs/status" } } } } Rule 4: A data element with cardinality 1+ (one or more) MUST be represented as a required JSON array with "minItems": 1 and the element MUST be listed under required in the corresponding JSON Schema. { "type": "object", "properties": { "records": { "type": "array", "items": { "$ref": "#/$defs/dnsRecord" }, "minItems": 1 } }, "required": ["records"] } Wullink & Kowalik Expires 7 January 2027 [Page 9] Internet-Draft JSON for RPP July 2026 4.3. Mutability Rules Data elements in the RPP data model carry a mutability attribute: create-only, read-only, or read-write. These MUST be represented in JSON Schema as follows: Rule 5: Data elements with mutability read-only MUST be annotated with "readOnly": true in the JSON Schema. Clients MUST NOT include read-only properties in create or update request bodies. Servers MUST ignore any read-only properties provided by a client in a request. { "repositoryId": { "type": "string", "readOnly": true } } Rule 6: Data elements with mutability create-only MUST be annotated with "writeOnly": true in the JSON Schema for request schemas, and excluded from update request schemas. Servers MUST reject requests that attempt to modify a create-only element after object creation. Rule 7: Data elements with mutability read-write have no additional annotation. They MAY appear in both request and response bodies. 4.4. Association Rules The RPP data model defines several association types between objects, the following rules specify their JSON representations. A Aggregation represents a relationship between two independent objects, where one object references another. A Composition represents a parent-child relationship where the child object is embedded within the parent object and cannot exist independently. 4.4.1. Labelled associations Some associations between objects carry a string label that provides additional context for the relationship. The label is not an identifier of the target object, but rather a descriptor of the association itself. Labelled associations can occur in both aggregations and compositions. When representing labelled associations in JSON, the property label MUST be included alongside the reference to the target object. A property with the name object MUST be used to contain the reference to the target object, which can be either limited representation containing at minimum the primary object identifier for aggregations or an embedded object for Wullink & Kowalik Expires 7 January 2027 [Page 10] Internet-Draft JSON for RPP July 2026 compositions. 4.4.2. Aggregation An Aggregation[Type] represents a relationship between two independent objects. When the cardinality allows more than one target, it MUST be represented as a JSON array. Each element of the array MUST be the identifier of the referenced object. Rule 8: Aggregation[Type] with cardinality 0+ or 1+ MUST be represented as a JSON array of embedded objects. Each object in the array MUST include the data elements of the referenced object type that are relevant to the context (at minimum the primary identifier field). Other data elements of the referenced object type MAY be included as needed to provide additional context for the client, but are not required. The JSON Schema MUST allow for the presence of these additional fields. Example: domain nameservers (Aggregation[Host Data Object]) in a read response, returning a limited object representation containing only the primary identifier field hostName: { "@type": "domainName", "name": "name.example", "nameservers": [ { "@type": "host", "hostName": "ns1.name.example" }, { "@type": "host", "hostName": "ns2.name.example" } ] } 4.4.3. Composition A Composition[Type] represents a parent-child relationship where the child's lifecycle is bound to the parent and the child cannot exist independently of the parent. In JSON, the child object MUST be fully embedded within the parent object. The JSON representation of a composition is the same as that of an aggregation. The distinction between the two is semantic and does not affect the JSON structure. Wullink & Kowalik Expires 7 January 2027 [Page 11] Internet-Draft JSON for RPP July 2026 { "@type": "domainName", "name": "name.example", "nameservers": [ { "@type": "host", "hostName": "ns1.name.example", "provMetadata": { "@type": "provMetadata", "repositoryId": "NS1EXAMPLE-REP", "spClientId": "ClientX" }, "status": [ { "@type": "status", "label": "ok" } ], "dns": { "@type": "dnsData", "records": [ { "@type": "dnsRecord", "name": "@", "type": "ns", "rdata": { "nsdname": "ns1.name.example." } }, { "@type": "dnsRecord", "name": "ns1.name.example.", "type": "a", "rdata": { "address": "192.0.2.1" } } ] } } ] } 4.4.4. Labelled Aggregation A LabelledAggregation[Type] is a relationship between two independent objects where each association carries a string label. Multiple associations with the same label are allowed. Rule 9: LabelledAggregation[Type] with cardinality 0+ MUST be represented as a JSON array of objects. Each object in the array MUST contain a label property (string) alongside the identifier of the referenced object. The object MUST include at least the primary identifier field of the referenced object type. Other data elements of the referenced object type MAY be included as needed to provide additional context for the client, but are not required. The JSON Schema MUST allow for the presence of these additional fields. Wullink & Kowalik Expires 7 January 2027 [Page 12] Internet-Draft JSON for RPP July 2026 Example: domain contacts (LabelledAggregation[Contact Object]): "contacts": [ { "label": "admin", "object": { "@type": "contact", "id": "ABC-8013" } }, { "label": "tech", "object": { "@type": "contact", "id": "ABC-8014" } } ] 4.4.5. Dictionary Aggregation A DictionaryAggregation[Type] is a relationship between two independent objects where each association carries a unique string label that serves as a dictionary key. Rule 10: DictionaryAggregation[Type] MUST be represented as a JSON object where each key is the unique label and the corresponding value is the referenced object, the object MUST include at least the primary identifier field of the referenced object type. Other data elements of the referenced object type MAY be included as needed to provide additional context for the client, but are not required. The JSON Schema MUST allow for the presence of these additional fields. Example: domain contacts keyed by unique role (DictionaryAggregation[Contact Object]): "contacts": { "admin": { "@type": "contact", "id": "ABC-8013" }, "tech": { "@type": "contact", "id": "ABC-8014" } } Wullink & Kowalik Expires 7 January 2027 [Page 13] Internet-Draft JSON for RPP July 2026 4.4.6. Labelled Composition A LabelledComposition[Type] is a parent-child relationship where each embedded child carries a string label. Multiple instances with the same label are allowed. Rule 11: LabelledComposition[Type] with cardinality 0+ MUST be represented as a JSON array of embedded objects. Each object in the array MUST contain a label property alongside the data elements of the composed type. Example: remarks (LabelledComposition[Remark Object]): "remarks": [ { "label": "public", "object": { "@type": "remark", "description": "This domain is used for test purposes." } }, { "label": "private", "object": { "@type": "remark", "description": "Internal note for the sponsoring client." } } ] 4.4.7. Dictionary Composition A DictionaryComposition[Type] is a parent-child relationship where each embedded child carries a unique string label used as a dictionary key. Rule 12: DictionaryComposition[Type] MUST be represented as a JSON object where each key is the unique label and the corresponding value is the fully embedded child object. Example: remarks keyed by scope (DictionaryComposition[Remark Object]): Wullink & Kowalik Expires 7 January 2027 [Page 14] Internet-Draft JSON for RPP July 2026 "remarks": { "public": { "@type": "remark", "description": "This domain is used for test purposes." }, "private": { "@type": "remark", "description": "Internal note for the sponsoring client." } } 4.5. Object Identifier Rules Rule 13: When a resource or component object is referenced by identifier (for example in an aggregation), the identifier MUST be represented as a JSON string using the value of the object's primary identifier data element. Rule 14: When a resource or component object is embedded (as in a composition), all data elements of the object MUST be represented as properties of a JSON object according to the rules of this section. 4.6. External Type Embedding Rules RPP data objects may include data elements whose types are defined by external specifications (e.g., JSContact in [RFC9553]). When embedding a value of an externally defined type into a JSON representation, the following rules apply, in order of preference: Rule 15: If the external type has a native JSON representation (i.e., the external specification defines how the type is represented using the JSON format), the value MUST be embedded as a valid JSON element using the native JSON representation defined by that specification. Rule 16: If the external type does not have a native JSON representation but has a native UTF-8 encoded text representation, the value MUST be embedded as a JSON string using the UTF-8 encoding. Rule 17: If the external type has neither a native JSON nor a native UTF-8 text representation, the binary representation of the value MUST be Base64-encoded ([RFC4648], Section 4) and embedded as a JSON string. Wullink & Kowalik Expires 7 January 2027 [Page 15] Internet-Draft JSON for RPP July 2026 4.7. Process Data Embedding Rules As defined in [I-D.ietf-rpp-core], a uniform interface operation MAY require process data in addition to the object representation data. This section defines how such process data MUST be represented in JSON when transmitted together with the object representation in a single request body. Rule 18: Process data accompanying a uniform interface operation MUST be represented using the processes data element of the owning resource object (see Processes Object), following the Aggregation rules for the corresponding process type (for example createProcess for creation-specific inputs). Each embedded process object MUST be a valid JSON representation of the process object. This applies uniformly regardless of whether the resource object already exists. Example: a domain create request body carrying a two-year registration period as process data embedded in a createProcess process object under processes: { "@type": "domainName", "name": "example.example", "nameservers": [ { "@type": "host", "hostName": "ns1.example.example" }, { "@type": "host", "hostName": "ns2.example.example" } ], "processes": { "@type": "processes", "createProcess": [ { "@type": "createProcess", "period": { "@type": "period", "value": 2, "unit": "y" } } ] } } 4.8. JSON Schema Definition Rules Rule 20: Each RPP component object and resource object MUST have a corresponding JSON Schema definition. Object definitions MUST be placed in the $defs keyword of the JSON Schema document. Wullink & Kowalik Expires 7 January 2027 [Page 16] Internet-Draft JSON for RPP July 2026 Rule 21: Identifier fields MUST use "type": "string" in JSON Schema. Rule 22: Enumeration constraints on string fields MUST be expressed using the "enum" keyword in JSON Schema. Example (Transfer Status enum): "trStatus": { "type": "string", "enum": ["pending", "clientApproved", "clientCancelled", "clientRejected", "serverApproved", "serverCancelled"] } Rule 23: Each JSON Schema definition for an RPP object MUST include a "required" array listing all data elements with cardinality 1 or 1+. Rule 24: JSON Schema definitions for extendible RPP objects MUST NOT use "additionalProperties": false or "unevaluatedProperties": false. However, before validation, schemas on every property level MUST be enriched with "unevaluatedProperties": false property to prevent the presence of undeclared properties in JSON instances. JSON Schemas for Object type MAY use "additionalProperties": true to allow for free key definition. Rule 25: Every RPP object representation MUST include a "@type" property whose value is the object's identifier as registered in the IANA RPP Data Object Registry. This property enables identification and allows clients and servers to unambiguously determine the type of an object. The "@type" property MUST be included in the JSON Schema "properties" object for each RPP object definition with a "const" constraint fixing the value to the object's registered identifier. The "@type" property MUST be listed in the "required" array of the corresponding JSON Schema definition. Example (Domain Name Data Object): { "@type": "domainName", "name": "example.example" } Rule 26: When a transfer request or other operation requires authorization information (e.g., EPP-style authinfo), the client MUST NOT include the authInfo object in the JSON request body. Instead, the client MUST convey the authorization information using the RPP- Authorization HTTP request header as defined in [I-D.ietf-rpp-core]. Servers MUST reject any request that includes an authInfo object in the JSON body with an appropriate error response. Wullink & Kowalik Expires 7 January 2027 [Page 17] Internet-Draft JSON for RPP July 2026 4.8.1. RPP Profiles and Validation RPP profiles, such as the EPP Compatibility Profile defined in [I-D.ietf-rpp-data-objects], may impose additional constraints on top of the base RPP data model. These additional constraints MUST be enforced by implementations through validation rules that go beyond what can be expressed in JSON Schema. Such validation rules MUST be clearly documented in the profile specification and implemented by both clients and servers when operating under that profile. For example, the EPP Compatibility Profile requires that certain fields be present in specific object types, and that certain identifier fields conform to EPP syntax rules. These constraints cannot be fully captured in JSON Schema and therefore require additional validation logic in implementations. 5. Update Rules *NOTE*: The update rules in this section are still under discussion and may be subject to change. Feedback from the community is welcome. 5.1. Full A full update operation replaces the entire state of a resource object with the new representation provided in the request, all required properties MUST be included in the new representation. 5.2. Partial A partial update operation allows clients to update specific properties of a resource object, while leaving other properties unchanged. A partial update MUST use JSON Patch [RFC6902] and an RPP extension to support the match property for matching of array elements. The match property is used to identify a specific element in an array, it is a JSON object that contains key-value pairs corresponding to the properties of the array elements. The server uses the match property to locate the specific element in the array that should be updated, removed, or replaced. The server MUST compare every key and corresponding value in the match object against the properties of each element in the array. If an element matches all key-value pairs in the match object, it is considered a match. If the righthand side of the match property contains a complex datatype (object or array), the match property MUST contain a key named object, the value of which is a JSON object that contains the properties to be matched against. The server MUST compare the Wullink & Kowalik Expires 7 January 2027 [Page 18] Internet-Draft JSON for RPP July 2026 properties of the nested object against the corresponding properties of the array element. If all properties match, the element is considered a match. The server MUST NOT allow recursive matching of nested data structures. The match property is only used for matching elements in the immediate array specified by the path property of the JSON Patch operation. If the array elements contain nested objects or arrays, the server MUST NOT attempt to match against those nested structures. Example domain object for matching an array element with a specific key-value pair: { "@type": "domainName", "name": "example.example", "contacts": [ { "label": "admin", "object": { "@type": "contact", "id": "REG-100" } }, { "label": "tech", "object": { "@type": "contact", "id": "REG-200" } }, { "label": "tech", "object": { "@type": "contact", "id": "REG-300" } } ] } Example match object for matching the array element with the "tech" label and the contact ID "REG-200" in the contacts array of the domain object above: { "match": { "label": "tech", "object": { "@type": "contact", "id": "REG-200" } } } For the remove operation, if multiple matched elements are found, then the sever MUST remove all matched elements. For the replace operation, if multiple matched elements are found, then the server MUST return an error response indicating that the operation is ambiguous and cannot be performed. If a match does not have any results, then the server MUST return an error response indicating that the specified element could not be found. The following rules apply for partial updates: * Rule 25: JSON Patch operations other than "add", "remove" and "replace" MUST NOT be used. Wullink & Kowalik Expires 7 January 2027 [Page 19] Internet-Draft JSON for RPP July 2026 * Rule 26: If a JSONPointer path points to field using a JSON simple data type (e.g. string or number) then the "value" property MUST be provided and its type MUST match the type of the target field. * Rule 27: If a JSONPointer path points to an object, then the "value" property MUST be provided and contain a valid object, the new object's "@type" property MUST match the "@type" of the target object. * Rule 28: If a JSONPointer path points to an array, then: - The "match" property MUST be provided to identify the specific element to be updated. - The "match" property MUST only be used for matching array elements of the same type, and the rules 26 and 27 apply. - The value of the "op" property determines the action to be taken on the matched element: o The "add" operation, appends the new value to the array. o The "remove" operation, removes the specified value from the array. o The "replace" operation, replaces the existing value at the matching array element with the specified value. - If the value of the "op" property is "replace", and there is a matching element, then the element MUST be fully replaced with the new value provided in the "value" property. The new value MUST include all required fields for the object type. * Rule 29: If any of the JSONPointer paths in the request fail to match an existing field or element in the target resource object, the server MUST reject the complete request with an appropriate error response. 5.3. Schema A partial update request body MUST be a JSON array of patch operation objects. Each operation MUST include an op and a path property. The value property MUST be present for add and replace operations. The match property MUST be present when the path points to an array property and is used to identify the specific array element to operate on. { "$schema": "https://json-schema.org/draft/2020-12/schema", "$ref": "#/$defs/partialUpdate", "$defs": { "partialUpdate": { "type": "array", "items": { "$ref": "#/$defs/patchOperation" }, "minItems": 1 }, "patchOperation": { "oneOf": [ Wullink & Kowalik Expires 7 January 2027 [Page 20] Internet-Draft JSON for RPP July 2026 { "$ref": "#/$defs/patchAdd" }, { "$ref": "#/$defs/patchRemove" }, { "$ref": "#/$defs/patchReplace" } ] }, "patchAdd": { "type": "object", "properties": { "op": { "type": "string", "const": "add" }, "path": { "type": "string" }, "value": {} }, "required": ["op", "path", "value"], "additionalProperties": false }, "patchRemove": { "type": "object", "properties": { "op": { "type": "string", "const": "remove" }, "path": { "type": "string" }, "match": { "type": "object" } }, "required": ["op", "path"], "additionalProperties": false }, "patchReplace": { "type": "object", "properties": { "op": { "type": "string", "const": "replace" }, "path": { "type": "string" }, "match": { "type": "object" }, "value": {} }, "required": ["op", "path", "value"], "additionalProperties": false } } } 5.3.1. Examples Example JSON document used by partial update examples below: Wullink & Kowalik Expires 7 January 2027 [Page 21] Internet-Draft JSON for RPP July 2026 { "@type": "domainName", "name": "example.example", "provMetadata": { "@type": "provMetadata", "repositoryId": "EXAMPLE1-REP", "spClientId": "ClientX", "crClientId": "ClientX", "crDate": "1999-04-03T22:00:00.0Z" }, "nameservers": [ { "@type": "host", "hostName": "ns1.example.example" }, { "@type": "host", "hostName": "ns2.example.example" } ], "registrant": { "@type": "contact", "id": "jd1234" }, "contacts": [ { "label": "admin", "object": { "@type": "contact", "id": "sh8013" } }, { "label": "tech", "object": { "@type": "contact", "id": "sh8013" } } ], "status": [ { "@type": "status", "label": "ok" } ], "expiryDate": "2027-01-01T00:00:00.0Z" } Example of a partial update request to change the registrant of a domain name from "jd1234" to "jd1234-new": [ { "op": "replace", "path": "/registrant", "value": { "@type": "contact", "id": "jd1234-new" } } ] Example of a partial update request to change the status of a domain name from "ok" to "clientProhibited": Wullink & Kowalik Expires 7 January 2027 [Page 22] Internet-Draft JSON for RPP July 2026 [ { "op": "replace", "path": "/status", "match": { "label": "ok" }, "value": { "@type": "status", "label": "clientProhibited" } } ] Example of a partial update request for adding a additional tech contact to a domain name: [ { "op": "add", "path": "/contacts", "value": { "label": "tech", "object": { "@type": "contact", "id": "sh8014" } } } ] 6. JSON Schema Definitions This section provides normative JSON Schema definitions for RPP component objects and resource objects. All schemas use JSON Schema draft 2020-12 [JSON-SCHEMA]. 6.1. Common Data Types Schemas This section defines shared data types that are based on the primitive data types above and are re-used across multiple data object definitions. Wullink & Kowalik Expires 7 January 2027 [Page 23] Internet-Draft JSON for RPP July 2026 6.1.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. In JSON, an Identifier MUST be represented as a string value conforming to the roidType syntax defined in Section 2.8 of [RFC5730]: one to eight word characters optionally preceded by an underscore, followed by a hyphen and one or more word characters, with a maximum total length of 89 characters. { "$defs": { "identifier": { "type": "string", "pattern": "^(\\w|_){1,8}-\\w{1,}$", "maxLength": 89 } } } 6.1.2. Client Identifier Client identifiers are character strings with a specified minimum length, a specified maximum length, and a specified format. Client identifiers use the clIDType syntax described in [RFC5730]. In JSON, a Client Identifier MUST be represented as a string value. { "$defs": { "clientIdentifier": { "type": "string", "minLength": 3, "maxLength": 16, "pattern": "^[a-zA-Z0-9]([-a-zA-Z0-9]*[a-zA-Z0-9])?$" } } } Wullink & Kowalik Expires 7 January 2027 [Page 24] Internet-Draft JSON for RPP July 2026 6.1.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. In JSON, a Phone Number MUST be represented as a string value conforming to the pattern described above. { "$defs": { "phoneNumber": { "type": "string", "pattern": "^\\+[0-9]{1,3}\\.[0-9]+( x[0-9]+)?$" } } } 6.2. Component Objects Schemas 6.2.1. Period Object { "$defs": { "period": { "type": "object", "properties": { "@type": { "type": "string", "const": "period" }, "value": { "type": "integer", "minimum": 1, "maximum": 99 }, "unit": { "type": "string", "enum": ["y", "m"] } }, "required": ["@type", "value", "unit"] } } } Wullink & Kowalik Expires 7 January 2027 [Page 25] Internet-Draft JSON for RPP July 2026 6.2.2. Provisioning Metadata Object The following constraints cannot be expressed in JSON Schema and MUST be enforced by implementations: * upClientId and upDate MUST NOT be present if the object has never been modified. * trDate MUST NOT be present if the object has never been transferred. * In EPP Compatibility Profile, repositoryId MUST be provided. { "$defs": { "provMetadata": { "type": "object", "properties": { "@type": { "type": "string", "const": "provMetadata", "readOnly": true }, "repositoryId": { "type": "string", "readOnly": true }, "spClientId": { "$ref": "#/$defs/clientIdentifier", "readOnly": true }, "crClientId": { "$ref": "#/$defs/clientIdentifier", "readOnly": true }, "crDate": { "type": "string", "format": "date-time", "readOnly": true }, "upClientId": { "$ref": "#/$defs/clientIdentifier", "readOnly": true }, "upDate": { "type": "string", "format": "date-time", "readOnly": true }, "trDate": { "type": "string", "format": "date-time", "readOnly": true } }, "required": ["@type", "spClientId"] } } } 6.2.3. Status Object The following constraints cannot be expressed in JSON Schema and MUST be enforced by implementations: * label MUST use camelCase notation using only ASCII alphabetic characters. Labels set explicitly by the server MUST use the prefix "server"; labels set explicitly by a client MUST use the prefix "client"; all other labels MUST NOT use either prefix. The allowed set of label values depends on the provisioning object type and MAY be extended by extensions. * due: Servers MAY restrict the ability of clients to set or update this value. Wullink & Kowalik Expires 7 January 2027 [Page 26] Internet-Draft JSON for RPP July 2026 * When the RGP feature is supported, the following additional status labels MAY appear on objects that support RGP: addPeriod, autoRenewPeriod, renewPeriod, transferPeriod, redemptionPeriod, pendingRestore, rgpPendingDelete. The labels redemptionPeriod, pendingRestore, and rgpPendingDelete MUST only appear alongside the standard pendingDelete status. { "$defs": { "status": { "type": "object", "properties": { "@type": { "type": "string", "const": "status" }, "label": { "type": "string", "pattern": "^[a-zA-Z]+$" }, "reason": { "type": "string" }, "due": { "type": "string", "format": "date-time" } }, "required": ["@type", "label"] } } } 6.2.4. DNS Resource Record Object The following constraints cannot be expressed in JSON Schema and MUST be enforced by implementations: * name MUST be a syntactically valid DNS host name in zone file string representation. Both absolute FQDNs (with trailing dot) and relative host names are allowed, as well as the @ symbol representing the domain name itself. * type MUST be a valid string representation of a DNS resource record type as defined in [RFC1035]. Values MUST be converted to lower case. Allowed values MAY be further constrained by server policy. * In EPP Compatibility Profile ([RFC5732]), the following record types MUST be supported: ns, a, and aaaa. With DNSSEC Extension [RFC5910], ds and dnskey MUST additionally be supported. * class, if present, MUST be chosen from Section 3.2.4 (CLASS values) of [RFC1035]. A client SHOULD omit this element; the server MUST assume IN as the default. * The fields within rdata MUST match the expected structure for the given record type (see RDATA structures below). RDATA structures required in EPP Compatibility Profile: * NS records ([RFC1035], Section 3.3.11): nsdname * A records ([RFC1035], Section 3.4.1): address Wullink & Kowalik Expires 7 January 2027 [Page 27] Internet-Draft JSON for RPP July 2026 * AAAA records ([RFC3596], Section 2.2): address * DS records ([RFC4034], Section 5, with DNSSEC Extension): keyTag, algorithm, digestType, digest * DNSKEY records ([RFC4034], Section 2, with DNSSEC Extension): flags, protocol, algorithm, publicKey All rdata property names MUST be written in camelCase and all values MUST use the string data type. { "$defs": { "dnsRecord": { "type": "object", "properties": { "@type": { "type": "string", "const": "dnsRecord" }, "name": { "type": "string" }, "class": { "type": "string" }, "type": { "type": "string" }, "rdata": { "type": "object", "unevaluatedProperties": true } }, "required": ["@type", "name", "type", "rdata"] } } } 6.2.5. DNS Operational Controls Object The DNS Operational Controls Object 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]. Wullink & Kowalik Expires 7 January 2027 [Page 28] Internet-Draft JSON for RPP July 2026 { "$defs": { "dnsControls": { "type": "object", "properties": { "@type": { "type": "string", "const": "dnsControls" }, "ttl": { "type": "object", "propertyNames": { "pattern": "^[a-z]+$" }, "additionalProperties": { "type": "integer", "minimum": 1 } }, "maxSigLifetime": { "type": "object", "propertyNames": { "pattern": "^[a-z]+$" }, "additionalProperties": { "type": "integer", "minimum": 1 } } }, "required": ["@type"] } } } 6.2.6. DNS Data Object The DNS Data Object is 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. It is aligned with [I-D.simmen-rpp-dns-data]. The following constraints cannot be expressed in JSON Schema and MUST be enforced by implementations: * In EPP Compatibility Profile with DNSSEC Extension [RFC5910], records of type ds and dnskey MUST be supported in addition to ns, a, and aaaa. A server MUST support either ds or dnskey or both. If provided with only dnskey, a server MUST calculate the DS record. Wullink & Kowalik Expires 7 January 2027 [Page 29] Internet-Draft JSON for RPP July 2026 { "$defs": { "dnsData": { "type": "object", "properties": { "@type": { "type": "string", "const": "dnsData" }, "records": { "type": "array", "items": { "$ref": "#/$defs/dnsRecord" } }, "controls": { "$ref": "#/$defs/dnsControls" } }, "required": ["@type"] } } } 6.2.7. Authorization Information Object The following constraints cannot be expressed in JSON Schema and MUST be enforced by implementations: * method MUST be one of the values registered in the IANA RPP Authorization Method Registry as defined in [I-D.ietf-rpp-core]. In EPP Compatibility Profile, this value MUST be "authinfo" for standard password-based authorization. * The Authorization Information Object is immutable. When authorization information changes, a new instance MUST be created rather than modifying the existing one. The value of authdata MAY be omitted from read responses, depending on the method and server policy. { "$defs": { "authInfo": { "type": "object", "properties": { "@type": { "type": "string", "const": "authInfo" }, "method": { "type": "string" }, "authdata": { "type": "string" } }, "required": ["@type", "method", "authdata"] } } } Wullink & Kowalik Expires 7 January 2027 [Page 30] Internet-Draft JSON for RPP July 2026 6.2.8. JSContact Card Object The Contact Data Object uses version 2.0 of JSContact [RFC9982] to represent contact information. The Contact object is defined below according to the RPP JSContact Profile [TODO Add Ref]. The following constraints cannot be expressed in JSON Schema and MUST be enforced by implementations: * addresses[*].countryCode MUST be a valid two-character ISO 3166-1 [ISO3166-1] alpha-2 code when present. * localizations MUST be fully expanded; nested PatchObject-style keys (e.g., "addresses/addr/full") are NOT allowed. * When phones[*].features is absent, the number MUST be treated as a voice number. { "$defs": { "Card": { "type": "object", "properties": { "@type": { "type": "string", "const": "Card" }, "version": { "type": "string", "const": "2.0" }, "kind": { "type": "string", "enum": ["individual", "org"] }, "language": { "type": "string" }, "name": { "type": "object", "properties": { "full": { "type": "string" }, "components": { "type": "array", "items": { "type": "object", "properties": { "kind": { "type": "string", "enum": ["given", "surname"] }, "value": { "type": "string" } }, "required": ["kind", "value"] } } } }, "organizations": { "type": "object", "additionalProperties": { "type": "object", "properties": { "name": { "type": "string" } Wullink & Kowalik Expires 7 January 2027 [Page 31] Internet-Draft JSON for RPP July 2026 } } }, "addresses": { "type": "object", "additionalProperties": { "type": "object", "properties": { "full": { "type": "string" }, "countryCode": { "type": "string", "pattern": "^[A-Z]{2}$" }, "components": { "type": "array", "items": { "type": "object", "properties": { "kind": { "type": "string", "enum": ["name", "locality", "region", "postcode", "country"] }, "value": { "type": "string" } }, "required": ["kind", "value"] } } } } }, "phones": { "type": "object", "additionalProperties": { "type": "object", "properties": { "number": { "type": "string" }, "features": { "type": "object", "additionalProperties": { "type": "boolean" } } }, "required": ["number"] } }, "emails": { "type": "object", "additionalProperties": { "type": "object", "properties": { "address": { "type": "string", "format": "email" } }, "required": ["address"] Wullink & Kowalik Expires 7 January 2027 [Page 32] Internet-Draft JSON for RPP July 2026 } }, "links": { "type": "object", "additionalProperties": { "type": "object", "properties": { "uri": { "type": "string", "format": "uri" }, "kind": { "type": "string", "const": "contact" } }, "required": ["uri"] } }, "localizations": { "type": "object" } }, "required": ["@type", "version"] } } } 6.2.9. Restore Report Object The Restore Report Object contains the redemption grace period restore report submitted by the sponsoring client as required by the RGP process ([RFC3915]). The following constraints cannot be expressed in JSON Schema and MUST be enforced by implementations: * At least one and at most two statements MUST be provided. * restoreTime MAY be omitted when the restore report is submitted inline within the restore request in a single-step process. * In EPP Compatibility Profile, restoreTime MUST be present as defined in [RFC3915]. * In EPP Compatibility Profile, exactly two statements MUST be present as defined in [RFC3915]. Wullink & Kowalik Expires 7 January 2027 [Page 33] Internet-Draft JSON for RPP July 2026 { "$defs": { "restoreReport": { "type": "object", "properties": { "@type": { "type": "string", "const": "restoreReport" }, "preData": { "type": "string" }, "postData": { "type": "string" }, "deleteTime": { "type": "string", "format": "date-time" }, "restoreTime": { "type": "string", "format": "date-time" }, "restoreReason": { "type": "string" }, "statements": { "type": "array", "items": { "type": "string" }, "minItems": 1, "maxItems": 2 }, "other": { "type": "string" } }, "required": ["@type", "statements"] } } } 6.2.10. Organisation Role Object The following constraints cannot be expressed in JSON Schema and MUST be enforced by implementations: * type MUST only use values registered in the IANA "EPP Organization Role Values" registry ([RFC8543]). Wullink & Kowalik Expires 7 January 2027 [Page 34] Internet-Draft JSON for RPP July 2026 { "$defs": { "organisationRole": { "type": "object", "properties": { "@type": { "type": "string", "const": "organisationRole" }, "status": { "type": "array", "items": { "type": "string", "enum": ["ok", "linked", "clientLinkProhibited", "serverLinkProhibited"] } }, "roleId": { "type": "string" } }, "required": ["@type"] } } } 6.2.11. Processes Object The Processes Object is a read-only container grouping the currently active Process Objects on the owning resource object, keyed by process type. Each key holds an array of the corresponding Process Object's read representation, per the Aggregation rules. Wullink & Kowalik Expires 7 January 2027 [Page 35] Internet-Draft JSON for RPP July 2026 { "$schema": "https://json-schema.org/draft/2020-12/schema", "$ref": "#/$defs/processes", "$defs": { "processes": { "type": "object", "properties": { "@type": { "type": "string", "const": "processes", "readOnly": true }, "createProcess": { "type": "array", "items": { "$ref": "#/$defs/createProcess.read" }, "readOnly": true }, "renewProcess": { "type": "array", "items": { "$ref": "#/$defs/renewProcess.read" }, "readOnly": true }, "transferProcess": { "type": "array", "items": { "$ref": "#/$defs/transferProcess.read" }, "readOnly": true }, "restoreProcess": { "type": "array", "items": { "$ref": "#/$defs/restoreProcess.read" }, "readOnly": true } }, "required": ["@type"] } } } 6.3. Process Object Schemas 6.3.1. Create Process Object The Create Process Object carries the process-specific inputs for a resource creation operation, such as the requested registration period. It is submitted as an element of the createProcess array under the processes data element of the owning resource object (see Processes Object), following the same Aggregation representation as the other process types. Create request schema (create-only and read-write properties): Wullink & Kowalik Expires 7 January 2027 [Page 36] Internet-Draft JSON for RPP July 2026 { "$schema": "https://json-schema.org/draft/2020-12/schema", "$ref": "#/$defs/createProcess.create", "$defs": { "createProcess.create": { "type": "object", "properties": { "@type": { "type": "string", "const": "createProcess" }, "period": { "$ref": "#/$defs/period" } }, "required": ["@type"] } } } Read response schema (read-only properties): { "$schema": "https://json-schema.org/draft/2020-12/schema", "$ref": "#/$defs/createProcess.read", "$defs": { "createProcess.read": { "type": "object", "properties": { "@type": { "type": "string", "const": "createProcess", "readOnly": true }, "period": { "$ref": "#/$defs/period", "readOnly": true } }, "required": ["@type"] } } } 6.3.2. Renew Process Object Renew request schema (create-only properties): Wullink & Kowalik Expires 7 January 2027 [Page 37] Internet-Draft JSON for RPP July 2026 { "$schema": "https://json-schema.org/draft/2020-12/schema", "$ref": "#/$defs/renewProcess.create", "$defs": { "renewProcess.create": { "type": "object", "properties": { "@type": { "type": "string", "const": "renewProcess" }, "expiryDate": { "type": "string", "format": "date-time" }, "renewalPeriod": { "$ref": "#/$defs/period" } }, "required": ["@type"] } } } Renew response schema (read-only properties): { "$schema": "https://json-schema.org/draft/2020-12/schema", "$ref": "#/$defs/renewProcess.read", "$defs": { "renewProcess.read": { "type": "object", "properties": { "@type": { "type": "string", "const": "renewProcess", "readOnly": true }, "expiryDate": { "type": "string", "format": "date-time", "readOnly": true } }, "required": ["@type"] } } } 6.3.3. Transfer Process Object 6.3.3.1. Create Create request schema (create-only and read-write properties): Wullink & Kowalik Expires 7 January 2027 [Page 38] Internet-Draft JSON for RPP July 2026 { "$schema": "https://json-schema.org/draft/2020-12/schema", "$ref": "#/$defs/transferProcess.create", "$defs": { "transferProcess.create": { "type": "object", "oneOf": [ { "properties": { "@type": { "type": "string", "const": "transferProcess"}, "transferDir": { "type": "string", "const": "push" }, "gainingClientId": { "$ref": "#/$defs/clientIdentifier" } }, "required": [ "@type", "transferDir", "gainingClientId" ] }, { "properties": { "@type": { "type": "string", "const": "transferProcess" }, "transferDir": { "type": "string", "const": "pull" } }, "required": [ "@type", "transferDir" ] } ] } } } 6.3.3.2. Read Read response schema (read-write and read-only properties): Wullink & Kowalik Expires 7 January 2027 [Page 39] Internet-Draft JSON for RPP July 2026 { "$schema": "https://json-schema.org/draft/2020-12/schema", "$ref": "#/$defs/transferProcess.read", "$defs": { "transferProcess.read": { "type": "object", "properties": { "@type": { "type": "string", "const": "transferProcess", "readOnly": true }, "trStatus": { "type": "string", "enum": ["pending", "clientApproved", "clientCancelled", "clientRejected", "serverApproved", "serverCancelled"], "readOnly": true }, "transferDir": { "type": "string", "enum": ["pull", "push"], "readOnly": true }, "gainingClientId": { "$ref": "#/$defs/clientIdentifier", "readOnly": true }, "reqClientId": { "$ref": "#/$defs/clientIdentifier", "readOnly": true}, "requestDate": { "type": "string", "format": "date-time", "readOnly": true }, "actClientId": { "$ref": "#/$defs/clientIdentifier", "readOnly": true }, "actionDate": { "type": "string", "format": "date-time", "readOnly": true } }, "required": [ "@type", "transferDir", "trStatus", "reqClientId", "requestDate", "actClientId", "actionDate" ] } } } 6.3.3.3. Approve The Approve operation MUST always have a request body, which may be an empty JSON object. The server can identify the transfer process to be approved based on the request URL and the authenticated client's permissions. There is no Approve request schema defined in this specification. The Approve response schema MUST equal the read response schema. Wullink & Kowalik Expires 7 January 2027 [Page 40] Internet-Draft JSON for RPP July 2026 6.3.3.4. Cancel The Cancel operation, which is similar to a delete operation, has no request body, the server can identify the transfer process to be cancelled based on the request URL and the authenticated client's permissions. Because the Cancel operation has no request body, it is not possible to extend the request schema with additional properties. The Cancel response schema MUST equal the read response schema or an empty response. 6.3.3.5. Reject Reject request schema: { "$schema": "https://json-schema.org/draft/2020-12/schema", "$ref": "#/$defs/transferProcess.reject", "$defs": { "transferProcess.reject": { "type": "object", "properties": { "@type": { "type": "string", "const": "transferProcess" }, "reason": { "type": "string" } }, "required": ["@type"] } } } Reject response schema MUST equal the read response schema. 6.3.4. Restore Process Object The Restore Process Object represents the current state of a restore request for an object that has entered the Redemption Grace Period (RGP). It is returned as a response for all restore operations. The following constraints cannot be expressed in JSON Schema and MUST be enforced by implementations: * requestDate MUST NOT be present if no restore request has been submitted yet. * reportDate MUST NOT be present if no restore report has been accepted yet. * reportDueDate MUST NOT be present when restoreStatus is not "pendingRestore". Wullink & Kowalik Expires 7 January 2027 [Page 41] Internet-Draft JSON for RPP July 2026 Create request schema (create-only and read-write properties): { "$schema": "https://json-schema.org/draft/2020-12/schema", "$ref": "#/$defs/restoreProcess.create", "$defs": { "restoreProcess.create": { "type": "object", "properties": { "@type": { "type": "string", "const": "restoreProcess" }, "restoreReport": { "$ref": "#/$defs/restoreReport" } }, "required": ["@type"] } } } Read response schema (read-write and read-only properties): { "$schema": "https://json-schema.org/draft/2020-12/schema", "$ref": "#/$defs/restoreProcess.read", "$defs": { "restoreProcess.read": { "type": "object", "properties": { "@type": { "type": "string", "const": "restoreProcess", "readOnly": true }, "restoreStatus": { "type": "string", "enum": ["pendingRestore", "restored", "rgpPendingDelete"], "readOnly": true }, "requestDate": { "type": "string", "format": "date-time", "readOnly": true }, "reportDate": { "type": "string", "format": "date-time", "readOnly": true }, "reportDueDate": { "type": "string", "format": "date-time", "readOnly": true } }, "required": ["@type", "restoreStatus"] } } } 6.4. Domain Name Data Object The Domain Name Data Object represents a domain name and its associated provisioning data. The following constraints cannot be expressed in JSON Schema and MUST be enforced by implementations: Wullink & Kowalik Expires 7 January 2027 [Page 42] Internet-Draft JSON for RPP July 2026 * name MUST be a fully qualified domain name conforming to the syntax described in [RFC1035]. Servers MAY restrict allowable domain names to a specific namespace for which they are authoritative. The implicit trailing dot MUST NOT be included. 6.4.1. Create Create request schema (create-only and read-write properties): Wullink & Kowalik Expires 7 January 2027 [Page 43] Internet-Draft JSON for RPP July 2026 { "$schema": "https://json-schema.org/draft/2020-12/schema", "$ref": "#/$defs/domainObject.create", "$defs": { "domainObject.create": { "type": "object", "properties": { "@type": { "type": "string", "const": "domainName" }, "name": { "type": "string", "writeOnly": true }, "registrant": { "$ref": "#/$defs/contactObject.reference" }, "contacts": { "type": "array", "items": { "type": "object", "properties": { "label": { "type": "string" }, "object": { "$ref": "#/$defs/contactObject.reference" } }, "required": ["label", "object"] } }, "nameservers": { "type": "array", "items": { "$ref": "#/$defs/hostObject.reference" } }, "dns": { "$ref": "#/$defs/dnsData" }, "authInfo": { "$ref": "#/$defs/authInfo" }, "processes": { "type": "object", "properties": { "@type": { "type": "string", "const": "processes" }, "createProcess": { "type": "array", "items": { "$ref": "#/$defs/createProcess.create" }, "maxItems": 1 } }, "required": ["@type"] } }, "required": ["@type", "name"] } } } Wullink & Kowalik Expires 7 January 2027 [Page 44] Internet-Draft JSON for RPP July 2026 6.4.2. Read Read response schema (read-write and read-only properties): Wullink & Kowalik Expires 7 January 2027 [Page 45] Internet-Draft JSON for RPP July 2026 { "$schema": "https://json-schema.org/draft/2020-12/schema", "$ref": "#/$defs/domainObject.read", "$defs": { "domainObject.read": { "type": "object", "properties": { "@type": { "type": "string", "const": "domainName", "readOnly": true }, "name": { "type": "string", "readOnly": true }, "provMetadata": { "$ref": "#/$defs/provMetadata" }, "status": { "type": "array", "items": { "$ref": "#/$defs/status" }, "readOnly": true }, "registrant": { "$ref": "#/$defs/contactObject.reference" }, "contacts": { "type": "array", "items": { "type": "object", "properties": { "label": { "type": "string" }, "object": { "$ref": "#/$defs/contactObject.reference" } }, "required": ["label", "object"] } }, "nameservers": { "type": "array", "items": { "$ref": "#/$defs/hostObject.reference" } }, "dns": { "$ref": "#/$defs/dnsData" }, "subordinateHosts": { "type": "array", "items": { "$ref": "#/$defs/hostObject.reference" }, "readOnly": true }, "expiryDate": { "type": "string", "format": "date-time", "readOnly": true }, "authInfo": { "$ref": "#/$defs/authInfo" }, "processes": { "$ref": "#/$defs/processes", "readOnly": true } }, "required": ["@type", "name", "provMetadata"] } } } Wullink & Kowalik Expires 7 January 2027 [Page 46] Internet-Draft JSON for RPP July 2026 6.4.3. Update Update request schema (read-write properties): { "$schema": "https://json-schema.org/draft/2020-12/schema", "$ref": "#/$defs/domainObject.update", "$defs": { "domainObject.update": { "type": "object", "properties": { "@type": { "type": "string", "const": "domainName" }, "registrant": { "$ref": "#/$defs/contactObject.reference" }, "contacts": { "type": "array", "items": { "type": "object", "properties": { "label": { "type": "string" }, "object": { "$ref": "#/$defs/contactObject.reference" } }, "required": ["label", "object"] } }, "nameservers": { "type": "array", "items": { "$ref": "#/$defs/hostObject.reference" } }, "dns": { "$ref": "#/$defs/dnsData" }, "authInfo": { "$ref": "#/$defs/authInfo" } }, "required": ["@type"] } } } 6.4.4. Renew Renew minimal response schema (only expire date): Wullink & Kowalik Expires 7 January 2027 [Page 47] Internet-Draft JSON for RPP July 2026 { "$schema": "https://json-schema.org/draft/2020-12/schema", "$ref": "#/$defs/renewProcess.create.domain", "$defs": { "renewProcess.create.domain": { "$ref": "#/$defs/renewProcess.create" } } } 6.4.5. Transfer Create request for Domain Transfer Process Object schema (create-only and read-write properties): { "$schema": "https://json-schema.org/draft/2020-12/schema", "$ref": "#/$defs/transferProcess.create.domain", "$defs": { "transferProcess.create.domain": { "allOf": [ { "$ref": "#/$defs/transferProcess.create" }, { "properties": { "transferPeriod": { "$ref": "#/$defs/period" } } } ] } } } Read response for Domain Transfer Process Object schema (read-write and read-only properties): Wullink & Kowalik Expires 7 January 2027 [Page 48] Internet-Draft JSON for RPP July 2026 { "$schema": "https://json-schema.org/draft/2020-12/schema", "$ref": "#/$defs/transferProcess.read.domain", "$defs": { "transferProcess.read.domain": { "allOf": [ { "$ref": "#/$defs/transferProcess.read" }, { "properties": { "expiryDate": { "type": "string", "format": "date-time", "readOnly": true } } } ] } } } Both Approve and Delete (Cancel) operations have no request body, the server can identify the transfer process to be approved or cancelled based on the request URL and the authenticated client's permissions. Delete (Cancel) response Domain Transfer Process Object schema (read- write and read-only properties): { "$schema": "https://json-schema.org/draft/2020-12/schema", "$ref": "#/$defs/transferProcess.delete.domain", "$defs": { "transferProcess.delete.domain": { "$ref": "#/$defs/transferProcess.read.domain" } } } Approve response Domain Transfer Process Object schema (read-write and read-only properties): { "$schema": "https://json-schema.org/draft/2020-12/schema", "$ref": "#/$defs/transferProcess.approve.domain", "$defs": { "transferProcess.approve.domain": { "$ref": "#/$defs/transferProcess.read.domain" } } } Reject request Domain Object schema: Wullink & Kowalik Expires 7 January 2027 [Page 49] Internet-Draft JSON for RPP July 2026 { "$schema": "https://json-schema.org/draft/2020-12/schema", "$ref": "#/$defs/transferProcess.reject.domain", "$defs": { "transferProcess.reject.domain": { "$ref": "#/$defs/transferProcess.reject" } } } Reject response schema (read-write and read-only properties): { "$schema": "https://json-schema.org/draft/2020-12/schema", "$ref": "#/$defs/transferProcess.reject.domain", "$defs": { "transferProcess.reject.domain": { "$ref": "#/$defs/transferProcess.read.domain" } } } 6.4.6. Reference Reference schema (identifier only): { "$schema": "https://json-schema.org/draft/2020-12/schema", "$ref": "#/$defs/domainObject.reference", "$defs": { "domainObject.reference": { "type": "object", "properties": { "@type": { "type": "string", "const": "domainName", "readOnly": true }, "name": { "type": "string", "readOnly": true } }, "required": ["@type", "name"] } } } 6.5. Contact Data Object This document uses version 2.0 of JSContact [RFC9982] for the JSON representation of Contact Data Object contact information. The contact's name, postal address, phone numbers, email addresses, and other contact details are encapsulated in a JSContact Card object embedded in the contactInfo property. Wullink & Kowalik Expires 7 January 2027 [Page 50] Internet-Draft JSON for RPP July 2026 6.5.1. JSContact Profile for RPP Since JSContact is a general-purpose representation of contact data, this document defines a restricted usage profile for use within RPP, see [TODO: ref to RPP JSContact profile here: https://github.com/SIDN/ietf-rpp-jscontact-profile (https://github.com/SIDN/ietf-rpp-jscontact-profile)]. The following constraints cannot be expressed in JSON Schema and MUST be enforced by implementations: * card.name.full MUST be provided in EPP Compatibility Profile. * card.addresses.addr MUST be provided in EPP Compatibility Profile, containing at least countryCode and a "locality" kind component. * card.emails.email.address MUST be provided in EPP Compatibility Profile. * card.addresses[*].countryCode MUST be a valid two-character ISO 3166-1 [ISO3166-1] alpha-2 code when present. 6.5.2. Create Create request schema (create-only and read-write properties): { "$schema": "https://json-schema.org/draft/2020-12/schema", "$ref": "#/$defs/contactObject.create", "$defs": { "contactObject.create": { "type": "object", "properties": { "@type": { "type": "string", "const": "contact" }, "id": { "type": "string" }, "contactInfo": { "$ref": "#/$defs/Card" }, "authInfo": { "$ref": "#/$defs/authInfo" } }, "required": ["@type", "id", "contactInfo"], "unevaluatedProperties": false } } } 6.5.3. Read Read response schema (read-write and read-only properties): Wullink & Kowalik Expires 7 January 2027 [Page 51] Internet-Draft JSON for RPP July 2026 { "$schema": "https://json-schema.org/draft/2020-12/schema", "$ref": "#/$defs/contactObject.read", "$defs": { "contactObject.read": { "type": "object", "properties": { "@type": { "type": "string", "const": "contact", "readOnly": true }, "id": { "type": "string", "readOnly": true }, "provMetadata": { "$ref": "#/$defs/provMetadata" }, "status": { "type": "array", "items": { "$ref": "#/$defs/status" }, "readOnly": true }, "contactInfo": { "$ref": "#/$defs/Card" }, "authInfo": { "$ref": "#/$defs/authInfo" } }, "required": ["@type", "id", "provMetadata", "contactInfo"], "unevaluatedProperties": false } } } 6.5.4. Update Update request schema (read-write properties): { "$schema": "https://json-schema.org/draft/2020-12/schema", "$ref": "#/$defs/contactObject.update", "$defs": { "contactObject.update": { "type": "object", "properties": { "@type": { "type": "string", "const": "contact" }, "contactInfo": { "$ref": "#/$defs/Card" }, "authInfo": { "$ref": "#/$defs/authInfo" }, "processes": { "$ref": "#/$defs/processes", "readOnly": true } }, "required": ["@type", "contactInfo"], "unevaluatedProperties": false } } } Wullink & Kowalik Expires 7 January 2027 [Page 52] Internet-Draft JSON for RPP July 2026 6.5.5. Transfer Transfer create request for Contact Object schema (create-only and read-write properties): { "$schema": "https://json-schema.org/draft/2020-12/schema", "$ref": "#/$defs/transferProcess.create.contact", "$defs": { "transferProcess.create.contact": { "$ref": "#/$defs/transferProcess.create" } } } 6.5.6. Reference Reference schema (identifier only): { "$schema": "https://json-schema.org/draft/2020-12/schema", "$ref": "#/$defs/contactObject.reference", "$defs": { "contactObject.reference": { "type": "object", "properties": { "@type": { "type": "string", "const": "contact", "readOnly": true }, "id": { "type": "string", "readOnly": true } }, "required": ["@type", "id"] } } } 6.6. Host Data Object The following constraints cannot be expressed in JSON Schema and MUST be enforced by implementations: * hostName MUST be a syntactically valid fully qualified host name. * If the host name is subordinate to a domain for which the server is authoritative, the superordinate domain MUST already exist in the server. 6.6.1. Create Create request schema (create-only and read-write properties): Wullink & Kowalik Expires 7 January 2027 [Page 53] Internet-Draft JSON for RPP July 2026 { "$schema": "https://json-schema.org/draft/2020-12/schema", "$ref": "#/$defs/hostObject.create", "$defs": { "hostObject.create": { "type": "object", "properties": { "@type": { "type": "string", "const": "host" }, "hostName": { "type": "string", "format": "hostname" }, "dns": { "$ref": "#/$defs/dnsData" } }, "required": ["@type", "hostName"] } } } 6.6.2. Read Read response schema (read-write and read-only properties): { "$schema": "https://json-schema.org/draft/2020-12/schema", "$ref": "#/$defs/hostObject.read", "$defs": { "hostObject.read": { "type": "object", "properties": { "@type": { "type": "string", "const": "host", "readOnly": true }, "hostName": { "type": "string", "format": "hostname" }, "provMetadata": { "$ref": "#/$defs/provMetadata" }, "status": { "type": "array", "items": { "$ref": "#/$defs/status" }, "readOnly": true }, "dns": { "$ref": "#/$defs/dnsData" }, "processes": { "$ref": "#/$defs/processes", "readOnly": true } }, "required": ["@type", "hostName", "provMetadata"] } } } 6.6.3. Update TODO Wullink & Kowalik Expires 7 January 2027 [Page 54] Internet-Draft JSON for RPP July 2026 6.6.4. Reference Reference schema (identifier only): { "$schema": "https://json-schema.org/draft/2020-12/schema", "$ref": "#/$defs/hostObject.reference", "$defs": { "hostObject.reference": { "type": "object", "properties": { "@type": { "type": "string", "const": "host", "readOnly": true }, "hostName": { "type": "string", "format": "hostname", "readOnly": true } }, "required": ["@type", "hostName"] } } } 6.7. Organisation Data Object The following constraints cannot be expressed in JSON Schema and MUST be enforced by implementations: * id MUST be a server-unique identifier conforming to the Identifier syntax. * status MUST always contain at least one value. pendingCreate, ok, hold, and terminated are mutually exclusive. ok MAY only be combined with linked. * parent, if present, MUST reference a known Organisation Object. Circular parent references MUST be rejected. * contacts keys MUST be contact type values registered in the IANA "EPP Organisation Contact Types" registry ([RFC8543]). 6.7.1. Create Create request schema (create-only and read-write properties): Wullink & Kowalik Expires 7 January 2027 [Page 55] Internet-Draft JSON for RPP July 2026 { "$schema": "https://json-schema.org/draft/2020-12/schema", "$ref": "#/$defs/organisationObject.create", "$defs": { "organisationObject.create": { "type": "object", "properties": { "@type": { "type": "string", "const": "organisation" }, "id": { "$ref": "#/$defs/identifier" }, "roles": { "type": "object", "additionalProperties": { "$ref": "#/$defs/organisationRole" }, "minProperties": 1 }, "parent": { "$ref": "#/$defs/organisationObject.reference" }, "contactInfo": { "$ref": "#/$defs/Card" }, "contacts": { "type": "array", "items": { "type": "object", "properties": { "label": { "type": "string" }, "object": { "$ref": "#/$defs/contactObject.reference" } }, "required": ["label", "object"] } } }, "required": ["@type", "id", "roles"] } } } 6.7.2. Read Read response schema (read-write and read-only properties): Wullink & Kowalik Expires 7 January 2027 [Page 56] Internet-Draft JSON for RPP July 2026 { "$schema": "https://json-schema.org/draft/2020-12/schema", "$ref": "#/$defs/organisationObject.read", "$defs": { "organisationObject.read": { "allOf": [ { "$ref": "#/$defs/organisationObject.create" }, { "properties": { "provMetadata": { "$ref": "#/$defs/provMetadata", "readOnly": true }, "status": { "type": "array", "items": { "$ref": "#/$defs/status" }, "readOnly": true }, "users": { "type": "array", "items": { "type": "object", "properties": { "label": { "type": "string" }, "object": { "$ref": "#/$defs/userObject.reference" } }, "required": ["label", "object"] } } }, "required": ["provMetadata", "status"] } ] } } } 6.7.3. Update Update request schema (read-write properties): Wullink & Kowalik Expires 7 January 2027 [Page 57] Internet-Draft JSON for RPP July 2026 { "$schema": "https://json-schema.org/draft/2020-12/schema", "$ref": "#/$defs/organisationObject.update", "$defs": { "organisationObject.update": { "type": "object", "properties": { "@type": { "type": "string", "const": "organisation" }, "roles": { "type": "object", "additionalProperties": { "$ref": "#/$defs/organisationRole" } }, "parent": { "$ref": "#/$defs/organisationObject.reference" }, "contactInfo": { "$ref": "#/$defs/Card" }, "contacts": { "type": "array", "items": { "type": "object", "properties": { "label": { "type": "string" }, "object": { "$ref": "#/$defs/contactObject.reference" } }, "required": ["label", "object"] } }, "status": { "type": "array", "items": { "$ref": "#/$defs/status" }, "readOnly": true }, "users": { "type": "array", "items": { "type": "object", "properties": { "label": { "type": "string" }, "object": { "$ref": "#/$defs/userObject.reference" } }, "required": ["label", "object"] } } }, "required": ["@type"] } } } Wullink & Kowalik Expires 7 January 2027 [Page 58] Internet-Draft JSON for RPP July 2026 6.7.4. Reference Reference schema (identifier only): { "$schema": "https://json-schema.org/draft/2020-12/schema", "$ref": "#/$defs/organisationObject.reference", "$defs": { "organisationObject.reference": { "type": "object", "properties": { "@type": { "type": "string", "const": "organisation", "readOnly": true }, "id": { "$ref": "#/$defs/identifier", "readOnly": true } }, "required": ["@type", "id"] } } } 6.8. User Data Object The User Data Object represents a user linked to an Organisation Object. The lifecycle of a User Object is bound to its owning Organisation Object. Note: User status values are plain strings, not Status Objects. 6.8.1. Create Create request schema (create-only and read-write properties): Wullink & Kowalik Expires 7 January 2027 [Page 59] Internet-Draft JSON for RPP July 2026 { "$schema": "https://json-schema.org/draft/2020-12/schema", "$ref": "#/$defs/userObject.create", "$defs": { "userObject.create": { "type": "object", "properties": { "@type": { "type": "string", "const": "user" }, "organisationId": { "$ref": "#/$defs/organisationObject.reference" }, "details": { "$ref": "#/$defs/contactObject.reference" }, "status": { "type": "array", "items": { "type": "string", "enum": ["active", "suspended", "deactivated", "pending"] } }, "description": { "type": "string", "const": "user" } }, "required": ["@type", "organisationId", "details"] } } } 6.8.2. Read Read response schema (read-write and read-only properties): Wullink & Kowalik Expires 7 January 2027 [Page 60] Internet-Draft JSON for RPP July 2026 { "$schema": "https://json-schema.org/draft/2020-12/schema", "$ref": "#/$defs/userObject.read", "$defs": { "userObject.read": { "type": "object", "properties": { "@type": { "type": "string", "const": "user", "readOnly": true }, "organisationId": { "$ref": "#/$defs/organisationObject.reference" }, "userId": { "$ref": "#/$defs/identifier", "readOnly": true }, "details": { "$ref": "#/$defs/contactObject.reference" }, "status": { "type": "array", "items": { "type": "string", "enum": ["active", "suspended", "deactivated", "pending"] } }, "description": { "type": "string", "const": "user" } }, "required": ["@type", "userId", "details", "status"] } } } 6.8.3. Update Update request schema (read-write properties): Wullink & Kowalik Expires 7 January 2027 [Page 61] Internet-Draft JSON for RPP July 2026 { "$schema": "https://json-schema.org/draft/2020-12/schema", "$ref": "#/$defs/userObject.update", "$defs": { "userObject.update": { "type": "object", "properties": { "@type": { "type": "string", "const": "user" }, "details": { "$ref": "#/$defs/contactObject.reference" }, "status": { "type": "array", "items": { "type": "string", "enum": ["active", "suspended", "deactivated", "pending"] } } }, "required": ["@type"] } } } 6.8.4. Reference Reference schema (identifier only): { "$schema": "https://json-schema.org/draft/2020-12/schema", "$ref": "#/$defs/userObject.reference", "$defs": { "userObject.reference": { "type": "object", "properties": { "@type": { "type": "string", "const": "user", "readOnly": true }, "id": { "$ref": "#/$defs/identifier", "readOnly": true } }, "required": ["@type", "id"] } } } 7. Examples This section provides examples that follow the JSON representation rules and JSON Schema definitions specified in the previous sections. The examples illustrate typical request and response messages for domain name, contact, and host resources. Wullink & Kowalik Expires 7 January 2027 [Page 62] Internet-Draft JSON for RPP July 2026 7.1. Domain Name 7.1.1. Create Example domain create request: { "@type": "domainName", "name": "example.example", "nameservers": [ { "@type": "host", "hostName": "ns1.example.example" }, { "@type": "host", "hostName": "ns2.example.example" } ], "registrant": { "@type": "contact", "id": "jd1234" }, "contacts": [ { "label": "admin", "object": { "@type": "contact", "id": "sh8013" } }, { "label": "tech", "object": { "@type": "contact", "id": "sh8013" } } ], "authInfo": { "@type": "authInfo", "method": "authinfo", "authdata": "2fooBAR" }, "processes": { "@type": "processes", "createProcess": [ { "@type": "createProcess", "period": { "@type": "period", "value": 2, "unit": "y" } } ] } } Example domain create response from a server with RGP support: Wullink & Kowalik Expires 7 January 2027 [Page 63] Internet-Draft JSON for RPP July 2026 { "@type": "domainName", "name": "example.example", "provMetadata": { "@type": "provMetadata", "repositoryId": "EXAMPLE1-REP", "spClientId": "ClientX", "crClientId": "ClientX", "crDate": "1999-04-03T22:00:00.0Z" }, "status": [ { "@type": "status", "label": "ok" }, { "@type": "status", "label": "addPeriod" } ], "expiryDate": "2001-04-03T22:00:00.0Z" } 7.1.2. Create Process Data Example Create Process Object for a two-year registration period, as embedded above in processes.createProcess: { "@type": "createProcess", "period": { "@type": "period", "value": 2, "unit": "y" } } 7.1.3. Read Example domain read response: { "@type": "domainName", "name": "example.example", "provMetadata": { "@type": "provMetadata", "repositoryId": "EXAMPLE1-REP", "spClientId": "ClientX", "crClientId": "ClientY", "crDate": "1999-04-03T22:00:00.0Z", "upClientId": "ClientX", "upDate": "1999-12-03T09:00:00.0Z", "trDate": "2000-04-08T09:00:00.0Z" }, Wullink & Kowalik Expires 7 January 2027 [Page 64] Internet-Draft JSON for RPP July 2026 "status": [ { "@type": "status", "label": "ok" } ], "registrant": { "@type": "contact", "id": "jd1234" }, "contacts": [ { "label": "admin", "object": { "@type": "contact", "id": "sh8013" } }, { "label": "tech", "object": { "@type": "contact", "id": "sh8013" } } ], "nameservers": [ { "@type": "host", "hostName": "ns1.example.example" }, { "@type": "host", "hostName": "ns2.example.example" } ], "subordinateHosts": [ { "@type": "host", "hostName": "ns1.example.example" }, { "@type": "host", "hostName": "ns2.example.example" } ], "expiryDate": "2005-04-03T22:00:00.0Z", "authInfo": { "@type": "authInfo", "method": "authinfo", "authdata": "2fooBAR" }, "processes": { "@type": "processes", "createProcess": [ { "@type": "createProcess", "period": { "@type": "period", "value": 2, "unit": "y" } } ] } } Wullink & Kowalik Expires 7 January 2027 [Page 65] Internet-Draft JSON for RPP July 2026 7.1.4. Update Example domain update request (read-write properties): { "@type": "domainName", "registrant": { "@type": "contact", "id": "sh8013" }, "authInfo": { "@type": "authInfo", "method": "authinfo", "authdata": "2BARfoo" } } Example domain update response: { "@type": "domainName", "name": "example.example", "provMetadata": { "@type": "provMetadata", "repositoryId": "EXAMPLE1-REP", "spClientId": "ClientX", "crClientId": "ClientY", "crDate": "1999-04-03T22:00:00.0Z", "upClientId": "ClientX", "upDate": "2000-01-15T09:00:00.0Z" }, "status": [ { "@type": "status", "label": "ok" } ], "registrant": { "@type": "contact", "id": "sh8013" } } 7.1.5. Delete The domain delete operation takes the domain name as the resource identifier in the request. No request body is required. Example domain delete response (minimal, server may return full representation): Wullink & Kowalik Expires 7 January 2027 [Page 66] Internet-Draft JSON for RPP July 2026 { "@type": "domainName", "name": "example.example", "provMetadata": { "@type": "provMetadata", "repositoryId": "EXAMPLE1-REP", "spClientId": "ClientX" } } 7.1.6. Renew The renew operation creates a Renew Process Object. The optional expiryDate in the request is the _current_ expiry date, sent by the client for server-side validation to prevent duplicate renewals. The response returns a Renew Process Object containing the _new_ expiry date. Example domain renew request: { "@type": "renewProcess", "expiryDate": "2005-04-03T22:00:00.0Z", "renewalPeriod": { "@type": "period", "value": 5, "unit": "y" } } Example domain renew response: { "@type": "renewProcess", "expiryDate": "2010-04-03T22:00:00.0Z" } 7.1.7. Transfer Request Authorization information for the transfer MUST be conveyed using the RPP-Authorization HTTP header (see Rule 21), not in the JSON request body. Example domain transfer request (pull transfer) Wullink & Kowalik Expires 7 January 2027 [Page 67] Internet-Draft JSON for RPP July 2026 { "@type": "transferProcess", "transferDir": "pull", "transferPeriod": { "@type": "period", "value": 1, "unit": "y" } } Example domain transfer response (Transfer Process Object): { "@type": "transferProcess", "trStatus": "pending", "transferDir": "pull", "reqClientId": "ClientX", "requestDate": "2000-06-08T22:00:00.0Z", "actClientId": "ClientY", "actionDate": "2000-06-13T22:00:00.0Z", "expiryDate": "2002-09-08T22:00:00.0Z" } 7.1.8. Transfer Query Example domain transfer query response (Transfer Process Object): { "@type": "transferProcess", "trStatus": "pending", "transferDir": "pull", "reqClientId": "ClientX", "requestDate": "2000-06-06T22:00:00.0Z", "actClientId": "ClientY", "actionDate": "2000-06-11T22:00:00.0Z", "expiryDate": "2002-09-08T22:00:00.0Z" } 7.1.9. Transfer Approve The Transfer approve operation has request body with an empty JSON object, the server can identify the transfer process to be approved based on the request URL and the authenticated client's permissions. Example domain transfer approve request with empty JSON object: Wullink & Kowalik Expires 7 January 2027 [Page 68] Internet-Draft JSON for RPP July 2026 { "@type": "transferProcess" } The response is the Transfer Process Object, similar to the transfer create and query responses. 7.1.10. Transfer Cancel The Transfer cancel operation has an empty request body, the server can identify the transfer process to be cancelled based on the request URL and the authenticated client's permissions. The response is the Transfer Process Object, similar to the transfer create and query responses. 7.1.11. Transfer Reject Example domain transfer reject request { "@type": "transferProcess", "reason": "Client rejected the transfer request." } The transfer reject response is the Transfer Process Object, similar to the transfer create and query responses. 7.1.12. Restore Request Example domain restore request (without inline report; object transitions to pendingRestore state): { "@type": "restoreProcess" } Example domain restore response (Restore Process Object, server requires a report): { "@type": "restoreProcess", "restoreStatus": "pendingRestore", "requestDate": "2025-01-20T15:30:00.0Z", "reportDueDate": "2025-01-27T15:30:00.0Z" } Wullink & Kowalik Expires 7 January 2027 [Page 69] Internet-Draft JSON for RPP July 2026 Example domain restore request with inline restore report (single- step; object restored immediately): { "@type": "restoreProcess", "restoreReport": { "@type": "restoreReport", "preData": "Domain example.example was registered on 2024-01-15 with registrant jd1234.", "postData": "Domain example.example is being restored with the same registration data.", "deleteTime": "2025-01-10T12:00:00.0Z", "restoreTime": "2025-01-20T15:30:00.0Z", "restoreReason": "Domain deleted in error by client operator.", "statements": [ "The information in this report is true to the best of my knowledge.", "I have a valid reason for restoring this domain name." ] } } Example domain restore response with inline report (Restore Process Object, immediately restored): { "@type": "restoreProcess", "restoreStatus": "restored", "requestDate": "2025-01-20T15:30:00.0Z", "reportDate": "2025-01-20T15:30:00.0Z" } 7.1.13. Restore Report Example domain restore report request: { "@type": "restoreProcess", "restoreReport": { "@type": "restoreReport", "preData": "Domain example.example was registered on 2024-01-15 with registrant jd1234.", "postData": "Domain example.example is being restored with the same registration data.", "deleteTime": "2025-01-10T12:00:00.0Z", "restoreTime": "2025-01-20T15:30:00.0Z", "restoreReason": "Domain deleted in error by client operator.", "statements": [ "The information in this report is true to the best of my knowledge.", "I have a valid reason for restoring this domain name." ] } } Wullink & Kowalik Expires 7 January 2027 [Page 70] Internet-Draft JSON for RPP July 2026 Example domain restore report response (Restore Process Object): { "@type": "restoreProcess", "restoreStatus": "restored", "requestDate": "2025-01-20T15:30:00.0Z", "reportDate": "2025-01-22T09:15:00.0Z" } 7.1.14. Restore Query The Restore Query operation takes no request body (Parameters: None). Example domain restore query response (Restore Process Object, object in pendingRestore state): { "@type": "restoreProcess", "restoreStatus": "pendingRestore", "requestDate": "2025-01-20T15:30:00.0Z", "reportDueDate": "2025-01-27T15:30:00.0Z" } Example domain restore query response (Restore Process Object, object restored): { "@type": "restoreProcess", "restoreStatus": "restored", "requestDate": "2025-01-20T15:30:00.0Z", "reportDate": "2025-01-22T09:15:00.0Z" } 7.2. Contact 7.2.1. Create Example contact create request: Wullink & Kowalik Expires 7 January 2027 [Page 71] Internet-Draft JSON for RPP July 2026 { "@type": "contact", "id": "jd1234", "contactInfo": { "@type": "Card", "version": "2.0", "kind": "individual", "name": { "full": "John Doe", "components": [ { "kind": "given", "value": "John" }, { "kind": "surname", "value": "Doe" } ] }, "organizations": { "org": { "name": "Example Inc." } }, "addresses": { "addr": { "components": [ { "kind": "name", "value": "123 Example Dr., Suite 100" }, { "kind": "locality", "value": "Dulles" }, { "kind": "region", "value": "VA" }, { "kind": "postcode", "value": "20166-6503" }, { "kind": "country", "value": "United States" } ], "countryCode": "US" } }, "phones": { "voice": { "number": "tel:+1-703-555-5555" }, "fax": { "features": { "fax": true }, "number": "tel:+1-703-555-5556" } }, "emails": { "email": { "address": "jdoe@example.example" } } }, "authInfo": { "@type": "authInfo", "method": "authinfo", "authdata": "2fooBAR" } } Example contact create response: Wullink & Kowalik Expires 7 January 2027 [Page 72] Internet-Draft JSON for RPP July 2026 { "@type": "contact", "id": "jd1234", "provMetadata": { "@type": "provMetadata", "repositoryId": "JD1234-REP", "spClientId": "ClientX", "crClientId": "ClientX", "crDate": "1999-04-03T22:00:00.0Z" }, "status": [ { "@type": "status", "label": "ok" } ], "contactInfo": { "@type": "Card", "version": "2.0", "kind": "individual", "name": { "full": "John Doe", "components": [ { "kind": "given", "value": "John" }, { "kind": "surname", "value": "Doe" } ] }, "organizations": { "org": { "name": "Example Inc." } }, "addresses": { "addr": { "components": [ { "kind": "name", "value": "123 Example Dr., Suite 100" }, { "kind": "locality", "value": "Dulles" }, { "kind": "region", "value": "VA" }, { "kind": "postcode", "value": "20166-6503" }, { "kind": "country", "value": "United States" } ], "countryCode": "US" } }, "phones": { "voice": { "number": "tel:+1-703-555-5555" }, "fax": { "features": { "fax": true }, "number": "tel:+1-703-555-5556" } }, "emails": { "email": { "address": "jdoe@example.example" } } } } Wullink & Kowalik Expires 7 January 2027 [Page 73] Internet-Draft JSON for RPP July 2026 7.2.2. Read Example contact read response: { "@type": "contact", "id": "jd1234", "provMetadata": { "@type": "provMetadata", "repositoryId": "JD1234-REP", "spClientId": "ClientX", "crClientId": "ClientX", "crDate": "1999-04-03T22:00:00.0Z", "upClientId": "ClientX", "upDate": "2000-01-15T09:00:00.0Z" }, "status": [ { "@type": "status", "label": "ok" } ], "contactInfo": { "@type": "Card", "version": "2.0", "kind": "individual", "name": { "full": "John Doe", "components": [ { "kind": "given", "value": "John" }, { "kind": "surname", "value": "Doe" } ] }, "organizations": { "org": { "name": "Example Inc." } }, "addresses": { "addr": { "components": [ { "kind": "name", "value": "123 Example Dr., Suite 100" }, { "kind": "locality", "value": "Dulles" }, { "kind": "region", "value": "VA" }, { "kind": "postcode", "value": "20166-6503" }, { "kind": "country", "value": "United States" } ], "countryCode": "US" } }, "phones": { "voice": { "number": "tel:+1-703-555-5555" } }, Wullink & Kowalik Expires 7 January 2027 [Page 74] Internet-Draft JSON for RPP July 2026 "emails": { "email": { "address": "jdoe@example.example" } } } } 7.2.3. Update Example contact update request: { "@type": "contact", "contactInfo": { "@type": "Card", "version": "2.0", "addresses": { "addr": { "components": [ { "kind": "name", "value": "456 New Street, Suite 200" }, { "kind": "locality", "value": "Reston" }, { "kind": "region", "value": "VA" }, { "kind": "postcode", "value": "20190" }, { "kind": "country", "value": "United States" } ], "countryCode": "US" } }, "phones": { "voice": { "number": "tel:+1-703-555-5556" } }, "emails": { "email": { "address": "jdoe-new@example.example" } } } } Example contact update response: { "@type": "contact", "id": "jd1234", "provMetadata": { "@type": "provMetadata", "repositoryId": "JD1234-REP", "spClientId": "ClientX", "crClientId": "ClientX", "crDate": "1999-04-03T22:00:00.0Z", "upClientId": "ClientX", Wullink & Kowalik Expires 7 January 2027 [Page 75] Internet-Draft JSON for RPP July 2026 "upDate": "2025-06-01T10:00:00.0Z" }, "status": [ { "@type": "status", "label": "ok" } ], "contactInfo": { "@type": "Card", "version": "2.0", "kind": "individual", "name": { "full": "John Doe", "components": [ { "kind": "given", "value": "John" }, { "kind": "surname", "value": "Doe" } ] }, "organizations": { "org": { "name": "Example Inc." } }, "addresses": { "addr": { "components": [ { "kind": "name", "value": "456 New Street, Suite 200" }, { "kind": "locality", "value": "Reston" }, { "kind": "region", "value": "VA" }, { "kind": "postcode", "value": "20190" }, { "kind": "country", "value": "United States" } ], "countryCode": "US" } }, "phones": { "voice": { "number": "tel:+1-703-555-5556" } }, "emails": { "email": { "address": "jdoe-new@example.example" } } } } 7.2.4. Delete The contact delete operation takes the contact identifier as the resource identifier. No request body is required. Wullink & Kowalik Expires 7 January 2027 [Page 76] Internet-Draft JSON for RPP July 2026 7.2.5. Transfer Request Authorization information for the transfer MUST be conveyed using the RPP-Authorization HTTP header (see Rule 21), not in the JSON request body. Example contact transfer request (pull transfer) { "@type": "transferProcess", "transferDir": "pull" } Example contact transfer response (Transfer Process Object): { "@type": "transferProcess", "trStatus": "pending", "transferDir": "pull", "reqClientId": "ClientX", "requestDate": "2000-06-08T22:00:00.0Z", "actClientId": "ClientY", "actionDate": "2000-06-13T22:00:00.0Z" } 7.2.6. Transfer Query Example contact transfer query response (Transfer Process Object): { "@type": "transferProcess", "trStatus": "pending", "transferDir": "pull", "reqClientId": "ClientX", "requestDate": "2000-06-06T22:00:00.0Z", "actClientId": "ClientY", "actionDate": "2000-06-11T22:00:00.0Z" } 7.2.7. Transfer Cancel / Approve Transfer cancel and approve responses return the Transfer Process Object. The response structure is the same as the Transfer Query response above. The trStatus value reflects the outcome of the operation (e.g. "clientCancelled", "clientRejected", or "clientApproved"). Wullink & Kowalik Expires 7 January 2027 [Page 77] Internet-Draft JSON for RPP July 2026 7.2.8. Transfer Reject Example Contact Transfer Reject request { "@type": "transferProcess", "reason": "Client rejected the transfer request." } The transfer reject response is the Transfer Process Object, similar to the transfer create and query responses. 7.3. Host 7.3.1. Create Example host create request: { "@type": "host", "hostName": "ns1.example.example", "dns": { "@type": "dnsData", "records": [ { "@type": "dnsRecord", "name": "@", "type": "ns", "rdata": { "nsdname": "ns1.example.example." } }, { "@type": "dnsRecord", "name": "ns1.example.example.", "type": "a", "rdata": { "address": "192.0.2.1" } }, { "@type": "dnsRecord", "name": "ns1.example.example.", "type": "aaaa", "rdata": { "address": "2001:db8::1" } } ] } } Example host create response: Wullink & Kowalik Expires 7 January 2027 [Page 78] Internet-Draft JSON for RPP July 2026 { "@type": "host", "hostName": "ns1.example.example", "provMetadata": { "@type": "provMetadata", "repositoryId": "NS1EXAMPLE-REP", "spClientId": "ClientX", "crClientId": "ClientX", "crDate": "1999-04-03T22:00:00.0Z" }, "status": [ { "@type": "status", "label": "ok" } ], "dns": { "@type": "dnsData", "records": [ { "@type": "dnsRecord", "name": "@", "type": "ns", "rdata": { "nsdname": "ns1.example.example." } }, { "@type": "dnsRecord", "name": "ns1.example.example.", "type": "a", "rdata": { "address": "192.0.2.1" } }, { "@type": "dnsRecord", "name": "ns1.example.example.", "type": "aaaa", "rdata": { "address": "2001:db8::1" } } ] } } 7.3.2. Read Example host read response: Wullink & Kowalik Expires 7 January 2027 [Page 79] Internet-Draft JSON for RPP July 2026 { "@type": "host", "hostName": "ns1.example.example", "provMetadata": { "@type": "provMetadata", "repositoryId": "NS1EXAMPLE-REP", "spClientId": "ClientX", "crClientId": "ClientY", "crDate": "1999-04-03T22:00:00.0Z" }, "status": [ { "@type": "status", "label": "ok" } ], "dns": { "@type": "dnsData", "records": [ { "@type": "dnsRecord", "name": "@", "type": "ns", "rdata": { "nsdname": "ns1.example.example." } }, { "@type": "dnsRecord", "name": "ns1.example.example.", "type": "a", "rdata": { "address": "192.0.2.1" } } ] } } 7.3.3. Update Example host update request: Wullink & Kowalik Expires 7 January 2027 [Page 80] Internet-Draft JSON for RPP July 2026 { "@type": "host", "hostName": "ns1.example.example", "dns": { "@type": "dnsData", "records": [ { "@type": "dnsRecord", "name": "@", "type": "ns", "rdata": { "nsdname": "ns1.example.example." } }, { "@type": "dnsRecord", "name": "ns1.example.example.", "type": "a", "rdata": { "address": "198.51.100.1" } } ] } } 7.3.4. Delete The host delete operation takes the host name as the resource identifier. No request body is required. The server SHOULD reject the request if the host object is associated with any domain name objects. 7.3.5. Restore Request Example host restore request (without inline report; object transitions to pendingRestore state): { "@type": "restoreProcess" } Example host restore request response (Restore Process Object, server requires a report): { "@type": "restoreProcess", "restoreStatus": "pendingRestore", "requestDate": "2025-01-20T15:30:00.0Z", "reportDueDate": "2025-01-27T15:30:00.0Z" } Wullink & Kowalik Expires 7 January 2027 [Page 81] Internet-Draft JSON for RPP July 2026 Example host restore request with inline restore report (single-step; object restored immediately): { "@type": "restoreProcess", "restoreReport": { "@type": "restoreReport", "preData": "Host ns1.example.example was registered on 2024-01-15 by ClientX.", "postData": "Host ns1.example.example is being restored with the same registration data.", "deleteTime": "2025-01-10T12:00:00.0Z", "restoreTime": "2025-01-20T15:30:00.0Z", "restoreReason": "Host deleted in error by client operator.", "statements": [ "The information in this report is true to the best of my knowledge.", "I have a valid reason for restoring this host object." ] } } Example host restore response with inline report (Restore Process Object, immediately restored): { "@type": "restoreProcess", "restoreStatus": "restored", "requestDate": "2025-01-20T15:30:00.0Z", "reportDate": "2025-01-20T15:30:00.0Z" } 7.3.6. Restore Report Example host restore report request: { "@type": "restoreProcess", "restoreReport": { "@type": "restoreReport", "preData": "Host ns1.example.example was registered on 2024-01-15 by ClientX.", "postData": "Host ns1.example.example is being restored with the same registration data.", "deleteTime": "2025-01-10T12:00:00.0Z", "restoreTime": "2025-01-20T15:30:00.0Z", "restoreReason": "Host deleted in error by client operator.", "statements": [ "The information in this report is true to the best of my knowledge.", "I have a valid reason for restoring this host object." ] } } Wullink & Kowalik Expires 7 January 2027 [Page 82] Internet-Draft JSON for RPP July 2026 Example host restore report response (Restore Process Object): { "@type": "restoreProcess", "restoreStatus": "restored", "requestDate": "2025-01-20T15:30:00.0Z", "reportDate": "2025-01-22T09:15:00.0Z" } 7.3.7. Restore Query The Restore Query operation takes no request body (Parameters: None). Example host restore query response (Restore Process Object, object in pendingRestore state): { "@type": "restoreProcess", "restoreStatus": "pendingRestore", "requestDate": "2025-01-20T15:30:00.0Z", "reportDueDate": "2025-01-27T15:30:00.0Z" } Example host restore query response (Restore Process Object, object restored): { "@type": "restoreProcess", "restoreStatus": "restored", "requestDate": "2025-01-20T15:30:00.0Z", "reportDate": "2025-01-22T09:15:00.0Z" } 7.4. Organisation 7.4.1. Create Example organisation create request: Wullink & Kowalik Expires 7 January 2027 [Page 83] Internet-Draft JSON for RPP July 2026 { "@type": "organisation", "id": "ORG-12345", "roles": { "registrar": { "@type": "organisationRole", "roleId": "1234" } }, "parent": { "@type": "organisation", "id": "ORG-9999" }, "contactInfo": { "@type": "Card", "version": "2.0", "kind": "org", "name": { "full": "Example Registrar Inc." }, "addresses": { "addr": { "components": [ { "kind": "name", "value": "Meander 501" }, { "kind": "locality", "value": "Arnhem" }, { "kind": "region", "value": "Gelderland" }, { "kind": "postcode", "value": "6825MD" }, { "kind": "country", "value": "Netherlands" } ], "countryCode": "NL" } }, "emails": { "email": { "address": "registrar@example.example" } } }, "contacts": [ { "label": "admin", "object": { "@type": "contact", "id": "CID-1001" } }, { "label": "tech", "object": { "@type": "contact", "id": "CID-1002" } } ] } Example organisation create response: { "@type": "organisation", "id": "ORG-12345", "provMetadata": { "@type": "provMetadata", "repositoryId": "ORG12345-REP", "spClientId": "ClientX", Wullink & Kowalik Expires 7 January 2027 [Page 84] Internet-Draft JSON for RPP July 2026 "crClientId": "ClientX", "crDate": "2025-03-15T10:00:00.0Z" }, "status": [ { "@type": "status", "label": "ok" } ], "roles": { "registrar": { "@type": "organisationRole", "status": ["ok"], "roleId": "1234" } }, "parent": { "@type": "organisation", "id": "ORG-9999" }, "contactInfo": { "@type": "Card", "version": "2.0", "kind": "org", "name": { "full": "Example Registrar Inc." }, "addresses": { "addr": { "components": [ { "kind": "name", "value": "Meander 501" }, { "kind": "locality", "value": "Arnhem" }, { "kind": "region", "value": "Gelderland" }, { "kind": "postcode", "value": "6825MD" }, { "kind": "country", "value": "Netherlands" } ], "countryCode": "NL" } }, "emails": { "email": { "address": "registrar@example.example" } } }, "contacts": [ { "label": "admin", "object": { "@type": "contact", "id": "CID-1001" } }, { "label": "tech", "object": { "@type": "contact", "id": "CID-1002" } } ], "users": [ { "label": "admin", "object": { "@type": "user", "id": "UID-5001" } } ] } Wullink & Kowalik Expires 7 January 2027 [Page 85] Internet-Draft JSON for RPP July 2026 7.4.2. Read Example organisation read response: { "@type": "organisation", "id": "ORG-12345", "provMetadata": { "@type": "provMetadata", "repositoryId": "ORG12345-REP", "spClientId": "ClientX", "crClientId": "ClientX", "crDate": "2025-03-15T10:00:00.0Z", "upClientId": "ClientX", "upDate": "2025-06-01T08:30:00.0Z" }, "status": [ { "@type": "status", "label": "linked" } ], "roles": { "registrar": { "@type": "organisationRole", "status": ["ok"], "roleId": "1234" } }, "parent": { "@type": "organisation", "id": "ORG-9999" }, "contactInfo": { "@type": "Card", "version": "2.0", "kind": "org", "name": { "full": "Example Registrar Inc." }, "addresses": { "addr": { "components": [ { "kind": "name", "value": "Meander 501" }, { "kind": "locality", "value": "Arnhem" }, { "kind": "region", "value": "Gelderland" }, { "kind": "postcode", "value": "6825MD" }, { "kind": "country", "value": "Netherlands" } ], "countryCode": "NL" } }, "emails": { "email": { "address": "registrar@example.example" } Wullink & Kowalik Expires 7 January 2027 [Page 86] Internet-Draft JSON for RPP July 2026 } }, "contacts": [ { "label": "admin", "object": { "@type": "contact", "id": "CID-1001" } }, { "label": "tech", "object": { "@type": "contact", "id": "CID-1002" } } ], "users": [ { "label": "admin", "object": { "@type": "user", "id": "UID-5001" } } ] } 7.4.3. Update Example organisation update request: { "@type": "organisation", "roles": { "registrar": { "@type": "organisationRole", "status": ["clientLinkProhibited"], "roleId": "1234" } }, "status": [ { "@type": "status", "label": "clientLinkProhibited" } ], "contacts": [ { "label": "admin", "object": { "@type": "contact", "id": "CID-2001" } }, { "label": "tech", "object": { "@type": "contact", "id": "CID-2002" } } ] } 7.4.4. Delete The organisation delete operation takes the organisation identifier as the resource identifier. No request body is required. The server MUST reject the request if the organisation object is associated with any other objects. 7.4.5. Reference Example organisation reference (used when referencing an organisation from another object): Wullink & Kowalik Expires 7 January 2027 [Page 87] Internet-Draft JSON for RPP July 2026 { "@type": "organisation", "id": "ORG-12345" } 7.5. User 7.5.1. Create Example user create request: { "@type": "user", "details": { "@type": "contact", "id": "USER-1234" }, "status": ["active"] } Example user create response: { "@type": "user", "userId": "UID-5001", "details": { "@type": "contact", "id": "USER-1234" }, "status": ["active"] } 7.5.2. Read Example user read response: { "@type": "user", "organisationId": { "@type": "organisation", "id": "ORG-12345" }, "userId": "UID-5001", "details": { "@type": "contact", "id": "USER-1234" }, "status": ["active"] } 7.5.3. Update Example user update request (suspend the user): { "@type": "user", "status": ["suspended"] } Wullink & Kowalik Expires 7 January 2027 [Page 88] Internet-Draft JSON for RPP July 2026 7.5.4. Delete The user delete operation takes the user identifier as the resource identifier in the context of the owning organisation. No request body is required. 7.5.5. Reference Example user reference (used when referencing a user from an organisation object): { "@type": "user", "id": "UID-5001" } 8. IANA Considerations TODO 9. Internationalization Considerations TODO 10. Security Considerations TODO 11. Acknowledgments TODO 12. Change History 12.1. Version draft-wullink-rpp-json-02 to draft-ietf-rpp-json-00 * Added "Update Rules" section, describing update requests (Issue #54) * Added schema and examples for Transfer approve/reject/cancel operations (Issue #28) * Added Organisation and User Object JSON schemas and examples. (Issue #57) * Added schema and examples for the Renew Process Object. (Issue #45) * Added representation for embedding of process data in uniform interface operations (especially create). (Issue #60) * Added JSContact as External Type Embedding (Issue #43). Wullink & Kowalik Expires 7 January 2027 [Page 89] Internet-Draft JSON for RPP July 2026 12.2. Version 01 to 02 * Adjust rule 19 and all schemas to match it. 12.3. Version 00 to 01 * Updated all examples and schemas to be based on RPP Data Object and no longer on EPP XML schemas. (Issue #15) * Updated labelled and dictionary aggregation rules (Issue #17) * Added required "@type" property to all JSON Schema definitions. (Issue #20) * Updated all example domain names to use the .example TLD. (Issue #26) 13. References 13.1. Normative References [I-D.ietf-rpp-core] Wullink, M. and P. Kowalik, "RESTful Provisioning Protocol (RPP)", Work in Progress, Internet-Draft, draft-ietf-rpp- core-00, 6 July 2026, . [I-D.ietf-rpp-data-objects] Kowalik, P. and M. Wullink, "RESTful Provisioning Protocol (RPP) Data Objects", Work in Progress, Internet-Draft, draft-ietf-rpp-data-objects-01, 3 July 2026, . [ISO3166-1] International Organization for Standardization, "Codes for the representation of names of countries and their subdivisions - Part 1: Country code", ISO 3166-1:2020, 2020, . [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, . Wullink & Kowalik Expires 7 January 2027 [Page 90] Internet-Draft JSON for RPP July 2026 [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, . [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, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, . [RFC5732] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Host Mapping", STD 69, RFC 5732, DOI 10.17487/RFC5732, August 2009, . [RFC6902] Bryan, P., Ed. and M. Nottingham, Ed., "JavaScript Object Notation (JSON) Patch", RFC 6902, DOI 10.17487/RFC6902, April 2013, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC8543] Zhou, L., Kong, N., Yao, J., Gould, J., and G. Zhou, "Extensible Provisioning Protocol (EPP) Organization Mapping", RFC 8543, DOI 10.17487/RFC8543, March 2019, . [RFC9553] Stepanek, R. and M. Loffredo, "JSContact: A JSON Representation of Contact Data", RFC 9553, DOI 10.17487/RFC9553, May 2024, . Wullink & Kowalik Expires 7 January 2027 [Page 91] Internet-Draft JSON for RPP July 2026 [RFC9982] Stepanek, R., "JSContact Version 2.0: A JSON Representation of Contact Data", RFC 9982, DOI 10.17487/RFC9982, May 2026, . 13.2. Informative References [I-D.simmen-rpp-dns-data] Simmen, C. and P. Kowalik, "DNS data representation for use in RESTful Provisioning Protocol (RPP)", Work in Progress, Internet-Draft, draft-simmen-rpp-dns-data-01, 20 October 2025, . [JSON-SCHEMA] JSON Schema, "JSON Schema: A Media Type for Describing JSON Documents", 2020, . [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 Maarten Wullink SIDN Labs Email: maarten.wullink@sidn.nl URI: https://sidn.nl/ Pawel Kowalik DENIC Email: pawel.kowalik@denic.de URI: https://denic.de/ Wullink & Kowalik Expires 7 January 2027 [Page 92]