



Network Working Group                                         P. Kowalik
Internet-Draft                                                     DENIC
Intended status: Standards Track                              M. Wullink
Expires: 23 April 2026                                         SIDN Labs
                                                         20 October 2025


            RESTful Provisioning Protocol (RPP) Data Objects
                   draft-kowalik-rpp-data-objects-01

Abstract

   This document defines data objects for the RESTful Provisioning
   Protocol (RPP) and sets up IANA RPP Data Object Registry to describe
   and catalogue them.  Specifically, it details the logical structure,
   constraints, and protocol operations (including their inputs and
   outputs) for foundational resources: domain names, contacts, and
   hosts.  In accordance with the RPP architecture
   [I-D.kowalik-rpp-architecture], these definitions focus entirely on
   the semantics, remaining independent of any specific data
   representation or media type (e.g., JSON or XML).

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 23 April 2026.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights



Kowalik & Wullink         Expires 23 April 2026                 [Page 1]

Internet-Draft              RPP Data Objects                October 2025


   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Conventions and Terminology . . . . . . . . . . . . . . .   4
   2.  Resource Definition Principles  . . . . . . . . . . . . . . .   4
     2.1.  Data Element Abstraction  . . . . . . . . . . . . . . . .   4
     2.2.  Extensibility . . . . . . . . . . . . . . . . . . . . . .   4
     2.3.  Data Element Semantics  . . . . . . . . . . . . . . . . .   4
     2.4.  Operations  . . . . . . . . . . . . . . . . . . . . . . .   5
       2.4.1.  Authorisation . . . . . . . . . . . . . . . . . . . .   5
       2.4.2.  Uniform interface . . . . . . . . . . . . . . . . . .   5
         2.4.2.1.  Create  . . . . . . . . . . . . . . . . . . . . .   5
         2.4.2.2.  Read  . . . . . . . . . . . . . . . . . . . . . .   5
         2.4.2.3.  Update  . . . . . . . . . . . . . . . . . . . . .   6
         2.4.2.4.  Delete  . . . . . . . . . . . . . . . . . . . . .   6
       2.4.3.  Operations beyond uniform interface . . . . . . . . .   6
     2.5.  EPP Compatibility Profile . . . . . . . . . . . . . . . .   6
   3.  Common Data Types . . . . . . . . . . . . . . . . . . . . . .   7
     3.1.  Identifier  . . . . . . . . . . . . . . . . . . . . . . .   7
     3.2.  Timestamp . . . . . . . . . . . . . . . . . . . . . . . .   7
     3.3.  Client Identifier . . . . . . . . . . . . . . . . . . . .   7
     3.4.  Phone Number  . . . . . . . . . . . . . . . . . . . . . .   7
   4.  Associations  . . . . . . . . . . . . . . . . . . . . . . . .   8
     4.1.  Aggregation . . . . . . . . . . . . . . . . . . . . . . .   8
     4.2.  Composition . . . . . . . . . . . . . . . . . . . . . . .   8
     4.3.  Labelled Aggregation  . . . . . . . . . . . . . . . . . .   8
     4.4.  Aggregation Dictionary  . . . . . . . . . . . . . . . . .   9
     4.5.  Labelled Composition  . . . . . . . . . . . . . . . . . .   9
     4.6.  Composition Dictionary  . . . . . . . . . . . . . . . . .   9
   5.  Component Objects . . . . . . . . . . . . . . . . . . . . . .   9
     5.1.  Period Object . . . . . . . . . . . . . . . . . . . . . .  10
     5.2.  Status Object . . . . . . . . . . . . . . . . . . . . . .  10
     5.3.  Nameserver Object . . . . . . . . . . . . . . . . . . . .  11
     5.4.  DNS Resource Record . . . . . . . . . . . . . . . . . . .  12
     5.5.  Authorisation Information Object  . . . . . . . . . . . .  12
     5.6.  Postal Address Object . . . . . . . . . . . . . . . . . .  13
     5.7.  Postal Info Object  . . . . . . . . . . . . . . . . . . .  14
     5.8.  Disclose Object . . . . . . . . . . . . . . . . . . . . .  16
   6.  Domain Name Data Object . . . . . . . . . . . . . . . . . . .  16
     6.1.  Object Description  . . . . . . . . . . . . . . . . . . .  16
     6.2.  Data Elements . . . . . . . . . . . . . . . . . . . . . .  16
     6.3.  Operations  . . . . . . . . . . . . . . . . . . . . . . .  20
       6.3.1.  Create Operation  . . . . . . . . . . . . . . . . . .  20



Kowalik & Wullink         Expires 23 April 2026                 [Page 2]

Internet-Draft              RPP Data Objects                October 2025


       6.3.2.  Read Operation  . . . . . . . . . . . . . . . . . . .  21
       6.3.3.  Delete Operation  . . . . . . . . . . . . . . . . . .  21
       6.3.4.  Renew Operation . . . . . . . . . . . . . . . . . . .  22
       6.3.5.  Transfer operation  . . . . . . . . . . . . . . . . .  22
   7.  Contact Data Object . . . . . . . . . . . . . . . . . . . . .  22
     7.1.  Object Description  . . . . . . . . . . . . . . . . . . .  22
     7.2.  Data Elements . . . . . . . . . . . . . . . . . . . . . .  23
     7.3.  Operations  . . . . . . . . . . . . . . . . . . . . . . .  26
   8.  Host Data Object  . . . . . . . . . . . . . . . . . . . . . .  26
     8.1.  Object Description  . . . . . . . . . . . . . . . . . . .  27
     8.2.  Data Elements . . . . . . . . . . . . . . . . . . . . . .  27
     8.3.  Operations  . . . . . . . . . . . . . . . . . . . . . . .  29
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  29
     9.1.  RPP Data Object Registry  . . . . . . . . . . . . . . . .  29
       9.1.1.  Registration Policy . . . . . . . . . . . . . . . . .  29
       9.1.2.  Registry Structure  . . . . . . . . . . . . . . . . .  30
       9.1.3.  Initial Registrations . . . . . . . . . . . . . . . .  30
   10. Normative References  . . . . . . . . . . . . . . . . . . . .  38
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  39

1.  Introduction

   The RESTful Provisioning Protocol (RPP) defines a set of data objects
   used to represent and manage foundational registry resources,
   including domain names, contacts, and hosts.  This initial list is
   not exhaustive; additional resource and component objects MAY be
   defined in future revisions or introduced via IANA registration to
   support new features and operational needs.

   In accordance with the RPP architecture
   [I-D.kowalik-rpp-architecture], a core architectural principle is the
   clear distinction between the abstract data model and its concrete
   data representation.  The data model defines the logical structure,
   relationships, and constraints of the objects, independent of
   formatting.  The data representation defines how these abstract
   concepts are expressed in specific formats (e.g., JSON, XML, or
   YAML).

   This document focuses on the data model of RPP objects and operations
   on them, including the data model of operation inputs and outputs.
   This separation of concerns ensures the protocol maintains a stable
   semantic foundation that can be consistently implemented across
   different media types and easily adapted to new representation
   formats.  For instance, the model defines a contact's name as a
   required string type, but it remains agnostic as to whether that
   string is ultimately encoded as a JSON property or an XML element.





Kowalik & Wullink         Expires 23 April 2026                 [Page 3]

Internet-Draft              RPP Data Objects                October 2025


1.1.  Conventions and Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  Resource Definition Principles

2.1.  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.

2.2.  Extensibility

   The set of data elements for a given data object is extensible.  New
   data elements, associations or operations MAY be defined and
   registered with IANA in order for the data object to support new
   features.

2.3.  Data Element Semantics

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

   *  Name: A human-readable name for the data element.
   *  Identifier: A machine-readable, unique identifier for the element,
      using camelCase notation.
   *  Cardinality: Specifies the number of times an element may appear.
      The notation is as follows:
      -  1 for exactly one
      -  0-1 for zero or one
      -  0+ for zero or more
      -  and 1+ for one or more
   *  Data Type: Defines the element's data structure, which can be a
      primitive type (e.g., String, Integer) 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:



Kowalik & Wullink         Expires 23 April 2026                 [Page 4]

Internet-Draft              RPP Data Objects                October 2025


      -  create-only: The element's value is provided during the
         object's creation and cannot be modified thereafter.
      -  read-only: The element's value is managed by the server.  It
         cannot be set or modified directly by the client, though it may
         change as a result of server-side operations.
      -  read-write: The element's value can be set and modified by the
         client.

2.4.  Operations

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

2.4.1.  Authorisation

   For each operation authorisation requirements and operation behaviour
   is specified.  Wherever "object authorisation" is mentioned, it means
   that an operation MAY accept or require additional authorisation data
   related to the object beyond default client-level authorisation, or
   that an operation MAY have different effect or response if such
   authorisation is provided.  Typically it would be a value related to
   or derived from Authorisation Information Object attached to the
   object.

2.4.2.  Uniform interface

   For the typical set of Create, Read, Update and Delete operations the
   following set of input and output data model is specified on top of
   additional transient input data, unless an operation for the specific
   object tells otherwise.

2.4.2.1.  Create

   *  Input: Object representation (create-only and read-write
      properties)
   *  Output: Object representation (read-write and read-only
      properties)

2.4.2.2.  Read

   *  Input: Object identifier
   *  Output: Object representation (read-write and read-only
      properties)

   The output representation MAY vary depending on the identity of the
   querying client, use of object authorisation information, and server
   policy towards unauthorized clients.  If the querying client is the
   sponsoring client, all available information MUST be returned.  If



Kowalik & Wullink         Expires 23 April 2026                 [Page 5]

Internet-Draft              RPP Data Objects                October 2025


   the querying client is not the sponsoring client but the client
   provides valid object authorisation information, all available
   information SHOULD be returned, however some optional elements MAY be
   reserved to the sponsoring client only.  If the querying client is
   not the sponsoring client and the client does not provide valid
   object authorisation information, server policy determines which
   OPTIONAL elements are returned, if any, or whether the entire request
   is rejected.

2.4.2.3.  Update

   *  Input: Object identifier, Object changes representation (read-
      write properties)
   *  Output: Object representation (read-write and read-only
      properties)

2.4.2.4.  Delete

   *  Input: Object identifier
   *  Output: Object representation (read-write and read-only
      properties) or no representation

2.4.3.  Operations beyond uniform interface

   For all other operations both input and output representation have to
   be fully specified.

2.5.  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.






Kowalik & Wullink         Expires 23 April 2026                 [Page 6]

Internet-Draft              RPP Data Objects                October 2025


3.  Common Data Types

   This section defines data types and structures that are re-used
   across multiple data object definitions.

3.1.  Identifier

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

3.2.  Timestamp

   Date and time attribute values MUST be represented in Universal
   Coordinated Time (UTC) using the Gregorian calendar using date-time
   form as defined in [RFC3339].  In EPP Compatibility Profile upper
   case "T" and "Z" characters MUST be used.

3.3.  Client Identifier

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

      |  TBC: do we need this or is it a relation with an entity/RFC8543
      |  organisation?  If registrars modeled are as first class objects
      |  (organisations), then clID is nothing else but a reference to
      |  this organisation, so maybe no need to define syntax separately
      |  on identifier level (or in other words it would be defined on
      |  this object).  R8.1 in the form of -02 RPP requirements
      |  includes RFC8543.

3.4.  Phone Number

   Telephone number syntax is derived from structures defined in
   [ITU.E164.2005].  Telephone numbers described in this specification
   are character strings that MUST begin with a plus sign ("+", ASCII
   value 0x002B), followed by a country code defined in [ITU.E164.2005],
   followed by a dot (".", ASCII value 0x002E), followed by a sequence
   of digits representing the telephone number.  An optional "x" (ASCII
   value 0x0078) separator with additional digits representing extension
   information can be appended to the end of the value.






Kowalik & Wullink         Expires 23 April 2026                 [Page 7]

Internet-Draft              RPP Data Objects                October 2025


4.  Associations

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

   The following generic Association Types are defined for RPP:

4.1.  Aggregation

   Notation: Aggregation[Type]

   A relation between two independent objects.

   If the cardinality of target object is more than 1, this represents
   an ordered array.  It MUST assured that the same unchanged data is
   always inserted in the same order in order to allow stable reference
   by position to data elements.  In case of data insertions, deletions
   or updates the remaining of the data SHALL preserve its order.

4.2.  Composition

   Notation: Composition[Type] or Type

   A relation between an independent parent object and 1 or more
   dependent child object(s).

   If the cardinality of target object is more than 1, this represents
   an ordered array.  It MUST assured that the same unchanged data is
   always inserted in the same order in order to allow stable reference
   by position to data elements.  In case of data insertions, deletions
   or updates the remaining of the data SHALL preserve its order.

4.3.  Labelled Aggregation

   Notation: LabelledAggregation[Type]

   A relation between two independent object with single text string
   attribute.  Multiple associations with the same label are allowed.



Kowalik & Wullink         Expires 23 April 2026                 [Page 8]

Internet-Draft              RPP Data Objects                October 2025


   A type defining such association MUST define Label Description with
   semantics of the label and Label Constraints with constraints related
   to the label.

4.4.  Aggregation Dictionary

   Notation: AggregationDictionary[Type]

   A relation between two independent object with single text string
   attribute.  Only single association with the same label is allowed
   allowing it to be used as dictionary key.

   A type defining such association MUST define Label Description with
   semantics of the label and Label Constraints with constraints related
   to the label.

4.5.  Labelled Composition

   Notation: LabelledComposition[Type]

   A relation between an independent parent object and a dependent child
   object with single text string attribute.  Multiple associations with
   the same label are allowed.

   A type defining such association MUST define Label Description with
   semantics of the label and Label Constraints with constraints related
   to the label.

4.6.  Composition Dictionary

   Notation: CompositionDictionary[Type]

   A relation between an independent parent object and a dependent child
   object with single text string attribute.  Only single association
   with the same label is allowed allowing it to be used as dictionary
   key.

   A type defining such association MUST define Label Description with
   semantics of the label and Label Constraints with constraints related
   to the label.

5.  Component Objects

   This section defines common objects that are re-used in the
   definitions of top-level data objects.  Component objects carry only
   data but do not define any operations.





Kowalik & Wullink         Expires 23 April 2026                 [Page 9]

Internet-Draft              RPP Data Objects                October 2025


5.1.  Period Object

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

5.2.  Status Object

   *  Name: Status Object
   *  Description: Represents one of the status values associated with a
      provisioning object
   *  Data Elements:
      -  Label
         o  Identifier: label
         o  Cardinality: 1
         o  Mutability: create-only
         o  Data Type: String
         o  Description: machine-readible enum label of a status
         o  Constraints:
            +  Exact list of allowed status labels depends on the
               provisioning object type.  This enumeration can be
               expanded by extensions.
            +  The status labels MUST use camel case notation and use
               only ASCII alphabetic characters.
            +  Statuses MAY be of three categories:
            1.  those explicitly set by a server.  Those MUST have
                "server" prefix
            2.  those explicitly set by a client.  Those MUST have
                "client" prefix
            3.  those indirectly controlled by provisioning object
                lifecycle or business logic.  Those MUST NOT use either
                "client" or "server" prefix.  They MAY use another
                prefix or no prefix at all



Kowalik & Wullink         Expires 23 April 2026                [Page 10]

Internet-Draft              RPP Data Objects                October 2025


      -  Reason
         o  Indentifier: reason
         o  Cardinality: 0-1
         o  Mutability: create-only
         o  Data Type: String
         o  Description: a human-readable text that describes the
            rationale for the status applied to the object.
         o  Constraints: None
      -  Due
         o  Identifier: due
         o  Cardinality: 0-1
         o  Mutability: read-write
         o  Data Type: Timestamp
         o  Description: a timestamp, when this status is going to be
            removed automatically, or changed to other status.  This
            field can be used to expresse lifecycle related information.
         o  Constraints: servers MAY restrict possibility to set or
            update this value by the client.

      |  TBD: Idea - model status object as Labelled Composition using
      |  "Label"?  Con: Generic Constraints for Label will be repeated.

5.3.  Nameserver Object

   *  Name: Nameserver Object
   *  Description: Represents a single nameserver.
   *  Data Elements:
      -  Host Name
         o  Identifier: hostName
         o  Cardinality: 1
         o  Mutability: read-write
         o  Data Type: String
         o  Description: Fully qualified name of a host.
         o  Constraints: The value MUST be a syntactically valid host
            name.
      -  DNS Resource Records
         o  Identifier: dns
         o  Cardinality: 0+
         o  Mutability: read-write
         o  Data Type: Composition[DNS Resource Record]
         o  Description: DNS Resource Records related to the host.
         o  Constraints:
            +  In EPP Compatibility Profile the entries MUST be limited
               to A and AAAA entries for IPv4 and IPv6 glue records
               respectively.
            +  The labels of DNS entries MUST be subordinate to the Host
               Name of the Nameserver.




Kowalik & Wullink         Expires 23 April 2026                [Page 11]

Internet-Draft              RPP Data Objects                October 2025


5.4.  DNS Resource Record

   *  Name: DNS Resource Record
   *  Description: Represents a DNS Entry
   *  Data Elements:
      -  Label
         o  Identifier: hostNamelabel
         o  Cardinality: 1
         o  Mutability: read-write
         o  Data Type: String.
         o  Description: DNS entry label.
         o  Constraints:
            +  The value MUST be a syntactically valid DNS host name in
               Zone file string representation.
            +  Absolute FQDNs and relative host names are allowed.
      -  Type
         o  Identifier: type
         o  Cardinality: 1
         o  Mutability: read-write
         o  Data Type: String.
         o  Description: DNS entry type.
         o  Constraints:
            +  Each value MUST be a valid string representation of
               resource record type as defined in [RFC1035].
            +  Allowed values MAY be constrained by server policies.
               For domain provisioning typically the Type would be
               constrained to the allowed parent side entries.
      -  Data
         o  Identifier: data
         o  Cardinality: 1
         o  Mutability: read-write
         o  Data Type: String.
         o  Description: DNS entry value.
         o  Constraints: Each value MUST be a syntactically valid
            resource record data for a Type in zone file string
            representation.
      -  TTL
         o  Identifier: ttl
         o  Cardinality: 1
         o  Mutability: read-write
         o  Data Type: Number.
         o  Description: TTL value of a resource record as defined in
            [RFC1035].
         o  Constraints: The allowed value range MAY be constrained by
            server policy.

5.5.  Authorisation Information Object




Kowalik & Wullink         Expires 23 April 2026                [Page 12]

Internet-Draft              RPP Data Objects                October 2025


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

5.6.  Postal Address Object

   *  Name: Postal Address Object
   *  Description: Contains the components of a postal address.
   *  Data Elements:
      -  Street
         o  Identifier: street
         o  Cardinality: 0+
         o  Mutability: read-write
         o  Data Type: String
         o  Description: The contact's street address.
         o  Constraints: Implementations MAY limit the maximum length of
            entries or character set.
      -  City
         o  Identifier: city



Kowalik & Wullink         Expires 23 April 2026                [Page 13]

Internet-Draft              RPP Data Objects                October 2025


         o  Cardinality: 0-1
         o  Mutability: read-write
         o  Data Type: String
         o  Description: The contact's city.
         o  Constraints:
            +  Implementations MAY limit the maximum length of entries
               or character set.
            +  In EPP Compatibility Profile this data element MUST be
               provided.
      -  State/Province
         o  Identifier: sp
         o  Cardinality: 0-1
         o  Mutability: read-write
         o  Data Type: String
         o  Description: The contact's state or province.
         o  Constraints: Implementations MAY limit the maximum length of
            entries or character set.
      -  Postal Code
         o  Identifier: pc
         o  Cardinality: 0-1
         o  Mutability: read-write
         o  Data Type: String
         o  Description: The contact's postal code.
         o  Constraints:
            +  Implementation MAY limit the maximum length of entries or
               character set.
            +  The limitations MAY differ depending on Country Code (cc)
               data element.
      -  Country Code
         o  Identifier: cc
         o  Cardinality: 0-1
         o  Mutability: read-write
         o  Data Type: String
         o  Description: The contact's country code.
         o  Constraints:
            +  The value MUST be a two-character identifier from
               [ISO3166-1].
            +  In EPP Compatibility Profile this data element MUST be
               provided.

5.7.  Postal Info Object

   *  Name: Postal Info Object
   *  Description: Contains postal-address information in either
      internationalised or localised forms.
   *  Data Elements:





Kowalik & Wullink         Expires 23 April 2026                [Page 14]

Internet-Draft              RPP Data Objects                October 2025


      |  TBC: Contact Type is not localised (shall be the same for
      |  PERSON and ORG).  Moving it level up would however detach it
      |  from related/dependant fields Name/Organisation

   *  Contact Type
      -  Identifier: type
      -  Cardinality: 0-1
      -  Mutability: read-write
      -  Data Type: String
      -  Description: Specifies whether the contact is and individual or
         an organisation.
      -  Constraints: The value MUST be one of: "PERSON" (individual) or
         "ORG" (organisation).
   *  Name
      -  Identifier: name
      -  Cardinality: 0-1
      -  Mutability: read-write
      -  Data Type: String
      -  Description: The name of the individual or role.
      -  Constraints:
         o  Implementations MAY limit the maximum length of entries or
            character set.
         o  In EPP Compatibility Profile this data element MUST be
            provided.
         o  The implementations MAY require this field if Contact Type
            (type) is set to "PERSON".
   *  Organisation
      -  Identifier: org
      -  Cardinality: 0-1
      -  Mutability: read-write
      -  Data Type: String
      -  Description: The name of the organisation.
      -  Constraints:
         o  Implementations MAY limit the maximum length of entries or
            character set.
         o  The implementations MAY require this field if Contact Type
            (type) is set to "ORG".
   *  Address
      -  Identifier: addr
      -  Cardinality: 0-1
      -  Mutability: read-write
      -  Data Type: Postal Address Object
      -  Description: The detailed postal address.
      -  Constraints: In EPP Compatibility Profile this data element
         MUST be provided.






Kowalik & Wullink         Expires 23 April 2026                [Page 15]

Internet-Draft              RPP Data Objects                October 2025


5.8.  Disclose Object

      |  TODO: Model Disclose in universal (extendible) way

   *  Name: Disclose
   *  Identifier: disclose
   *  Description: TBD

6.  Domain Name Data Object

6.1.  Object Description

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

6.2.  Data Elements

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

   *  Name

      -  Identifier: name
      -  Cardinality: 1
      -  Mutability: create-only
      -  Data Type: String
      -  Description: The fully qualified name of the domain object.
      -  Constraints:
         o  The value MUST be a fully qualified domain name that
            conforms to the syntax described in [RFC1035].
         o  A server MAY restrict allowable domain names to a particular
            top-level domain, second-level domain, or other domain for
            which the server is authoritative.
         o  The trailing dot required when these names are stored in a
            DNS zone is implicit and MUST NOT be provided when
            exchanging host and domain names.

   *  Repository ID

      -  Identifier: repositoryId
      -  Cardinality: 0-1
      -  Mutability: read-only
      -  Data Type: Identifier





Kowalik & Wullink         Expires 23 April 2026                [Page 16]

Internet-Draft              RPP Data Objects                October 2025


      -  Description: A server-assigned unique identifier for the
         object.  In EPP Compatibility Profile this data element MUST be
         provided.
      -  Constraints: (None)

   *  Status

      -  Identifier: status
      -  Cardinality: 0+
      -  Mutability: read-only
      -  Data Type: Status Object
      -  Description: The current status descriptors associated with the
         domain.
      -  Constraints: Possible combinations of Status Object Labels is
         specified in Section 2.3 of [RFC5731] and [RFC3915]

      |  TBC: IANA registry for statuses?

   *  Registrant
      -  Identifier: registrant
      -  Cardinality: 0-1
      -  Mutability: read-write
      -  Data Type: Contact Object.
      -  Description: The contact object associated with the domain as
         the registrant.
      -  Constraints:
         o  The relation MUST correspond to a valid Contact Data Object
            known to the server.
         o  Servers MAY restrict association of a Contact Object of a
            different sponsoring client.

      |  TBC: leave registrant here or move it to contacts with a type?

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



Kowalik & Wullink         Expires 23 April 2026                [Page 17]

Internet-Draft              RPP Data Objects                October 2025


      |  TBC: IANA registry for contact role label?

   *  Nameservers

      -  Identifier: nameservers
      -  Cardinality: 0+
      -  Mutability: read-write
      -  Data Type: Composition[Host Data Object] or Aggregation[Host
         Data Object]
      -  Description: A collection of nameservers associated with the
         domain.
      -  Constraints: (None)

   *  DNS

      -  Identifier: dns
      -  Cardinality: 0+
      -  Mutability: read-write
      -  Data Type: Composition[DNS Resource Record]
      -  Description: A collection of DNS entries related to the domain
         name.
      -  Constraints:
         o  The Type of the entries MAY be constrained by the server
            policy.  Typically the values would be limited to allowed
            parent side resource record types.
         o  In EPP Compatibility Profide with DNSSEC Extension allowed
            values MUST be DS and DNSKEY.
         o  The labels of DNS entries MUST be subordinate to the domain
            name and MUST NOT be below zone cut in case of present
            delegation.

   *  Subordinate Hosts

      -  Identifier: subordinateHosts
      -  Cardinality: 0+
      -  Mutability: read-only
      -  Data Type: Aggregation[Host Object]
      -  Description: A collection of subordinate host objects that
         exist under this domain.
      -  Constraints: (None)

   *  Sponsoring Client ID

      -  Identifier: sponsoringClientId
      -  Cardinality: 1
      -  Mutability: read-only
      -  Data Type: Client Identifier.




Kowalik & Wullink         Expires 23 April 2026                [Page 18]

Internet-Draft              RPP Data Objects                October 2025


      -  Description: The identifier of the client that is the current
         sponsor of the domain object.
      -  Constraints: (None)

   *  Creating Client ID

      -  Identifier: creatingClientId
      -  Cardinality: 0-1
      -  Mutability: read-only
      -  Data Type: Client Identifier.
      -  Description: The identifier of the client that created the
         domain object.
      -  Constraints: (None)

   *  Creation Date

      -  Identifier: creationDate
      -  Cardinality: 0-1
      -  Mutability: read-only
      -  Data Type: Timestamp.
      -  Description: The date and time of domain object creation.
      -  Constraints: The value is set by the server and cannot be
         specified by the client.

   *  Updating Client ID

      -  Identifier: updatingClientId
      -  Cardinality: 0-1
      -  Mutability: read-only
      -  Data Type: Client Identifier.
      -  Description: The identifier of the client that last updated the
         domain object.
      -  Constraints: This element MUST NOT be present if the domain has
         never been modified.

   *  Update Date

      -  Identifier: updateDate
      -  Cardinality: 0-1
      -  Mutability: read-only
      -  Data Type: Timestamp.
      -  Description: The date and time of the most recent domain object
         modification.
      -  Constraints: This element MUST NOT be present if the domain
         object has never been modified.

   *  Expiry Date




Kowalik & Wullink         Expires 23 April 2026                [Page 19]

Internet-Draft              RPP Data Objects                October 2025


      -  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.

   *  Transfer Date

      -  Identifier: transferDate
      -  Cardinality: 0-1
      -  Mutability: read-only
      -  Data Type: Timestamp
      -  Description: The date and time of the most recent successful
         domain object transfer.
      -  Constraints: This element MUST NOT be provided if the domain
         object has never been transferred.

   *  Authorisation Information

      -  Identifier: authInfo
      -  Cardinality: 0-1
      -  Mutability: read-write
      -  Data Type: Authorisation Information Object
      -  Description: Authorisation information associated with the
         domain object.
      -  Constraints: (None)

6.3.  Operations

6.3.1.  Create Operation

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

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

   In addition, the following transient data element is defined for this
   operation:

   *  Registration Period



Kowalik & Wullink         Expires 23 April 2026                [Page 20]

Internet-Draft              RPP Data Objects                October 2025


      -  Identifier: period
      -  Cardinality: 0-1
      -  Data Type: Period Object.
      -  Description: The initial registration period for the domain
         name.  This value is used by the server to calculate the
         initial expiryDate of the object.  This element is not
         persisted as part of the object's state.

6.3.2.  Read Operation

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

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

   The following transient data elements are defined for this operation:

   *  Hosts Filter
      -  Identifier: hostsFilter
      -  Cardinality: 0-1
      -  Data Type: String
      -  Description: Controls which host information is returned with
         the object.
      -  Constraints: The value MUST be one of "all", "del" (delegated),
         "sub" (subordinate), or "none".  The default value is "all".

6.3.3.  Delete Operation

   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.



Kowalik & Wullink         Expires 23 April 2026                [Page 21]

Internet-Draft              RPP Data Objects                October 2025


   The error response SHOULD indicate the related subordinate host
   objects.

6.3.4.  Renew Operation

   The Renew operation allows a client to extend the validity period of
   an existing Domain Name resource.  The operation targets a specific
   data object identified by its name.

   *  Authorisation:
      -  Only sponsoring client is authorised to perform this operation
   *  Input: Domain Name
   *  Output: Full object representation (read-write and read-only
      properties), or a minimum representation of properties affected by
      the operation (Expiry Date).

   The following transient data elements are defined for this operation:

   *  Current Expiry Date

      -  Identifier: currentExpiryDate
      -  Cardinality: 1
      -  Data Type: Timestamp
      -  Description: The current expiry date of the domain name.  The
         server MUST validate this against the object's current
         expiryDate to prevent unintended duplicate renewals.

   *  Renewal Period

      -  Identifier: renewalPeriod
      -  Cardinality: 0-1
      -  Data Type: Period Object
      -  Description: The duration to be added to the object's
         registration period.  This value is used by the server to
         calculate the new expiryDate.  The default value MAY be defined
         by server policy.  The number of units available MAY be subject
         to limits imposed by the server.

6.3.5.  Transfer operation

      |  TODO: define transfer operation

7.  Contact Data Object

7.1.  Object Description

   *  Name: Contact Data Object
   *  Identifier: contact



Kowalik & Wullink         Expires 23 April 2026                [Page 22]

Internet-Draft              RPP Data Objects                October 2025


   *  Description: A Contact Data Object represents the social
      information for an individual or organisation associated with
      other objects.

7.2.  Data Elements

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

   *  Handle ID

      -  Identifier: id
      -  Cardinality: 1
      -  Mutability: create-only
      -  Data Type: Identifier.
      -  Description: External unique identifier of the contact object.
      -  Constraints:
         o  This value MUST be supported to be provided by the client.
         o  Servers MAY support server-side generation of this value.

   *  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.

   *  Postal Information

      -  Identifier: postalInfo
      -  Cardinality: 1-2
      -  Mutability: read-write
      -  Data Type: AggregationDictionary[Postal Info Object]
         o  Label Description: type of contact data localisation
         o  Label Constraints: Allowed values: "int" for
            "internationalised" all-ASCII version of an address and
            "loc" for localised forms with possible non-ASCII character
            sets.
      -  Description: Contains postal-address information.
      -  Constraints: There MUST be no more that 1 element of type "int"
         and one element of type "loc".

   *  Voice Phone Number




Kowalik & Wullink         Expires 23 April 2026                [Page 23]

Internet-Draft              RPP Data Objects                October 2025


      -  Identifier: voice
      -  Cardinality: 0+
      -  Mutability: read-write
      -  Data Type: Phone Number
      -  Description: Voice phone number associated with the contact
      -  Constraints: (None)

   *  Fax Phone Number

      -  Identifier: fax
      -  Cardinality: 0+
      -  Mutability: read-write
      -  Data Type: Phone Number
      -  Description: Fax number associated with the contact
      -  Constraints: (None)

   *  E-mail

      -  Identifier: email
      -  Cardinality: 0+
      -  Mutability: read-write
      -  Data Type: String.
      -  Description: The contact's email address.
      -  Constraints: Email address syntax is defined in [RFC5322].

   *  Status

      -  Identifier: status

      -  Cardinality: 0+

      -  Mutability: read-only

      -  Data Type: Status Object

      -  Description: The current status descriptors associated with the
         contact.

      -  Constraints:

         o  Description: The current status descriptors associated with
            the contact.

         o  Constraints: Possible combinations of Domain Status Labels
            is specified in Section 2.2 of [RFC5733]

         o  The value MUST be one of the status tokens defined in the
            IANA registry for domain statuses.



Kowalik & Wullink         Expires 23 April 2026                [Page 24]

Internet-Draft              RPP Data Objects                October 2025


         o  The initial value list MAY be as defined in [RFC5733].  In
            this case the values MUST have the same semantics.

   *  Sponsoring Client ID

      -  Identifier: sponsoringClientId
      -  Cardinality: 1
      -  Mutability: read-only
      -  Data Type: Client Identifier.
      -  Description: The identifier of the client that is the current
         sponsor of the domain object.
      -  Constraints: (None)

   *  Creating Client ID

      -  Identifier: creatingClientId
      -  Cardinality: 0-1
      -  Mutability: read-only
      -  Data Type: Client Identifier.
      -  Description: The identifier of the client that created the
         contact object.
      -  Constraints: (None)

   *  Creation Date

      -  Identifier: creationDate
      -  Cardinality: 0-1
      -  Mutability: read-only
      -  Data Type: Timestamp.
      -  Description: The date and time of contact object creation.
      -  Constraints: The value is set by the server and cannot be
         specified by the client.

   *  Updating Client ID

      -  Identifier: updatingClientId
      -  Cardinality: 0-1
      -  Mutability: read-only
      -  Data Type: Client Identifier.
      -  Description: The identifier of the client that last updated the
         contact object.
      -  Constraints: This element MUST NOT be present if the contact
         has never been modified.

   *  Update Date

      -  Identifier: updateDate
      -  Cardinality: 0-1



Kowalik & Wullink         Expires 23 April 2026                [Page 25]

Internet-Draft              RPP Data Objects                October 2025


      -  Mutability: read-only
      -  Data Type: Timestamp.
      -  Description: The date and time of the most recent contact
         object modification.
      -  Constraints: This element MUST NOT be present if the contact
         object has never been modified.

   *  Transfer Date

      -  Identifier: transferDate
      -  Cardinality: 0-1
      -  Mutability: read-only
      -  Data Type: Timestamp.
      -  Description: The date and time of the most recent successful
         contact object transfer.
      -  Constraints: This element MUST NOT be provided if the contact
         object has never been transferred.

   *  Authorisation Information

      -  Identifier: authInfo
      -  Cardinality: 0-1
      -  Mutability: read-write
      -  Data Type: Authorisation Information
      -  Description: Authorisation information associated with the
         contact object.
      -  Constraints: (None)

   *  Disclose

      -  Identifier: disclose
      -  Cardinality: 0-1
      -  Mutability: read-write
      -  Data Type: Disclose Object.
      -  Description: Identifies elements that require exceptional
         server-operator handling to allow or restrict disclosure to
         third parties.

      |  TBC: IANA registry for statuses?

7.3.  Operations

      |  TODO: Describe operations for contacts

8.  Host Data Object






Kowalik & Wullink         Expires 23 April 2026                [Page 26]

Internet-Draft              RPP Data Objects                October 2025


8.1.  Object Description

   A Host Data Object represents a name server that provides DNS
   services for a a domain name.

8.2.  Data Elements

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

      |  TBC: hostName/dns properties are identical to Nameserver
      |  Object.  Shall we define something like "Extends"?

   *  Host Name

      -  Identifier: hostName
      -  Cardinality: 1
      -  Mutability: read-write
      -  Data Type: String
      -  Description: Fully qualified name of a host.
      -  Constraints: The value MUST be a syntactically valid host name.

   *  DNS Resource Records

      -  Identifier: dns
      -  Cardinality: 0+
      -  Mutability: read-write
      -  Data Type: Composition[DNS Resource Record]
      -  Description: DNS Resource Records related to the host.
      -  Constraints:
         o  The labels of DNS entries MUST be subordinate to the Host
            Name of the Nameserver.
         o  In EPP Compatibility Profile the entries MUST be limited to
            A and AAAA entries for IPv4 and IPv6 glue records
            respectively.

   *  Status

      -  Identifier: status
      -  Cardinality: 0+
      -  Mutability: read-only
      -  Data Type: Status Object
      -  Description: The current status descriptors associated with the
         domain.
      -  Constraints: Possible combinations of Domain Status Labels is
         specified in Section 2.3 of [RFC5732]






Kowalik & Wullink         Expires 23 April 2026                [Page 27]

Internet-Draft              RPP Data Objects                October 2025


      |  TBD: this block
      |  repositoryId/sponsoringClientId/creationDate/updatingClientId/
      |  updateDate/transferDate is the same as for Domain Name.  Shall
      |  it be abstracted to a new component object like "Provisioning
      |  Metadata"?

   *  Repository ID

      -  Identifier: repositoryId
      -  Cardinality: 0-1
      -  Mutability: read-only
      -  Data Type: Identifier
      -  Description: A server-assigned unique identifier for the
         object.  For EPP compatibility this data element is obligatory.
      -  Constraints: (None)

   *  Sponsoring Client ID

      -  Identifier: sponsoringClientId
      -  Cardinality: 1
      -  Mutability: read-only
      -  Data Type: Client Identifier.
      -  Description: The identifier of the client that is the current
         sponsor of the host object.
      -  Constraints: (None)

   *  Creating Client ID

      -  Identifier: creatingClientId
      -  Cardinality: 0-1
      -  Mutability: read-only
      -  Data Type: Client Identifier.
      -  Description: The identifier of the client that created the host
         object.
      -  Constraints: (None)

   *  Creation Date

      -  Identifier: creationDate
      -  Cardinality: 0-1
      -  Mutability: read-only
      -  Data Type: Timestamp.
      -  Description: The date and time of host object creation.
      -  Constraints: The value is set by the server and cannot be
         specified by the client.

   *  Updating Client ID




Kowalik & Wullink         Expires 23 April 2026                [Page 28]

Internet-Draft              RPP Data Objects                October 2025


      -  Identifier: updatingClientId
      -  Cardinality: 0-1
      -  Mutability: read-only
      -  Data Type: Client Identifier.
      -  Description: The identifier of the client that last updated the
         host object.
      -  Constraints: This element MUST NOT be present if the domain has
         never been modified.

   *  Update Date

      -  Identifier: updateDate
      -  Cardinality: 0-1
      -  Mutability: read-only
      -  Data Type: Timestamp.
      -  Description: The date and time of the most recent host object
         modification.
      -  Constraints: This element MUST NOT be present if the host
         object has never been modified.

   *  Transfer Date

      -  Identifier: transferDate
      -  Cardinality: 0-1
      -  Mutability: read-only
      -  Data Type: Timestamp
      -  Description: The date and time of the most recent successful
         host object transfer.
      -  Constraints: This element MUST NOT be provided if the host
         object has never been transferred.

8.3.  Operations

      |  TODO: Describe operations for hosts

9.  IANA Considerations

9.1.  RPP Data Object Registry

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

9.1.1.  Registration Policy

   The policy for adding new objects, data elements, or operations to
   this registry is "Specification Required" [RFC8126].



Kowalik & Wullink         Expires 23 April 2026                [Page 29]

Internet-Draft              RPP Data Objects                October 2025


9.1.2.  Registry Structure

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

   *  A header containing the Object Identifier, Object Name, Object
      Type (Resource or Component), a brief description, and a reference
      to its defining specification.

   *  A "Data Elements" table listing all persisted data elements
      associated with the object.  Each entry MUST specify the element's
      Identifier, Name, Cardinality, Mutability, Data Type, and
      description.

   *  If applicable, an "Operations" section.  For each operation, the
      registry MUST provide:

      -  The Operation's Name and a description.
      -  A "Parameters" table listing all data elements that are
         provided as input to the operation but are not persisted as
         part of the object's state.  Each entry MUST specify the
         parameter's Identifier, Name, Cardinality, Data Type, and a
         description.

9.1.3.  Initial Registrations

   The initial contents of the RPP Data Object Registry are defined
   below.

   Object: period

   Object Name: Period Object

   Object Type: Component

   Description: Represents a duration of time.

   Reference: [This-ID]

   Data Elements











Kowalik & Wullink         Expires 23 April 2026                [Page 30]

Internet-Draft              RPP Data Objects                October 2025


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

                                  Table 1

   Object: nameserver

   Object Name: Nameserver Object

   Object Type: Component

   Description: Represents a single nameserver.

   Reference: [This-ID]

   Data Elements

   +==========+========+=====+==========+=================+============+
   |Element   |Element |Card.|Mutability| Data Type       |Description |
   |Identifier|Name    |     |          |                 |            |
   +==========+========+=====+==========+=================+============+
   |hostName  |Host    |1    |read-write| String          |The name of |
   |          |Name    |     |          |                 |the host.   |
   +----------+--------+-----+----------+-----------------+------------+
   |dns       |DNS     |0+   |read-write| Composition[DNS |DNS         |
   |          |Resource|     |          | Resource        |Resource    |
   |          |Records |     |          | Record]         |Records     |
   |          |        |     |          |                 |related to  |
   |          |        |     |          |                 |the host.   |
   +----------+--------+-----+----------+-----------------+------------+

                                  Table 2

   Object: dnsrr

   Object Name: DNS Resource Record

   Object Type: Component




Kowalik & Wullink         Expires 23 April 2026                [Page 31]

Internet-Draft              RPP Data Objects                October 2025


   Description: Represents a DNS Entry.

   Reference: [This-ID]

   Data Elements

   +===============+=========+=====+============+======+===============+
   | Element       | Element |Card.| Mutability |Data  | Description   |
   | Identifier    | Name    |     |            |Type  |               |
   +===============+=========+=====+============+======+===============+
   | hostNamelabel | Label   |1    | read-write |String| DNS entry     |
   |               |         |     |            |      | label.        |
   +---------------+---------+-----+------------+------+---------------+
   | type          | Type    |1    | read-write |String| DNS entry     |
   |               |         |     |            |      | type.         |
   +---------------+---------+-----+------------+------+---------------+
   | data          | Data    |1    | read-write |String| DNS entry     |
   |               |         |     |            |      | value.        |
   +---------------+---------+-----+------------+------+---------------+
   | ttl           | TTL     |1    | read-write |Number| TTL value     |
   |               |         |     |            |      | for a         |
   |               |         |     |            |      | reource       |
   |               |         |     |            |      | record.       |
   +---------------+---------+-----+------------+------+---------------+

                                  Table 3

   Object: authInfo

   Object Name: Authorisation Information

   Object Type: Component

   Description: Contains authorisation credentials for an operation.

   Reference: [This-ID]

   Data Elements













Kowalik & Wullink         Expires 23 April 2026                [Page 32]

Internet-Draft              RPP Data Objects                October 2025


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

                                  Table 4

   Object: domainStatus

   Object Name: Status Object

   Object Type: Component

   Description: Represents one of the status values associated with the
   provisioning object.

   Reference: [This-ID]

   Data Elements








Kowalik & Wullink         Expires 23 April 2026                [Page 33]

Internet-Draft              RPP Data Objects                October 2025


   +==========+=======+=====+===========+=========+===================+
   |Element   |Element|Card.|Mutability |Data Type| Description       |
   |Identifier|Name   |     |           |         |                   |
   +==========+=======+=====+===========+=========+===================+
   |label     |Label  |1    |create-only|String   | machine-reasible  |
   |          |       |     |           |         | 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 expresse       |
   |          |       |     |           |         | lifecycle related |
   |          |       |     |           |         | information       |
   +----------+-------+-----+-----------+---------+-------------------+

                                 Table 5

      |  TODO: IANA table: Postal Address Object TODO: IANA table:
      |  Postal Info Object TODO: IANA table: Disclose Object

   Object: domainName

   Object Name: Domain Name Data Object

   Object Type: Resource

   Description: Represents a domain name and its associated data.

   Reference: [This-ID]

   Data Elements







Kowalik & Wullink         Expires 23 April 2026                [Page 34]

Internet-Draft              RPP Data Objects                October 2025


   +==================+=============+=====+==========+===================+=============+
   |Identifier        |Name         |Card.|Mutability|Data Type          |Description  |
   +==================+=============+=====+==========+===================+=============+
   |name              |Name         |1    |create-   |String             |The fully    |
   |                  |             |     |only      |                   |qualified    |
   |                  |             |     |          |                   |name of the  |
   |                  |             |     |          |                   |domain       |
   |                  |             |     |          |                   |object.      |
   +------------------+-------------+-----+----------+-------------------+-------------+
   |repositoryId      |Repository ID|0-1  |read-only |Identifier         |A server-    |
   |                  |             |     |          |                   |assigned     |
   |                  |             |     |          |                   |unique       |
   |                  |             |     |          |                   |identifier   |
   |                  |             |     |          |                   |for the      |
   |                  |             |     |          |                   |object.      |
   +------------------+-------------+-----+----------+-------------------+-------------+
   |status            |Status       |0+   |read-only |Status Object      |The current  |
   |                  |             |     |          |                   |status       |
   |                  |             |     |          |                   |descriptors  |
   |                  |             |     |          |                   |for the      |
   |                  |             |     |          |                   |domain.      |
   +------------------+-------------+-----+----------+-------------------+-------------+
   |registrant        |Registrant   |0-1  |read-write|Contact Object     |The          |
   |                  |             |     |          |                   |registrant   |
   |                  |             |     |          |                   |contact ID.  |
   +------------------+-------------+-----+----------+-------------------+-------------+
   |contacts          |Contacts     |0+   |read-write|LabelledAggregation|Associated   |
   |                  |             |     |          |[Contact Object]   |contact      |
   |                  |             |     |          |                   |objects.     |
   +------------------+-------------+-----+----------+-------------------+-------------+
   |nameservers       |Nameservers  |0+   |read-write|Composition[Host   |A collection |
   |                  |             |     |          |Data Object] or    |of           |
   |                  |             |     |          |Aggregation[Host   |nameservers  |
   |                  |             |     |          |Data Object]       |associated   |
   |                  |             |     |          |                   |with the     |
   |                  |             |     |          |                   |domain.      |
   +------------------+-------------+-----+----------+-------------------+-------------+
   |dns               |DNS          |0+   |read-write|Composition[DNS    |A collection |
   |                  |             |     |          |Resource Record]   |of DNS       |
   |                  |             |     |          |                   |entries      |
   |                  |             |     |          |                   |related to   |
   |                  |             |     |          |                   |the domain   |
   |                  |             |     |          |                   |name.        |
   +------------------+-------------+-----+----------+-------------------+-------------+
   |subordinateHosts  |Subordinate  |0+   |read-only |Aggregation [Host  |Subordinate  |
   |                  |Hosts        |     |          |Object]            |host names.  |
   +------------------+-------------+-----+----------+-------------------+-------------+
   |sponsoringClientId|Sponsoring   |1    |read-only |Client Identifier  |The current  |



Kowalik & Wullink         Expires 23 April 2026                [Page 35]

Internet-Draft              RPP Data Objects                October 2025


   |                  |Client ID    |     |          |                   |sponsoring   |
   |                  |             |     |          |                   |client ID.   |
   +------------------+-------------+-----+----------+-------------------+-------------+
   |creatingClientId  |Creating     |0-1  |read-only |Client Identifier  |The client ID|
   |                  |Client ID    |     |          |                   |that created |
   |                  |             |     |          |                   |the object.  |
   +------------------+-------------+-----+----------+-------------------+-------------+
   |creationDate      |Creation Date|0-1  |read-only |Timestamp          |Creation     |
   |                  |             |     |          |                   |timestamp.   |
   +------------------+-------------+-----+----------+-------------------+-------------+
   |updatingClientId  |Updating     |0-1  |read-only |Client Identifier  |The client ID|
   |                  |Client ID    |     |          |                   |that last    |
   |                  |             |     |          |                   |updated the  |
   |                  |             |     |          |                   |object.      |
   +------------------+-------------+-----+----------+-------------------+-------------+
   |updateDate        |Update Date  |0-1  |read-only |Timestamp          |The timestamp|
   |                  |             |     |          |                   |of the last  |
   |                  |             |     |          |                   |update.      |
   +------------------+-------------+-----+----------+-------------------+-------------+
   |expiryDate        |Expiry Date  |0-1  |read-only |Timestamp          |Expiry       |
   |                  |             |     |          |                   |timestamp.   |
   +------------------+-------------+-----+----------+-------------------+-------------+
   |transferDate      |Transfer Date|0-1  |read-only |Timestamp          |The timestamp|
   |                  |             |     |          |                   |of the last  |
   |                  |             |     |          |                   |successful   |
   |                  |             |     |          |                   |transfer.    |
   +------------------+-------------+-----+----------+-------------------+-------------+
   |authInfo          |Authorisation|0-1  |read-write|authInfo           |Authorisation|
   |                  |Info         |     |          |                   |information  |
   |                  |             |     |          |                   |for the      |
   |                  |             |     |          |                   |object.      |
   +------------------+-------------+-----+----------+-------------------+-------------+

                                  Table 6

   Operations

   Operation: Create

   Description: Provisions a new Domain Name resource.

   Parameters









Kowalik & Wullink         Expires 23 April 2026                [Page 36]

Internet-Draft              RPP Data Objects                October 2025


   +============+==============+=======+========+======================+
   | Identifier | Name         | Card. | Data   | Description          |
   |            |              |       | Type   |                      |
   +============+==============+=======+========+======================+
   | period     | Registration | 0-1   | period | The initial          |
   |            | Period       |       |        | registration         |
   |            |              |       |        | period for the       |
   |            |              |       |        | domain name.         |
   +------------+--------------+-------+--------+----------------------+

                                  Table 7

   Operation: Read

   Description: Retrieves the data elements of a Domain Name resource.

   Parameters

   +===============+===============+=======+==========+================+
   | Identifier    | Name          | Card. | Data     | Description    |
   |               |               |       | Type     |                |
   +===============+===============+=======+==========+================+
   | hostsFilter   | Hosts Filter  | 0-1   | String   | Controls       |
   |               |               |       |          | which host     |
   |               |               |       |          | information    |
   |               |               |       |          | is returned.   |
   +---------------+---------------+-------+----------+----------------+
   | queryAuthInfo | Query         | 0-1   | authInfo | Credentials    |
   |               | Authorisation |       |          | to authorise   |
   |               | Information   |       |          | access to      |
   |               |               |       |          | full object    |
   |               |               |       |          | data.          |
   +---------------+---------------+-------+----------+----------------+

                                  Table 8

   Operation: Delete

   Description: Removes an existing Domain Name resource.

   Parameters: (None)

   Operation: Renew

   Description: Extends the validity period of a Domain Name resource.

   Parameters




Kowalik & Wullink         Expires 23 April 2026                [Page 37]

Internet-Draft              RPP Data Objects                October 2025


   +===================+=========+=======+===========+================+
   | Identifier        | Name    | Card. | Data Type | Description    |
   +===================+=========+=======+===========+================+
   | currentExpiryDate | Current | 1     | Timestamp | The expected   |
   |                   | Expiry  |       |           | current expiry |
   |                   | Date    |       |           | date, for      |
   |                   |         |       |           | validation.    |
   +-------------------+---------+-------+-----------+----------------+
   | renewalPeriod     | Renewal | 0-1   | period    | The duration   |
   |                   | Period  |       |           | to add to the  |
   |                   |         |       |           | registration   |
   |                   |         |       |           | period.        |
   +-------------------+---------+-------+-----------+----------------+

                                 Table 9

      |  TODO: IANA table: Contact Data Object TODO: IANA table: Host
      |  Data Object

   Security Considerations

      |  TODO: write security considerations, if any

10.  Normative References

   [I-D.kowalik-rpp-architecture]
              Kowalik, P. and M. Wullink, "RPP Architecture", Work in
              Progress, Internet-Draft, draft-kowalik-rpp-architecture-
              03, 10 October 2025,
              <https://datatracker.ietf.org/doc/html/draft-kowalik-rpp-
              architecture-03>.

   [ISO3166-1]
              International Organization for Standardization, "Codes for
              the representation of names of countries and their
              subdivisions -- Part 1: Country codes", ISO Standard 3166,
              November 2000.

   [ITU.E164.2005]
              International Telecommunication Union, "The international
              public telecommunication numbering plan", ITU-T
              Recommendation E.164, February 2005.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <https://www.rfc-editor.org/info/rfc1035>.





Kowalik & Wullink         Expires 23 April 2026                [Page 38]

Internet-Draft              RPP Data Objects                October 2025


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3339]  Klyne, G. and C. Newman, "Date and Time on the Internet:
              Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
              <https://www.rfc-editor.org/info/rfc3339>.

   [RFC3915]  Hollenbeck, S., "Domain Registry Grace Period Mapping for
              the Extensible Provisioning Protocol (EPP)", RFC 3915,
              DOI 10.17487/RFC3915, September 2004,
              <https://www.rfc-editor.org/info/rfc3915>.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              DOI 10.17487/RFC5322, October 2008,
              <https://www.rfc-editor.org/info/rfc5322>.

   [RFC5730]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
              STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
              <https://www.rfc-editor.org/info/rfc5730>.

   [RFC5731]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
              Domain Name Mapping", STD 69, RFC 5731,
              DOI 10.17487/RFC5731, August 2009,
              <https://www.rfc-editor.org/info/rfc5731>.

   [RFC5732]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
              Host Mapping", STD 69, RFC 5732, DOI 10.17487/RFC5732,
              August 2009, <https://www.rfc-editor.org/info/rfc5732>.

   [RFC5733]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
              Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733,
              August 2009, <https://www.rfc-editor.org/info/rfc5733>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

Authors' Addresses

   Pawel Kowalik
   DENIC



Kowalik & Wullink         Expires 23 April 2026                [Page 39]

Internet-Draft              RPP Data Objects                October 2025


   Email: pawel.kowalik@denic.de
   URI:   https://denic.de/


   Maarten Wullink
   SIDN Labs
   Email: maarten.wullink@sidn.nl
   URI:   https://sidn.nl/











































Kowalik & Wullink         Expires 23 April 2026                [Page 40]
