RESTful Provisioning Protocol (RPP) Data Objects

Introduction The RESTful Provisioning Protocol (RPP) defines a set of data objects used to represent and manage registry resources, including domain names, contacts, hosts, organisations, users, and messages, as well as the discovery and profile objects that describe server capabilities. This initial list is not exhaustive; additional resource and component objects MAY be defined in future revisions or introduced via IANA registration to support new features and operational needs. In accordance with the RPP architecture , a core architectural principle is the clear distinction between the abstract data model and its concrete data representation. The data model defines the logical structure, relationships, and constraints of the objects, independent of formatting. The data representation defines how these abstract concepts are expressed in specific formats (e.g., JSON, XML, or YAML). This document focuses on the data model of RPP objects and operations on them, including the data model of operation inputs, outputs as well as the necessary business logic of state transitions. This separation of concerns ensures the protocol maintains a stable semantic foundation that can be consistently implemented across different media types and easily adapted to new representation formats. For instance, the model defines a contact's name as a required string type, but it remains agnostic as to whether that string is ultimately encoded as a JSON property or an XML element.

Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. The following terms related to the relationship between host objects and domain objects are used as defined in :

Subordinate host: A host name object is a subordinate host of a domain when the host name consists of one or more labels followed by the name of that domain, for example, host ns1.domain.example is a subordinate host of domain domain.example.
Superordinate domain: A domain name object is the superordinate domain of a host when the name of the host consists of one or more labels followed by the name of that domain, for example, domain domain.example is the superordinate domain of host ns1.domain.example.
Internal host: A host whose name belongs to the namespace of the repository in which the host is being used for delegation purposes.
External host: A host whose name does not belong to the namespace of the repository in which the host is being used for delegation purposes.
Object Authorisation: Authorisation data related to the object beyond the default client-level authorisation accompanying the request, in order to authorise operations on the object. Typically it is a value related to or derived from an Authorisation Information Object provisioned with the object.
Data Object: A top-level provisioned resource object that has an independent lifecycle and identity in the registry. Data Objects carry data elements describing the resource and define the set of operations that can be performed on them.
Component Object: A reusable data structure that carries data only, with no operations of its own. Component Objects are embedded within Data Objects or other objects to avoid repetition of common data patterns.
Process Object: An object that represents a long-running or multi-step operation initiated on a Data Object. Process Objects carry operation-related state and data, and may define their own operations to interact with the process. They have no independent existence - their lifecycle is bound to the owning Data Object.
Owner Data Object: A Data Object which a process (represented as Process Object) was initiated upon and which owns this Process Object.
Unique Identifier: The data element of an object whose value uniquely identifies an instance of that object within its applicable scope. The scope is defined by the object: for a Data Object it is typically the server, whereas for a Process Object it is the Owner Data Object. An object definition names its Unique Identifier explicitly in the object preamble. Objects that have no independent identity, such as component objects embedded within another object, have no Unique Identifier.
Input Data Element: A data element that a client provides as input to a specific operation, in addition to the identifier or data elements of the object the operation targets, and that carries content the operation acts upon. An input data element is defined as part of the operation definition and is not part of the state of the object. An input data element is described using the attributes defined in , except Direct Access, and Visibility, which do not apply.

Parameter A data element that a client provides with an operation to control how the server performs the operation or which data it returns. Unlike an Input Data Element, a parameter does not carry content that the operation acts upon. A parameter is not part of the state of the object and is never returned as part of the object. A parameter is described using the same attributes as an Input Data Element, and its definition specifies the behaviour of the operation when the parameter is absent.

Label Generation Ruleset (LGR): A set of rules defining the valid labels for a registry, including the permitted repertoire, contextual rules, and, where applicable, variant mappings. Also historically known as IDN tables.

Resource Definition Principles

Primitive Data Types RPP data elements use strict typing, meaning that each element must conform exactly to its declared primitive data type, and type violations MUST be treated as errors by implementations. The exact specifications for these types, including allowed ranges, encoding, and formatting, are determined by the representation format used (e.g., JSON, XML, CBOR). New RPP non-primitive data types based on existing primitive data types MAY be defined to support additional features.

String A String is a sequence of Unicode characters. Usages MAY impose additional constraints on string values, such as maximum length or allowed character sets, based on specific data element definitions. An example of a string is "host.example".

Integer An Integer is a whole number, positive or negative. Usages MAY impose additional constraints on integer values, such as minimum and maximum allowable values, based on specific data element definitions. An example of an integer is 42.

Boolean A Boolean represents a logical true or false value. An example of a boolean is true or false, but it MAY be different depending on the native encoding of boolean values in the representation.

Decimal A Decimal is a number providing an exact, base-10 representation of fractional values within a defined precision. Usage of this type MUST impose additional constraints on decimal values, such as precision or range, based on specific data element definitions. An example of a decimal is 3.14159.

Date A Date is a full-date calendar date as described in , an example of a date is 2025-10-27.

Timestamp Timestamp (Date and time attribute) values MUST be represented in Coordinated Universal Time (UTC) using the Gregorian calendar in date-time form as defined in . In EPP Compatibility Profile upper case "T" and "Z" characters MUST be used. An example of a timestamp is 2025-10-27T09:42:51Z.

URL A Uniform Resource Locator (URL) as defined in . An example of a URL is "https://host.example".

Binary Raw binary data, implementations MAY choose how to encode the binary data, for example as base64 or hexadecimal string. An example of binary data encoded as base64 is "UlBQIFNheXMgSGk=".

Dictionary Notation: Dictionary[Value Type] A Dictionary is a collection of key-value pairs where keys are unique Strings and values are of the specified primitive data type. Usages MUST define the constraints on allowed keys and values. A Dictionary differs from an Dictionary Aggregation in that it maps String keys to primitive values rather than to Component or Resource Objects.

Object An Object is a composite structure containing named properties. The set of allowed property names, their data types, and their constraints are determined by the data element definition that uses this type. Usages MUST specify the expected structure, including any required or optional properties. An Object differs from a Component Object in that it is defined inline as part of a data element rather than being a standalone reusable definition registered separately.

Fully Qualified Domain Name (FQDN) A String that represents a Fully Qualified Domain Name (FQDN) that conforms to the description included in section 2 of and includes the following additional restrictions:

The trailing dot required when these names are stored in a DNS zone is implicit and MUST NOT be used in RPP, with the exception of the name element of the DNS Resource Record Object.
Internationalized domain names MUST be represented in ASCII Compatible Encoding (ACE) using the A-label, defined in Section 2.3.2.1 of [RFC5890]
Case-insensitive comparison MUST be used when comparing two FQDNs.
All representations generated by the server are to be in lowercase.

Data Element Abstraction Each data object is composed of logical data elements. A data element is a logical unit of information identified by a stable name, independent of its representation in any given media type. The definition for each element specifies its logical name, purpose, cardinality, data type, and constraints. The data type of a data element may also be a reference to another data object, using the target object's stable name.

Extensibility The RPP data model is designed to be extensible. Extensions MAY introduce new data objects, add new data elements or associations to existing objects, define new processes on existing or new data objects, and define new operations or extend the inputs and outputs of existing operations.

Standardised and Private Extensions RPP distinguishes between standardised and private extensions:

Standardised extensions MUST be registered with IANA, as described in the IANA Considerations section of this document and in . Registration ensures global uniqueness of extension identifiers and promotes interoperability across implementations.
Private (non-standardised) extensions MAY be defined for use within specific implementations or organisations. Private extensions are not required to be registered with IANA, but MUST still use unique identifiers that are unlikely to conflict with standardised extensions or other private extensions. The use of reverse domain notation as a prefix (e.g., org.example.rpp.myElement) is RECOMMENDED for private extension identifiers to avoid naming collisions.

Extension Points The following aspects of the data model are extensible:

New data objects: Additional resource or component objects MAY be defined by extensions and registered with IANA.
New data elements: Extensions MAY add new data elements to existing data objects. Such elements follow the same Data Element Semantics as core data elements.
New associations: Extensions MAY introduce new associations between existing or new objects.
New operations: Extensions MAY define entirely new operations on existing or new data objects.
New processes: Extensions MAY define new Process Objects and MAY declare that existing or new Data Objects support them. A new Process Object MUST extend the Base Process Object, either directly or through another Process Object.
Extended operation inputs and outputs: Extensions MAY add new data elements to the inputs or outputs of existing operations.

When an extension adds data elements, input data elements, or parameters to a core object or operation, these additions MUST NOT alter the semantics or constraints of existing core data elements.

Data Element Semantics The definition of each data element within an object consists of the following attributes:

Name: A human-readable name for the data element.
Identifier: A machine-readable, unique identifier for the element, using camelCase notation.
Cardinality: Specifies the number of times an element may appear. The notation is as follows:
- 1 for exactly one
- 0-1 for zero or one
- 0+ for zero or more
- 1+ for one or more
- and X-Y for at least X and at most Y, where X and Y are non-negative integers, X is less than Y, and Y is greater than 1, e.g. 1-2 for one or two
Data Type: Defines the element's data structure, which can be a primitive type, a Common Data Type or a reference to another component object.
Description: Explains the purpose of the data element and any other relevant information.
Constraints: Provides specific validation rules or limitations on top of the data type itself, such as value ranges.
Mutability: Defines the lifecycle of the data element's value. It MUST be one of the following:
- create-only: The element's value is provided during the object's creation and cannot be modified thereafter. After object's creation the element behaves like read-only element.
- read-only: The element's value is managed by the server. It cannot be set or modified directly by the client, though it may change as a result of server-side operations.
- read-write: The element's value can be set and modified by the client.
Direct Access: An optional flag indicating whether the associated object or objects are additionally exposed as an addressable sub-resource of the containing object. When set to true, the associated object or objects are exposed as a sub-resource that can be addressed independently of the containing object, in addition to their inline representation within it. When absent or set to false, the element is accessed only inline. The default value is false.

A data element is required when the lower bound of its cardinality is greater than zero (1, 1+, or X-Y with X greater than 0); otherwise it is optional. The Direct Access flag is applicable only to a data element whose Data Type is an association (Aggregation, Composition, Labelled Aggregation, Dictionary Aggregation, Labelled Composition, or Dictionary Composition) with a Data Object, Component Object, or Process Object, of any cardinality. Where such a data element has a cardinality greater than 1, the associated object type MUST define a Unique Identifier, so that an individual associated object can be addressed unambiguously among the collection. * Visibility: An optional attribute indicating whether the data element is included in operation output by default. It MUST be one of the following: * default: The element is included in the output of any operation returning the containing object, subject to authorisation and server policy. This value applies when the attribute is absent. * onDemand: The element is included in the output only when the client explicitly requests it using the Include Elements parameter (see ), subject to authorisation and server policy. The Visibility attribute affects operation output only. It does not affect whether a client can provide the element as input.

Inheritance A Data Object, Component Object or Process Object (the "derived object") MAY inherit the data elements and operations of another object (the "base object"). Inheritance is denoted in the preamble of the derived object's definition using the Extends keyword, whose value is the name of the base object, for example: The following rules apply:

Single inheritance: an object MUST extend at most one base object.
Transitivity: the base object MAY itself extend another object. Inheritance is transitive, so a derived object inherits the data elements and operations of every ancestor in its chain. An object MUST NOT directly or indirectly extend itself.
Inherited content: a derived object has all data elements of its base object, including their cardinality, mutability, data type and constraints, and supports all operations of its base object. Inherited data elements and operations are not repeated in the derived object's definition.
Additions: a derived object MAY define additional data elements and operations. It MUST NOT define a data element whose identifier is already defined by any of its ancestors. A derived object MAY modify the inherited operation input and output data as needed.
Polymorphism: where a data element or operation refers to a base object, any object that directly or indirectly extends the base object MAY be used in its place.
Abstract objects: an object MAY be declared abstract using the Abstract keyword in the preamble of its definition, with the value true. When the Abstract keyword is absent or set to false, the object is not abstract. An abstract object serves only as a base object for its derived objects. Wherever a data element or operation refers to an abstract object, an instance of a non-abstract object that directly or indirectly extends it is used in its place. A client MUST NOT provide, and a server MUST NOT return, an instance whose own type is an abstract object. The Abstract keyword is not inherited.

Reserved Property Names Data object definitions MUST NOT define properties whose names begin with the @ character. Names beginning with @ are reserved for use by representation specifications. This prohibition applies to all data object types: resource objects, component objects, and process objects.

Operations For each data object a set of possible operations is defined together with their respective input and output data.

Authorisation For each operation authorisation requirements and operation behaviour are specified. Wherever "Object Authorisation" is mentioned, it means that an operation MAY accept or require additional authorisation data related to the object beyond default client-level authorisation, or that an operation MAY result in different processing or response if such authorisation is provided.

Operation Input and Output The input and output of an operation are declared by the Input and Output attributes of the operation definition. The value of each attribute is either a literal (None) or a list of items, each of one of the following kinds:

Reference: a reference to the context of operation or process. It can contain either a literal value This Object for the object that defines the operation, or literal value Owner Data Object for the Owner Data Object of a Process Object.
Object: The name of the object type in the input or output. It can contain either the type or a literal value This Object for the object type that defines the operation, or literal value Owner Data Object for the type of Owner Data Object of a Process Object. It specifies an additional attribute:
- Cardinality: [OPTIONAL] the number of representations, in the notation defined in . The default value is 1.
Input Data Elements: the input data elements of the operation, listed in the same form as the Data Elements of an object: each entry is the Name of an input data element, followed by its attributes as defined in , except Mutability, Direct Access and Visibility. It is allowed in Input only, at most once.
Parameters: the parameters of the operation, listed in the same form as Input Data Elements. It is allowed in Input only, at most once.

For example:

Include Elements The includeElements parameter is defined for every operation whose output contains one or more objects, including, but not limited to, the Uniform Interface operations and the operations of Process Objects. It allows a client to request specific data elements to be included in the operation output in addition to those included by default. Individual operation definitions do not repeat it.

Include Elements
- Identifier: includeElements
- Cardinality: 0-1
- Data Type: String
- Description: A comma-separated list of Identifiers of data elements that the client requests to be included in the operation output.
- Constraints: Each list item is the Identifier of a top-level data element of the object or objects returned by the operation. Data elements nested within component objects or other associated objects cannot be listed. Identifiers are case-sensitive. The list contains no whitespace.

A listed Identifier refers to the data element as a whole. For a data element with a cardinality of 0+, 1+, or X-Y, it refers to the entire collection of values, and individual values cannot be selected. For a data element whose Data Type is a component object or an association, it refers to the complete associated object or objects. The server processes this data element as follows:

If includeElements is absent, the server MUST NOT include any data element with onDemand Visibility in the output.
If a listed Identifier is not the Identifier of a top-level data element defined for the returned object, including data elements defined by extensions not supported by the server, the server MUST reject the request with an error.
For each listed Identifier, the server MUST include the referenced data element in the output if it is present on the object and the client is authorised to view it. Otherwise the element is omitted without an error.

Listing a data element that is already included in the output by default has no effect. The parameter thereby remains applicable where an operation or a representation defines an output that omits some elements by default.

Uniform interface For the Create, Read, Query, Update and Delete operations of a Data Object, the following Input and Output apply, using the notation defined in . An operation definition that declares its own Input or Output attribute replaces the corresponding default.

Create

Input:
- Object: This Object
Output:
- Object: This Object

Read

Input:
- Reference: This Object
Output:
- Object: This Object

The output Object MAY vary depending on the identity of the querying client, use of Object Authorisation information, and server policy towards unauthorised clients. If the querying client is the sponsoring client, all available information MUST be returned, except data elements with onDemand Visibility not requested using includeElements (see ). If the querying client is not the sponsoring client but the client provides valid Object Authorisation information, all available information SHOULD be returned, however some optional elements MAY be reserved to the sponsoring client only. If the querying client is not the sponsoring client and the client does not provide valid Object Authorisation information, server policy determines which OPTIONAL elements are returned, if any, or whether the entire request is rejected.

Query

Input: (None)
Output:
- Object: This Object
  - Cardinality: 0+

Update

Input:
- Reference: This Object
- Object: This Object
Output:
- Object: This Object

Delete

Input:
- Reference: This Object
Output:
- Object: This Object
  - Cardinality: 0-1

Availability

Input:
- Reference: This Object
Output:
- Object: Base Availability Object

The Availability operation allows a client to determine whether the object identified by the Reference can be created using the Create operation at the time of the request. The referenced object does not need to exist. The operation does not create, reserve, or otherwise change the state of any object. A Data Object that supports the Availability operation declares as its Output an Availability Object that extends the Base Availability Object (see ). Extensions MAY add parameters that further specify the check and data elements to the Availability Objects.

Offline Review RPP allows for offline review for operations that change the state of an object (Uniform Interface Create, Update, Delete, and the Renew and Transfer process operations) before the requested action is actually completed. In such situations, the response from the server MUST clearly indicate that the operation has been received, but that the requested action is pending. The state of the corresponding object MUST clearly reflect processing of the pending action, typically through a server-set pending status label (e.g. pendingCreate, pendingUpdate, pendingDelete, pendingRenew, pendingTransfer). The server MUST also notify the client when offline processing of the action has been completed, by sending a review-response message (see ).

Operations Beyond Uniform Interface For all other operations both input and output have to be fully specified.

Transfer Operations Transfer operations manage the change of sponsorship of a provisioned object from one client (the sponsoring client) to another (the gaining client). They are specified once in this section as the transfer model is common across all transferable resource objects. Individual object definitions reference this section and specify any object-specific extensions to the common pattern. RPP supports two types of transfer:

Pull Transfer: Initiated by the gaining client. The gaining client MUST provide valid Object Authorisation to initiate the request.
Push Transfer: Initiated by the sponsoring client, who designates a gaining client in the request.

The transfer process MAY be immediate or follow a multi-step workflow depending on server policy. If the server implements immediate transfers, the Approve and Reject operations need not be supported; the server completes the transfer upon receipt of the Create operation. The server MAY implement local policies to prevent transfers from stalling and implement a form of automated transfer escalation, approval or cancellation when such a stalled process is recognised. All transfer operations act on or return the Transfer Process Object and are executed in the context of the Owner Data Object the operation is created upon. If the server does not directly approve a pull transfer request and the current sponsoring client first approve the transfer request, the server MUST wait for the sponsoring client's decision before proceeding. If the sponsoring client approves, the server completes the transfer; if the sponsoring client rejects, the server cancels the transfer. The server MUST send a transfer-request message to the sponsoring client. For a pending push transfer, the server MUST send a transfer-request message to the designated gaining client that must act on it. If the server directly approves a transfer, it MUST send a transfer-outcome message to the client managing the object before the transfer. When a transfer is resolved after the currently managing client's decision, the server MUST send a transfer-outcome message to the requesting client.

Transfer Messages The Pull Transfer Direct Approval Message Diagram illustrates the sequence of messages exchanged during a pull transfer with direct approval. The Pull Transfer Pending Approval Message Diagram illustrates the sequence of messages exchanged during a pull transfer that requires approval. The Push Transfer Message Diagram illustrates the sequence of messages exchanged during a push transfer. For a pull transfer, the requesting client is the gaining client; for a push transfer, the requesting client is the sponsoring client. The messages in the diagrams are surrounded by square brackets to indicate message types. Pull transfer (direct approval):

Pull Transfer Pending Approval Message | | | | | | | | | Pending approval | | |--- [transfer-request] -->| | |<-- approve / reject -----| |<-- [transfer-outcome] --| | ]]> Push transfer:

Push Transfer Message Diagram | | | |--- [transfer-request] --->| | |<-- approve / reject ------| |<-- [transfer-outcome] --| | ]]>

Restore Operations Restore operations manage the recovery of an object that has entered the Redemption Grace Period (RGP). They are OPTIONAL and are only available when the RGP feature is supported by the server and MAY be supported only for a subset of Data Object types. The RGP process MAY involve two distinct steps:

Restore Request: (REQUIRED) Initiates the recovery of an object in the rgpRedemptionPeriod state, signalling to the registry the intent to restore. This corresponds to the Create operation on the Restore Process Object. On success, the object transitions to rgpPendingRestore.
Restore Report: (OPTIONAL) Submits a report documenting the circumstances of the deletion and restoration, as required by registry policy. This corresponds to the Update operation on the Restore Process Object. On success, the object is returned to its pre-deletion status and all RGP status labels are removed.

Whether a restore report is required after a restore request is a matter of server policy. If the server does not require a restore report, the object returns to its pre-deletion status immediately upon a successful Create operation, bypassing the rgpPendingRestore state. The Create operation MAY include the restore report, provided as the restoreReport data element, to complete both steps atomically in a single operation. All restore operations act on or return the Restore Process Object and are executed in the context of the Owner Data Object the operation is created upon.

Renew Operations Renew operations manage the validity period of a provisioned object. They are specified once in this section as the renewal model is common across all renewable resource objects. Individual object definitions reference this section and specify any object-specific extensions to the common pattern.

EPP Compatibility Profile RPP is designed to coexist with the Extensible Provisioning Protocol (EPP), often operating in parallel against a common backend provisioning system. While RPP is not inherently constrained by all of EPP's requirements, a specific set of rules is necessary to ensure seamless interoperability in such mixed environments. To address this, this document defines an "EPP Compatibility Profile". This profile specifies a set of additional constraints on RPP data objects and operations that a server MUST adhere to when supporting both RPP and EPP concurrently. Throughout this document, all constraints that are part of this profile are explicitly marked with a reference to "EPP Compatibility Profile". Implementers of systems in a mixed EPP/RPP environment MUST follow these specific constraints in addition to the base RPP requirements.

Internationalized Domain Names (IDN) Internationalized Domain Names (IDN) are domain names that include one or more non-ASCII characters. IDNs are represented in the Domain Name System (DNS) using ASCII Compatible Encoding (ACE), commonly known as Punycode. This allows the DNS to handle Unicode domain names while maintaining compatibility with the existing ASCII-based infrastructure.

Profiles A profile is a named set of protocol features and versions that are used to define the compatibility and capabilities of RPP server implementations, allowing for better interoperability between different implementations. Using profiles helps to simplify the implementation and deployment of RPP by providing a clear and concise way for the client and server to communicate their capabilities and requirements. A profile is identified by a unique name and may be published as a standard profile in the IANA registry for RPP profiles, to promote interoperability and standardisation across implementations. Standard profile names MUST use the RPP URN namespace defined in this document, for example: urn:ietf:params:rpp:profile:{profile_name}. The profile name MUST be unique within the RPP URN namespace and SHOULD be descriptive of the features and versions included in the profile. A profile can also be defined as a private profile, which is not published in the IANA registry, but is used by specific server implementations only. A private profile can be defined by a server operator to specify the features and versions supported by their implementation. If the profile is not published in the IANA registry, then the server operator MUST ensure that the profile name is globally unique to avoid conflicts with other profiles, the use of reverse domain name notation is RECOMMENDED for private profiles to ensure uniqueness.

Inheritance A profile can include another profile, which is referred to as "inheriting" from that profile. When a profile inherits from another profile, it means that the features and versions defined in the inherited profile are also included in the inheriting profile. This allows for the creation of more complex profiles by building upon existing profiles. For example, a profile named "example-profile" could inherit from a base profile named "base-profile", which includes a set of common features and versions. The "example-profile" could then add additional features and versions on top of the ones defined in the base profile, or it can override some of the features and versions from the base profile. This allows for greater flexibility and modularity in defining profiles, as well as promoting reuse of common features and versions across different profiles. However, it is important to note that the use of inheritance in profiles can also make things more complicated, as it can create dependencies between profiles and make it harder to understand the features and versions included in a profile. Therefore, it is recommended to use inheritance with caution and to clearly document the relationships between profiles. The depth of inheritance MUST be limited to 1 to prevent excessive complexity, and profile designers MUST NOT create circular dependencies between profiles, where a profile inherits from itself directly.

Messages Messages are used to communicate events, requests, and responses between clients and the server. They provide a mechanism for notifying clients about changes in the state of objects, the outcome of operations, and other relevant information. For a message reporting completion of an offline review, the server MUST send a review-response message to each client involved in the transaction when the requested action has been completed and the pending status has been removed. The server can send transfer-outcome, expiration-deletion, and auto-renewal messages to clients affected by those events. The service-notice conveys operational information to all clients. Extensions should use the Base Message Object as the foundation for defining new message types for notifications of changes to Data Objects.

External Data Types The RPP object model is designed to be extensible and interoperable with existing standards. To reduce redundancy and improve consistency, RPP data objects MAY incorporate data types and structures defined in external specifications rather than redefining equivalent types within this specification. An external data type is any type, structure, or format that is normatively defined in a separate standards document and referenced by this specification. When an external data type is used, RPP implementations MUST conform to the semantics, constraints, and encoding rules defined in the originating specification.

Referencing External Data Types When this document or any RPP specification references an external data type, the reference MUST follow the requirements and guidelines for references described in . The reference MUST include a clear description of the specific type or structure being used. For example, if referencing the JSContact format defined in , the reference should specify that the Card data type is being used. The reference MUST use the following format: External:<specification-identifier>:<type-name>. For example, External:RPP-JSContact-Profile:Card indicates that the Card type from the RPP JSContact Profile specification is being used. The syntax for the reference is defined using ABNF as follows:

Versioning and Compatibility External data types are versioned by the specification that defines them. The RPP specifications are pinned to a single version of an external type. If a newer version updates the defining specification, the RPP specification MUST be updated to indicate explicit support.

JSContact This specification references the RPP JSContact Profile for RPP defined in as an external specification for representing contact information. The JSContact Card data type defined in MUST be used for the representation of contact information. When referring to this type the following values MUST be used in the Data Type reference identifiers:

specification-identifier:: RPP-JSContact-Profile
type-name:: Card
Data Type:: External:RPP-JSContact-Profile:Card

Common Data Types This section defines new shared data types and structures that are re-used across multiple data object definitions and are based on the existing Primitive Data Types.

Identifier Identifiers are character strings with a specified minimum length, a specified maximum length, and a specified format outlined in . Identifiers for certain object types MAY have additional constraints imposed either by server policy, object-specific specifications or both.

Client Identifier Client identifiers are character strings with a specified minimum length, a specified maximum length, and a specified format. Client identifiers use the "clIDType" client identifier syntax described in .

Phone Number Telephone number syntax is derived from structures defined in . 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 , 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.

Associations RPP allows for different types of associations (relationships) between the objects. The association may be added between 2 objects with own independent lifecycle (UML aggregation) or in the relation when one object's existence and lifecycle is bound to the other parent/owner object (UML composition). In both cases, especially if the relation allows for cardinality higher than one on either side, the association may be assigned additional attributes, not being part of an object on either side of relation. In many cases such relation would be attributed with a single text string label, describing a role or a type of relation. Depending on the context this value might be unique, which allows using such label as a key in a dictionary. The following generic Association Types are defined for RPP:

Aggregation Notation: Aggregation[Type] A relation between two independent objects. If the cardinality of the target object is more than 1, this represents an unordered array. The target object of an aggregation MUST already exist when the association is created. The target object MAY be only partially visible to the client, or not visible at all, for example when it is managed by the server or by another client and the client only knows its identifier. Limited visibility of the target object does not prevent the client from using it in the association. This rule also applies to Labelled Aggregation and Dictionary Aggregation. Example aggregation having cardinality 1: Example aggregation having cardinality >1:

Composition Notation: Type A relation between an independent parent object and 1 or more dependent child object(s). If the cardinality of the target object is more than 1, this represents an unordered array. Example composition having cardinality 1: Example composition having cardinality >1:

Labelled Aggregation Notation: LabelledAggregation[Type] A relation between two independent objects with a single text string attribute. Multiple associations with the same label are allowed and represent an unordered array. A type defining such association MUST define Label Description with semantics of the label and Label Constraints with constraints related to the label. Example labelled aggregation: +----------+ | | | [Object] | | | | ... | | | +----------+ | +---("label_B")---> +----------+ | | | [Object] | | | | ... | | | +----------+ | +---("label_A")---> +----------+ | | (labels repeat) | [Object] | | | | ... | | | +----------+ | ... | +--------------------------------+ ]]>

Dictionary Aggregation Notation: DictionaryAggregation[Type] A relation between two independent objects with a single text string attribute. Association labels MUST be unique, allowing them to be used as dictionary keys. A type defining such association MUST define Label Description with semantics of the label and Label Constraints with constraints related to the label. Example Dictionary Aggregation: +-----------+ | | [Object] | | | ... | | +-----------+ | "key2" -> +-----------+ | | [Object] | | | ... | | +-----------+ | ... | +--------------------------+ ]]>

Labelled Composition Notation: LabelledComposition[Type] A relation between an independent parent object and a dependent child object with a single text string attribute. Multiple associations with the same label are allowed. A type defining such association MUST define Label Description with semantics of the label and Label Constraints with constraints related to the label. Example Labelled Composition: +----------+ | | | | [Child] | | | | | ... | | | | +----------+ | | +---("label_B")---> +----------+ | | | | [Child] | | | | | ... | | | | +----------+ | | +---("label_A")---> +----------+ | | | (labels repeat) | [Child] | | | | | ... | | | | +----------+ | | ... | +-------------------------------------+ ]]>

Dictionary Composition Notation: DictionaryComposition[Type] A relation between an independent parent object and a dependent child object with a single text string attribute. Only a single association with the same label is allowed, allowing it to be used as a dictionary key. A type defining such association MUST define Label Description with semantics of the label and Label Constraints with constraints related to the label. Example Dictionary Composition: +---------+ | | | [Child] | | | | ... | | | +---------+ | | "key2" -> +---------+ | | | [Child] | | | | ... | | | +---------+ | | ... | +--------------------------+ ]]>

Component Objects This section defines the Component Objects used in this document.

Period Object

Name: Period Object
Identifier: period
Description: Represents a duration of time.
Data Elements:
- Value
  - Identifier: value
  - Cardinality: 1
  - Mutability: read-write
  - Data Type: Integer
  - Description: The numeric value of the period.
  - Constraints: The value MUST be from 1 to 99, inclusive.
- Unit
  - Identifier: unit
  - Cardinality: 1
  - Mutability: read-write
  - Data Type: String
  - Description: The unit of the period.
  - Constraints: The value MUST be one of: "y" (years) or "m" (months).

Provisioning Metadata Object

Name: Provisioning Metadata Object
Identifier: provMetadata
Description: Contains standard metadata about the lifecycle and ownership of a provisioned object. This metadata is common across all resource objects in the registry system.
Data Elements:
- Repository ID
  - Identifier: repositoryId
  - Cardinality: 0-1
  - Mutability: read-only
  - Data Type: Identifier
  - Description: A server-assigned unique identifier for the object.
  - Constraints: In EPP Compatibility Profile this data element MUST be provided.
- Sponsoring Client ID
  - Identifier: spClientId
  - Cardinality: 1
  - Mutability: read-only
  - Data Type: Client Identifier
  - Description: The identifier of the client that is the current sponsor of the object.
  - Constraints: (None)
- Creating Client ID
  - Identifier: crClientId
  - Cardinality: 0-1
  - Mutability: read-only
  - Data Type: Client Identifier
  - Description: The identifier of the client that created the object.
  - Constraints: (None)
- Creation Date
  - Identifier: crDate
  - Cardinality: 0-1
  - Mutability: read-only
  - Data Type: Timestamp
  - Description: The date and time of object creation.
  - Constraints: The value is set by the server and cannot be specified by the client.
- Updating Client ID
  - Identifier: upClientId
  - Cardinality: 0-1
  - Mutability: read-only
  - Data Type: Client Identifier
  - Description: The identifier of the client that last updated the object.
  - Constraints: This element MUST NOT be present if the object has never been modified.
- Update Date
  - Identifier: upDate
  - Cardinality: 0-1
  - Mutability: read-only
  - Data Type: Timestamp
  - Description: The date and time of the most recent object modification.
  - Constraints: This element MUST NOT be present if the object has never been modified.
- Transfer Date
  - Identifier: trDate
  - Cardinality: 0-1
  - Mutability: read-only
  - Data Type: Timestamp
  - Description: The date and time of the most recent successful object transfer.
  - Constraints: This element MUST NOT be provided if the object has never been transferred.

Domain Name Status Object

Name: Domain Name Status Object
Identifier: domainStatus
Description: Represents one of the status values associated with a Domain Name Data Object
Data Elements:
- Label
  - Identifier: label
  - Cardinality: 1
  - Mutability: create-only
  - Data Type: String
  - Description: machine-readable enum label of a status
  - Constraints:
    - Only status values defined in Domain Status Values and Redemption Grace Period Status Values are allowed.
- Reason
  - Identifier: reason
  - Cardinality: 0-1
  - Mutability: create-only
  - Data Type: String
  - Description: a human-readable text that describes the rationale for the status applied to the object.
  - Constraints: (None)
- Due
  - Identifier: due
  - Cardinality: 0-1
  - Mutability: read-write
  - Data Type: Timestamp
  - Description: a timestamp, when this status is going to be removed automatically, or changed to other status. This field can be used to express lifecycle related information.
  - Constraints: servers MAY restrict possibility to set or update this value by the client.

Status Values Status values that can be added or removed by a client are prefixed with "client". Corresponding status values that can be added or removed by a server are prefixed with "server". Status values that do not begin with either "client" or "server" are server-managed. Status values that begin with "rgp" are related to the Redemption Grace Period (RGP) and are also server-managed. A client MUST NOT alter status values set by the server. A server MAY alter or override status values set by a client, subject to local server policies. The Set By column identifies the entity that adds and removes each status value: client, server, or client, server for a value that the server manages and that a client can also manage where server policy permits. A server MUST assign at least one status value to the object. A client is not required to provide a status value when creating or updating the object. Domain Name Status Values

Status Value	Set By	Description
clientDeleteProhibited	client	Requests to delete the object MUST be rejected.
serverDeleteProhibited	server	Requests to delete the object MUST be rejected.
clientHold	client	DNS delegation information MUST NOT be published for the object.
serverHold	server	DNS delegation information MUST NOT be published for the object.
clientRenewProhibited	client	Requests to renew the object MUST be rejected.
serverRenewProhibited	server	Requests to renew the object MUST be rejected.
clientTransferProhibited	client	Requests to transfer the object MUST be rejected.
serverTransferProhibited	server	Requests to transfer the object MUST be rejected.
clientUpdateProhibited	client	Requests to update the object (other than to remove this status) MUST be rejected.
serverUpdateProhibited	server	Requests to update the object (other than to remove this status) MUST be rejected.
inactive	server	Delegation information has not been associated with the object. This is the default status when a domain object is first created and there are no associated host objects for the DNS delegation. This status can also be set by the server when all host-object associations are removed.
ok	server	This is the normal status value for an object that has no pending operations or prohibitions. This value is set and removed by the server as other status values are added or removed.
pendingCreate	server	A transform command has been processed for the object, but the action has not been completed by the server. Server operators can delay action completion for a variety of reasons, such as to allow for human review or third-party action.
pendingDelete	server	A transform command has been processed for the object, but the action has not been completed by the server. Server operators can delay action completion for a variety of reasons, such as to allow for human review or third-party action.
pendingRenew	server	A transform command has been processed for the object, but the action has not been completed by the server. Server operators can delay action completion for a variety of reasons, such as to allow for human review or third-party action.
pendingTransfer	server	A transform command has been processed for the object, but the action has not been completed by the server. Server operators can delay action completion for a variety of reasons, such as to allow for human review or third-party action.
pendingUpdate	server	A transform command has been processed for the object, but the action has not been completed by the server. Server operators can delay action completion for a variety of reasons, such as to allow for human review or third-party action.

Allowed Transitions The following diagram describes the allowed status transitions for a domain object, excluding the "rgp" status values, which follow the separate Redemption Grace Period State Diagram below. The clientHold, serverHold, clientDeleteProhibited, serverDeleteProhibited, clientRenewProhibited, serverRenewProhibited, clientTransferProhibited, serverTransferProhibited, clientUpdateProhibited, and serverUpdateProhibited status values are additive flags that MAY be combined with the states shown below (subject to the Status Exclusions rules) and are not depicted as separate states; while present, the corresponding flag blocks the associated transition (delete, renew, transfer, or update, respectively) from being initiated.

Domain Object State Diagram | status: ok / inactive (3)|<-----------+ | +-----------------------------------+ | | | | | | | | | (6) | | v v v | | +-------------+ +-------------+ +--------------------+ | | | status: | | status: | | status: | | | |pendingUpdate| |pendingRenew | | pendingTransfer | | | | (4) | | (5) | | (6)| | | +-------------+ +-------------+ +--------------------+ | | | | | | | +----------------+--------------------+ | | action completed (7) | +--------------------------------------------------------------+ +-----------------------------------+ | status: ok / inactive (3)| +-----------------------------------+ | (8) v +-----------------------------------+ | status: pendingDelete (8)| +-----------------------------------+ | | no RGP support (9) RGP support (9) v v +------------------+ +-----------------------------------+ | Deleted (purged) | | status: pendingDelete + | | (10) | | rgpRedemptionPeriod | +------------------+ | (see Redemption Grace Period | | State Diagram below) (10)| +-----------------------------------+ ]]> State descriptions:

A create operation is received and processed. If the server defers completion, the object enters pendingCreate state.
The create action completes. The object transitions to ok if one or more nameservers are associated with the domain, or to inactive if none are associated.
The object is in normal operation, either as ok (nameservers associated) or inactive (no nameservers associated). The object toggles between these two sub-states as nameserver associations are added to or removed from the domain, independently of the transitions described below.
An update operation is received. If the server defers completion, the object enters pendingUpdate state.
A renew operation is received to extend the domain's registration period. If the server defers completion, the object enters pendingRenew state.
A transfer Create operation is received, initiating a transfer request. The object enters pendingTransfer state while the request awaits approval, rejection, or automated server action.
Once the pending update, renew, or transfer action completes, the corresponding pending status is removed and the object returns to its ok or inactive state, as determined by its current nameserver associations.
A delete operation is received and processed. The object enters pendingDelete state.
Whether RGP is supported for the domain determines the next transition upon completion of the pending delete action.
If RGP is not supported, the object is purged once the delete action completes. If RGP is supported, the object instead continues into the rgpRedemptionPeriod state, following the Redemption Grace Period State Diagram below.

Pending Status Removal When the requested action has been completed, the pendingCreate, pendingDelete, pendingRenew, pendingTransfer, or pendingUpdate status value MUST be removed. All clients involved in the transaction MUST be notified using a service message that the action has been completed and that the status of the object has changed.

Status Exclusions Status Exclusions

Status Value	MUST NOT be combined with
ok	Any other status
pendingDelete	clientDeleteProhibited, serverDeleteProhibited
pendingRenew	clientRenewProhibited, serverRenewProhibited
pendingTransfer	clientTransferProhibited, serverTransferProhibited
pendingUpdate	clientUpdateProhibited, serverUpdateProhibited
pendingCreate, pendingDelete, pendingRenew, pendingTransfer, pendingUpdate	Each other (mutually exclusive)

Other status combinations not expressly prohibited MAY be used.

Redemption Grace Period Status values that begin with "rgp" are related to the Redemption Grace Period (RGP) and are server-managed. The Set By column identifies the entity that adds and removes each status value: client, server, or client, server for a value that the server manages and that a client can also manage where server policy permits. Redemption Grace Period Status Values

Status Value	Set By	Description
rgpAddPeriod	server	This grace period is provided after the initial registration of a domain name. If the domain name is deleted by the registrar during this period, the registry provides a credit to the registrar for the cost of the registration.
rgpAutoRenewPeriod	server	This grace period is provided after a domain name registration period expires and is extended (renewed) automatically by the registry. If the domain name is deleted by the registrar during this period, the registry provides a credit to the registrar for the cost of the renewal.
rgpRenewPeriod	server	This grace period is provided after a domain name registration period is explicitly extended (renewed) by the registrar. If the domain name is deleted by the registrar during this period, the registry provides a credit to the registrar for the cost of the renewal.
rgpTransferPeriod	server	This grace period is provided after the successful transfer of domain name registration sponsorship from one registrar to another registrar. If the domain name is deleted by the new sponsoring registrar during this period, the registry provides a credit to the registrar for the cost of the transfer.
rgpRedemptionPeriod	server	This status value is used to describe a domain for which a delete operation has been received, but the domain has not yet been purged because an opportunity exists to restore the domain and abort the deletion process.
rgpPendingRestore	server	This status value is used to describe a domain that is in the process of being restored after being in the rgpRedemptionPeriod state.
rgpPendingDelete	server	This status value is used to describe a domain that has entered the purge processing state after completing the rgpRedemptionPeriod state. A domain in this status MUST also be in the pendingDelete status described above.

Allowed Transitions The following state diagram describes the object lifecycle when the Redemption Grace Period (RGP) feature is supported. It adapts the diagram from to the RPP data model, using RPP status labels and operations instead of EPP command names. In the diagram below, each state box shows the values of the status data element of the Domain Name Data Object. The values ok and pendingDelete are defined in , and the values beginning with "rgp" are defined in . The <delete> label refers to the Delete operation on the Domain Name Data Object. The <create> and <update> labels refer to the Create operation () and the Update operation () of the Restore Process Object.

The object is in normal operation (ok or other status allowing a delete operation).
A delete operation is received and processed.
RGP begins. The object enters pendingDelete + rgpRedemptionPeriod state. The object remains here until a restore operation is requested or the redemption period elapses.
A restore Create operation is submitted. The registry accepts the request. Go to step 9 if the redemption period elapses before a restore is received (4a).
If the server does not require a restore report, the object returns to its pre-deletion status (1) immediately upon a successful Create operation. If the server requires a report but the client includes it inline in the Create operation, the server processes both atomically and the object transitions directly from rgpRedemptionPeriod to its pre-deletion status (1), bypassing the rgpPendingRestore state.
The object enters pendingDelete + rgpPendingRestore state. The registry awaits a restore report from the sponsoring client.
If no restore report is received within the registry-defined time, the object returns to rgpRedemptionPeriod state (step 3).
If a restore report is received and accepted, the object returns to its pre-deletion status and all RGP status labels are removed.
The redemption period elapses without a restore request being received.
The object enters pendingDelete + rgpPendingDelete state and awaits final purge processing.
The pending delete period elapses and the object is purged.
The object is purged and available for re-registration.

Host Status Object

Name: Host Status Object
Identifier: hostStatus
Description: Represents one of the status values associated with a Host Data Object
Data Elements:
- Label
  - Identifier: label
  - Cardinality: 1
  - Mutability: create-only
  - Data Type: String
  - Description: machine-readable enum label of a status
  - Constraints:
    - Only status values defined in Status Values are allowed.
- Reason
  - Identifier: reason
  - Cardinality: 0-1
  - Mutability: create-only
  - Data Type: String
  - Description: a human-readable text that describes the rationale for the status applied to the object.
  - Constraints: (None)

Status Values Status values that can be added or removed by a client are prefixed with "client". Corresponding status values that can be added or removed by a server are prefixed with "server". Status values that do not begin with either "client" or "server" are server-managed. A client MUST NOT alter status values set by the server. A server MAY alter or override status values set by a client, subject to local server policies. The Set By column identifies the entity that adds and removes each status value: client, server, or client, server for a value that the server manages and that a client can also manage where server policy permits. A server MUST assign at least one status value to the object. A client is not required to provide a status value when creating or updating the object. Host Status Values

Status Value	Set By	Description
clientDeleteProhibited	client	Requests to delete the object MUST be rejected.
serverDeleteProhibited	server	Requests to delete the object MUST be rejected.
clientUpdateProhibited	client	Requests to update the object (other than to remove this status) MUST be rejected.
serverUpdateProhibited	server	Requests to update the object (other than to remove this status) MUST be rejected.
linked	server	The host object has at least one active association with another object, such as a domain object. Servers SHOULD provide services to determine existing object associations.
ok	server	This is the normal status value for an object that has no pending operations or prohibitions. This value is set and removed by the server as other status values are added or removed.
pendingCreate	server	A transform command has been processed for the object, but the action has not been completed by the server. Server operators can delay action completion for a variety of reasons, such as to allow for human review or third-party action.
pendingDelete	server	A transform command has been processed for the object, but the action has not been completed by the server. Server operators can delay action completion for a variety of reasons, such as to allow for human review or third-party action.
pendingTransfer	server	A transform command has been processed for the object's superordinate domain object (i.e. a transfer of the domain object is pending), but the action has not been completed by the server. Server operators can delay action completion for a variety of reasons, such as to allow for human review or third-party action.
pendingUpdate	server	A transform command has been processed for the object, but the action has not been completed by the server. Server operators can delay action completion for a variety of reasons, such as to allow for human review or third-party action.

Allowed Transitions The following diagram describes the allowed status transitions for a host object, based on the status values defined in . The clientDeleteProhibited, serverDeleteProhibited, clientUpdateProhibited, and serverUpdateProhibited status values are additive flags that MAY be combined with the states shown below (subject to the Status Exclusions rules) and are not depicted as separate states; while present, the corresponding flag blocks the associated transition (delete or update, respectively) from being initiated. The linked status is set and removed by the server as associations with other objects are added or removed, independently of the transitions described below.

Host Object State Diagram | status: ok (3) |<---------+ | +-----------------------------------+ | | | | | | (4) | (5) | | | v v | | +--------------------+ +--------------------+ | | | status: | | status: | | | | pendingUpdate (4) | | pendingTransfer(5) | | | +--------------------+ +--------------------+ | | | | | | +------------------------+ | | action completed (6) | +---------------------------------------------------------+ +-----------------------------------+ | status: ok (3) | +-----------------------------------+ | | (7) v +-----------------------------------+ | status: pendingDelete (7) | +-----------------------------------+ | | delete action completed (8) v +------------------+ | Deleted (purged) | | (9) | +------------------+ ]]> State descriptions:

A create operation is received and processed. If the server defers completion, the object enters pendingCreate state.
The create action completes and the pendingCreate status is removed. The object enters the ok state.
The object is in normal operation with the ok status. The linked status MAY accompany ok while the host has an active association with another object, such as a domain object.
An update operation is received. If the server defers completion, the object enters pendingUpdate state.
A transfer of the superordinate domain object is initiated. The server sets the pendingTransfer status on the subordinate host object while the domain transfer request is pending. This status is not set by a client.
Once the pending update or transfer action completes, the corresponding pending status is removed and the object returns to its ok state.
A delete operation is received and processed. The object enters pendingDelete state.
The pending delete action completes.
The object is purged.

Pending Status Removal When the requested action has been completed, the pendingCreate, pendingDelete, pendingTransfer, or pendingUpdate status value MUST be removed. All clients involved in the transaction MUST be notified using a service message that the action has been completed and that the status of the object has changed.

Status Exclusions Host Status Exclusions

Status Value	MUST NOT be combined with
ok	Any status other than `linked`
pendingDelete	clientDeleteProhibited, serverDeleteProhibited
pendingUpdate	clientUpdateProhibited, serverUpdateProhibited
pendingCreate, pendingDelete, pendingTransfer, pendingUpdate	Each other (mutually exclusive)

The linked status MAY be combined with any status. Other status combinations not expressly prohibited MAY be used.

Contact Status Object

Name: Contact Status Object
Identifier: contactStatus
Description: Represents one of the status values associated with a Contact Data Object
Data Elements:
- Label
  - Identifier: label
  - Cardinality: 1
  - Mutability: create-only
  - Data Type: String
  - Description: machine-readable enum label of a status
  - Constraints:
    - Only status values defined in Status Values are allowed.
- Reason
  - Identifier: reason
  - Cardinality: 0-1
  - Mutability: create-only
  - Data Type: String
  - Description: a human-readable text that describes the rationale for the status applied to the object.
  - Constraints: (None)

Status Values Status values that can be added or removed by a client are prefixed with "client". Corresponding status values that can be added or removed by a server are prefixed with "server". Status values that do not begin with either "client" or "server" are server-managed. A client MUST NOT alter status values set by the server. A server MAY alter or override status values set by a client, subject to local server policies. The Set By column identifies the entity that adds and removes each status value: client, server, or client, server for a value that the server manages and that a client can also manage where server policy permits. A server MUST assign at least one status value to the object. A client is not required to provide a status value when creating or updating the object. Contact Status Values

Status Value	Set By	Description
clientDeleteProhibited	client	Requests to delete the object MUST be rejected.
serverDeleteProhibited	server	Requests to delete the object MUST be rejected.
clientTransferProhibited	client	Requests to transfer the object MUST be rejected.
serverTransferProhibited	server	Requests to transfer the object MUST be rejected.
clientUpdateProhibited	client	Requests to update the object (other than to remove this status) MUST be rejected.
serverUpdateProhibited	server	Requests to update the object (other than to remove this status) MUST be rejected.
linked	server	The contact object has at least one active association with another object, such as a domain object. Servers SHOULD provide services to determine existing object associations.
ok	server	This is the normal status value for an object that has no pending operations or prohibitions. This value is set and removed by the server as other status values are added or removed.
pendingCreate	server	A transform command has been processed for the object, but the action has not been completed by the server. Server operators can delay action completion for a variety of reasons, such as to allow for human review or third-party action.
pendingDelete	server	A transform command has been processed for the object, but the action has not been completed by the server. Server operators can delay action completion for a variety of reasons, such as to allow for human review or third-party action.
pendingTransfer	server	A transform command has been processed for the object, but the action has not been completed by the server. Server operators can delay action completion for a variety of reasons, such as to allow for human review or third-party action.
pendingUpdate	server	A transform command has been processed for the object, but the action has not been completed by the server. Server operators can delay action completion for a variety of reasons, such as to allow for human review or third-party action.

Allowed Transitions The following diagram describes the allowed status transitions for a contact object, based on the status values defined in . The clientDeleteProhibited, serverDeleteProhibited, clientTransferProhibited, serverTransferProhibited, clientUpdateProhibited, and serverUpdateProhibited status values are additive flags that MAY be combined with the states shown below (subject to the Status Exclusions rules) and are not depicted as separate states; while present, the corresponding flag blocks the associated transition (delete, transfer, or update, respectively) from being initiated. The linked status is set and removed by the server as associations with other objects are added or removed, independently of the transitions described below.

Contact Data Object State Diagram | status: ok (3) |<---------+ | +-----------------------------------+ | | | | | | (4) | (5) | | | v v | | +--------------------+ +--------------------+ | | | status: | | status: | | | | pendingUpdate (4) | | pendingTransfer(5) | | | +--------------------+ +--------------------+ | | | | | | +------------------------+ | | action completed (6) | +---------------------------------------------------------+ +-----------------------------------+ | status: ok (3) | +-----------------------------------+ | | (7) v +-----------------------------------+ | status: pendingDelete (7) | +-----------------------------------+ | | delete action completed (8) v +------------------+ | Deleted (purged) | | (9) | +------------------+ ]]> State descriptions:

A create operation is received and processed. If the server defers completion, the object enters pendingCreate state.
The create action completes and the pendingCreate status is removed. The object enters the ok state.
The object is in normal operation with the ok status. The linked status MAY accompany ok while the contact has an active association with another object, such as a domain object.
An update operation is received. If the server defers completion, the object enters pendingUpdate state.
A transfer Create operation is received for the contact, initiating a transfer request. The object enters pendingTransfer state while the request awaits approval, rejection, cancellation, or automated server action.
Once the pending update or transfer action completes, the corresponding pending status is removed and the object returns to its ok state. A transfer that is approved changes the sponsoring client of the contact.
A delete operation is received and processed. The object enters pendingDelete state.
The pending delete action completes.
The object is purged.

Status Exclusions Contact Status Exclusions

Status Value	MUST NOT be combined with
ok	Any status other than `linked`
pendingDelete	clientDeleteProhibited, serverDeleteProhibited
pendingTransfer	clientTransferProhibited, serverTransferProhibited
pendingUpdate	clientUpdateProhibited, serverUpdateProhibited
pendingCreate, pendingDelete, pendingTransfer, pendingUpdate	Each other (mutually exclusive)

The linked status MAY be combined with any status. Other status combinations not expressly prohibited MAY be used.

Organisation Role Status Object

Name: Organisation Role Status Object
Identifier: organisationRoleStatus
Description: Represents one of the status values associated with an Organisation Role Object. A role SHOULD have at least one associated status value.
Data Elements:
- Label
  - Identifier: label
  - Cardinality: 1
  - Mutability: create-only
  - Data Type: String
  - Description: machine-readable enum label of a status
  - Constraints:
    - Only status values defined in Status Values are allowed.
- Reason
  - Identifier: reason
  - Cardinality: 0-1
  - Mutability: create-only
  - Data Type: String
  - Description: a human-readable text that describes the rationale for the status applied to the role.
  - Constraints: (None)

Status Value	Set By	Description
clientLinkProhibited	client	Requests to add new links to the role MUST be rejected.
serverLinkProhibited	server	Requests to add new links to the role MUST be rejected.
linked	server	The role has at least one active association with another object. This value is set and removed by the server and is not explicitly set by the client.
ok	server	This is the normal status value for a role that has no active prohibitions. This value is set and removed by the server as other status values are added or removed.

Allowed Transitions The following diagram describes the allowed status transitions for an organisation role. The ok status is mutually exclusive with clientLinkProhibited and serverLinkProhibited, and the linked status MAY be combined with either ok or the link prohibition statuses (subject to the Status Exclusions rules). The linked status is set and removed by the server as associations with other objects are added or removed, independently of link prohibition changes, so the transitions in the top row apply equally to the bottom row. The clientLinkProhibited and serverLinkProhibited status values MAY be set at the same time.

Organisation Role State Diagram | clientLinkProhibited | | |<----(3)----| and/or | | | | serverLinkProhibited | +------------------------+ +------------------------+ | ^ | ^ (4) | | (5) (4) | | (5) v | v | +------------------------+ +------------------------+ | | | status: linked, | | status: ok, linked |---(2)----->| clientLinkProhibited | | |<----(3)----| and/or | | | | serverLinkProhibited | +------------------------+ +------------------------+ ]]> State descriptions:

A role is added to an organisation. The role starts with the ok status.
A clientLinkProhibited or serverLinkProhibited status is set, by the client or the server respectively, and the ok status is removed. Requests to add new links to the role MUST be rejected while a link prohibition is present.
The last link prohibition status is removed and the server sets the ok status.
The role gets its first active association with another object and the server sets the linked status.
The last active association of the role is removed and the server removes the linked status.

Status Exclusions Organisation Role Status Exclusions

Status Value	MUST NOT be combined with
ok	Any status other than `linked`

Other status combinations not expressly prohibited MAY be used.

Organisation Status Object

Name: Organisation Status Object
Identifier: organisationStatus
Description: Represents one of the status values associated with an Organisation Data Object, as defined in . An Organisation Data Object MUST always have at least one associated status value.
Data Elements:
- Label
  - Identifier: label
  - Cardinality: 1
  - Mutability: create-only
  - Data Type: String
  - Description: machine-readable enum label of a status
  - Constraints:
    - Only status values defined in Status Values are allowed.
- Reason
  - Identifier: reason
  - Cardinality: 0-1
  - Mutability: create-only
  - Data Type: String
  - Description: a human-readable text that describes the rationale for the status applied to the object.
  - Constraints: (None)

Status Values Status values that can be added or removed by a client are prefixed with "client". Corresponding status values that can be added or removed by a server are prefixed with "server". The hold and terminated status values are server-managed when the organisation has no parent organisation and otherwise MAY be client-managed based on server policy. Other status values that do not begin with either "client" or "server" are server-managed. The Set By column identifies the entity that adds and removes each status value: client, server, or client, server for a value that the server manages and that a client can also manage where server policy permits. A server MUST assign at least one status value to the object. A client is not required to provide a status value when creating or updating the object. Organisation Status Values

Status Value	Set By	Description
ok	server	This is the normal status value for an object that has no pending operations or prohibitions. This value is set and removed by the server as other status values are added or removed.
hold	client, server	Organisation transform commands and new links MUST be rejected.
terminated	client, server	The organisation has been terminated and MUST NOT be linked. Organisation transform commands and new links MUST be rejected.
linked	server	The organisation object has at least one active association with another object. This value is not explicitly set by the client. Servers SHOULD provide services to determine existing object associations.
clientLinkProhibited	client	Requests to add new links to the organisation MUST be rejected.
serverLinkProhibited	server	Requests to add new links to the organisation MUST be rejected.
clientUpdateProhibited	client	Requests to update the object (other than to remove this status) MUST be rejected.
serverUpdateProhibited	server	Requests to update the object (other than to remove this status) MUST be rejected.
clientDeleteProhibited	client	Requests to delete the object MUST be rejected.
serverDeleteProhibited	server	Requests to delete the object MUST be rejected.
pendingCreate	server	A transform command has been processed for the object, but the action has not been completed by the server. Server operators can delay action completion for a variety of reasons, such as to allow for human review or third-party action.
pendingUpdate	server	A transform command has been processed for the object, but the action has not been completed by the server. Server operators can delay action completion for a variety of reasons, such as to allow for human review or third-party action.
pendingDelete	server	A transform command has been processed for the object, but the action has not been completed by the server. Server operators can delay action completion for a variety of reasons, such as to allow for human review or third-party action.

Allowed Transitions The following diagram describes the allowed status transitions for an organisation object. The linked, clientLinkProhibited, serverLinkProhibited, clientUpdateProhibited, serverUpdateProhibited, clientDeleteProhibited, and serverDeleteProhibited status values are additive flags that MAY be combined with the states shown below (subject to the Status Exclusions rules) and are not depicted as separate states; while present, the corresponding flag blocks the associated transition (new link, update, or delete, respectively) from being initiated. The linked status is set and removed by the server as associations with other objects are added or removed, independently of the transitions described below.

Organisation Object State Diagram | hold | | | | |<-----------------| | | | +------+ (5) +------+ | | | | | | | | | (6) | (6) | | v v | | +--------------------------------+ | | | terminated | | | +--------------------------------+ | | | +--------------------------------------------------------+ | ^ | ^ (7) | | (8) (9) | | (10) v | v | +---------------+ +---------------+ | pendingUpdate | | pendingDelete | +---------------+ +---------------+ | | delete completed (11) v +-----------+ | Purged | +-----------+ ]]> State descriptions:

A create operation is received and processed. If the server defers completion, the object enters pendingCreate state. If the server completes the create immediately, the object enters the ok state directly.
The create action completes and the pendingCreate status is removed. The object enters the operational state (3), normally ok.
The object is in exactly one of the mutually exclusive operational states ok, hold, or terminated. The pending states (7) and (9) are entered from, and return to, this operational state.
A hold status is set. Organisation transform operations and new links MUST be rejected while the object is in hold. The hold status is set by the server, or by the client if the organisation has a parent organisation and server policy allows it.
The hold status is removed and the object returns to ok, by the same parties that are allowed to set it.
A terminated status is set, from either ok or hold, by the same parties that are allowed to set hold. A terminated organisation MUST NOT be linked, and organisation transform operations and new links MUST be rejected. Whether and how an object can leave the terminated state is subject to server policy.
An update operation is received. If the server defers completion, the object enters pendingUpdate state.
The pending update completes, the pendingUpdate status is removed, and the object returns to its operational state.
A delete operation is received. If the server defers completion, the object enters pendingDelete state.
The pending delete is rejected by the server, the pendingDelete status is removed, and the object returns to its operational state.
The pending delete completes and the object is purged.

Pending Status Removal When the requested action has been completed, the pendingCreate, pendingDelete, or pendingUpdate status value MUST be removed. All clients involved in the transaction MUST be notified using a service message that the action has been completed and that the status of the object has changed.

Status Exclusions Organisation Status Exclusions

Status Value	MUST NOT be combined with
pendingCreate, ok, hold, terminated	Each other (mutually exclusive); an organisation MUST have exactly one of these statuses
ok	Any status other than `linked`
pendingDelete	clientDeleteProhibited, serverDeleteProhibited
pendingCreate, pendingDelete, pendingUpdate	Each other (mutually exclusive)

The linked status MAY be combined with clientLinkProhibited or serverLinkProhibited if new links must be prohibited. Other status combinations not expressly prohibited MAY be used.

User Status Object

Name: User Status Object
Identifier: userStatus
Description: Represents the status value associated with a User Data Object. A User Data Object MUST always have exactly one associated status value.
Data Elements:
- Label
  - Identifier: label
  - Cardinality: 1
  - Mutability: create-only
  - Data Type: String
  - Description: machine-readable enum label of a status
  - Constraints:
    - Only status values defined in Status Values are allowed.
- Reason
  - Identifier: reason
  - Cardinality: 0-1
  - Mutability: create-only
  - Data Type: String
  - Description: a human-readable text that describes the rationale for the status applied to the object.
  - Constraints: (None)

Status Values The pending status value is server-managed. The suspended and deactivated status values are server-managed and MAY additionally be client-managed by a client with permission to manage users in the owning organisation, based on server policy. The active status value is set and removed by the server as other status values are added or removed. The Set By column identifies the entity that adds and removes each status value: client, server, or client, server for a value that the server manages and that a client can also manage where server policy permits. A server MUST assign at least one status value to the object. A client is not required to provide a status value when creating or updating the object. User Status Values

Status Value	Set By	Description
active	server	This is the normal status value for a user that is permitted to authenticate and act within the permissions of its roles.
pending	server	The user has been created, but activation has not been completed by the server. Server operators can delay activation for a variety of reasons, such as to allow for verification of the user's details or human review. Requests authenticated as the user MUST be rejected.
suspended	client, server	The user has been temporarily suspended. Requests authenticated as the user MUST be rejected.
deactivated	client, server	The user has been deactivated. Requests authenticated as the user MUST be rejected.

Allowed Transitions The following diagram describes the allowed status transitions for a user object.

User Object State Diagram | suspended | | |<----------------| | +--------+ (4) +-----------+ | | | (5) | (5) v v +-------------------------------------+ | deactivated | +-------------------------------------+ | | delete completed (6) v +-----------+ | Purged | +-----------+ ]]> State descriptions:

A create operation is received and processed. If the server defers activation, the object enters the pending state. If the server activates the user immediately, the object enters the active state directly.
Activation completes and the pending status is replaced by active.
A suspended status is set, replacing active.
The suspended status is removed and the object returns to active, by the same parties that are allowed to set it.
A deactivated status is set, from either active or suspended. Whether and how an object can leave the deactivated state is subject to server policy.
A delete operation completes and the object is purged. A delete operation can be received in any state; only the transition from deactivated is depicted.

Pending Status Removal When activation has been completed, the pending status value MUST be replaced by active. The client that created the user MUST be notified using a service message that activation has been completed and that the status of the object has changed.

Status Exclusions User Status Exclusions

Status Value	MUST NOT be combined with
active, pending, suspended, deactivated	Each other (mutually exclusive); a user MUST have exactly one of these statuses

DNS Resource Record Object

Name: DNS Resource Record Object
Identifier: dnsRecord
Description: Represents a single DNS resource record. The structure follows the top-level format of a DNS resource record as described in Section 3.2.1 of , adapted for use in provisioning. The RDATA field is represented as a structured object whose fields depend on the record type, following the RDATA presentation format described by the corresponding RFC defining the record type. This approach is aligned with .
Data Elements:
- Name
  - Identifier: name
  - Cardinality: 1
  - Mutability: read-write
  - Data Type: String
  - Description: The owner name of the DNS entry. This MAY be the domain itself or a subordinate host name.
  - Constraints:
    - The value MUST be a syntactically valid DNS host name.
    - Absolute FQDNs (with trailing dot) and relative host names are allowed, as well as the "@" symbol representing the domain name itself.
- Class
  - Identifier: class
  - Cardinality: 0-1
  - Mutability: read-write
  - Data Type: String
  - Description: The DNS resource record class.
  - Constraints:
    - If present, the value MUST be chosen from Section 3.2.4 (CLASS values) of .
    - A client SHOULD omit this element. The server MUST assume "IN" as the default class and MAY decline other values.
- Type
  - Identifier: type
  - Cardinality: 1
  - Mutability: read-write
  - Data Type: String
  - Description: The DNS resource record type, indicating the format of the RDATA field.
  - Constraints:
    - The value MUST be a valid string representation of a resource record type as defined in or other RFC describing the record type.
    - Allowed values MAY be constrained by server policies. For domain provisioning, the type would typically be constrained to the allowed parent-side entries.
    - Values MUST be converted to lowercase.
    - In EPP Compatibility Profile (), the following record types MUST be supported: ns, a, and aaaa.
    - In EPP Compatibility Profile with DNSSEC Extension , the following record types MUST additionally be supported: ds and dnskey.
- RDATA
  - Identifier: rdata
  - Cardinality: 1
  - Mutability: read-write
  - Data Type: Object
  - Description: The actual payload data of the DNS record. The structure of this object depends on the record type and MUST follow the RDATA presentation format described by the corresponding RFC. Property names MUST be written in camelCase. All property values MUST be represented as Strings encoding the presentation format of the value.
  - Constraints:
    - The fields within RDATA MUST match the expected structure for the given record type.
    - See for required structures in the EPP Compatibility Profile.

RDATA Structures in EPP Profile This section defines the RDATA field structures required for interoperability in the EPP Compatibility Profile. In EPP Compatibility Profile (), the following RDATA structures MUST be supported:

For NS records (, Section 3.3.11): nsdname (the fully qualified domain name of the nameserver).
For A records (, Section 3.4.1): address (the IPv4 address in dotted-decimal notation).
For AAAA records (, Section 2.2): address (the IPv6 address in text representation as defined in ).

In EPP Compatibility Profile with DNSSEC Extension (), the following RDATA structures MUST additionally be supported:

For DS records (, Section 5): keyTag (key tag value), algorithm (algorithm number), digestType (digest algorithm type), and digest (digest value).
For DNSKEY records (, Section 2): flags (flags field value), protocol (protocol field value), algorithm (algorithm number), and publicKey (encoded public key value).

DNS Operational Controls Object

Name: DNS Operational Controls Object
Identifier: dnsControls
Description: Contains operational control parameters that a client MAY use to influence server-side DNS behaviour for a set of DNS records. A server MAY ignore these values, e.g. for policy reasons. This structure is aligned with .
Data Elements:
- TTL
  - Identifier: ttl
  - Cardinality: 0-1
  - Mutability: read-write
  - Data Type: Dictionary[Integer]
  - Description: Controls the caching behaviour of DNS resource records. The dictionary is keyed by lowercase record type name, with values representing the TTL in seconds for that record type.
  - Constraints:
    - The keys MUST be valid DNS resource record type names in lowercase.
    - The values MUST be positive Integers.
    - The allowed value ranges MAY be constrained by server policy.
    - A server MAY ignore client-specified TTL values and apply default or policy-defined values.
- Maximum Signature Lifetime
  - Identifier: maxSigLifetime
  - Cardinality: 0-1
  - Mutability: read-write
  - Data Type: Dictionary[Integer]
  - Description: Specifies a child's preference for the maximum number of seconds after signature generation when the parent's signature on signed DNS information should expire. The dictionary is keyed by lower-case record type name, with values representing the maximum signature lifetime in seconds for that record type. The value applies to the RRSIG resource record over the signed DNS RRset. See Section 3 of for information on the RRSIG resource record. This corresponds to the maxSigLife concept from .
  - Constraints:
    - The keys MUST be valid DNS resource record type names in lowercase.
    - The values MUST be positive Integers (minimum value of 1).
    - A server MAY ignore client-specified values and apply its own default signature expiration policy.

DNS Data Object

Name: DNS Data Object
Identifier: dnsData
Description: A container for DNS resource records and associated operational controls for a provisioned object. This structure groups DNS records together with control parameters that influence server-side DNS behaviour. The structure is aligned with .
Data Elements:
- Records
  - Identifier: records
  - Cardinality: 0+
  - Mutability: read-write
  - Data Type: DNS Resource Record Object
  - Description: An array of DNS resource records associated with the provisioned object.
  - Constraints:
    - Allowed record types MAY be constrained by server policy.
    - In EPP Compatibility Profile with DNSSEC Extension , records of type DS and DNSKEY MUST be supported in addition to NS, A, and AAAA.
    - A server MUST support either DS or DNSKEY or both record types for DNSSEC provisioning. If provided with only DNSKEY, a server MUST calculate the DS record. If both record types are provided, a server MAY use the DNSKEY to validate the DS record.
- Controls
  - Identifier: controls
  - Cardinality: 0-1
  - Mutability: read-write
  - Data Type: DNS Operational Controls Object
  - Description: Operational control parameters for the DNS records.
  - Constraints: (None)

Authorisation Information Object

Name: Authorisation Information Object
Identifier: authInfo
Description: Contains information used to authorise operations on a data object. It may hold different kinds of authorisation information.
Data Elements:
- Method
  - Identifier: method
  - Cardinality: 1
  - Mutability: create-only
  - Data Type: String
  - Description: The identifier of the RPP authorisation method.
  - Constraints:
    - The value MUST be one of the values registered at IANA as defined in [I-D.draft-wullink-rpp-core].
    - In EPP Compatibility Profile this value MUST be set to authinfo if standard password-based authorisation is used
- Authorisation Information
  - Identifier: authdata
  - Cardinality: 1
  - Mutability: create-only
  - Data Type: String
  - Description: The value of the authorisation information. It might be as simple as a password string, but also more complex values like public key certificates or tokens encoded as string are possible.
  - Constraints:
    - Authorisation Information object is immutable. If the information changes (for example password is updated) a new instance MUST be created.
    - Depending on the method and server policy Authorisation Information MAY not be available for read or any other operation responding with this data element.

Disclose Object

Name: Disclose Object
Identifier: disclose
Description: TBD

Restore Report Object

Name: Restore Report Object
Identifier: restoreReport
Description: Contains the redemption grace period restore report submitted by the sponsoring client as required by the RGP process (). A restore report documents the state of the object before and after deletion, provides the reason for restoration, and includes mandatory client statements. This object is OPTIONAL and is only required when the RGP feature is supported and a restore report is being submitted.
Data Elements:
- Pre-Delete Data
  - Identifier: preData
  - Cardinality: 0-1
  - Mutability: read-write
  - Data Type: String
  - Description: A copy of the registration data that existed for the object prior to the object being deleted.
  - Constraints: (None)
- Post-Restore Data
  - Identifier: postData
  - Cardinality: 0-1
  - Mutability: read-write
  - Data Type: String
  - Description: A copy of the registration data that exists for the object at the time the restore report is submitted.
  - Constraints: (None)
- Delete Time
  - Identifier: deleteTime
  - Cardinality: 0-1
  - Mutability: read-write
  - Data Type: Timestamp
  - Description: The date and time when the object delete request was sent to the server.
  - Constraints: (None)
- Restore Time
  - Identifier: restoreTime
  - Cardinality: 0-1
  - Mutability: read-write
  - Data Type: Timestamp
  - Description: The date and time when the original restore request operation was sent to the server.
  - Constraints:
    - This element MAY be omitted when the restore report is submitted inline within the restore request in a single-step process.
    - In EPP Compatibility Profile this element MUST be present as defined in .
- Restore Reason
  - Identifier: restoreReason
  - Cardinality: 0-1
  - Mutability: read-write
  - Data Type: String
  - Description: A brief explanation of the reason for restoring the object.
  - Constraints: (None)
- Statements
  - Identifier: statements
  - Cardinality: 1-2
  - Mutability: read-write
  - Data Type: String
  - Description: Client statements required by the RGP process.
  - Constraints: In EPP Compatibility Profile exactly two statements MUST be present as defined in .
- Other
  - Identifier: other
  - Cardinality: 0-1
  - Mutability: read-write
  - Data Type: String
  - Description: Any additional information needed to support the statements provided by the client.
  - Constraints: (None)

Organisation Role Object

Name: Organisation Role Object
Identifier: organisationRole
Description: Represents a role that an organisation has within the registry ecosystem. An organisation object MUST always have at least one associated role. A single organisation MAY have multiple roles with different role types.
Data Elements:
- Role Identifier
  - Identifier: roleId
  - Cardinality: 0-1
  - Mutability: read-write
  - Data Type: String
  - Description: A third-party-assigned identifier for the role, such as an IANA ID for registrars.
  - Constraints: (None)
- Role Status
  - Identifier: status
  - Cardinality: 0+
  - Mutability: read-write
  - Data Type: Organisation Role Status Object
  - Description: The status of this particular role. A role SHOULD have at least one associated status value.
  - Constraints:
    - Possible values and combinations are specified in Organisation Role Status Values.

Processes Object

Name: Processes Object
Identifier: processes
Description: A container grouping the Process Objects currently or recently initiated on a Data Object. Each data element MUST be named after the identifier of a Process Object and MUST be of type Aggregation of that Process Object. The data elements below are the process types defined in this document. Extensions MUST add further data elements for the Process Objects they define.
Data Elements:
- Transfer Processes
  - Identifier: transferProcess
  - Cardinality: 0+
  - Mutability: read-only
  - Data Type: Aggregation[Transfer Process Object]
  - Direct Access: true
  - Description: The transfer processes initiated on the owning Data Object.
  - Constraints: (None)
- Renew Processes
  - Identifier: renewProcess
  - Cardinality: 0+
  - Mutability: read-only
  - Data Type: Aggregation[Renew Process Object]
  - Direct Access: true
  - Description: The renew processes initiated on the owning Data Object.
  - Constraints: (None)
- Restore Processes
  - Identifier: restoreProcess
  - Cardinality: 0+
  - Mutability: read-only
  - Data Type: Aggregation[Restore Process Object]
  - Direct Access: true
  - Description: The restore processes initiated on the owning Data Object.
  - Constraints: (None)
- Create Processes
  - Identifier: createProcess
  - Cardinality: 0+
  - Mutability: read-only
  - Data Type: Aggregation[Create Process Object]
  - Direct Access: true
  - Description: The create processes initiated on the owning Data Object.
  - Constraints: (None)

Base Process Object

Name: Base Process Object
Identifier: baseProcess
Abstract: true
Description: Base structure for all Process Objects, containing the data elements common to every process. Each Process Object extends this object.
Data Elements:
- Process ID
  - Identifier: processId
  - Cardinality: 0-1
  - Mutability: read-only
  - Data Type: String
  - Description: A server-assigned identifier of the process instance, unique within the scope of the Owner Data Object.
  - Constraints: The value is set by the server and cannot be specified by the client.

Availability The Availability Objects define the output of the Availability operation (see ). Each Data Object that supports the Availability operation defines its own Availability Object extending the Base Availability Object. Extensions add availability information, for example pricing, as data elements of these objects.

Base Availability Object

Name: Base Availability Object
Identifier: baseAvailability
Abstract: true
Description: Base structure for the result of an Availability operation, indicating whether the referenced object can be created.
Data Elements:
- Available
  - Identifier: available
  - Cardinality: 1
  - Mutability: read-only
  - Data Type: Boolean
  - Description: Indicates whether the referenced object can be created at the time the operation is completed. The value true means that the object can be created. It does not guarantee that a subsequent Create operation for the same object succeeds, as the state of the server can change between the two operations. The value false means that the object cannot be created.
  - Constraints: (None)
- Reason
  - Identifier: reason
  - Cardinality: 0-1
  - Mutability: read-only
  - Data Type: String
  - Description: Server-specific text explaining why the referenced object cannot be created.
  - Constraints: The element is present only when available is false.

Domain Name Availability Object

Name: Domain Name Availability Object
Identifier: domainNameAvailability
Extends: Base Availability Object
Description: The result of an Availability operation on a Domain Name Data Object.
Data Elements: (None)

Contact Availability Object

Name: Contact Availability Object
Identifier: contactAvailability
Extends: Base Availability Object
Description: The result of an Availability operation on a Contact Data Object.
Data Elements: (None)

Host Availability Object

Name: Host Availability Object
Identifier: hostAvailability
Extends: Base Availability Object
Description: The result of an Availability operation on a Host Data Object.
Data Elements: (None)

Messages The Message Components define the structure and data elements for all message objects used in the protocol. Each specific message type extends the Base Message Object to include additional data elements relevant to that message type. Any of the types defined in this section may be used for the data data element defined for the Message Data Object.

Base Message Object

Name: Base Message Object
Identifier: baseMessage
Abstract: true
Description: Base structure for all message objects, containing common data elements such as the object type and object identifier.
Data Elements:
- Object Type
  - Identifier: objectType
  - Cardinality: 0-1
  - Mutability: read-only
  - Data Type: String
  - Description: The object identifier of the object affected by the requested action (e.g., "domainName", "host", "contact").
  - Constraints:
    - Must only be used when the objectId field is present.
- Object Identifier
  - Identifier: objectId
  - Cardinality: 0-1
  - Mutability: read-only
  - Data Type: String
  - Description: The unique identifier of the object affected by the requested operation.
  - Constraints:
    - Must be a valid unique identifier for the object type specified in the objectType field.
    - For "domainName" and "host" the objectId must be a valid fully qualified domain name (FQDN).
    - For "contact" the objectId must be a valid contact identifier.
    - When the message is not related to a specific object, the objectId field may be empty.

Review Response Object The Review Response Object defines the data elements for returning the result of an offline review. Offline review is optional for the create, update, delete, transfer, renew and restore actions, where the server may want to perform an offline review before completing the requested action.

Name: Review Response Object
Identifier: reviewResponseMessage
Extends: Base Message Object
Description: Notification of the result of an offline review of a requested operation.
Data Elements:
- Approval Result
  - Identifier: approved
  - Cardinality: 1
  - Mutability: read-only
  - Data Type: Boolean
  - Description: Whether the requested action was approved and completed.
  - Constraints: false means the action was denied and not performed.
- Client Transaction ID
  - Identifier: clientTransactionId
  - Cardinality: 0-1
  - Mutability: read-only
  - Data Type: String
  - Description: The client transaction identifier from the original request, if supplied.
  - Constraints: (None)
- Server Transaction ID
  - Identifier: serverTransactionId
  - Cardinality: 1
  - Mutability: read-only
  - Data Type: String
  - Description: The server transaction identifier returned for the original request.
  - Constraints: (None)
- Completion Date
  - Identifier: completionDate
  - Cardinality: 1
  - Mutability: read-only
  - Data Type: Timestamp
  - Description: The date and time when review of the requested action was completed.
  - Constraints: (None)
- Message
  - Identifier: message
  - Cardinality: 1
  - Mutability: read-only
  - Data Type: String
  - Description: Human-readable message associated with the review response.
  - Constraints: (None)
- Process
  - Identifier: process
  - Cardinality: 0-1
  - Mutability: read-only
  - Data Type: Base Process Object
  - Description: The process whose operation was subject to the offline review.
  - Constraints: Present when the reviewed operation was performed through a Process Object (create, renew, transfer, or restore) and the server exposes that Process Object; absent otherwise, including for update and delete operations.

Transfer Request Message Object

Name: Transfer Request Message Object
Identifier: transferRequestMessage
Extends: Base Message Object
Description: Notification for losing client of started transfer request, where the client expected to act on the pending transfer request.
Data Elements:
- Transfer Status
  - Identifier: status
  - Cardinality: 1
  - Mutability: read-only
  - Data Type: String
  - Description: The current state of the transfer request.
  - Constraints: The value MUST be pending.
- Request Date
  - Identifier: requestDate
  - Cardinality: 1
  - Mutability: read-only
  - Data Type: Timestamp
  - Description: The date and time the transfer was requested.
  - Constraints: (None)
- Action Date
  - Identifier: actionDate
  - Cardinality: 0-1
  - Mutability: read-only
  - Data Type: Timestamp
  - Description: The deadline for responding before the server takes an automated action.
  - Constraints:
    - The action date MUST be later than the request date and is subject to server policy.
- Process
  - Identifier: process
  - Cardinality: 0-1
  - Mutability: read-only
  - Data Type: Transfer Process Object
  - Description: The transfer process the message pertains to.
  - Constraints: Absent if the server does not expose the Transfer Process Object.

Transfer Outcome Message Object

Name: Transfer Outcome Message Object
Identifier: transferOutcomeMessage
Extends: Base Message Object
Description: Notification for a client affected by the completion of a transfer request.
Data Elements:
- Transfer Status
  - Identifier: trStatus
  - Cardinality: 1
  - Mutability: read-only
  - Data Type: String
  - Description: The final state of the transfer request.
  - Constraints: The value MUST be one of clientApproved, clientCancelled, clientRejected, serverApproved, or serverCancelled.
- Request Date
  - Identifier: requestDate
  - Cardinality: 1
  - Mutability: read-only
  - Data Type: Timestamp
  - Description: The date and time the transfer was requested.
  - Constraints: (None)
- Action Date
  - Identifier: actionDate
  - Cardinality: 1
  - Mutability: read-only
  - Data Type: Timestamp
  - Description: The date and time the transfer request was resolved.
  - Constraints: (None)
- Expiry Date
  - Identifier: expiryDate
  - Cardinality: 0-1
  - Mutability: read-only
  - Data Type: Timestamp
  - Description: The end of the object's validity period if the operation causes a change in the validity period.
  - Constraints: (None)
- Process
  - Identifier: process
  - Cardinality: 0-1
  - Mutability: read-only
  - Data Type: Transfer Process Object
  - Description: The transfer process the message pertains to.
  - Constraints: Absent if the server does not expose the Transfer Process Object.

Expiration Deletion Message Object

Name: Expiration Deletion Message Object
Identifier: expirationDeletionMessage
Extends: Base Message Object
Description: Notification for the sponsoring client that an object was deleted following expiration.
Data Elements:
- Deletion Date
  - Identifier: deletionDate
  - Cardinality: 1
  - Mutability: read-only
  - Data Type: Timestamp
  - Description: The date and time the server deleted the object.
  - Constraints: (None)

Auto-Renewal Message Object

Name: Auto-Renewal Message Object
Identifier: autoRenewalMessage
Extends: Base Message Object
Description: Notification for the sponsoring client that the server automatically renewed an object.
Data Elements:
- Renewal Date
  - Identifier: renewalDate
  - Cardinality: 1
  - Mutability: read-only
  - Data Type: Timestamp
  - Description: The date and time the server renewed the object.
  - Constraints: (None)
- Expiry Date
  - Identifier: expiryDate
  - Cardinality: 1
  - Mutability: read-only
  - Data Type: Timestamp
  - Description: The new expiration date of the object.
  - Constraints: (None)

Service Notice Message Object The Service Notice Message Object is not linked to a specific object or process and can be used to convey general information to the client.

Name: Service Notice Message Object
Identifier: serviceNoticeMessage
Extends: Base Message Object
Description: Generic text-based message containing information not covered by any other message type.
Data Elements:
- Message
  - Identifier: message
  - Cardinality: 1
  - Mutability: read-only
  - Data Type: String
  - Description: Human-readable service information for the receiving organisation.
  - Constraints:
    - The server MUST NOT misuse this field by using it for transmitting structured data or machine-readable information.

TODO Complete the Service Notice Message Object definition, do we need it at all?

Discovery

Version Object

Name: Discovery Version Object
Identifier: discoveryVersion
Description: Describes a version of RPP supported by the server.
Data Elements:
- Version
  - Identifier: version
  - Cardinality: 1
  - Mutability: read-only
  - Data Type: String
  - Description: The RPP version, for example "1.0".
  - Constraints: The value MUST use the Semantic Versioning format.
- Base URL
  - Identifier: baseUrl
  - Cardinality: 1
  - Mutability: read-only
  - Data Type: URL
  - Description: The base URL specific for the version, used as a prefix for all endpoint URL templates.
  - Constraints: (None)

Environment Object

Name: Discovery Environment Object
Identifier: discoveryEnvironment
Description: Describes the environment of the RPP server.
Data Elements:
- Name
  - Identifier: name
  - Cardinality: 1
  - Mutability: read-only
  - Data Type: String
  - Description: The name of the RPP server, for example "rpp.example".
  - Constraints: (None)
- Status
  - Identifier: status
  - Cardinality: 1
  - Mutability: read-only
  - Data Type: String
  - Description: The operational status of the RPP server, for example "production", "test", or "development".
  - Constraints: (None)

Extension Object

Name: Extension Object
Identifier: extension
Description: Describes an extension supported by the server.
Data Elements:
- Name
  - Identifier: name
  - Cardinality: 1
  - Mutability: read-only
  - Data Type: String
  - Description: A short name for the extension, for example "registry fee extension".
  - Constraints: (None)
- Extension ID
  - Identifier: id
  - Cardinality: 1
  - Mutability: read-only
  - Data Type: String
  - Description: A unique URN identifier for the extension, for example "urn:ietf:params:rpp:extension:registry-fee".
  - Constraints: (None)
- Version
  - Identifier: version
  - Cardinality: 1
  - Mutability: read-only
  - Data Type: String
  - Description: The version of the extension that is supported or required for the profile, for example "1.0".
  - Constraints: (None)
- URL
  - Identifier: url
  - Cardinality: 1
  - Mutability: read-only
  - Data Type: URL
  - Description: The location of the extension specification.
  - Constraints:
    - For standard extensions, the value MUST be the URL of the extension in the IANA registry.
    - For private extensions, the value MUST be the URL of the extension specification. The domain name used in the URL MUST resolve and the URL MUST be accessible to the client.

IDN LGR Object

Name: Discovery IDN LGR Object
Identifier: discoveryIdnLgr
Description: Describes a Label Generation Ruleset (LGR) supported by the server for internationalized domain names.
Data Elements:
- TLDs
  - Identifier: tld
  - Cardinality: 1+
  - Mutability: read-only
  - Data Type: String
  - Description: The top-level domains (TLDs) to which the LGR applies.
  - Constraints: (None)
- Name
  - Identifier: name
  - Cardinality: 1
  - Mutability: read-only
  - Data Type: String
  - Description: The IANA-registered name of the LGR.
  - Constraints: The value MUST be a valid LGR name as listed in the IANA IDN Tables registry [IDN-Tables].
- URL
  - Identifier: url
  - Cardinality: 1
  - Mutability: read-only
  - Data Type: URL
  - Description: The location of the LGR specification in the IANA IDN Tables registry [IDN-Tables].
  - Constraints: (None)
- Default
  - Identifier: default
  - Cardinality: 1
  - Mutability: read-only
  - Data Type: Boolean
  - Description: Indicates whether this LGR is the default for the specified TLDs.
  - Constraints: (None)

Notice Object

Name: Discovery Notice Object
Identifier: discoveryNotice
Description: Describes a notice from the server operator.
Data Elements:
- Publication Time
  - Identifier: pubTime
  - Cardinality: 1
  - Mutability: read-only
  - Data Type: Timestamp
  - Description: The publication time of the notice.
  - Constraints: (None)
- Text
  - Identifier: text
  - Cardinality: 1
  - Mutability: read-only
  - Data Type: String
  - Description: A human-readable description of the notice.
  - Constraints: (None)

Process Objects This section defines the Process Objects used in this document. Each Process Object extends the Base Process Object and therefore carries its OPTIONAL Process ID data element.

Transfer Process Object

Name: Transfer Process Object
Identifier: transferProcess
Unique Identifier: processId
Extends: Base Process Object
Description: Represents a transfer request for a provisioned object. Creating this object initiates a transfer. The object supports approve and reject as additional operations, and delete as the cancel operation. Reading the object returns the current transfer status.
Data Elements:
- Transfer Direction
  - Identifier: transferDir
  - Cardinality: 0-1
  - Mutability: create-only
  - Data Type: String
  - Description: Indicates whether the transfer is a "pull" or "push" transfer. Per policy, servers usually support only one model. If omitted, server policy determines the default.
  - Constraints: The value MUST be one of: "pull" (initiated by the gaining client) or "push" (initiated by the sponsoring client).
- Gaining Client ID
  - Identifier: gainingClientId
  - Cardinality: 0-1
  - Mutability: create-only
  - Data Type: Client Identifier
  - Description: The identifier of the designated gaining client. This element is REQUIRED for push transfers and MUST NOT be provided for pull transfers.
  - Constraints: (None)
- Transfer Status
  - Identifier: trStatus
  - Cardinality: 1
  - Mutability: read-only
  - Data Type: String
  - Description: The state of the transfer request.
  - Constraints: The value MUST be one of: "pending", "clientApproved", "clientCancelled", "clientRejected", "serverApproved", "serverCancelled".
- Requesting Client ID
  - Identifier: reqClientId
  - Cardinality: 1
  - Mutability: read-only
  - Data Type: Client Identifier
  - Description: The identifier of the client that initiated the transfer request.
  - Constraints: (None)
- Request Date
  - Identifier: requestDate
  - Cardinality: 1
  - Mutability: read-only
  - Data Type: Timestamp
  - Description: The date and time that the transfer was requested.
  - Constraints: (None)
- Acting Client ID
  - Identifier: actClientId
  - Cardinality: 1
  - Mutability: read-only
  - Data Type: Client Identifier
  - Description: For a pending pull transfer, the identifier of the sponsoring client that SHOULD act upon the request. For a pending push transfer, the identifier of the designated gaining client that SHOULD act upon the request. For all other statuses, the identifier of the client that took the indicated action.
  - Constraints: (None)
- Action Date
  - Identifier: actionDate
  - Cardinality: 1
  - Mutability: read-only
  - Data Type: Timestamp
  - Description: For a pending request, the date and time by which a response is required before an automated response action SHOULD be taken by the server. For all other statuses, the date and time when the request was completed.
  - Constraints: (None)

Operations

Create (Transfer Request)

Identifier: transferCreate

The Create operation initiates a transfer by creating a Transfer Process Object associated with the provisioned object. The transfer direction and gaining client (for push transfers) are provided as create-only data elements of the Transfer Process Object.

Authorisation:
- Pull transfer:
  - The requesting client (gaining client) MUST provide valid Object Authorisation.
- Push transfer:
  - Only the sponsoring client is authorised to initiate a push transfer.
Input:
- Reference: Owner Data Object
- Object: Transfer Process Object
Output:
- Object: Transfer Process Object

Read (Transfer Query)

Identifier: transferRead

The Read operation allows a client to determine the real-time status of a pending or recently completed transfer request.

Authorisation:
- This operation MUST be accessible to both the sponsoring client and the gaining client.
- Server policy determines whether other clients may query transfer status and what information is returned.
Input:
- Reference: This Object
Output:
- Object: Transfer Process Object

Delete (Transfer Cancel)

Identifier: transferDelete

The Delete operation allows the initiating client to cancel its own pending transfer request.

Authorisation:
- Only the initiating client (the client that originally requested the transfer).
Input:
- Reference: This Object
Output:
- Object: Transfer Process Object
  - Cardinality: 0-1

Approve

Identifier: transferApprove

The Approve operation allows the appropriate client to accept a pending transfer request.

Authorisation:
- Pull transfer:
  - only the sponsoring client
- Push transfer:
  - only the designated gaining client
Input:
- Reference: This Object
Output:
- Object: Transfer Process Object

Reject

Identifier: transferReject

The Reject operation allows the appropriate client to decline a pending transfer request.

Authorisation:
- Pull transfer:
  - only the sponsoring client
- Push transfer:
  - only the designated gaining client
Input:
- Reference: This Object
- Input Data Elements:
  - Reason
    - Identifier: reason
    - Cardinality: 0-1
    - Data Type: String
    - Description: A human-readable text describing the rationale for rejecting the transfer request.
    - Constraints: In EPP Compatibility Profile this data element MUST NOT be used
Output:
- Object: Transfer Process Object

Restore Process Object

Name: Restore Process Object
Identifier: restoreProcess
Unique Identifier: processId
Extends: Base Process Object
Description: Represents the current state of a restore request for an object that has entered the Redemption Grace Period (RGP).
Data Elements:
- Restore Status
  - Identifier: restoreStatus
  - Cardinality: 1
  - Mutability: read-only
  - Data Type: String
  - Description: The current state of the restore process.
  - Constraints: The value MUST be one of: "pendingRestore", "restored", "rgpPendingDelete"
- Request Date
  - Identifier: requestDate
  - Cardinality: 0-1
  - Mutability: read-only
  - Data Type: Timestamp
  - Description: The date and time when the restore request was submitted.
  - Constraints: MUST NOT be present if no restore request has been submitted yet.
- Report Date
  - Identifier: reportDate
  - Cardinality: 0-1
  - Mutability: read-only
  - Data Type: Timestamp
  - Description: The date and time when the most recent restore report was accepted by the server.
  - Constraints: MUST NOT be present if no restore report has been accepted yet.
- Report Due Date
  - Identifier: reportDueDate
  - Cardinality: 0-1
  - Mutability: read-only
  - Data Type: Timestamp
  - Description: The date and time by which a restore report must be submitted before the object reverts to rgpRedemptionPeriod state. Only present when the object is in rgpPendingRestore state.
  - Constraints: MUST NOT be present when restoreStatus is not "pendingRestore".
- Restore Report
  - Identifier: restoreReport
  - Cardinality: 0-1
  - Mutability: read-write
  - Data Type: Restore Report Object
  - Visibility: onDemand
  - Description: The restore report submitted by the sponsoring client as required by the RGP process. A client MAY provide it in the Create operation, so that the restore request and the report are processed atomically, or in a later Update operation while the object is in rgpPendingRestore state. A report provided in an Update operation replaces any previously submitted report.
  - Constraints:
    - MUST NOT be provided if the server does not require a restore report.
    - In EPP Compatibility Profile, the restore report is write-only: the server does not return it in the output of any operation, because provides no means to retrieve a submitted report.
    - In EPP Compatibility Profile, providing this element in the Create operation corresponds to op="report", omitting it corresponds to op="request", and providing it in the Update operation corresponds to op="report" as defined in .

Operations

Create (Restore Request)

Identifier: create

The Create operation initiates the recovery of an object in the rgpRedemptionPeriod state by creating a Restore Process Object. The server MUST reject this operation if the owning object is not in the rgpRedemptionPeriod state. If the server requires a restore report and restoreReport is absent, the object transitions to rgpPendingRestore state awaiting a subsequent Update operation. Otherwise the restore is completed immediately.

Authorisation:
- Only the sponsoring client is authorised to perform this operation.
Input:
- Reference: Owner Data Object
- Object: Restore Process Object
- Input Data Elements:
  - Restore Report
    - Identifier: restoreReport
    - Cardinality: 0-1
    - Data Type: Restore Report Object
    - Description: An OPTIONAL inline restore report. If provided, the server processes the request and the report atomically. If the server does not require a restore report, this element MUST NOT be present and the restore is completed immediately. If the server requires a report and this element is absent, the object transitions to pendingRestore state awaiting a subsequent Report operation.
    - Constraints:
    - MUST NOT be provided if the server does not require a restore report.
    - In EPP Compatibility Profile, corresponds to op="request" (without report) or a combined op="request" followed immediately by op="report" as defined in .
Output:
- Object: Restore Process Object

Read (Restore Query)

Identifier: read

The Read operation allows the sponsoring client to retrieve the current state of the RGP process for an object.

Authorisation:
- Only the sponsoring client is authorised to perform this operation.
Input:
- Reference: This Object
Output:
- Object: Restore Process Object

In EPP Compatibility Profile this operation is not supported.

Update (Restore Report)

Identifier: update

This operation is OPTIONAL, only for servers which support or require submission of a restore report. The Update operation submits the restore report required by the RGP process for an object in the rgpPendingRestore state. Since restoreReport is the only read-write data element of the Restore Process Object, the client MUST provide it in this operation. A report MAY be submitted more than once if corrections are required. The server MUST reject this operation if the object is not in the rgpPendingRestore state.

Authorisation:
- Only the sponsoring client is authorised to perform this operation.
Input:
- Reference: This Object
- Input Data Elements:
  - Restore Report
    - Identifier: restoreReport
    - Cardinality: 1
    - Data Type: Restore Report Object
    - Description: The restore report to be submitted as part of the RGP process.
    - Constraints:
    - In EPP Compatibility Profile, corresponds to op="report" as defined in .
Output:
- Object: Restore Process Object

Renew Process Object

Name: Renew Process Object
Identifier: renewProcess
Unique Identifier: processId
Extends: Base Process Object
Description: Represents a renew request for a provisioned object. Creating this object initiates a renewal process that extends the registration period of the object. Reading this object returns the new expiry date if the renewal has been completed.
Data Elements:
- Expiry Date
  - Identifier: expiryDate
  - Cardinality: 0-1
  - Mutability: create-only
  - Data Type: Timestamp
  - Description: The current expiry date of the object. The server MUST validate this against the object's current expiryDate to prevent unintended duplicate renewals.
- Renewal Period
  - Identifier: renewalPeriod
  - Cardinality: 0-1
  - Mutability: create-only
  - Data Type: Period Object
  - Description: The duration to be added to the object's registration period. This value is used by the server to calculate the new expiryDate. The default value MAY be defined by server policy. The number of units available MAY be subject to limits imposed by the server.

Operations

Create (Renew Request)

Identifier: renewCreate

The renew operation extends the validity period of an existing object by creating a Renew Process Object.

Input:
- Reference: Owner Data Object
- Object: Renew Process Object
Output:
- Object: Renew Process Object
Authorisation:
- Only the sponsoring client is authorised to perform this operation.

Create Process Object

Name: Create Process Object
Identifier: createProcess
Unique Identifier: processId
Extends: Base Process Object
Description: Represents the process initiated when a resource creation operation is performed. It carries creation-specific inputs that are consumed during the creation operation and are not stored as persistent attributes of the created resource object.
Data Elements: (None)

Beyond the data elements of the Base Process Object, the generic Create Process Object defines no additional data elements. Individual object definitions extend it with object-specific creation inputs (such as the Domain Create Process Object , which adds the registration period).

Operations

Create

Identifier: create

The Create operation is invoked implicitly as a side effect of the resource object create operation and is never invoked directly. It carries the creation-specific inputs consumed during the creation of the owning resource object.

Input:
- Object: Create Process Object
Output:
- Object: Create Process Object
Authorisation:
- Inherited from the resource object create operation that initiates this process.

Read

Identifier: read

The Read operation retrieves the result or status of the creation, if the server exposes the process resource.

Input:
- Reference: This Object
Output:
- Object: Create Process Object
Authorisation:
- Only the sponsoring client is authorised to perform this operation.

Domain Name Data Object

Object Description

Name: Domain Name Data Object
Identifier: domainName
Unique Identifier: name
Description: A Domain Name data object represents a domain name and contains the data required for its provisioning and management in the registry.

Data Elements The following data elements are defined for the Domain Name Data Object.

Name
- Identifier: name
- Cardinality: 1
- Mutability: create-only
- Data Type: Fully Qualified Domain Name
- Description: The fully qualified name of the domain object.
- Constraints:
  - A server MAY restrict allowable domain names to a particular top-level domain, second-level domain, or other domain for which the server is authoritative.
  - If the domain name is an internationalized domain name (IDN), the value MUST be a valid ACE-encoded string representing the Unicode Name (uName).
Unicode Name
- Identifier: uName
- Cardinality: 0-1
- Mutability: create-only
- Data Type: String
- Description: The fully qualified name of the domain using the Unicode character set.
- Constraints:
  - The value MUST be a fully qualified domain name in Unicode Normalization Form C (NFC) as defined in [UNICODE.NFC].
  - The server MUST validate the Unicode Name using the procedure described in section 4.2 of [RFC5891].
  - Every code point in the value MUST be classified as a candidate for inclusion by the rules defined in .
  - If the value contains a code point from a script with Right-to-Left directionality, the value MUST satisfy the Bidi Rule defined in .
  - The Unicode (U-label) form of the domain name, when converted according to the procedures defined in Section 2.3.2.4 of , MUST be equal to the corresponding A-label representation.
  - Any code point valid under IDNA2003 but disallowed under IDNA2008 MUST NOT be allowed in the Unicode Name (uName).
LGR
- Identifier: lgr
- Cardinality: 0-1
- Mutability: create-only
- Data Type: String
- Description: The name of the Label Generation Ruleset (LGR) containing the valid code points used for the Unicode Name (uName).
- Constraints:
  - MUST NOT be empty when the Unicode Name (uName) is provided.
  - MUST be a valid LGR name registered in the IANA IDN Tables registry [IDN-Tables].
Provisioning Metadata
- Identifier: provMetadata
- Cardinality: 1
- Mutability: read-only
- Data Type: Provisioning Metadata Object
- Description: Standard metadata about the object's lifecycle and ownership.
- Constraints: (None)
Status
- Identifier: status
- Cardinality: 1+
- Mutability: read-write
- Data Type: Domain Name Status Object
- Description: The current status descriptors associated with the domain.
- Constraints:
  - Possible combinations of Status Object Labels are specified in .
Registrant
- Identifier: registrant
- Cardinality: 0-1
- Mutability: read-write
- Data Type: Aggregation[Contact Data Object]
- Description: The contact object associated with the domain as the registrant.
- Constraints:
  - The relation MUST correspond to a valid Contact Data Object known to the server.
  - Servers MAY restrict association of a Contact Data Object of a different sponsoring client.

Contacts
- Identifier: contacts
- Cardinality: 0+
- Mutability: read-write
- Data Type: LabelledAggregation[Contact Data Object]
  - Label Description: The role of the associated contact.
  - Label Constraints:
    - List of supported roles is defined by server policy
    - In the EPP Compatibility Profile, the value MUST be one of: "admin", "billing", or "tech"
- Description: A collection of other contact objects associated with the domain object.
- Constraints:
  - Each associated contact MUST correspond to a valid Contact Data Object known to the server before it can be associated with the domain.
  - Maximum number of associated contacts (per role) MAY be restricted by server policy

Nameservers
- Identifier: nameservers
- Cardinality: 0+
- Mutability: read-write
- Data Type: Aggregation[Host Data Object]
- Description: A collection of nameservers associated with the domain.
- Constraints:
  - A Host Data Object MUST be known to the server before it can be associated with the domain.
  - MUST not be used when 1 or more DNS Data entries are specified through the DNS Data element.
DNS Data
- Identifier: dns
- Cardinality: 0-1
- Mutability: read-write
- Data Type: DNS Data Object
- Description: DNS resource records and operational controls related to the domain name. This structure follows the unified DNS data model defined in , providing a single container for all DNS-related provisioning data including delegation, DNSSEC, and other record types.
- Constraints:
  - The type of the record entries MAY be constrained by the server policy. Typically the values would be limited to allowed parent-side resource record types.
  - In EPP Compatibility Profile, a server MUST support NS, A, and AAAA record types for delegation, and with DNSSEC Extension a server MUST additionally support DS and/or DNSKEY record types.
  - The names of DNS entries MUST be the domain name itself or subordinate to the domain name and MUST NOT be below zone cut in case of present delegation.
  - A server MAY forbid use of NS/A/AAAA record types if the server only supports host object model through Nameserver property defining those records.
  - MUST not be used when 1 or more nameservers are specified through the Nameserver element.
Subordinate Hosts
- Identifier: subordinateHosts
- Cardinality: 0+
- Mutability: read-only
- Data Type: Aggregation[Host Data Object]
- Description: A collection of subordinate host objects that exist under this domain.
- Constraints: (None)
Expiry Date
- Identifier: expiryDate
- Cardinality: 0-1
- Mutability: read-only
- Data Type: Timestamp
- Description: The date and time identifying the end of the domain object's registration period.
- Constraints: The value is set by the server and cannot be specified by the client.
Authorisation Information
- Identifier: authInfo
- Cardinality: 0-1
- Mutability: read-write
- Data Type: Authorisation Information Object
- Visibility: onDemand
- Description: Authorisation information associated with the domain object.
- Constraints:
  - This element MUST only be returned if the querying client is the sponsoring client or if the client supplied valid Object Authorisation with the operation.
Processes
- Identifier: processes
- Cardinality: 0-1
- Mutability: read-only
- Data Type: Processes Object
- Direct Access: true
- Description: The Process Objects currently or recently initiated on the domain object.
- Constraints: (None)

Operations

Availability Operation

Identifier: availability

The Availability operation allows a client to determine whether a Domain Name resource with the given name can be created. The operation has no input data elements and takes no object representation as input. The client identifies the resource by its Reference only, i.e. only the Unique Identifier (Name) is taken into consideration.

Authorisation:
- Any authenticated client is authorised to perform this operation.
Input:
- Reference: This Object
- Parameters:
  - Unicode Name
    - Identifier: uName
    - Cardinality: 0-1
    - Data Type: String
    - Description: The Unicode Name (uName) of the domain name for which availability is determined. If the parameter is absent, the server determines availability from the referenced domain name only.
    - Constraints:
    - The value MUST satisfy the constraints of the Unicode Name data element of the Domain Name Data Object.
    - If the value does not map to the referenced domain name, the server MUST return an error indicating the mismatch.
  - LGR
    - Identifier: lgr
    - Cardinality: 0-1
    - Data Type: String
    - Description: The name of the Label Generation Ruleset (LGR) against which the server determines availability of the domain name. If the parameter is absent, the server uses its default LGR for the top-level domain, as indicated by the Discovery IDN LGR Object.
    - Constraints:
    - The value MUST be a valid LGR name registered in the IANA IDN Tables registry [IDN-Tables].
    - If the domain name contains a code point not available in the specified LGR, the server MUST return an error indicating the invalid code point.
Output:
- Object: Domain Name Availability Object

Create Operation

Identifier: create

The Create operation allows a client to provision a new Domain Name resource. The operation accepts as input all create-only and read-write data elements defined for the Domain Name Data Object.

Authorisation:
- Generally each client is authorised to create new domain objects becoming a sponsoring client. This can be however constrained by the server policy in many ways, i.e. by applying rate limiting, billing-related constraints or compliance locks.
Input:
- Object: This Object
- Object: Domain Create Process Object

The Create operation implicitly initiates the Domain Create Process Object , which carries the creation-specific inputs that are consumed during creation and not persisted as part of the domain object's state. The server MUST validate the name using the procedure described in section 4.2 of [RFC5891]. If the validation of the IDN name failed because it contained a code point not available in the specified IDN table, the server MUST return an error indicating the invalid code point. If the name does not map to the provided Unicode Name (uName), the server MUST respond with an appropriate error indicating the mismatch.

Read Operation

Identifier: read

The Read operation allows a client to retrieve the data elements of a Domain Name resource. The server's response MAY vary depending on client authorisation and server policy.

Authorisation:
- Sponsoring client:
  - Full object
- Other client:
  - Without Object Authorisation:
    - Limited object (non-confidential properties) or operation denied
  - With Object Authorisation:
    - Full object, however some properties only authorised to the sponsoring client MAY be redacted according to server policy
Input:
- Reference: This Object
- Parameters:
  - Hosts Filter
    - Identifier: hostsFilter
    - Cardinality: 0-1
    - Data Type: String
    - Description: Controls which host information is returned with the object.
    - Constraints: The value MUST be one of "all", "del" (delegated), "sub" (subordinate), or "none". The default value is "all".

Update Operation

Identifier: update

The Update operation allows a client to modify the read-write data elements of an existing Domain Name resource.

Authorisation:
- Only sponsoring client is authorised to perform this operation

At least one change to a read-write data element MUST be provided, unless the operation is extended. The registrant and the Authorisation Information MAY be removed. Contacts, nameservers, and the registrant to be added MUST be known to the server.

Delete Operation

Identifier: delete

The Delete operation allows a client to remove an existing Domain Name resource. The operation targets a specific data object identified by its name.

Authorisation:
- Only sponsoring client is authorised to perform this operation

The server SHOULD reject a delete request if subordinate host objects are associated with the domain name. The error response SHOULD indicate the related subordinate host objects.

Processes The Domain Name Data Object supports the following Process Objects unmodified:

Renew Process
Restore Process
- Constraints: OPTIONAL; available only when the RGP feature is supported.

The Domain Name Data Object supports the following Process Objects extended by an object-specific definition: * Domain Create Process * Domain Transfer Process

Domain Create Process Object

Name: Domain Create Process Object
Identifier: domainCreateProcess
Extends: Create Process Object
Unique Identifier: processId
Description: The domain-specific Create Process Object . It is implicitly initiated by the Domain Name Data Object create operation and carries the domain creation-specific inputs, namely the requested initial registration period, that are consumed during creation and not persisted as part of the domain object's state.
Data Elements:
- Period
  - Identifier: period
  - Cardinality: 0-1
  - Mutability: create-only
  - Data Type: Period Object
  - Description: The initial registration period for the domain name. This value is used by the server to calculate the initial expiryDate of the object.
  - Constraints: The default value MAY be defined by server policy. The number of units available MAY be subject to limits imposed by the server.

Operations

Create

Identifier: create

The Create operation is invoked implicitly as a side effect of the Domain Name Data Object create operation and is never invoked directly. It carries the registration period consumed during domain creation.

Input:
- Object: Domain Create Process Object
Output:
- Object: Domain Create Process Object
Authorisation:
- Inherited from the Domain Name Data Object create operation that initiates this process.

Read

Identifier: read

The Read operation retrieves the result or status of the domain creation, if the server exposes the process resource.

Input:
- Reference: This Object
Output:
- Object: Domain Create Process Object
Authorisation:
- Only the sponsoring client is authorised to perform this operation.

Domain Transfer Process Object

Name: Domain Transfer Process Object
Identifier: domainTransferProcess
Extends: Transfer Process Object
Unique Identifier: processId
Description: The domain-specific Transfer Process Object . It carries the domain-specific transfer inputs and outputs (the requested transfer period and the resulting expiry date) that extend the common transfer process.
Data Elements:
- Expiry Date
  - Identifier: expiryDate
  - Cardinality: 0-1
  - Mutability: read-only
  - Data Type: Timestamp
  - Description: The end of the domain object's registration period if the transfer caused or causes a change in the validity period.
  - Constraints: (None)
- Transfer Period
  - Identifier: transferPeriod
  - Cardinality: 0-1
  - Mutability: create-only
  - Data Type: Period Object
  - Description: The number of units to be added to the registration period of the domain object upon successful completion of the transfer. The number of units available MAY be subject to limits imposed by the server.
  - Constraints:
    - In EPP Compatibility Profile, Transfer Period cannot be read from the Transfer Process Object

Transfer of a Domain Name Data Object MUST implicitly transfer all Host Data Objects that are subordinate to the domain object. For example, if domain object "example.com" is transferred and host object "ns1.example.com" exists, the host object MUST be transferred as part of the "example.com" transfer process. Actions that do not preserve the relationship between a domain object and its subordinate host objects MUST be disallowed.

Operations

Create

Identifier: transferCreate

The Create operation initiates a transfer of the Domain Name Data Object by creating a Domain Transfer Process Object, extending the common Transfer Create Operation .

Input:
- Reference: Owner Data Object
- Object: Domain Transfer Process Object
Output:
- Object: Domain Transfer Process Object
Authorisation: as defined in .

Contact Data Object

Object Description

Name: Contact Data Object
Identifier: contact
Unique Identifier: id
Description: A Contact Data Object represents the contact information for an individual or organisation associated with other objects.

Data Elements The following data elements are defined for the Contact Data Object.

Handle ID
- Identifier: id
- Cardinality: 1
- Mutability: create-only
- Data Type: Identifier
- Description: External unique identifier of the contact object.
- Constraints:
  - This value MUST be supported to be provided by the client.
  - Servers MAY support server-side generation of this value.
Provisioning Metadata
- Identifier: provMetadata
- Cardinality: 1
- Mutability: read-only
- Data Type: Provisioning Metadata Object
- Description: Standard metadata about the object's lifecycle and ownership.
- Constraints: (None)
Status
- Identifier: status
- Cardinality: 1+
- Mutability: read-write
- Data Type: Contact Status Object
- Description: Status descriptors associated with the contact.
- Constraints:
  - Possible combinations of Contact Status Labels are specified in Contact Status Values.
Contact Information
- Identifier: contactInfo
- Cardinality: 1
- Mutability: read-write
- Data Type: External:RPP-JSContact-Profile:Card
- Description: Contains contact information.
- Constraints:
  - In EPP Compatibility Profile, at most one internationalised and one localised form of the contact information are provided. The internationalised form MUST be represented in a subset of UTF-8 that can be represented in the 7-bit US-ASCII character set, while the localised form MAY be represented in unrestricted UTF-8.
  - In EPP Compatibility Profile, a postal address consists of up to three street lines, a city, an OPTIONAL state or province, an OPTIONAL postal code, and a country code that is a two-character identifier as specified in ISO 3166-1.
  - In EPP Compatibility Profile, telephone numbers MUST begin with a plus sign ("+"), followed by a country code defined in ITU-T E.164, followed by a dot ("."), followed by a sequence of digits, and MAY note an extension. Email addresses MUST conform to the syntax defined in .
Authorisation Information
- Identifier: authInfo
- Cardinality: 0-1
- Mutability: read-write
- Data Type: Authorisation Information Object
- Visibility: onDemand
- Description: Authorisation information associated with the contact object.
- Constraints: (None)
Disclose
- Identifier: disclose
- Cardinality: 0-1
- Mutability: read-write
- Data Type: Disclose Object
- Description: Identifies elements that require exceptional server-operator handling to allow or restrict disclosure to third parties.
- Constraints:
  - A server MUST reject any transaction that requests disclosure practices that do not conform to the server's announced data-collection policy.
Processes
- Identifier: processes
- Cardinality: 0-1
- Mutability: read-only
- Data Type: Processes Object
- Direct Access: true
- Description: The Process Objects currently or recently initiated on the contact object.
- Constraints: (None)

Operations

Availability Operation

Identifier: availability

The Availability operation allows a client to determine whether a Contact resource with the given Handle ID can be created. The operation has no input data elements and takes no object representation as input. The client identifies the resource by its Reference only, i.e. only the Unique Identifier (Handle ID) is taken into consideration.

Authorisation:
- Any authenticated client is authorised to perform this operation.
Output:
- Object: Contact Availability Object

Create Operation

Identifier: create

The Create operation allows a client to provision a new Contact resource. The operation accepts as input all create-only and read-write data elements defined for the Contact Data Object.

Authorisation:
- Generally each client is authorised to create new contact objects becoming a sponsoring client. This can be however constrained by the server policy, e.g. by applying rate limiting or compliance locks.

In EPP Compatibility Profile, the following data elements MUST be provided:

Handle ID (id)
At least one Contact Information entry (contactInfo) containing a Name (name) and an Address (addr) with City (city) and Country Code (cc)
Email (email)
Authorisation Information (authInfo)

Read Operation

Identifier: read

The Read operation allows a client to retrieve the data elements of a Contact resource. The server's response MAY vary depending on client authorisation and server policy.

Authorisation:
- Sponsoring client:
  - Full object
- Other client:
  - Without Object Authorisation:
    - Limited object (non-confidential properties) or operation denied
  - With Object Authorisation:
    - Full object, however some properties only authorised to the sponsoring client MAY be redacted according to server policy

Authorisation Information (authInfo) MUST NOT be provided in the response if the querying client is not the current sponsoring client. When constructing the response, the server MUST respect the disclosure policies defined by the Disclose Object (disclose), whether set by the server operator's default data-collection policy or by the sponsoring client for the contact. Data elements marked for non-disclosure MUST NOT be included in responses to unauthorised clients.

Update Operation

Identifier: update

The Update operation allows a client to modify the attributes of an existing Contact resource.

Authorisation:
- Only sponsoring client is authorised to perform this operation

The following aspects of the contact object MAY be modified:

Status values that are client-manageable (prefixed with "client") MAY be added or removed.
Contact Information, Voice Phone Number, Fax Phone Number, Email, Authorisation Information, and Disclose preferences MAY be changed.

At least one change MUST be provided, unless the operation is extended.

Delete Operation

Identifier: delete

The Delete operation allows a client to remove an existing Contact resource. The operation targets a specific data object identified by its Handle ID.

Authorisation:
- Only sponsoring client is authorised to perform this operation

The server SHOULD reject a delete request if the contact object is associated with other known objects (e.g., domain names). An associated contact SHOULD NOT be deleted until associations with other known objects have been broken. The error response SHOULD indicate the existing object associations.

Processes The Contact Data Object supports the following Process Objects unmodified:

Transfer Process

The Contact Data Object supports no Process Objects extended by an object-specific definition.

Host Data Object

Object Description

Name: Host Data Object
Identifier: host
Unique Identifier: hostName
Description: A Host Data Object represents a nameserver that provides DNS services for a domain name.

Data Elements The following data elements are defined for the Host Data Object.

Host Name
- Identifier: hostName
- Cardinality: 1
- Mutability: read-write
- Data Type: Fully Qualified Domain Name
- Description: Fully qualified name of a host.
- Constraints:
  - An Internal host MUST be treated as a subordinate host when it is used as a nameserver for a domain other than its superordinate domain.
  - Actions that do not preserve the relationship between a host object and its superordinate domain object MUST be disallowed.
Provisioning Metadata
- Identifier: provMetadata
- Cardinality: 1
- Mutability: read-only
- Data Type: Provisioning Metadata Object
- Description: Standard metadata about the object's lifecycle and ownership.
- Constraints: (None)
Status
- Identifier: status
- Cardinality: 1+
- Mutability: read-write
- Data Type: Host Status Object
- Description: The current status descriptors associated with the host.
- Constraints: Possible combinations of Host Status Labels are specified in Host Status Values
DNS Data
- Identifier: dns
- Cardinality: 0-1
- Mutability: read-write
- Data Type: DNS Data Object
- Description: DNS resource records and operational controls related to the host. This structure follows the unified DNS data model defined in .
- Constraints:
  - The names of DNS entries MUST be the host name itself or subordinate to the host name.
  - In EPP Compatibility Profile the record entries MUST be limited to A and AAAA entries for IPv4 and IPv6 glue records respectively.
  - In EPP Compatibility Profile, IPv4 addresses MUST conform to and IPv6 addresses MUST conform to . A server MAY reject IP addresses that have not been allocated for public use by IANA.
Processes
- Identifier: processes
- Cardinality: 0-1
- Mutability: read-only
- Data Type: Processes Object
- Direct Access: true
- Description: The Process Objects currently or recently initiated on the host object.
- Constraints: (None)

Operations

Availability Operation

Identifier: availability

The Availability operation allows a client to determine whether a Host Data Object with the given host name can be created. The operation has no input data elements and takes no object representation as input. The client identifies the resource by its Reference only, i.e. only the Unique Identifier (Host Name) is taken into consideration.

Authorisation:
- Any authenticated client is authorised to perform this operation.
Output:
- Object: Host Availability Object

Create Operation

Identifier: create

The Create operation allows a client to provision a new Host Data Object. The operation accepts as input all create-only and read-write data elements defined for the Host Data Object.

Authorisation:
- Generally each client is authorised to create new host objects becoming a sponsoring client. This can be however constrained by the server policy, e.g. by applying rate limiting or compliance locks.

If the host name exists in a namespace for which the server is authoritative, then the superordinate domain of the host MUST be known to the server before the host object can be created. In EPP Compatibility Profile, IP addresses are REQUIRED only as needed to produce DNS glue records. If the host name exists in a namespace for which the server is authoritative and is subordinate to an existing domain, IP addresses SHOULD be provided. If the host name is external to the server's namespace, IP addresses are not required by the DNS and MAY be omitted.

Read Operation

Identifier: read

The Read operation allows a client to retrieve the data elements of a Host Data Object.

Authorisation:
- Any client is authorised to retrieve the full object. In EPP Compatibility Profile, host objects do not carry authorisation information and there is no distinction based on client identity as described in .

Update Operation

Identifier: update

The Update operation allows a client to modify the attributes of an existing Host Data Object. The operation targets a specific data object identified by its host name.

Authorisation:
- Only sponsoring client is authorised to perform this operation

Host name changes MAY require the addition or removal of IP addresses to be accepted by the server. IP address association MAY be subject to server policies for provisioning hosts as nameservers. The IP address restrictions described for the Create operation apply to updates as well. At least one change to a data element MUST be provided, unless the operation is extended. Host name changes can have an impact on associated objects that refer to the host object. A Host Name change SHOULD NOT require additional updates of associated objects to preserve existing associations, with one exception: changing an External host object that has associations with objects that are sponsored by a different client. Attempts to update such hosts directly MUST fail. The change can be provisioned by creating a new External host with a new name and any needed new attributes, and subsequently updating the other objects sponsored by the client.

Delete Operation

Identifier: delete

The Delete operation allows a client to remove an existing Host Data Object. The operation targets a specific data object identified by its host name.

Authorisation:
- Only sponsoring client is authorised to perform this operation

The server SHOULD reject a delete request if the host object is associated with any other object, such as a domain name object. Deleting a host object without first breaking existing associations can cause DNS resolution failure for domain objects that refer to the deleted host object. The error response SHOULD indicate the related associated objects.

Processes The Host Data Object supports the following Process Objects unmodified:

Transfer Process
- Constraints: Host objects MUST NOT be transferred directly. They are transferred implicitly when their superordinate domain object is transferred.

The Host Data Object supports no Process Objects extended by an object-specific definition.

Organisation Data Object

Object Description

Name: Organisation Data Object
Identifier: organisation
Unique Identifier: id
Description: An Organisation Data Object represents an entity, such as a registrar or reseller that is involved in the domain registration process. This object is based on the EPP Organisation Mapping defined in .

Data Elements The following data elements are defined for the Organisation Data Object.

Organisation ID
- Identifier: id
- Cardinality: 1
- Mutability: create-only
- Data Type: Identifier
- Description: A server-unique identifier for the organisation object.
- Constraints:
  - This value MUST be supported to be provided by the client.
  - Servers MAY support server-side generation of this value.
Provisioning Metadata
- Identifier: provMetadata
- Cardinality: 1
- Mutability: read-only
- Data Type: Provisioning Metadata Object
- Description: Standard metadata about the object's lifecycle and ownership.
- Constraints: (None)
Status
- Identifier: status
- Cardinality: 1+
- Mutability: read-write
- Data Type: Organisation Status Object
- Description: The current operational status descriptors associated with the organisation. An organisation object MUST always have at least one associated status value.
- Constraints:
  - Possible combinations of Organisation Status Labels are specified in Organisation Status Values.
  - A client MUST NOT alter server status values set by the server itself.
Roles
- Identifier: roles
- Cardinality: 1+
- Mutability: read-write
- Data Type: DictionaryComposition[Organisation Role Object]
  - Label Description: type of role
  - Label Constraints: The value MUST be one of the role types registered in the IANA "EPP Organisation Role Values" registry as defined in . Initial values include registrar, reseller, privacyproxy, and dns-operator.
- Description: One or more roles describing the relationship the organisation has within the registry ecosystem. An organisation object MUST always have at least one associated role.
- Constraints:
  - An organisation MAY have multiple roles with different role types.
  - Role types are registered in the IANA "EPP Organisation Role Values" registry as defined in . Initial values include registrar, reseller, privacyproxy, and dns-operator.
Parent Organisation
- Identifier: parent
- Cardinality: 0-1
- Mutability: read-write
- Data Type: Aggregation[Organisation Data Object]
- Description: The parent organisation in a hierarchical organisation structure (e.g., a reseller's parent registrar).
- Constraints:
  - Loops MUST be prohibited. If organisation A has organisation B as its parent, organisation B MUST NOT have organisation A as its parent, directly or transitively.
Contact Information
- Identifier: contactInfo
- Cardinality: 0-1
- Mutability: read-write
- Data Type: External:RPP-JSContact-Profile:Card
- Description: Contact information for the organisation.
Contacts
- Identifier: contacts
- Cardinality: 0+
- Mutability: read-write
- Data Type: LabelledAggregation[Contact Data Object]
  - Label Description: type of contact
  - Label Constraints: The value MUST be one of the contact types registered in the IANA "EPP Organisation Contact Types" registry as defined in . Initial values include admin, tech, billing, abuse, and custom.
- Description: Identifiers of contact objects associated with the organisation.
- Constraints:
  - Contact object identifiers MUST be known to the server before the contact can be associated.

Users
- Identifier: users
- Cardinality: 0+
- Mutability: read-write
- Data Type: LabelledAggregation[User Data Object]
  - Label Description: RBAC role of the user
  - Label Constraints: The value MUST be one of the role types registered in the IANA "RPP User Role Values" registry.
- Direct Access: true
- Description: One or more RBAC roles assigned to the user.
- Constraints:
  - Each role value MUST be a non-empty string.
  - Allowed role values MAY be constrained by server policy.
Processes
- Identifier: processes
- Cardinality: 0-1
- Mutability: read-only
- Data Type: Processes Object
- Direct Access: true
- Description: The Process Objects currently or recently initiated on the organisation object.
- Constraints: (None)

Operations

Create Operation

Identifier: create

The Create operation allows a client to provision a new Organisation Data Object. The operation accepts as input all create-only and read-write data elements defined for the Organisation Data Object.

Authorisation:
- Generally only registry clients are authorised to create new organisation objects.

An organisation object MUST include at least one role on creation. The server MAY defer completing the action and return a pendingCreate status if human or third-party review is required.

Read Operation

Identifier: read

The Read operation allows a client to retrieve the data elements of an Organisation Data Object.

Authorisation:
- Any client is authorised to retrieve organisation object information. The server MAY restrict the information returned based on client identity and server policy.

Update Operation

Identifier: update

The Update operation allows a client to modify the attributes of an existing Organisation Data Object.

Authorisation:
- Generally only registry clients are authorised to update organisation objects.

The following aspects of the organisation object MAY be modified:

Contacts MAY be added or removed.
Roles MAY be added or removed.
Status values that are client-manageable (prefixed with "client") MAY be added or removed.
Parent Organisation ID and Contact Information MAY be changed.
Users MAY be added or removed.

A client MUST NOT add, delete, or alter values for statuses managed by the server (prefixed with "server"). A server MAY add, delete, or alter status values set by a client, subject to server policy.

Delete Operation

Identifier: delete

The Delete operation allows a client to remove an existing Organisation Data Object. The operation targets a specific data object identified by its Organisation ID.

Authorisation:
- Generally only registry clients are authorised to delete organisation objects.

An organisation object MUST NOT be deleted if it is associated with other known objects (e.g., domain names, contacts, or child organisations). The server MUST reject such a delete request and notify the client that object relationships exist. The error response SHOULD indicate the related associated objects.

Message Data Object

Object Description

Name: Message Data Object
Identifier: message
Unique Identifier: id
Description: A Message Data Object represents a message which is inserted in the message queue of an organisation and retrieved by clients associated with that organisation.

Data Elements The following data elements are defined for the Message Data Object.

Message ID
- Identifier: id
- Cardinality: 1
- Mutability: read-only
- Data Type: Identifier
- Description: A server-unique identifier for the message object.
- Constraints: (None)
Creation Date
- Identifier: creationDate
- Cardinality: 1
- Mutability: read-only
- Data Type: Timestamp
- Description: The date and time when the message object was created and inserted into the queue.
- Constraints: The value is set by the server.
Status
- Identifier: status
- Cardinality: 1
- Mutability: read-only
- Data Type: String
- Description: The current lifecycle status of the message object.
- Constraints:
  - Possible values: queued, delivered and removed
Data
- Identifier: data
- Cardinality: 1
- Mutability: create-only
- Data Type: Base Message Object
- Description: The data related to a specific message type, such as a transfer request or a review response.
- Constraints: (None)

Operations

Create Operation

Identifier: create

The Create operation allows a server to insert a new message into the queue for a registrar. The operation accepts as input all create-only and read-write data elements defined for the Message Data Object.

Authorisation:
- Only the server is authorised to create new message objects.

Read Operation

Identifier: read

The Read operation allows a client to retrieve the data elements of a Message Data Object.

Authorisation:
- Any client is authorised to retrieve message object information. The server MAY restrict the information returned based on client identity and server policy.

Organisation ID (owner) MUST NOT be provided in the response, since a client can only ever retrieve messages linked to its own organisation.

Query Operation

Identifier: query

The Query operation allows a client to retrieve a collection of Message Data Object instances based on specified criteria.

Authorisation:
- Any client is authorised to retrieve message object information. The server MAY restrict the information returned based on client identity and server policy.
Input:
- Parameters:
  - Message Type
    - Identifier: type
    - Cardinality: 0-1
    - Data Type: String
    - Description: The type of the message to use as a filter when retrieving message objects.
    - Constraints:
    - The type value MUST be a valid identifier for an RPP message component (e.g. reviewResponse).

Delete Operation

Identifier: delete

The Delete operation allows a client to remove an existing Message Data Object. The operation targets a specific data object identified by its Message ID.

Authorisation:
- Generally clients are authorised to delete message objects linked to the organisation the client belongs to.

User Object

Object Description

Name: User Data Object
Identifier: user
Unique Identifier: id
Description: Represents a user linked to an Organisation Object. Each user carries a set of RBAC roles that define the user's permissions within the context of the owning Organisation Object. The lifecycle of a User Object is bound to its Organisation Object.

Data Elements The following data elements are defined for the User Data Object.

User Identifier
- Identifier: id
- Cardinality: 1
- Mutability: create-only
- Data Type: Identifier
- Description: A unique identifier for the user
- Constraints: MUST be globally unique in the server scope
Details
- Identifier: details
- Cardinality: 1
- Mutability: read-write
- Data Type: External:RPP-JSContact-Profile:Card
- Description: The details of the user, such as name, email, and phone number
- Constraints: (None)
Description
- Identifier: description
- Cardinality: 0-1
- Mutability: read-write
- Data Type: String
- Description: A description of the user
- Constraints: (None)
Status
- Identifier: status
- Cardinality: 1
- Mutability: read-write
- Data Type: User Status Object
- Description: The current status of the user.
- Constraints:
  - Allowed status values and transitions are specified in User Status Values.
  - A client MUST NOT alter server status values set by the server itself.
Organisation
- Identifier: organisation
- Cardinality: 1
- Mutability: read-only
- Data Type: Aggregation[Organisation Data Object]
- Description: A reference to the owner organisation object.
- Constraints: (None)
Processes
- Identifier: processes
- Cardinality: 0-1
- Mutability: read-only
- Data Type: Processes Object
- Direct Access: true
- Description: The Process Objects currently or recently initiated on the user object.
- Constraints: (None)

Operations

Create Operation

Identifier: create

The Create operation creates a new user, which is associated with an existing Organisation Object. The operation accepts as input all create-only and read-write data elements of the User Object.

Authorisation:
- Client can only create users in the context of the organisation linked to the client, and only if the client has the necessary permissions to create users in that organisation.

Read Operation

Identifier: read

The Read operation retrieves the data of a specific User Object.

Authorisation:
- Client can only read users in the context of the organisation linked to the client, and only if the client has the necessary permissions to read users in that organisation.

Update Operation

Identifier: update

The Update operation modifies the read-write data elements.

Authorisation:
- Client can only update users in the context of the organisation linked to the client, and only if the client has the necessary permissions to update users in that organisation.

Delete Operation

Identifier: delete

The Delete operation removes a specific User Object.

Authorisation:
- Client can only delete users in the context of the organisation linked to the client, and only if the client has the necessary permissions to delete users in that organisation.

The server MUST reject this operation if the target User Object is the last user of the owning organisation that is permitted to manage users. User Objects are deleted together with their owning Organisation Object.

Discovery Data Object

Object Description

Name: Discovery Data Object
Identifier: discovery
Unique Identifier: (None)
Description: A Discovery Data Object describes the capabilities of an RPP server, such as the supported versions, TLDs, extensions, profiles, resource collections, authentication methods and endpoints. The server provides a single Discovery Data Object, which is therefore not identified by a Unique Identifier.

Data Elements The following data elements are defined for the Discovery Data Object.

Versions
- Identifier: versions
- Cardinality: 1+
- Mutability: read-only
- Data Type: Discovery Version Object
- Description: The versions of RPP supported by the server.
- Constraints: An operator that supports more than one incompatible version MUST deploy them on distinct base URLs and announce each of them.
Environment
- Identifier: environment
- Cardinality: 1
- Mutability: read-only
- Data Type: Discovery Environment Object
- Description: Information about the RPP server.
- Constraints: (None)
TLDs
- Identifier: tlds
- Cardinality: 1+
- Mutability: read-only
- Data Type: String
- Description: The TLDs supported by the server, for example "example" or "org".
- Constraints: (None)
Extensions
- Identifier: extensions
- Cardinality: 0+
- Mutability: read-only
- Data Type: Extension Object
- Description: The extensions supported by the server.
- Constraints: The server MUST include the version of each extension.
Profiles
- Identifier: profiles
- Cardinality: 0+
- Mutability: read-only
- Data Type: String
- Description: The names of the profiles supported by the server.
Objects
- Identifier: objects
- Cardinality: 1+
- Mutability: read-only
- Data Type: String
- Description: The list of identifiers of data objects supported by the server
- Constraints: (None)
Date and Time
- Identifier: datetime
- Cardinality: 1
- Mutability: read-only
- Data Type: Timestamp
- Description: The current date and time of the server.
- Constraints: The value MUST be expressed in UTC using the Z suffix, for example 2026-06-01T10:00:00Z, and MUST NOT use a numeric UTC offset or any other time zone.
Links
- Identifier: links
- Cardinality: 0+
- Mutability: read-only
- Data Type: LabelledAggregation[String]
  - Label Description: The relation type of the link.
  - Label Constraints: The value MUST be a link relation type registered in the IANA "Link Relation" registry.
- Description: Links to documents related to the use of RPP with the server, such as policies and terms. Each value is the location of a linked document, labelled with its relation type.
- Constraints:
  - Each value MUST be an absolute URL using the HTTPS scheme.
  - The document MUST be accessible to the client without authentication.
  - A server SHOULD provide a link for each of the privacy-policy and terms-of-service relation types, defined in .
IDN LGRs
- Identifier: idnLgr
- Cardinality: 0+
- Mutability: read-only
- Data Type: Discovery IDN LGR Object
- Description: The Label Generation Rulesets (LGRs) supported by the server.
- Constraints: (None)
Notices
- Identifier: notices
- Cardinality: 0+
- Mutability: read-only
- Data Type: Discovery Notice Object
- Description: Notices from the server operator.
- Constraints: (None)
- Description: The objects allowed for provisioning operations, for example "domainName", "host" or "contact".
- Constraints: The values MUST be valid object identifiers as defined in the RPP Data Object Registry.

Operations

Read Operation

Identifier: read

The Read operation allows a client to retrieve the Discovery Data Object. It is the only operation supported for this object.

Input: (None)
Authorisation:
- Any client is authorised to perform this operation. The operation MUST be available without authentication, so that a client can retrieve it before authenticating with the server.

Profile Data Object

Object Description

Name: Profile Data Object
Identifier: profile
Unique Identifier: name
Description: A Profile Data Object represents a named set of protocol features and versions that defines the compatibility and capabilities of RPP server implementations. A profile is published by the server, and a client can retrieve it to determine which features, objects and extensions it can use.

Data Elements The following data elements are defined for the Profile Data Object. All data elements are managed by the server.

Name
- Identifier: name
- Cardinality: 1
- Mutability: read-only
- Data Type: String
- Description: A unique name that identifies the profile.
- Constraints:
  - The name of a standard profile, which is published in the IANA registry for RPP profiles, MUST use the RPP URN namespace, for example urn:ietf:params:rpp:profile:{profile_name}, and MUST be unique within that namespace. It SHOULD be descriptive of the features and versions included in the profile.
  - The name of a private profile, which is not published in the IANA registry, MUST be globally unique. The use of reverse domain name notation is RECOMMENDED.
Description
- Identifier: description
- Cardinality: 1
- Mutability: read-only
- Data Type: String
- Description: A human-readable description of the profile and its intended use.
- Constraints: (None)
Version
- Identifier: version
- Cardinality: 1
- Mutability: read-only
- Data Type: String
- Description: The version of the profile.
- Constraints: (None)
RPP Version
- Identifier: rppVersion
- Cardinality: 1
- Mutability: read-only
- Data Type: String
- Description: The minimum version of the RPP protocol that is supported or required for the profile.
- Constraints: (None)
Objects
- Identifier: objects
- Cardinality: 1+
- Mutability: read-only
- Data Type: String
- Description: The list of identifiers of data objects supported by the server
- Constraints: (None)
Extensions
- Identifier: extensions
- Cardinality: 0+
- Mutability: read-only
- Data Type: Extension Object
- Description: The extensions, including their names and versions, that are supported or required for the profile.
- Constraints:
  - A profile MUST NOT list the same extension name more than once.
  - The server MUST support all extensions listed in the profile.
Base Profile
- Identifier: baseProfile
- Cardinality: 0-1
- Mutability: read-only
- Data Type: Aggregation[Profile Data Object]
- Description: A base profile that is extended by this profile. The features and versions of the base profile are included in this profile, which MAY add to them or override them, for example the version of an extension.
- Constraints:
  - The base profile MUST be published in the IANA registry for RPP profiles, or be made available to the client using other means.
  - The depth of inheritance MUST be limited to 1: the base profile MUST NOT itself have a base profile.
  - A profile MUST NOT be its own base profile.
Default Profile
- Identifier: defaultProfile
- Cardinality: 1
- Mutability: read-only
- Data Type: Boolean
- Description: The default profile that is used when no specific profile is requested by the client.
- Constraints:
  - The default profile MUST be published in the IANA registry for RPP profiles, or be made available to the client using other means.
  - Only one profile MUST be designated as the default profile.

Operations

Read Operation

Identifier: read

The Read operation allows a client to retrieve the Profile Data Object identified by its name. It is the only operation supported for this object.

Authorisation:
- Any authenticated client is authorised to perform this operation.

IANA Considerations

RPP Registry Group The IANA is requested to create a new registry group for RPP, this will be used to group together all the RPP-related registries such as those for discovery URLs, extensions and profiles.

RPP Data Object Registry Name of the registry: RPP Data Object Registry Registry group: RESTful Provisioning Protocol (RPP) Registration procedure: Specification Required This document establishes the "RESTful Provisioning Protocol (RPP) Data Object Registry". This registry serves as a catalogue of all data objects, component objects, data elements, and operations used within RPP.

Registration Policy The policy for adding new objects, data elements, or operations to this registry is "Specification Required" . Standardised RPP extensions that introduce new data objects, add data elements to existing objects, or define new operations, operation input data elements, or operation parameters MUST register these additions in this registry. Each such registration MUST reference the specification that defines the extension. Private (non-standardised) extensions are not required to register in this registry.

Registry Structure The registry is organised as a collection of Object definitions. Each Object definition MUST include:

A header containing the Object Identifier, Object Name, Object Type (Resource, Process or Component), the identifier of the object it extends (if any), a brief description, and a reference to its defining specification.
A "Data Elements" table listing all persisted data elements associated with the object. Each entry MUST specify the element's Identifier, Name, Cardinality, Mutability, Data Type, description, and a reference to the specification that defines it.
An "Operations" section (applicable only for Object Types Resource or Process). For each operation, the registry MUST provide:
- The Operation's Name, a description, and a reference to the specification that defines it.
- An "Input Data Elements" table listing all input data elements of the operation. Each entry MUST specify the input data element's Identifier, Name, Cardinality, Data Type, description, and a reference to the specification that defines it.
- A "Parameters" table listing all parameters of the operation. Each entry MUST specify the parameter's Identifier, Name, Cardinality, Data Type, description, and a reference to the specification that defines it.

Extensions MAY add new data elements, operations, operation input data elements, or operation parameters to existing Object definitions in the registry. Each such addition MUST reference the extension specification that introduces it, allowing implementations to distinguish core protocol elements from extension-defined elements.

Initial Registrations The initial contents of the RPP Data Object Registry are defined below. Object: period Object Name: Period Object Object Type: Component Description: Represents a duration of time. Reference: [This-ID] Data Elements

Element Identifier	Element Name	Card.	Mutability	Data Type	Description
value	Value	1	read-write	Integer	The numeric value of the period.
unit	Unit	1	read-write	String	The unit of the period.

Object: dnsRecord Object Name: DNS Resource Record Object Object Type: Component Description: Represents a single DNS resource record. Reference: [This-ID] Data Elements

Element Identifier	Element Name	Card.	Mutability	Data Type	Description
name	Name	1	read-write	String	The owner name of the DNS entry.
class	Class	0-1	read-write	String	The DNS resource record class.
type	Type	1	read-write	String	The DNS resource record type, indicating the format of the RDATA field.
rdata	RDATA	1	read-write	Object	The actual payload data of the DNS record. Structure depends on the record type.

Object: dnsControls Object Name: DNS Operational Controls Object Object Type: Component Description: Contains operational control parameters that a client MAY use to influence server-side DNS behaviour for a set of DNS records. Reference: [This-ID] Data Elements

Element Identifier	Element Name	Card.	Mutability	Data Type	Description
ttl	TTL	0-1	read-write	Dictionary [Integer]	Controls the caching behaviour of DNS resource records, keyed by lowercase record type name.
maxSigLifetime	Maximum Signature Lifetime	0-1	read-write	Dictionary [Integer]	Maximum number of seconds after signature generation when the parent's signature on signed DNS data should expire, keyed by lower-case record type name.

Object: dnsData Object Name: DNS Data Object Object Type: Component Description: A container for DNS resource records and associated operational controls for a provisioned object. Reference: [This-ID] Data Elements

Element Identifier	Element Name	Card.	Mutability	Data Type	Description
records	Records	0+	read-write	DNS Resource Record Object	An array of DNS resource records associated with the provisioned object.
controls	Controls	0-1	read-write	DNS Operational Controls Object	Operational control parameters for the DNS records.

Object: authInfo Object Name: Authorisation Information Object Object Type: Component Description: Contains authorisation credentials for an operation. Reference: [This-ID] Data Elements

Element Identifier	Element Name	Card.	Mutability	Data Type	Description
method	Method	1	create-only	String	The identifier of the RPP authorisation method.
authdata	Authorisation Information	1	create-only	String	The value of the authorisation information. It might be as simple as a password string, but also more complex values like public key certificates or tokens encoded as string are possible.

Object: domainStatus Object Name: Domain Name Status Object Object Type: Component Description: Represents one of the status values associated with a Domain Name Data Object Reference: [This-ID] Data Elements

Element Identifier	Element Name	Card.	Mutability	Data Type	Description
label	Label	1	create-only	String	machine-readable enum label of a status
reason	Reason	0-1	create-only	String	a human-readable text that describes the rationale for the status applied to the object.
due	Due	0-1	read-write	Timestamp	a timestamp, when this status is going to be removed automatically, or changed to other status. This field can be used to express lifecycle related information.

Object: hostStatus Object Name: Host Status Object Object Type: Component Description: Represents one of the status values associated with a Host Data Object Reference: [This-ID] Data Elements

Element Identifier	Element Name	Card.	Mutability	Data Type	Description
label	Label	1	create-only	String	machine-readable enum label of a status
reason	Reason	0-1	create-only	String	a human-readable text that describes the rationale for the status applied to the object.

Object: contactStatus Object Name: Contact Status Object Object Type: Component Description: Represents one of the status values associated with a Contact Data Object Reference: [This-ID] Data Elements

Element Identifier	Element Name	Card.	Mutability	Data Type	Description
label	Label	1	create-only	String	machine-readable enum label of a status
reason	Reason	0-1	create-only	String	a human-readable text that describes the rationale for the status applied to the object.

Object: organisationRoleStatus Object Name: Organisation Role Status Object Object Type: Component Description: Represents one of the status values associated with an Organisation Role Object. A role SHOULD have at least one associated status value. Reference: [This-ID] Data Elements

Element Identifier	Element Name	Card.	Mutability	Data Type	Description
label	Label	1	create-only	String	machine-readable enum label of a status
reason	Reason	0-1	create-only	String	a human-readable text that describes the rationale for the status applied to the role.

Object: organisationStatus Object Name: Organisation Status Object Object Type: Component Description: Represents one of the status values associated with an Organisation Data Object, as defined in . An Organisation Data Object MUST always have at least one associated status value. Reference: [This-ID] Data Elements

Element Identifier	Element Name	Card.	Mutability	Data Type	Description
label	Label	1	create-only	String	machine-readable enum label of a status
reason	Reason	0-1	create-only	String	a human-readable text that describes the rationale for the status applied to the object.

Object: userStatus Object Name: User Status Object Object Type: Component Description: Represents the status value associated with a User Data Object. A User Data Object MUST always have exactly one associated status value. Reference: [This-ID] Data Elements

Element Identifier	Element Name	Card.	Mutability	Data Type	Description
label	Label	1	create-only	String	machine-readable enum label of a status
reason	Reason	0-1	create-only	String	a human-readable text that describes the rationale for the status applied to the object.

Object: provMetadata Object Name: Provisioning Metadata Object Object Type: Component Description: Contains standard metadata about the lifecycle and ownership of a provisioned object. Reference: [This-ID] Data Elements

Element Identifier	Element Name	Card.	Mutability	Data Type	Description
repositoryId	Repository ID	0-1	read-only	Identifier	A server-assigned unique identifier for the object.
spClientId	Sponsoring Client ID	1	read-only	Client Identifier	The identifier of the client that is the current sponsor of the object.
crClientId	Creating Client ID	0-1	read-only	Client Identifier	The identifier of the client that created the object.
crDate	Creation Date	0-1	read-only	Timestamp	The date and time of object creation.
upClientId	Updating Client ID	0-1	read-only	Client Identifier	The identifier of the client that last updated the object.
upDate	Update Date	0-1	read-only	Timestamp	The date and time of the most recent object modification.
trDate	Transfer Date	0-1	read-only	Timestamp	The date and time of the most recent successful object transfer.

Object: processes Object Name: Processes Object Object Type: Component Description: A container grouping the Process Objects currently or recently initiated on a Data Object, structured as a dictionary keyed by process type where each element holds an unordered array of Process Objects of that type. The set of process-type data elements is extensible; extensions MAY register additional process-type elements. Reference: [This-ID] Data Elements

Element Identifier	Element Name	Card.	Mutability	Data Type	Description
transferProcess	Transfer Processes	0+	read-only	Aggregation [Transfer Process Object]	The transfer processes initiated on the owning Data Object.
renewProcess	Renew Processes	0+	read-only	Aggregation [Renew Process Object]	The renew processes initiated on the owning Data Object.
restoreProcess	Restore Processes	0+	read-only	Aggregation [Restore Process Object]	The restore processes initiated on the owning Data Object.
createProcess	Create Processes	0+	read-only	Aggregation [Create Process Object]	The create processes initiated on the owning Data Object.

Object: baseProcess Object Name: Base Process Object Object Type: Component Description: Base structure for all Process Objects, containing the data elements common to every process. Reference: [This-ID] Data Elements

Element Identifier	Element Name	Card.	Mutability	Data Type	Description
processId	Process ID	0-1	read-only	String	A server-assigned identifier of the process instance, unique within the Owner Data Object.

Object: baseAvailability Object Name: Base Availability Object Object Type: Component Description: Base structure for the result of an Availability operation, indicating whether the referenced object can be created. Reference: [This-ID] Data Elements

Element Identifier	Element Name	Card.	Mutability	Data Type	Description
available	Available	1	read-only	Boolean	Indicates whether the referenced object can be created at the time the operation is completed.
reason	Reason	0-1	read-only	String	Server-specific text explaining why the referenced object cannot be created.

Object: domainNameAvailability Object Name: Domain Name Availability Object Object Type: Component Extends: baseAvailability Description: The result of an Availability operation on a Domain Name Data Object. Reference: [This-ID] Data Elements: (None) Object: contactAvailability Object Name: Contact Availability Object Object Type: Component Extends: baseAvailability Description: The result of an Availability operation on a Contact Data Object. Reference: [This-ID] Data Elements: (None) Object: hostAvailability Object Name: Host Availability Object Object Type: Component Extends: baseAvailability Description: The result of an Availability operation on a Host Data Object. Reference: [This-ID] Data Elements: (None) Object: baseMessage Object Name: Base Message Object Object Type: Component Description: Base structure for all message objects, containing common data elements such as the object type and object identifier. Reference: [This-ID] Data Elements

Element Identifier	Element Name	Card.	Mutability	Data Type	Description
objectType	Object Type	0-1	read-only	String	The object identifier of the object affected by the requested action.
objectId	Object Identifier	0-1	read-only	String	The unique identifier of the object affected by the requested operation.

Object: reviewResponseMessage Object Name: Review Response Object Object Type: Component Extends: baseMessage Description: Notification of the result of an offline review of a requested operation. Reference: [This-ID] Data Elements

Element Identifier	Element Name	Card.	Mutability	Data Type	Description
approved	Approval Result	1	read-only	Boolean	Whether the requested action was approved and completed.
clientTransactionId	Client Transaction ID	0-1	read-only	String	The client transaction identifier from the original request, if supplied.
serverTransactionId	Server Transaction ID	1	read-only	String	The server transaction identifier returned for the original request.
completionDate	Completion Date	1	read-only	Timestamp	The date and time when review of the requested action was completed.
message	Message	1	read-only	String	Human-readable message associated with the review response.
process	Process	0-1	read-only	Base Process Object	The process whose operation was subject to the offline review.

Object: transferRequestMessage Object Name: Transfer Request Message Object Object Type: Component Extends: baseMessage Description: Notification for losing client of started transfer request, where the client expected to act on the pending transfer request. Reference: [This-ID] Data Elements

Element Identifier	Element Name	Card.	Mutability	Data Type	Description
status	Transfer Status	1	read-only	String	The current state of the transfer request.
requestDate	Request Date	1	read-only	Timestamp	The date and time the transfer was requested.
actionDate	Action Date	0-1	read-only	Timestamp	The deadline for responding before the server takes an automated action.
process	Process	0-1	read-only	Transfer Process Object	The transfer process the message pertains to.

Object: transferOutcomeMessage Object Name: Transfer Outcome Message Object Object Type: Component Extends: baseMessage Description: Notification for a client affected by the completion of a transfer request. Reference: [This-ID] Data Elements

Element Identifier	Element Name	Card.	Mutability	Data Type	Description
trStatus	Transfer Status	1	read-only	String	The final state of the transfer request.
requestDate	Request Date	1	read-only	Timestamp	The date and time the transfer was requested.
actionDate	Action Date	1	read-only	Timestamp	The date and time the transfer request was resolved.
expiryDate	Expiry Date	0-1	read-only	Timestamp	The end of the object's validity period if the operation causes a change in the validity period.
process	Process	0-1	read-only	Transfer Process Object	The transfer process the message pertains to.

Object: expirationDeletionMessage Object Name: Expiration Deletion Message Object Object Type: Component Extends: baseMessage Description: Notification for the sponsoring client that an object was deleted following expiration. Reference: [This-ID] Data Elements

Element Identifier	Element Name	Card.	Mutability	Data Type	Description
deletionDate	Deletion Date	1	read-only	Timestamp	The date and time the server deleted the object.

Object: autoRenewalMessage Object Name: Auto-Renewal Message Object Object Type: Component Extends: baseMessage Description: Notification for the sponsoring client that the server automatically renewed an object. Reference: [This-ID] Data Elements

Element Identifier	Element Name	Card.	Mutability	Data Type	Description
renewalDate	Renewal Date	1	read-only	Timestamp	The date and time the server renewed the object.
expiryDate	Expiry Date	1	read-only	Timestamp	The new expiration date of the object.

Object: serviceNoticeMessage Object Name: Service Notice Message Object Object Type: Component Extends: baseMessage Description: Generic text-based message containing information not covered by any other message type. Reference: [This-ID] Data Elements

Element Identifier	Element Name	Card.	Mutability	Data Type	Description
message	Message	1	read-only	String	Human-readable service information for the receiving organisation.

Object: transferProcess Object Name: Transfer Process Object Object Type: Process Extends: baseProcess Description: Represents a transfer request for a provisioned object. Creating this object initiates the transfer. Approve and Reject are additional operations; Delete corresponds to cancel. Reference: [This-ID] Data Elements

Element Identifier	Element Name	Card.	Mutability	Data Type	Description
transferDir	Transfer Direction	0-1	create-only	String	The direction of the transfer ("pull" or "push"). If omitted, server policy determines default.
gainingClientId	Gaining Client ID	0-1	create-only	Client Identifier	The designated gaining client. REQUIRED for push transfers; MUST NOT be provided for pull.
trStatus	Transfer Status	1	read-only	String	The state of the transfer request.
reqClientId	Requesting Client ID	1	read-only	Client Identifier	The identifier of the client that initiated the transfer request.
requestDate	Request Date	1	read-only	Timestamp	The date and time that the transfer was requested.
actClientId	Acting Client ID	1	read-only	Client Identifier	The identifier of the client that should or did act on the request.
actionDate	Action Date	1	read-only	Timestamp	The response deadline (if pending) or completion date.

Operations Operation: Create Operation Identifier: transferCreate Description: Initiates a transfer of a provisioned object by creating a Transfer Process Object. Input Data Elements: (None) Parameters: (None) Operation: Transfer Read Operation Identifier: transferRead Description: Queries the status of a transfer of a provisioned object. Input Data Elements: (None) Parameters: (None) Operation: Transfer Delete Operation Identifier: transferDelete Description: Cancels a pending transfer of a provisioned object. Input Data Elements: (None) Parameters: (None) Operation: Transfer Approve Operation Identifier: transferApprove Description: Approves a pending transfer of a provisioned object. Input Data Elements: (None) Parameters: (None) Operation: Transfer Reject Operation Identifier: transferReject (on Transfer Process Object) Description: Rejects a pending transfer of a provisioned object. Input Data Elements

Identifier	Name	Card.	Data Type	Description
reason	Reason	0-1	String	A human-readable text describing the rationale for rejection.

Parameters: (None) Object: renewProcess Object Name: Renew Process Object Object Type: Process Extends: baseProcess Description: Represents a renewal request for a provisioned object. Creating this object initiates the renewal. Reference: [This-ID] Data Elements

Element Identifier	Element Name	Card.	Mutability	Data Type	Description
expiryDate	Expiry Date	0-1	create-only	Timestamp	The expiry date of the object after the renewal is completed.
renewalPeriod	Renewal Period	0-1	create-only	Period Object	The duration to be added to the object's registration period. This value is used by the server to calculate the new `expiryDate`. The default value MAY be defined by server policy. The number of units available MAY be subject to limits imposed by the server.

Operations Operation: Create Operation Identifier: renewCreate Description: Initiates a renewal of a provisioned object by creating a Renew Process Object. Input Data Elements: (None) Parameters: (None) Object: createProcess Object Name: Create Process Object Object Type: Process Extends: baseProcess Description: Represents the process initiated when a resource creation operation is performed. Carries creation-specific inputs that are consumed during creation and not stored as persistent attributes of the created resource object. Reference: [This-ID] Data Elements: (None) Operations Operation: Create Operation Identifier: create Description: Invoked implicitly as a side effect of the resource object create operation; never invoked directly. Carries creation-specific inputs consumed during creation of the owning resource object. Input Data Elements: (None) Parameters: (None) Operation: Read Operation Identifier: read Description: Retrieves the result or status of the creation, if the server exposes the process resource. Input Data Elements: (None) Parameters: (None) Object: domainCreateProcess Object Name: Domain Create Process Object Object Type: Process Extends: baseProcess Description: The Create Process Object specific to the Domain Name Data Object. Implicitly initiated by the domain create operation; carries the requested initial registration period consumed during creation and not persisted as part of the domain object's state. Reference: [This-ID] Data Elements

Element Identifier	Element Name	Card.	Mutability	Data Type	Description
period	Period	0-1	create-only	Period Object	The initial registration period for the domain name.

Operations Operation: Create Operation Identifier: create Description: Invoked implicitly as a side effect of the Domain Name Data Object create operation; never invoked directly. Carries the registration period consumed during domain creation. Input Data Elements: (None) Parameters: (None) Operation: Read Operation Identifier: read Description: Retrieves the result or status of the domain creation, if the server exposes the process resource. Input Data Elements: (None) Parameters: (None) Object: domainTransferProcess Object Name: Domain Transfer Process Object Object Type: Process Description: The Transfer Process Object specific to the Domain Name Data Object. Carries the domain-specific transfer inputs and outputs, namely the requested transfer period and the resulting expiry date, that extend the common transfer process. Reference: [This-ID] Data Elements

Element Identifier	Element Name	Card.	Mutability	Data Type	Description
expiryDate	Expiry Date	0-1	read-only	Timestamp	The end of the domain object's registration period if the transfer caused or causes a change in the validity period.
transferPeriod	Transfer Period	0-1	create-only	Period Object	The number of units to be added to the registration period of the domain object upon successful completion of the transfer. The number of units available MAY be subject to limits imposed by the server.

Operations Operation: Create Operation Identifier: transferCreate Description: Initiates a transfer of a Domain Name Data Object by creating a Domain Transfer Process Object. Input Data Elements: (None) Parameters: (None) Object: disclose Object Name: Disclose Object Object Type: Component Description: TBD Reference: [This-ID] Data Elements

Element Identifier	Element Name	Card.	Mutability	Data Type	Description

Object: restoreProcess Object Name: Restore Process Object Object Type: Process Extends: baseProcess Description: Represents the current state of a restore request for an object that has entered the Redemption Grace Period (RGP). Returned as output of all restore operations. This object is OPTIONAL and is only used when the RGP feature is supported. Reference: [This-ID] Data Elements

Element Identifier	Element Name	Card.	Mutability	Data Type	Description
restoreStatus	Restore Status	1	read-only	String	The current state of the restore process.
requestDate	Request Date	0-1	read-only	Timestamp	The date and time when the restore request was submitted. Absent if no request has been submitted.
reportDate	Report Date	0-1	read-only	Timestamp	The date and time when the most recent restore report was accepted. Absent if no report has been accepted.
reportDueDate	Report Due Date	0-1	read-only	Timestamp	The deadline for submitting a restore report before the object reverts to rgpRedemptionPeriod. Present only when status is rgpPendingRestore.
restoreReport	Restore Report	0-1	read-write	Restore Report Object	The restore report submitted as required by the RGP process.

Operations Operation: Restore Create Operation Identifier: create Description: Initiates recovery of a domain name in the rgpRedemptionPeriod state by creating a Restore Process Object. This operation is OPTIONAL and is only available when the RGP feature is supported. Input Data Elements

Identifier	Name	Card.	Data Type	Description
restoreReport	Restore Report	0-1	Restore Report Object	An OPTIONAL inline restore report. If provided, the server processes the request and the report atomically. If the server does not require a restore report, this element MUST NOT be present and the restore is completed immediately. If the server requires a report and this element is absent, the object transitions to `pendingRestore` state awaiting a subsequent Report operation.

Parameters: (None) Operation: Restore Read Operation Identifier: read (on Restore Process Object) Description: Retrieves the current state of the RGP restore process for a domain name. This operation is OPTIONAL and is only available when the RGP feature is supported. Input Data Elements: (None) Parameters: (None) Operation: Restore Update Operation Identifier: update Description: Submits or replaces the restore report for a domain name in the rgpPendingRestore state. This operation is OPTIONAL and is only available when the RGP feature is supported and the server requires a restore report. Input Data Elements

Identifier	Name	Card.	Data Type	Description
restoreReport	Restore Report	1	Restore Report Object	The restore report to be submitted as part of the RGP process.

Parameters: (None) Object: restoreReport Object Name: Restore Report Object Object Type: Component Description: Contains the redemption grace period restore report submitted by the sponsoring client as required by the RGP process. This object is OPTIONAL and is only used when the RGP feature is supported and a restore report is required by server policy. Reference: [This-ID] Data Elements

Element Identifier	Element Name	Card.	Mutability	Data Type	Description
preData	Pre-Delete Data	0-1	read-write	String	A copy of the registration data that existed for the object prior to deletion.
postData	Post-Restore Data	0-1	read-write	String	A copy of the registration data that exists for the object at the time the restore report is submitted.
deleteTime	Delete Time	0-1	read-write	Timestamp	The date and time when the object delete request was sent to the server.
restoreTime	Restore Time	0-1	read-write	Timestamp	The date and time when the original restore request operation was sent to the server.
restoreReason	Restore Reason	0-1	read-write	String	A brief explanation of the reason for restoring the object.
statements	Statements	1-2	read-write	String	Mandatory client statements required by the RGP process.
other	Other	0-1	read-write	String	Any additional information needed to support the statements provided by the client.

Object: domainName Object Name: Domain Name Data Object Object Type: Resource Description: Represents a domain name and its associated data. Reference: [This-ID] Data Elements

Identifier	Name	Card.	Mutability	Data Type	Description
name	Name	1	create-only	Fully Qualified Domain Name	The fully qualified name of the domain object.
uName	Unicode Name	0-1	create-only	String	The fully qualified name of the domain using the Unicode character set.
lgr	LGR	0-1	create-only	String	The name of the Label Generation Ruleset (LGR) containing the valid code points used for the Unicode Name (uName).
provMetadata	Provisioning Metadata	1	read-only	Provisioning Metadata Object	Standard metadata about object lifecycle and ownership.
status	Status	1+	read-write	Domain Name Status Object	The current status descriptors for the domain.
registrant	Registrant	0-1	read-write	Aggregation[Contact Data Object]	The registrant contact ID.
contacts	Contacts	0+	read-write	LabelledAggregation [Contact Data Object]	Associated contact objects.
nameservers	Nameservers	0+	read-write	Aggregation [Host Data Object]	A collection of nameservers associated with the domain.
dns	DNS Data	0-1	read-write	DNS Data Object	DNS resource records and operational controls related to the domain name.
subordinateHosts	Subordinate Hosts	0+	read-only	Aggregation [Host Data Object]	Subordinate host names.
expiryDate	Expiry Date	0-1	read-only	Timestamp	Expiry timestamp.
authInfo	Authorisation Information	0-1	read-write	Authorisation Information Object	Authorisation information for the object.
processes	Processes	0-1	read-only	Processes Object	Process Objects initiated on the domain object.

Operations Operation: Availability Operation Identifier: availability Description: Determines whether a Domain Name resource can be created. Input Data Elements: (None) Parameters

Identifier	Name	Card.	Data Type	Description
uName	Unicode Name	0-1	String	The Unicode Name of the domain name for which availability is determined.
lgr	LGR	0-1	String	The LGR against which availability of the domain name is determined.

Operation: Create Operation Identifier: create Description: Provisions a new Domain Name resource. Input Data Elements: (None) Parameters: (None) Operation: Read Operation Identifier: read Description: Retrieves the data elements of a Domain Name resource. Input Data Elements: (None) Parameters

Identifier	Name	Card.	Data Type	Description
hostsFilter	Hosts Filter	0-1	String	Controls which host information is returned.

Operation: Update Description: Modifies the read-write data elements of a Domain Name resource. Input Data Elements: (None) Parameters: (None) Operation: Delete Operation Identifier: delete Description: Removes an existing Domain Name resource. Input Data Elements: (None) Parameters: (None) Object: contact Object Name: Contact Data Object Object Type: Resource Description: A Contact Data Object represents the contact information for an individual or organisation associated with other objects. Reference: [This-ID] Data Elements

Identifier	Name	Card.	Mutability	Data Type	Description
id	Handle ID	1	create-only	Identifier	External unique identifier of the contact object.
provMetadata	Provisioning Metadata	1	read-only	Provisioning Metadata Object	Standard metadata about the object's lifecycle and ownership.
status	Status	1+	read-write	Contact Status Object	Status descriptors associated with the contact.
contactInfo	Contact Information	1	read-write	External:RPP-JSContact-Profile:Card	JSContact Card information.
authInfo	Authorisation Information	0-1	read-write	Authorisation Information Object	Authorisation information associated with the contact object.
disclose	Disclose	0-1	read-write	Disclose Object	Identifies elements that require exceptional server-operator handling to allow or restrict disclosure to third parties.
processes	Processes	0-1	read-only	Processes Object	Process Objects initiated on the contact object.

Operations Operation: Availability Operation Identifier: availability Description: Determines whether a Contact resource can be created. Input Data Elements: (None) Parameters: (None) Operation: Create Operation Operation Identifier: create Description: The Create operation allows a client to provision a new Contact resource. The operation accepts as input all create-only and read-write data elements defined for the Contact Data Object. Input Data Elements: (None) Parameters: (None) Operation: Read Operation Operation Identifier: read Description: The Read operation allows a client to retrieve the data elements of a Contact resource. The server's response MAY vary depending on client authorisation and server policy. Input Data Elements: (None) Parameters: (None) Operation: Update Operation Operation Identifier: update Description: The Update operation allows a client to modify the attributes of an existing Contact resource. Input Data Elements: (None) Parameters: (None) Operation: Delete Operation Operation Identifier: delete Description: The Delete operation allows a client to remove an existing Contact resource. The operation targets a specific data object identified by its Handle ID. Input Data Elements: (None) Parameters: (None) Object: host Object Name: Host Data Object Object Type: Resource Description: Represents a nameserver that provides DNS services for a domain name. Reference: [This-ID] Data Elements

Identifier	Name	Card.	Mutability	Data Type	Description
hostName	Host Name	1	read-write	Fully Qualified Domain Name	Fully qualified name of a host.
provMetadata	Provisioning Metadata	1	read-only	Provisioning Metadata Object	Standard metadata about object lifecycle and ownership.
status	Status	1+	read-write	Host Status Object	The current status descriptors for the host.
dns	DNS Data	0-1	read-write	DNS Data Object	DNS resource records and operational controls related to the host.
processes	Processes	0-1	read-only	Processes Object	Process Objects initiated on the host object.

Operations Operation: Availability Operation Identifier: availability Description: Determines whether a Host Data Object can be created. Input Data Elements: (None) Parameters: (None) Operation: Create Description: Provisions a new Host Data Object. Input Data Elements: (None) Parameters: (None) Operation: Read Description: Retrieves the data elements of a Host Data Object. Input Data Elements: (None) Parameters: (None) Operation: Update Description: Modifies the attributes of a Host Data Object. Input Data Elements: (None) Parameters: (None) Operation: Delete Description: Removes an existing Host Data Object. Input Data Elements: (None) Parameters: (None) Object: organisationRole Object Name: Organisation Role Object Object Type: Component Description: Represents a role that an organisation has within the registry ecosystem, as defined in . An organisation object MUST always have at least one associated role. Reference: [This-ID] Data Elements

Element Identifier	Element Name	Card.	Mutability	Data Type	Description
status	Role Status	0+	read-write	Organisation Role Status Object	The status of this role.
roleId	Role Identifier	0-1	read-write	String	A third-party-assigned identifier for this role, such as an IANA registrar ID.

Object: organisation Object Name: Organisation Data Object Object Type: Resource Description: Represents an entity, such as a registrar, reseller, DNS service operator, or privacy proxy, involved in the domain registration process. Based on the EPP Organisation Mapping defined in . Reference: [This-ID] Data Elements

Identifier	Name	Card.	Mutability	Data Type	Description
id	Organisation ID	1	create-only	Identifier	A server-unique identifier for the organisation object.
provMetadata	Provisioning Metadata	1	read-only	Provisioning Metadata Object	Standard metadata about the object's lifecycle and ownership.
status	Status	1+	read-write	Organisation Status Object	The current operational status descriptors for the organisation.
roles	Roles	1+	read-write	DictionaryComposition [Organisation Role Object]	One or more roles describing the organisation's relationship within the registry ecosystem.
parent	Parent Organisation	0-1	read-write	Aggregation [Organisation Data Object]	The parent organisation in a hierarchical organisation structure.
contactInfo	Contact Information	0-1	read-write	External:RPP-JSContact-Profile:Card	Contact information.
contacts	Contacts	0+	read-write	LabelledAggregation[Contact Data Object]	Identifiers of contact objects associated with the organisation.
users	Users	0+	read-write	LabelledAggregation [User Data Object]	Identifiers of user objects associated with the organisation.
processes	Processes	0-1	read-only	Processes Object	Process Objects initiated on the organisation object.

Operations Operation: Create Operation Identifier: create Description: Provisions a new Organisation Data Object. Input Data Elements: (None) Parameters: (None) Operation: Read Operation Identifier: read Description: Retrieves the data elements of an Organisation Data Object. Input Data Elements: (None) Parameters: (None) Operation: Update Operation Identifier: update Description: Modifies the attributes of an existing Organisation Data Object. Input Data Elements: (None) Parameters: (None) Operation: Delete Operation Identifier: delete Description: Removes an existing Organisation Data Object. Input Data Elements: (None) Parameters: (None) Object: message Object Name: Message Data Object Object Type: Resource Description: Represents a message placed into an organisation's queue by the server and retrieved by the client. Reference: [This-ID] Data Elements

Identifier	Name	Card.	Mutability	Data Type	Description
id	Message ID	1	read-only	Identifier	A server-unique identifier for the message object.
creationDate	Creation Date	1	read-only	Timestamp	The date and time when the message object was created and inserted into the queue.
status	Status	1	read-only	String	The current lifecycle status of the message object (`queued`, `delivered`, `removed`).
data	Data	1	create-only	Base Message Object	The data related to a specific message, such as a transfer request or a review response.

Operations Operation: Create Operation Identifier: create Description: Inserts a new message into the queue for an organisation. Input Data Elements: (None) Parameters: (None) Operation: Read Operation Identifier: read Description: Retrieves the data elements of one or more Message Data Objects. Input Data Elements: (None) Parameters: (None) Operation: Query Operation Identifier: query Description: Retrieves zero or more Message Data Objects, optionally filtered by the specified parameters. Input Data Elements: (None) Parameters

Identifier	Name	Card.	Data Type	Description
type	Message Type	0-1	String	The type of the message to use as a filter when retrieving message objects.

Operation: Delete Operation Identifier: delete Description: Removes a specific Message Data Object. Input Data Elements: (None) Parameters: (None) Object: user Object Name: User Data Object Object Type: Resource Description: Represents a user linked to an Organisation Data Object. Each user carries a set of RBAC roles that define the user's permissions within the context of the owning organisation. The lifecycle of a User Object is bound to its Organisation Object. Reference: [This-ID] Data Elements

Identifier	Name	Card.	Mutability	Data Type	Description
id	User Identifier	1	create-only	Identifier	A unique identifier for the user. MUST be globally unique in the server scope.
details	Details	1	read-write	External:RPP-JSContact-Profile:Card	The details of the user.
status	Status	1	read-write	User Status Object	The current status of the user.
processes	Processes	0-1	read-only	Processes Object	Process Objects initiated on the user object.
description	Description	0-1	read-write	String	A description of the user
organisation	Organisation	1	read-only	Aggregation [Organisation Data Object]	A reference to the owner organisation object.

Operations Operation: Create Operation Identifier: create Description: Creates a new User Object. Input Data Elements: (None) Parameters: (None) Operation: Read Operation Identifier: read Description: Retrieves the data elements of a specific User Object. Input Data Elements: (None) Parameters: (None) Operation: Update Operation Identifier: update Description: Modifies the read-write data elements (e.g., roles) of a specific User Object. Input Data Elements: (None) Parameters: (None) Operation: Delete Operation Identifier: delete Description: Removes a specific User Object. Input Data Elements: (None) Parameters: (None) Object: profile Object Name: Profile Data Object Object Type: Resource Description: Represents a named set of protocol features and versions that defines the compatibility and capabilities of RPP server implementations. Reference: [This-ID] Data Elements

Identifier	Name	Card.	Mutability	Data Type	Description
name	Name	1	read-only	String	A unique name that identifies the profile.
description	Description	1	read-only	String	A human-readable description of the profile and its intended use.
version	Version	1	read-only	String	The version of the profile.
rppVersion	RPP Version	1	read-only	String	The minimum version of the RPP protocol that is supported or required for the profile.
objects	Objects	1+	read-only	String	The objects allowed for provisioning operations.
extensions	Extensions	0+	read-only	Extension Object	The extensions, including their names and versions, that are supported or required for the profile.
baseProfile	Base Profile	0-1	read-only	Aggregation [Profile Data Object]	A base profile that is extended by this profile.
defaultProfile	Default Profile	1	read-only	Boolean	Indicates whether this profile is the default profile.

Operations Operation: Read Operation Identifier: read Description: Retrieves the Profile Data Object identified by its name. Input Data Elements: (None) Parameters: (None) Object: discoveryVersion Object Name: Discovery Version Object Object Type: Component Description: Describes a version of RPP supported by the server. Reference: [This-ID] Data Elements

Element Identifier	Element Name	Card.	Mutability	Data Type	Description
version	Version	1	read-only	String	The RPP version, for example "1.0".
baseUrl	Base URL	1	read-only	URL	The base URL specific for the version, used as a prefix for all endpoint URL templates.

Object: discoveryEnvironment Object Name: Discovery Environment Object Object Type: Component Description: Describes the environment of the RPP server. Reference: [This-ID] Data Elements

Element Identifier	Element Name	Card.	Mutability	Data Type	Description
name	Name	1	read-only	String	The name of the RPP server.
status	Status	1	read-only	String	The operational status of the RPP server.

Object: extension Object Name: Extension Object Object Type: Component Description: Describes an extension supported by the server. Reference: [This-ID] Data Elements

Element Identifier	Element Name	Card.	Mutability	Data Type	Description
name	Name	1	read-only	String	A short name for the extension.
id	Extension ID	1	read-only	String	A unique URN identifier for the extension.
version	Version	1	read-only	String	The version of the extension supported by the server.
url	URL	1	read-only	URL	The location of the extension specification.

Object: discoveryIdnLgr Object Name: Discovery IDN LGR Object Object Type: Component Description: Describes a Label Generation Ruleset (LGR) supported by the server for internationalized domain names. Reference: [This-ID] Data Elements

Element Identifier	Element Name	Card.	Mutability	Data Type	Description
tld	TLDs	1+	read-only	String	The top-level domains to which the LGR applies.
name	Name	1	read-only	String	The IANA-registered name of the LGR.
url	URL	1	read-only	URL	The location of the LGR specification.
default	Default	1	read-only	Boolean	Indicates whether this LGR is the default for the specified TLDs.

Object: discoveryNotice Object Name: Discovery Notice Object Object Type: Component Description: Describes a notice from the server operator. Reference: [This-ID] Data Elements

Element Identifier	Element Name	Card.	Mutability	Data Type	Description
pubTime	Publication Time	1	read-only	Timestamp	The publication time of the notice.
text	Text	1	read-only	String	A human-readable description of the notice.

Object: discovery Object Name: Discovery Data Object Object Type: Resource Description: Describes the capabilities of an RPP server. Reference: [This-ID] Data Elements

Identifier	Name	Card.	Mutability	Data Type	Description
versions	Versions	1+	read-only	Discovery Version Object	The versions of RPP supported by the server.
environment	Environment	1	read-only	Discovery Environment Object	Information about the RPP server.
tlds	TLDs	1+	read-only	String	The TLDs supported by the server.
extensions	Extensions	0+	read-only	Extension Object	The extensions supported by the server.
profiles	Profiles	0+	read-only	String	The profiles supported by the server.
objects	Objects	1+	read-only	String	The resource collections supported by the server.
datetime	Date and Time	1	read-only	Timestamp	The current date and time of the server.
links	Links	0+	read-only	LabelledAggregation [String]	Links to documents related to the use of RPP with the server, labelled with a relation type registered in the IANA "Link Relation Types" registry.
idnLgr	IDN LGRs	0+	read-only	Discovery IDN LGR Object	The Label Generation Rulesets supported by the server.
notices	Notices	0+	read-only	Discovery Notice Object	Notices from the server operator.

Operations Operation: Read Operation Identifier: read Description: Retrieves the Discovery Data Object. Input Data Elements: (None) Parameters: (None)

RPP User Role Values Registry This document establishes the "RESTful Provisioning Protocol (RPP) User Role Values Registry". This registry serves as a catalogue of all user role values used within RPP. Fields to be registered:

name: The name of the user role, for example "RPP example role".
url: The URL for the user role specification, for example "https://www.iana.org/assignments/rpp-user-roles/rpp-example-role-1.0".
permission: The permission level associated with the user role, for example "read-only", "read-write", or "admin".
description: A human-readable description of the user role and its intended use.

RPP Domain Name Status Values Registry This document establishes the "RESTful Provisioning Protocol (RPP) Domain Name Status Values Registry". Fields to be registered:

value: The machine-readable status label, for example "clientDeleteProhibited".
description: A human-readable description of the status and the conditions under which it applies.
set-by: The entity that adds and removes the status value: "client", "server", or "client, server" for a value that the server manages and that a client can also manage where server policy permits.
reference: A reference to the specification that defines the status value.

Initial Registrations The initial registrations for the RPP Domain Name Status Values registry are the status values defined in , reproduced below with their reference. Initial RPP Domain Name Status Values Registrations

Value	Set By	Description	Reference
clientDeleteProhibited	client	Requests to delete the object MUST be rejected.	[This-ID]
serverDeleteProhibited	server	Requests to delete the object MUST be rejected.	[This-ID]
clientHold	client	DNS delegation information MUST NOT be published for the object.	[This-ID]
serverHold	server	DNS delegation information MUST NOT be published for the object.	[This-ID]
clientRenewProhibited	client	Requests to renew the object MUST be rejected.	[This-ID]
serverRenewProhibited	server	Requests to renew the object MUST be rejected.	[This-ID]
clientTransferProhibited	client	Requests to transfer the object MUST be rejected.	[This-ID]
serverTransferProhibited	server	Requests to transfer the object MUST be rejected.	[This-ID]
clientUpdateProhibited	client	Requests to update the object (other than to remove this status) MUST be rejected.	[This-ID]
serverUpdateProhibited	server	Requests to update the object (other than to remove this status) MUST be rejected.	[This-ID]
inactive	server	Delegation information has not been associated with the object. This is the default status when a domain object is first created and there are no associated host objects for the DNS delegation. This status can also be set by the server when all host-object associations are removed.	[This-ID]
ok	server	This is the normal status value for an object that has no pending operations or prohibitions. This value is set and removed by the server as other status values are added or removed.	[This-ID]
pendingCreate	server	A transform command has been processed for the object, but the action has not been completed by the server. Server operators can delay action completion for a variety of reasons, such as to allow for human review or third-party action.	[This-ID]
pendingDelete	server	A transform command has been processed for the object, but the action has not been completed by the server. Server operators can delay action completion for a variety of reasons, such as to allow for human review or third-party action.	[This-ID]
pendingRenew	server	A transform command has been processed for the object, but the action has not been completed by the server. Server operators can delay action completion for a variety of reasons, such as to allow for human review or third-party action.	[This-ID]
pendingTransfer	server	A transform command has been processed for the object, but the action has not been completed by the server. Server operators can delay action completion for a variety of reasons, such as to allow for human review or third-party action.	[This-ID]
pendingUpdate	server	A transform command has been processed for the object, but the action has not been completed by the server. Server operators can delay action completion for a variety of reasons, such as to allow for human review or third-party action.	[This-ID]
rgpAddPeriod	server	This grace period is provided after the initial registration of a domain name. If the domain name is deleted by the registrar during this period, the registry provides a credit to the registrar for the cost of the registration.	[This-ID]
rgpAutoRenewPeriod	server	This grace period is provided after a domain name registration period expires and is extended (renewed) automatically by the registry. If the domain name is deleted by the registrar during this period, the registry provides a credit to the registrar for the cost of the renewal.	[This-ID]
rgpRenewPeriod	server	This grace period is provided after a domain name registration period is explicitly extended (renewed) by the registrar. If the domain name is deleted by the registrar during this period, the registry provides a credit to the registrar for the cost of the renewal.	[This-ID]
rgpTransferPeriod	server	This grace period is provided after the successful transfer of domain name registration sponsorship from one registrar to another registrar. If the domain name is deleted by the new sponsoring registrar during this period, the registry provides a credit to the registrar for the cost of the transfer.	[This-ID]
rgpRedemptionPeriod	server	This status value is used to describe a domain for which a delete operation has been received, but the domain has not yet been purged because an opportunity exists to restore the domain and abort the deletion process.	[This-ID]
rgpPendingRestore	server	This status value is used to describe a domain that is in the process of being restored after being in the rgpRedemptionPeriod state.	[This-ID]
rgpPendingDelete	server	This status value is used to describe a domain that has entered the purge processing state after completing the rgpRedemptionPeriod state. A domain in this status MUST also be in the pendingDelete status described above.	[This-ID]

RPP Host Status Values Registry This document establishes the "RESTful Provisioning Protocol (RPP) Host Status Values Registry". Fields to be registered:

value: The machine-readable status label, for example "clientDeleteProhibited".
description: A human-readable description of the status and the conditions under which it applies.
set-by: The entity that adds and removes the status value: "client", "server", or "client, server" for a value that the server manages and that a client can also manage where server policy permits.
reference: A reference to the specification that defines the status value.

Initial Registrations The initial registrations for the RPP Host Status Values registry are the status values defined in , reproduced below with their reference. Initial RPP Host Status Values Registrations

Value	Set By	Description	Reference
clientDeleteProhibited	client	Requests to delete the object MUST be rejected.	[This-ID]
serverDeleteProhibited	server	Requests to delete the object MUST be rejected.	[This-ID]
clientUpdateProhibited	client	Requests to update the object (other than to remove this status) MUST be rejected.	[This-ID]
serverUpdateProhibited	server	Requests to update the object (other than to remove this status) MUST be rejected.	[This-ID]
linked	server	The host object has at least one active association with another object, such as a domain object. Servers SHOULD provide services to determine existing object associations.	[This-ID]
ok	server	This is the normal status value for an object that has no pending operations or prohibitions. This value is set and removed by the server as other status values are added or removed.	[This-ID]
pendingCreate	server	A transform command has been processed for the object, but the action has not been completed by the server. Server operators can delay action completion for a variety of reasons, such as to allow for human review or third-party action.	[This-ID]
pendingDelete	server	A transform command has been processed for the object, but the action has not been completed by the server. Server operators can delay action completion for a variety of reasons, such as to allow for human review or third-party action.	[This-ID]
pendingTransfer	server	A transform command has been processed for the object's superordinate domain object (i.e. a transfer of the domain object is pending), but the action has not been completed by the server. Server operators can delay action completion for a variety of reasons, such as to allow for human review or third-party action.	[This-ID]
pendingUpdate	server	A transform command has been processed for the object, but the action has not been completed by the server. Server operators can delay action completion for a variety of reasons, such as to allow for human review or third-party action.	[This-ID]

RPP Contact Status Values Registry This document establishes the "RESTful Provisioning Protocol (RPP) Contact Status Values Registry". Fields to be registered:

value: The machine-readable status label, for example "clientDeleteProhibited".
description: A human-readable description of the status and the conditions under which it applies.
set-by: The entity that adds and removes the status value: "client", "server", or "client, server" for a value that the server manages and that a client can also manage where server policy permits.
reference: A reference to the specification that defines the status value.

Initial Registrations The initial registrations for the RPP Contact Status Values registry are the status values defined in , reproduced below with their reference. Initial RPP Contact Status Values Registrations

Value	Set By	Description	Reference
clientDeleteProhibited	client	Requests to delete the object MUST be rejected.	[This-ID]
serverDeleteProhibited	server	Requests to delete the object MUST be rejected.	[This-ID]
clientTransferProhibited	client	Requests to transfer the object MUST be rejected.	[This-ID]
serverTransferProhibited	server	Requests to transfer the object MUST be rejected.	[This-ID]
clientUpdateProhibited	client	Requests to update the object (other than to remove this status) MUST be rejected.	[This-ID]
serverUpdateProhibited	server	Requests to update the object (other than to remove this status) MUST be rejected.	[This-ID]
linked	server	The contact object has at least one active association with another object, such as a domain object. Servers SHOULD provide services to determine existing object associations.	[This-ID]
ok	server	This is the normal status value for an object that has no pending operations or prohibitions. This value is set and removed by the server as other status values are added or removed.	[This-ID]
pendingCreate	server	A transform command has been processed for the object, but the action has not been completed by the server. Server operators can delay action completion for a variety of reasons, such as to allow for human review or third-party action.	[This-ID]
pendingDelete	server	A transform command has been processed for the object, but the action has not been completed by the server. Server operators can delay action completion for a variety of reasons, such as to allow for human review or third-party action.	[This-ID]
pendingTransfer	server	A transform command has been processed for the object, but the action has not been completed by the server. Server operators can delay action completion for a variety of reasons, such as to allow for human review or third-party action.	[This-ID]
pendingUpdate	server	A transform command has been processed for the object, but the action has not been completed by the server. Server operators can delay action completion for a variety of reasons, such as to allow for human review or third-party action.	[This-ID]

RPP Organisation Role Status Values Registry This document establishes the "RESTful Provisioning Protocol (RPP) Organisation Role Status Values Registry". Fields to be registered:

value: The machine-readable status label, for example "clientLinkProhibited".
description: A human-readable description of the status and the conditions under which it applies.
set-by: The entity that adds and removes the status value: "client", "server", or "client, server" for a value that the server manages and that a client can also manage where server policy permits.
reference: A reference to the specification that defines the status value.

Initial Registrations The initial registrations for the RPP Organisation Role Status Values registry are the status values defined in , reproduced below with their reference. Initial RPP Organisation Role Status Values Registrations

Value	Set By	Description	Reference
clientLinkProhibited	client	Requests to add new links to the role MUST be rejected.	[This-ID]
serverLinkProhibited	server	Requests to add new links to the role MUST be rejected.	[This-ID]
linked	server	The role has at least one active association with another object. This value is set and removed by the server and is not explicitly set by the client.	[This-ID]
ok	server	This is the normal status value for a role that has no active prohibitions. This value is set and removed by the server as other status values are added or removed.	[This-ID]

RPP Organisation Status Values Registry This document establishes the "RESTful Provisioning Protocol (RPP) Organisation Status Values Registry". Fields to be registered:

value: The machine-readable status label, for example "clientDeleteProhibited".
description: A human-readable description of the status and the conditions under which it applies.
set-by: The entity that adds and removes the status value: "client", "server", or "client, server" for a value that the server manages and that a client can also manage where server policy permits.
reference: A reference to the specification that defines the status value.

Initial Registrations The initial registrations for the RPP Organisation Status Values registry are the status values defined in , reproduced below with their reference. Initial RPP Organisation Status Values Registrations

Value	Set By	Description	Reference
ok	server	This is the normal status value for an object that has no pending operations or prohibitions. This value is set and removed by the server as other status values are added or removed.	[This-ID]
hold	client, server	Organisation transform commands and new links MUST be rejected.	[This-ID]
terminated	client, server	The organisation has been terminated and MUST NOT be linked. Organisation transform commands and new links MUST be rejected.	[This-ID]
linked	server	The organisation object has at least one active association with another object. This value is not explicitly set by the client. Servers SHOULD provide services to determine existing object associations.	[This-ID]
clientLinkProhibited	client	Requests to add new links to the organisation MUST be rejected.	[This-ID]
serverLinkProhibited	server	Requests to add new links to the organisation MUST be rejected.	[This-ID]
clientUpdateProhibited	client	Requests to update the object (other than to remove this status) MUST be rejected.	[This-ID]
serverUpdateProhibited	server	Requests to update the object (other than to remove this status) MUST be rejected.	[This-ID]
clientDeleteProhibited	client	Requests to delete the object MUST be rejected.	[This-ID]
serverDeleteProhibited	server	Requests to delete the object MUST be rejected.	[This-ID]
pendingCreate	server	A transform command has been processed for the object, but the action has not been completed by the server. Server operators can delay action completion for a variety of reasons, such as to allow for human review or third-party action.	[This-ID]
pendingUpdate	server	A transform command has been processed for the object, but the action has not been completed by the server. Server operators can delay action completion for a variety of reasons, such as to allow for human review or third-party action.	[This-ID]
pendingDelete	server	A transform command has been processed for the object, but the action has not been completed by the server. Server operators can delay action completion for a variety of reasons, such as to allow for human review or third-party action.	[This-ID]

RPP User Status Values Registry This document establishes the "RESTful Provisioning Protocol (RPP) User Status Values Registry". Fields to be registered:

value: The machine-readable status label, for example "suspended".
description: A human-readable description of the status and the conditions under which it applies.
set-by: The entity that adds and removes the status value: "client", "server", or "client, server" for a value that the server manages and that a client can also manage where server policy permits.
reference: A reference to the specification that defines the status value.

Initial Registrations The initial registrations for the RPP User Status Values registry are the status values defined in , reproduced below with their reference. Initial RPP User Status Values Registrations

Value	Set By	Description	Reference
active	server	This is the normal status value for a user that is permitted to authenticate and act within the permissions of its roles.	[This-ID]
pending	server	The user has been created, but activation has not been completed by the server. Server operators can delay activation for a variety of reasons, such as to allow for verification of the user's details or human review. Requests authenticated as the user MUST be rejected.	[This-ID]
suspended	client, server	The user has been temporarily suspended. Requests authenticated as the user MUST be rejected.	[This-ID]
deactivated	client, server	The user has been deactivated. Requests authenticated as the user MUST be rejected.	[This-ID]

URN Sub-namespace for RPP (urn:ietf:params:rpp) The IANA is requested to add the following value to the "IETF URN Sub-namespace for Registered Protocol Parameter Identifiers" registry, following the template in : TODO: add filled in template, if we decide to use URN for profile identification, for example "urn:ietf:params:rpp:profile:example-profile"

RPP Discovery Registry The IANA is requested to create a new registry for RPP discovery URLs, this registry will be used to register the well-known URLs for RPP discovery endpoints, used by RPP clients to discover the capabilities of an RPP server. Fields to be registered:

tld: The top-level domain (TLD) for which the discovery URL is applicable, for example "example".
url: The URL for the discovery endpoint, for example "https://rpp.example/.well-known/rpp.json".
description: A human-readable description of the discovery URL and its intended use.

RPP Extension Registry The IANA is requested to create a new registry for RPP extensions, this registry will be used to register standardised extensions to the RPP protocol. Extensions are defined as additional features or capabilities that can be added to the base RPP protocol, for example support for additional resource types, additional operations or additional authentication methods. Fields to be registered:

name: The name of the extension, for example "RPP example extension".
version: The version of the extension, for example "1.0".
url: The URL for the extension specification, for example "https://www.iana.org/assignments/rpp-extensions/rpp-example-extension".
description: A human-readable description of the extension and its intended use.

RPP Profile Registry The IANA is requested to create a new registry for RPP profiles, this registry will be used to register standardised profiles for the RPP protocol. Profiles are defined as specific configurations of the RPP protocol that are designed to meet the needs of specific use cases or environments, for example an EPP compatibility profile that defines a set of RPP features and behaviours that are compatible with the Extensible Provisioning Protocol (EPP) . Fields to be registered:

name: The name of the profile, for example "EPP compatibility profile".
id: A unique URN identifier for the profile, for example "urn:ietf:params:rpp:profile:epp-compatibility".
version: The version of the profile, for example "1.0".
url: The URL for the profile specification, for example "https://www.iana.org/assignments/rpp-profiles/epp-compatibility-profile".
description: A human-readable description of the profile and its intended use.

Security Considerations

Changes History

draft-ietf-rpp-data-objects -01 - -02

added Availability operation to the Uniform Interface and to the Domain Name, Contact and Host Data Objects #46
add Abstract keyword to flag objects used only as base objects; Base Process Object and Base Message Object declared abstract #188
clarified the Processes a Data Object supports or extends, and allowed extensions to define new processes
moved restore report from operation input to read-write element of Restore Process Object and replaced Report operation with Update
added a Status Object per Data Object, including the User Status Object, with status values, allowed transitions, and IANA registries, replacing the inline user status definition #118
fixed User Object delete operation constraint that prevented any user from being deleted
added X-Y bounded cardinality notation and set cardinality of Restore Report statements to 1-2 #183
defined a structured notation for operation input and output, with input data elements and parameters (replacing transient data elements) inside the Input attribute, and split IANA operation tables into "Input Data Elements" and "Parameters" #147
moved process data element from Base Message Object to Review Response, Transfer Request and Transfer Outcome message objects, using specific process types where possible; registered all message objects in IANA #179
create-only definition clarified about reading #80
moved requests for IANA registrations to here, from rpp-core document #151
added Profile Data Object, including the Default Profile element #140 #155
added Discovery Data Object, with links labelled by IANA link relation types #136 #137
added Visibility data element attribute and generic includeElements parameter. Set authInfo of domain and contact to onDemand visibility #57
added "Inheritance" section to describe how objects can use inheritance #134
removed the urgent parameter from the update operation for Domain Object #52
removed all mandatory ordering requirements for arrays, making them unordered #30
added support for IDN (Internationalized Domain Names) #124
added Message Data Object and new Uniform Interface "Query" operation #116
removed the redefined processId data element from the Domain Transfer Process Object
added Set By column and set-by registry field for status values, and required the server to assign at least one status value #186
renamed Authorisation Information and Disclose component objects to "Authorisation Information Object" and "Disclose Object" to match their references
updated document metadata, and Abstract and Introduction scope
editorial fixes to spelling, hyphenation, capitalisation, and terminology consistency

draft-ietf-rpp-data-objects -00 - -01

Added Organisation, Organisation Role and User Objects, based on RFC8543 (Issue #25)
Added Renew Process Object and operations (Issue #76)
reserve property names beginning with @ for representation specifications #89
add generic Create Process Object and Domain Create Process Object carrying the registration period #89
add optional processId to all Process Objects #89
add extensible Processes Object component and processes element to all Data Objects #89
declare the unique identifier element explicitly in every object preamble #89
add "Direct Access" flag exposing association data elements as addressable sub-resources #89
editorial pass: fix spelling, grammar, subject-verb agreement, missing articles, cross-reference wording, and copy-paste object names
Add External Data Types section and JSContact (Issue #83)
restructure object processes: per-object "Processes" sections, process objects extending generic ones, add Domain Transfer Process Object, with IANA updates #119

draft-kowalik-rpp-data-objects-04 - draft-ietf-rpp-data-objects-00

RPP working group adoption

draft-kowalik-rpp-data-objects -03 - -04

correct "postalInfo" to be DictionaryComposition not DictionaryAggregation
Added missing IANA tables for Contact, Postal Address and Postal Info. Added missing Operations. Added missing operation identifiers. Fixes #17, #18, #19, #20, #21.

draft-kowalik-rpp-data-objects -02 - -03

add Object and Dictionary[Value Type] primitive data types
change "Aggregation/Composition Dictionary" to "Dictionary Aggregation/Composition" (Issue #32)
describe operations for contacts #15
describe operations for hosts #16
add Domain Update operation with urgent transient parameter from
add identifiers to all operations
abstract common provisioning metadata into reusable component object
define common RGP/restore process and Restore Process Object
define common transfer operations and Transfer Process Object with support for pull and push transfers #23
add domain-specific transfer operations with implicit renewal and subordinate host transfer
add host/domain relationship terminology from RFC 5732
restructure DNS data model aligned with draft-simmen-rpp-dns-data-01: redefine DNS Resource Record Object, add DNS Operational Controls Object, add DNS Data Object; update Domain, Host, and Nameserver objects to use it
add DNSSEC support based on : DS and DNSKEY record types with structured RDATA fields
add NS, A, and AAAA RDATA structures and record type constraints to EPP compatibility profile for DNS Resource Record Object
expand extensibility section with standardised/private extension mechanisms, extension points, and operation extensibility
update IANA registration policy and registry structure to accommodate extension registrations

draft-kowalik-rpp-data-objects -01 - -02

ontology of allowed basic datatypes #4
add examples of associations #31