



Network Working Group                                         P. Kowalik
Internet-Draft                                                  DENIC eG
Intended status: Informational                                M. Wullink
Expires: 31 December 2025                                      SIDN Labs
                                                            29 June 2025


                            RPP Architecture
                   draft-kowalik-rpp-architecture-02

Abstract

   Advancements in development, integration, deployment environments and
   operational paradigms have led to a desire for an alternative for the
   Extensible Provisioning Protocol (EPP).  This document defines the
   architecture for the RESTful Provisioning Protocol (RPP) an HTTP
   based provisioning protocol leveraging the REST architectural style
   and JSON data-interchange format, aiming to standardize a RESTful
   protocol for provisioning database objects.  The architecture
   includes support for extensibility, allowing for multiple possible
   use cases.  RPP is intended to co-exist with EPP, offering an
   alternative protocol including data model compatibility with EPP core
   objects and the benefits associated with the REST architectural style
   and widely adopted HTTP-based technologies.

Contributing

   When contributing to this document, please use the following GitHub
   project: https://github.com/pawel-kow/RPP-architecture.

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 31 December 2025.





Kowalik & Wullink       Expires 31 December 2025                [Page 1]

Internet-Draft              rpp-architecture                   June 2025


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
   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
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Architectural Overview  . . . . . . . . . . . . . . . . . . .   4
     4.1.  Resource Oriented Architecture  . . . . . . . . . . . . .   6
     4.2.  Architecture Layers . . . . . . . . . . . . . . . . . . .   7
       4.2.1.  HTTP Transport Layer  . . . . . . . . . . . . . . . .   7
       4.2.2.  Data Representation Layer . . . . . . . . . . . . . .   8
       4.2.3.  Resource Definition Layer . . . . . . . . . . . . . .   9
   5.  Protocol Details  . . . . . . . . . . . . . . . . . . . . . .   9
     5.1.  HTTP Transport Layer Details  . . . . . . . . . . . . . .   9
       5.1.1.  Authentication and Authorisation  . . . . . . . . . .   9
       5.1.2.  Resource Addressing . . . . . . . . . . . . . . . . .  11
       5.1.3.  Mapping of basic operations to HTTP uniform interface
               (verbs) . . . . . . . . . . . . . . . . . . . . . . .  12
       5.1.4.  Asynchronous Operation Processing . . . . . . . . . .  13
       5.1.5.  RPP specific status codes and relation to HTTP status
               codes . . . . . . . . . . . . . . . . . . . . . . . .  14
       5.1.6.  Transaction tracing and idempotency . . . . . . . . .  15
       5.1.7.  Caching . . . . . . . . . . . . . . . . . . . . . . .  15
       5.1.8.  Content negotiation for media types . . . . . . . . .  15
       5.1.9.  Protocol Versioning . . . . . . . . . . . . . . . . .  16
       5.1.10. Profiles  . . . . . . . . . . . . . . . . . . . . . .  16
       5.1.11. Prefer Header for Response Verbosity  . . . . . . . .  16
       5.1.12. Language negotiation for textual content  . . . . . .  17
       5.1.13. Prefer Header for Request Validation  . . . . . . . .  17
       5.1.14. Definition of special resources . . . . . . . . . . .  17
       5.1.15. Service discovery mechanisms  . . . . . . . . . . . .  17
     5.2.  Data Representation Layer . . . . . . . . . . . . . . . .  18
       5.2.1.  Data structure  . . . . . . . . . . . . . . . . . . .  18
       5.2.2.  Data format . . . . . . . . . . . . . . . . . . . . .  19
       5.2.3.  Data Validation . . . . . . . . . . . . . . . . . . .  20



Kowalik & Wullink       Expires 31 December 2025                [Page 2]

Internet-Draft              rpp-architecture                   June 2025


       5.2.4.  Media Type definition . . . . . . . . . . . . . . . .  20
     5.3.  Resource Definition Layer . . . . . . . . . . . . . . . .  20
       5.3.1.  Data Elements . . . . . . . . . . . . . . . . . . . .  20
       5.3.2.  Mapping . . . . . . . . . . . . . . . . . . . . . . .  21
       5.3.3.  Operations  . . . . . . . . . . . . . . . . . . . . .  21
     5.4.  Extension mechanisms  . . . . . . . . . . . . . . . . . .  21
       5.4.1.  Name Management and Collision Avoidance . . . . . . .  22
   6.  Change History  . . . . . . . . . . . . . . . . . . . . . . .  23
     6.1.  -01 to -02  . . . . . . . . . . . . . . . . . . . . . . .  23
     6.2.  -00 to -01  . . . . . . . . . . . . . . . . . . . . . . .  24
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  24
     7.1.  Informational References  . . . . . . . . . . . . . . . .  24
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  26

1.  Introduction

   This document outlines the architecture of the RESTful Provisioning
   Protocol (RPP).  RPP aims to provide a modern, standardised, and
   developer-friendly protocol for provisioning and managing objects in
   a shared database or registry, initially focusing on functional
   equivalents of EPP object mappings for domain names [RFC5731], hosts
   [RFC5732], and contacts [RFC5733].  RPP also considers provisioning
   of other objects as a potential use case, aiming for a uniform API
   layer for various registry operations.

   RPP is designed to leverage the benefits of REST (REpresentational
   State Transfer), including statelessness, ease of integration, and
   compatibility with existing web infrastructure and tooling such as
   OpenAPI, API gateways, and web application firewalls.  By adopting
   JSON as the data-interchange format, RPP seeks to align with current
   development practices and the successful deployment patterns observed
   in protocols such as RDAP [RFC9082].  The choice of REST and JSON
   also facilitates direct browser and mobile application integration
   including modern security mechanisms such as OAuth2.0.

   This architecture document serves as a foundation for a series of
   specifications that will collectively define RPP.  It details the
   layered approach, core components, and design considerations for
   building an interoperable and extensible provisioning protocol.  RPP
   is intended to coexist with EPP, offering an alternative for
   implementers seeking a RESTful approach without aiming to replace EPP
   or define migration paths from EPP.  RPP aims for data model
   compatibility with EPP core objects to allow automatic and mechanical
   mapping and conversion, especially for core objects (domain, contact,
   host).






Kowalik & Wullink       Expires 31 December 2025                [Page 3]

Internet-Draft              rpp-architecture                   June 2025


2.  Terminology

   This document uses terminology from RFC5730 [RFC5730] and broadly
   adopts the REST architectural principles as defined in [REST] and
   related RFCs.

   *  *RPP:* RESTful Provisioning Protocol.  The protocol being defined
      by the RPP working group.

   *  *EPP:* Extensible Provisioning Protocol as defined in [RFC5730].

   *  *REST:* Representational State Transfer architectural style
      [REST].

   *  *JSON:* JavaScript Object Notation [RFC8259].

   *  *JWT:* JSON Web Token [RFC7519].

   *  *OpenAPI:* The OpenAPI Specification (OAS) (formerly known as
      Swagger Specification) is an API description format for REST APIs
      [OpenAPI].

   *  *RPP client:* An entity or application that interacts with the RPP
      server to perform provisioning operations, such as creating,
      updating, or deleting resources.

3.  Requirements

   This document is based on the requirements defined by RPP WG in state
   from 7.3.2025 [RPPReq].

   The actual state of the requirements is present on WG Wiki
   https://wiki.ietf.org/en/group/rpp/requirements.

4.  Architectural Overview

   This chapter provides an overview of the RESTful Provisioning
   Protocol (RPP) architecture.  A key design principle is to leverage
   existing web standards and principles, particularly HTTP and REST
   principles.  This allows RPP to delegate functionality and features
   to the well-established infrastructure and semantics of the web,
   focusing its own definitions on the specific domain of object
   provisioning.  Therefore, we assume:

   *  *HTTP and RESTful principles are foundational:* RPP leverages HTTP
      for transport and adheres to RESTful principles for resource
      management.




Kowalik & Wullink       Expires 31 December 2025                [Page 4]

Internet-Draft              rpp-architecture                   June 2025


   *  *Domain-specific logic resides in data representations:* The
      specifics of resource provisioning are encoded within the data
      structures and semantics of the RPP message bodies.

   *  *Layered architecture for modularity:* The architecture is layered
      to promote modularity, separation of concerns, and independent
      evolution of different aspects of the protocol.

   The architecture is divided into three main layers: *HTTP Transport*,
   *Data Representation*, and *Resource Definition*. Each layer defines
   specific aspects of the protocol.  This layered approach allows for
   clear separation of concerns.

   *Data Structure* is a sub-layer of Data Representation and described
   later in this document.  It focuses on the structure of RPP messages.

   Similarly *Data Elements*, their *Mapping* onto Data Structure and
   *Operations* are elements of Resource Definition.  They focus on the
   semantic structure of RPP resources and transformation of those
   resources.































Kowalik & Wullink       Expires 31 December 2025                [Page 5]

Internet-Draft              rpp-architecture                   June 2025


     +---------------------------------------------------------+
     |                      HTTP Transport                     |
     |                                                         |
     | +-----------------------------------------------------+ |
     | |                 Data Representation                 | |
     | |                                                     | |
     | |   +- - - - - - - - - - - - - - - - - - - - - - -+   | |
     | |   |                Data Structure               |<-------+
     | |                                                     | |  |
     | |   | +-----------------------------------------+ |   | |  |
     | |     |           Resource Definition           |     | |  |
     | |   | |                                         | |   | |  |
     | |     | +--------------+       +--------------+ |     | |  |
     | |   | | |              |       |              | | |   | |  |
     | |     | |     Data     |       |   Mapping    | |     | |  |
     | |   | | |   Elements   |------>|              |------------+
     | |     | |              |       |              | |     | |
     | |   | | |              |       |              | | |   | |
     | |     | +--------------+       +--------------+ |     | |
     | |   | |     ^                                   | |   | |
     | |     |     |                                   |     | |
     | |   | |     |      +--------------+             | |   | |
     | |     |     |      |              |             |     | |
     | |   | |     |      |  Operations  |             | |   | |
     | |     |     +------|              |             |     | |
     | |   | |            |              |             | |   | |
     | |     |            +--------------+             |     | |
     | |   | |                                         | |   | |
     | |     +-----------------------------------------+ |   | |
     | |   +- - - - - - - - - - - - - - - - - - - - - - -+   | |
     | +-----------------------------------------------------+ |
     +---------------------------------------------------------+

4.1.  Resource Oriented Architecture

   RPP adopts a Resource Oriented Architecture (ROA), aligning with
   RESTful principles.  This approach defines all manageable entities as
   "resources," identified by unique URLs.  Operations on these
   resources are performed through a uniform interface using the
   standard HTTP methods and their semantics.  This contrasts with RPC-
   style protocols, which often define new and specific operations with
   custom parameters.  ROA promotes a more standardised and
   interoperable approach, leveraging the existing web infrastructure
   and its well-defined semantics.  Key aspects of ROA within RPP
   include:

   *  *Resource Identification:* Each resource is uniquely identifiable
      by a URL.



Kowalik & Wullink       Expires 31 December 2025                [Page 6]

Internet-Draft              rpp-architecture                   June 2025


   *  *Uniform Interface:* HTTP methods (HEAD, GET, POST, PUT, DELETE,
      PATCH) are used to perform operations on resources in a consistent
      manner.

   *  *Operation Singularity* Operations, excluding collection
      retrieval, are defined to target a single resource.  Operations
      intended to affect multiple resources, such as bulk operations (a
      single command applied to multiple resources) or command sets
      (multiple commands on multiple resources), should be modelled
      through dedicated "batch" or "bulk operation" resources.

   *  *Representation:* Resources can be represented in various formats
      (e.g., JSON, XML) through HTTP standard content negotiation.

   *  *Statelessness:* Each request to a resource is treated as
      independent of previous requests.  The server does not maintain
      client state between requests.

   *  *Cacheability:* Responses can be cached to improve performance.

4.2.  Architecture Layers

4.2.1.  HTTP Transport Layer

   This layer defines the transport mechanism for RPP messages,
   utilising HTTP as the underlying protocol.

   It encompasses aspects such as:

   *  *Authentication and Authorisation:* Mechanisms for verifying the
      identity of clients and controlling access to resources.

   *  *Resource Addressing using URLs:* Consistent and meaningful URL
      structures for identifying, accessing resources and enabling
      request routing.

   *  *Mapping of basic operations to HTTP uniform interface (verbs):*
      Mapping CRUD (Create, Read, Update, Delete) operations to POST,
      HEAD/GET, PUT/PATCH, and DELETE respectively.

   *  *Mapping of operations beyond HTTP uniform interface to URLs and
      verbs:* Handling more complex operations through appropriate URL
      structures and HTTP methods.

   *  *Asynchronous Operation Management:* Facilitating the handling of
      operations that are not completed immediately, by defining an
      HTTP-based interaction pattern for status checking and deferred
      result retrieval.



Kowalik & Wullink       Expires 31 December 2025                [Page 7]

Internet-Draft              rpp-architecture                   June 2025


   *  *RPP specific error codes and relation to HTTP error codes:*
      Defining RPP-specific error codes while relating them to standard
      HTTP error codes for consistency.

   *  *Transaction tracing and idempotency:* Mechanisms for tracking
      requests and ensuring idempotent operations where appropriate.

   *  *Caching:* Leveraging HTTP caching mechanisms to improve
      performance.

   *  *Content negotiation for media types:* Supporting multiple data
      representation formats and using content negotiation to select the
      appropriate format.

   *  *Versions and profiles:* Support signalling of versions of RPP
      protocol and other protocol elements as well as defining sets of
      protocol elements and their versions in the form of profiles.

   *  *Language negotiation for textual content:* Supporting multiple
      languages for textual content and using language negotiation to
      select the appropriate language.

   *  *Definition of special resources:* Defining specific resources for
      service discovery, metadata retrieval, etc.

   *  *Service discovery mechanisms:* Mechanisms for clients to discover
      available RPP services.

4.2.2.  Data Representation Layer

   This layer focuses on the data representation of RPP messages.  It
   defines the media type used to carry RPP data and supports various
   data representation formats.

   It encompasses aspects such as:

   *  *Data structure:* Defining the structure and schema of the RPP
      data, potentially using a specific schema language.

   *  *Data format:* Defining the specific format used to represent RPP
      data within the representation (e.g., JSON, XML or JWT).

   *  *Media Type definition:* Defining the specific media type to be
      used in RPP, including any constraints on the data format and
      structure






Kowalik & Wullink       Expires 31 December 2025                [Page 8]

Internet-Draft              rpp-architecture                   June 2025


4.2.3.  Resource Definition Layer

   This layer defines the structure and operations for each resource
   type, independent of media type or representation.  It ensures
   resources are well-defined and allows for easy extensibility and
   compatibility with different media types.

   It encompasses aspects such as:

   *  *Data elements:* Defining the individual data elements that make
      up a resource, including their data types, formats, and any
      constraints.

   *  *Resource type definitions:* Defining the structure of specific
      resource types by combining data elements.

   *  *IANA registry definitions:* Potentially registering resource
      definitions with IANA for standardised and automated processing.

   *  *Mapping of data elements to media types:* Defining how the data
      elements of a resource type are represented in different media
      types (e.g., JSON, XML).

   *  *Extension mechanisms:* Providing mechanisms for creating new
      resource types and for extending existing resource types with new
      data elements or operations including potentially new response
      status codes.

5.  Protocol Details

   This section provides further details on each layer of the RPP
   architecture.

5.1.  HTTP Transport Layer Details

   The RPP architecture uses the best practices described in [RFC9205]
   for the HTTP transport layer.

5.1.1.  Authentication and Authorisation

   RPP is aimed to leverage scalable and modern authorisation standards,
   with a focus on OAuth 2.0 [RFC6749] and related frameworks, however
   it should also support other authentication schemes defined for HTTP,
   an example would be HTTP Basic Authentication which might be required
   for compatibility with existing EPP systems.  RPP should be able to
   support future authentication and authorisation standards defined for
   HTTP.




Kowalik & Wullink       Expires 31 December 2025                [Page 9]

Internet-Draft              rpp-architecture                   June 2025


   Specifications will define profiles for:

   *  HTTP Authentication schemes (e.g., HTTP Basic Authentication,
      Bearer Token [RFC6750] etc.)

   *  Authorisation frameworks (e.g., OAuth 2.0 [RFC6749])

   Implementations will be able to choose authentication and
   authorisation methods appropriate for their security requirements.

5.1.1.1.  Authorisation Scopes

   RPP specifications will standardise authorisation scopes (like
   rpp:read or rpp:write) to define granular access control for
   different usage scenarios.  These scopes will be defined for various
   operations and resource types, ensuring that clients can be granted
   only the necessary permissions.

5.1.1.2.  Fine-Grained Authorisation

   RPP authorisation models may become fine-grained, extending beyond
   simple auth-code based models used in EPP.  Authorisation decisions
   will be able to consider the specific operation being performed
   (e.g., update vs. read), the resource being accessed (e.g., a
   specific domain name), and potentially even attributes within the
   resource.

   Here solutions like OAuth2 RAR [RFC9396] could be considered to
   provide fine-grained access control.

5.1.1.3.  Relationship between clients and authentication credentials

   RPP authentication and authorisation model will make a clear
   distinction between the login credentials and the authorisation to
   act in context of a given RPP client.  More than one credential might
   be authorised to act on behalf of the same RPP client.  The same
   credential however must always be assigned to one and only one RPP
   client context.













Kowalik & Wullink       Expires 31 December 2025               [Page 10]

Internet-Draft              rpp-architecture                   June 2025


   In case of HTTP Basic Authentication, one user-id is always bound to
   at most one RPP client.  For OAuth, the issued token is bound to the
   context of at most one RPP client, even though the OAuth client
   itself might have access to multiple RPP clients.  The assignment of
   tokens to specific RPP clients can be controlled through the
   authorisation flow using the OAuth scope parameter.  For example, if
   an OAuth client has access to two RPP clients (Client A and Client
   B), the scope parameter can specify which client the token applies
   to.  A scope value like scope=rpp:clientA would ensure the token is
   valid only for Client A, while scope=rpp:clientB would apply to
   Client B.

5.1.1.4.  Security

   RPP will not explicitly define security related policies related to
   authentication or authorisation (such as password complexity, token
   lifetime or cryptography used) on the protocol level.  Instead, these
   properties will be delegated to the best practices of the chosen
   authentication schemes, which may evolve over time and would have to
   be independent of the protocol itself.

5.1.1.5.  Object level authorisation

   RPP will define a mechanism for object-level authorisation,
   preventing unauthorised access to specific objects or resources.
   Each object will have an associated sponsor or owner with full
   control over an object, and the protocol will allow for the
   specification of which clients are authorised to access or modify
   non-sponsored/owned objects.  This could be achieved through state-
   of-the-art standards like OAuth authorisation tokens, scopes, and
   resource-specific permissions but also shared secrets for backward
   compatibility with EPP password-based authorisation information.

5.1.2.  Resource Addressing

   RPP resources are addressed using URLs.  Considerations include:

   *  Hierarchical URL structure to represent resources of different
      types (e.g., /domains/{domain-name}, /contacts/{contact-id}).

   *  URL structure to represent list of related resources (e.g.,
      /domains/{domain-name}/contacts/)

   RPP URL structure will be designed to be human-readable, intuitive,
   and RESTful, allowing clients to easily navigate and interact with
   resources.





Kowalik & Wullink       Expires 31 December 2025               [Page 11]

Internet-Draft              rpp-architecture                   June 2025


   RPP would not require all URLs to be hard wired to server's RPP root
   URL.  Instead, it would allow for relative URLs to be defined and
   discovered by the client.  This would allow servers to distribute
   resources across multiple servers and URLs and allow for easier
   scaling as described in [RFC9205].  At the same time the URLs shall
   be deterministic for the duration of the client session in order to
   minimise round trips and streamline the interaction.

   As a matter of extensibility consideration RPP should allow for
   additional path segments to be added to the URLs and be discoverable
   by clients.

   RPP responses will include URLs for related resources, allowing
   clients to navigate newly created resources easily.  This is similar
   to the "links" concept in RESTful APIs, where related resources are
   linked together.

5.1.2.1.  Internationalised Domain Names (IDN)

   RPP will address the handling of Internationalised Domain Names
   (IDNs) in resource addressing.  Specifications will define whether to
   use IDN or UTF-8 encoding directly in URLs and whether to employ
   redirects to canonical URLs or "see-also" linking for alternative
   representations.  For example, a "see-also" link could point from a
   UTF-8 encoded URL to an IDN URL and vice versa, allowing clients to
   use either URL.  Another way would be to always redirect to the
   canonical URL, which would be the IDN URL.

5.1.3.  Mapping of basic operations to HTTP uniform interface (verbs)

   RPP operations are mapped to standard HTTP methods to leverage the
   uniform interface and RESTful principles:

   *  *HEAD:* Retrieve resource state (e.g., retrieving domain existence
      information).  This may be a candidate for equivalence of EPP
      check command, however it may come with a few caveats to consider:

      -  EPP check is intended to check whether domain registration is
         possible.  This is not semantically the same as resource state.
         Overloading HEAD with EPP semantics may lead to confusion,
         especially as some frameworks implicitly implement HEAD out of
         GET handling.

      -  a better equivalence of EPP check would be a POST with Expect
         header

   *  *GET:* Retrieve resource state (e.g., retrieving domain or contact
      information) - EPP info command



Kowalik & Wullink       Expires 31 December 2025               [Page 12]

Internet-Draft              rpp-architecture                   June 2025


   *  *POST:* Create a new resource (e.g., registering a domain or
      create contact object) - EPP create command

   *  *PUT:* Update an existing resource in its entirety (e.g., updating
      domain registration details) - not 100% equivalent of EPP update
      command

   *  *DELETE:* Delete a resource (e.g., deleting a domain registration)
      - EPP delete command

   *  *PATCH:* Partially modify a resource (e.g., updating specific
      attributes of a domain or contact) - EPP update command

   EPP transfer commands (query and transform), being in fact a
   representation of a running process, may be modelled by a subresource
   /transfer of the resource being transferred, with a PUT operation to
   initiate the transfer, GET operation to query the transfer status and
   POST operation to approve or reject the transfer.  The same approach
   may apply when adding any other process to the resource, like domain
   restore.

   EPP check command may be modelled either as a GET operation with a
   dedicated media type, a POST operation with Expect header or a HEAD
   verb - depending on the specific requirements of the check operation.

   Other transform operations like renew, or restore which are not
   addressable resources in terms of REST may be either also modelled as
   POST requests with a dedicated media type, or be a convention of URLs
   with processing resources with only POST interface starting with
   underscore, e.g. /domains/{domain-name}/_renew.

   This basic set of rules and guidelines will be further refined in the
   RPP specifications and give a universal toolset for extending RPP
   with new resources and commands.

5.1.4.  Asynchronous Operation Processing

   The RPP architecture accommodates operations that are potentially
   long-running or cannot be completed synchronously due to their nature
   (e.g., acting on multiple objects, resource-intensive tasks, or
   processes involving manual steps).  This is achieved by leveraging
   standard HTTP mechanisms to provide an asynchronous interaction
   pattern.  This pattern allows a client to initiate an operation and
   receive an immediate acknowledgement, with the means to check the
   operation's status and retrieve its outcome at a later point.






Kowalik & Wullink       Expires 31 December 2025               [Page 13]

Internet-Draft              rpp-architecture                   June 2025


   The typical interaction flow facilitated by the architecture is as
   follows: 1.  A client initiates an operation via an HTTP request. 2.
   For operations processed asynchronously, the server typically
   responds immediately with an appropriate HTTP status code and an
   indication of a status resource where the client would be able to
   obtain result of the operation.  The resource may be dedicated to the
   specific performed operation, be a subresource of the resource being
   processed, or be a separate message queue resource with a stream of
   operation results. 3.  The server may also provide additional
   signalling in the response to indicate the expected time for
   completion or other relevant information using standard HTTP
   mechanisms. 4.  The representation of the status resource reflects
   the operation's progress.  Once the operation concludes, this
   representation indicates the final outcome, providing either the
   results directly, links to the results, or detailed error information
   in line with RPP's error reporting principles.  It shall remain up to
   protocol design for certain operation and server policy which
   granularity of status information shall be offered.  In some cases it
   might be sufficient to have one final message, in other cases
   intermediate statuses might be required.  The lifetime of these
   resources might also be differentiated.  Messages in the queue would
   exist until they are read out by the RPP client.  Other status
   resources might exist for a specific time defined by the server after
   the processing reached its final state.  Finally resources might
   virtually exist forever or require an explicit delete operation from
   the client.

   This architectural approach to asynchronous operations allows client
   applications to remain responsive and manage extended processing
   times effectively, contributing to the overall scalability and
   robustness of interactions within the RPP ecosystem.  Specific RPP
   operations intended for asynchronous execution will be designed to
   utilise this pattern.

5.1.5.  RPP specific status codes and relation to HTTP status codes

   RPP utilises HTTP headers for transferring HTTP and RPP status codes,
   using the standard HTTP headers and RPP-specific HTTP headers.  The
   response body may contain machine readable problem details.  Using
   HTTP status codes and headers allows the client or an intermediate to
   determine what action to take based on status code only.

   *  Use of HTTP status codes to indicate general status categories
      (e.g., 2xx success responses, 4xx for client errors, 5xx for
      server errors) [RFC7231].

   *  Use of additional signalling already standardised for HTTP, for
      example for rate limiting



Kowalik & Wullink       Expires 31 December 2025               [Page 14]

Internet-Draft              rpp-architecture                   June 2025


   *  Definition of RPP-specific status codes, warnings or additional
      processing information, provided in the response, preferably
      outside of resource representation (e.g. in HTTP Headers) to give
      granular information about provisioning request status.

   *  RPP-specific status codes will be defined in a way that allows for
      easy mapping to HTTP status codes, but also provide additional
      information specific to RPP operations.

   *  The HTTP status code is used to determine if the outcome of a
      request is successful or not.

   *  Categorisation of RPP status codes as temporary or permanent to
      guide client retry behaviour.

5.1.6.  Transaction tracing and idempotency

   RPP shall support identification of requests and responses on both
   client side and server side with use of client provided identifiers
   and server provided identifiers.  This will allow for tracking of
   requests and responses in case of errors, and for idempotency of
   requests.  This should be defined outside of the Data Representation
   Layer (e.g. as HTTP Headers), to assure clear separation of resource
   representation from performed actions.  If possible existing
   mechanisms of HTTP shall be employed.

5.1.7.  Caching

   RPP shall benefit from HTTP standard caching mechanisms to enable
   standard components like proxies and caches to improve performance
   and reduce load on servers.  RPP shall define caching policies for
   different resources and operations, including cache-control headers
   and ETag support.

5.1.8.  Content negotiation for media types

   RPP supports content negotiation to allow clients to specify
   preferred media types for request and response payloads using the
   HTTP 'Accept' and 'Content-Type' headers [RFC7231].

   *  Support for 'application/rpp+json' as the primary media type.

   *  Potential support for other media types defined in the Data
      Representation Layer







Kowalik & Wullink       Expires 31 December 2025               [Page 15]

Internet-Draft              rpp-architecture                   June 2025


5.1.9.  Protocol Versioning

   RPP will define a versioning schema for the protocol itself, the
   extensions and other protocol elements such as profiles as
   appropriate.  The versioning schema shall on one side allow for
   independent introduction of new features in a non-breaking manner on
   both client and server side, and on the other side allow the opposite
   party of the communication to determine if the version is compatible
   or not.  One of potential approaches having this property might be
   use of Semantic Versioning [SemVer], but also other versioning schema
   shall be possible.

   Signalling of the versions will be preferably realised using
   parameters of the media type.

5.1.10.  Profiles

   In real operational conditions different RPP server operators may
   have different requirements regarding set of protocol elements and
   their versions necessary to be supported by the client to enable
   reliable communication.  Such requirements may also be defined by
   external policies.  For this purpose RPP will define a concept of
   profiles, being identifiers translated into a certain minimum
   configuration of protocol version, extensions and their versions.
   The profiles themselves will be versioned in the same way as other
   protocol elements.

   RPP may define a machine-readable definition of profiles to allow
   automatic processing by the clients, but may also refer to other
   forms of profile specification.

   Signalling of the profiles will be preferably realised using
   parameters of the media type.

5.1.11.  Prefer Header for Response Verbosity

   RPP may utilise the HTTP Prefer header [RFC7240] with the "return"
   preference to allow clients to control the verbosity of responses.
   For example, clients not interested in full resource representations
   could use Prefer: return=minimal to request minimal responses,
   reducing payload sizes and improving efficiency.  The default
   behaviour, without the Prefer header, would be to return a full
   resource representation, similar to object info responses in EPP,
   especially after compound requests are completed.  For certain use-
   cases it might be convenient for a client to receive also
   dereferenced full or partial representation of related objects.  For
   example details about sponsoring client of domain name instead of
   just ID. "return" preference syntax alone is not sufficient for this



Kowalik & Wullink       Expires 31 December 2025               [Page 16]

Internet-Draft              rpp-architecture                   June 2025


   purpose, therefore RPP would need to define custom preference and
   register it in "HTTP Preferences" IANA registry.

5.1.12.  Language negotiation for textual content

   RPP shall support language negotiation to enable clients to request
   responses in a preferred language using the HTTP 'Accept-Language'
   header [RFC7231].

   *  Server implementations MAY support multiple languages for textual
      content in responses to provide human-readable localised
      responses.

   *  The default language and mechanisms for indicating supported
      languages will be defined, preferably using HTTP methods, like
      OPTIONS or HEAD requests.

   *  application/rpp+json media type may support multi-language
      representations, especially for writing operations involving user
      provided content.  Other media types may have different mechanisms
      for language representation.

5.1.13.  Prefer Header for Request Validation

   RPP may utilise the HTTP Prefer header [RFC7240] for signalling the
   preference for either strict or lenient processing of requests.  This
   allows clients to indicate whether they prefer strict validation of
   message payloads and rejection of requests with unknown properties or
   a more lenient approach ignoring unknown properties that may allow
   for additional flexibility in processing.  The default behaviour,
   without the Prefer header, would be to process requests leniently.

5.1.14.  Definition of special resources

   RPP may define special resources for specific purposes:

   *  Service Discovery endpoints to advertise protocol capabilities and
      supported features (see Section 5.1.15).

   *  Metadata endpoints to provide schema information or other
      protocol-level metadata, potentially including OpenAPI definitions
      for documentation and code generation.

5.1.15.  Service discovery mechanisms

   RPP will define mechanisms for service discovery, allowing clients to
   dynamically discover RPP service endpoints and capabilities, reducing
   coupling between clients and servers.



Kowalik & Wullink       Expires 31 December 2025               [Page 17]

Internet-Draft              rpp-architecture                   June 2025


   *  Potential discovery of RPP server location, like IANA
      bootstrapping document or a special DNS TXT RR with location of
      RPP service for the tld.

   *  Potential use of well-known URIs (e.g., /.well-known/rpp-
      capabilities) for service discovery.

   *  Advertising supported protocol versions, extensions, available
      resource types, authentication methods, and supported features.

   *  It may be considered for RPP to distribute service discovery for
      each resource type separately for better scalability and
      management.  For example instead of having a single service
      discovery endpoint for the whole registry on /.well-known/rpp-
      capabilities there might be a separate discovery placed under
      /{resource-type}/.well-known/rpp-capabilities e.g. /domains/.well-
      known/rpp-capabilities.

   *  Service discovery shall utilise standardised methods, like URI
      templates [RFC6570] to allow easy navigation of resources and
      avoid hard-coding of URLs, same time allowing clients to navigate
      directly to a known resource without additional server queries.

   *  As a matter of principle service discovery shall be used to
      bootstrap the communication between client and server, its
      capabilities and operational policies.  The server configuration
      shall be considered static between reconfiguration of the server
      and not be used for any dynamic configuration, like load balancing
      etc.  It would enable the right balance between discoverability
      and reduction of round trips between clients and servers.

5.2.  Data Representation Layer

   This layer focuses on the data representation of RPP messages.  It
   defines the media type used to carry RPP data and supports various
   data representation formats.

5.2.1.  Data structure

   RPP will define the overall structure of the message payload carried
   by the chosen media type.  By default one data structure will be
   defined, however RPP should be able to support multiple data
   structures, especially for compatibility with EPP and other
   standards.

   *  *'RPP' Structure:* Defining a new, dedicated data structure
      specifically for RPP messages.  This would be the default in core
      specifications.



Kowalik & Wullink       Expires 31 December 2025               [Page 18]

Internet-Draft              rpp-architecture                   June 2025


   Other future possibilities:

   *  *'EPP' Structure Adaptation:* Reusing or adapting to the existing
      EPP XML schemas, to maintain data model compatibility with EPP
      core objects and simplify mapping from EPP.

   *  *'JSContact' Structure Adaptation:* Adapting to the existing JSON
      representation for Contact Information [RFC9553], to maintain
      alignment with RDAP.

   *  *'VC' Structure Adaptation:* Adapting to existing Verifiable
      Credentials ([W3C-VC], [I-D.draft-ietf-oauth-sd-jwt-vc]) data
      structures, especially for representing identity or authorisation
      information, allowing for integration with external identity
      systems.

5.2.2.  Data format

   The primary format for RPP data representations shall be JSON,
   however RPP should be able to be extended to support other formats
   like XML, JWT, JWT-SD or CBOR.

   *  *JSON:* Standard JSON format [RFC8259].

   *  *XML:* eXtensible Markup Language [XML] (considered for potential
      compatibility with EPP).

   *  *JWT:* JSON data encapsulated within a JSON Web Token [RFC7519]
      for potential use-cases when verifiable data consistency is
      required

   *  *JWT-SD:* JSON data with Selective Disclosure using JWTs
      [I-D.draft-ietf-oauth-selective-disclosure-jwt] for minimisation
      of exposed data.

   *  *CBOR:* Concise Binary Object Representation for specific use
      cases requiring compact binary encoding [RFC8949].

   Some data formats can be optionally represented in other
   encapsulations, for example JSON data can be represented also in JWT
   or CBOR.  Change of encapsulation shall not affect the data
   structure.  This might be beneficial if RPP is to be extended to
   support different data formats in the future that only require
   additional properties provided by encapsulation, like signing,
   encryption or binary representation.






Kowalik & Wullink       Expires 31 December 2025               [Page 19]

Internet-Draft              rpp-architecture                   June 2025


5.2.3.  Data Validation

   Data structures and formats will be described using a schema
   language, such as JSON Schema, OpenAPI, CDDL or other appropriate
   stable and open standard for JSON data structures.  It will enable
   data validation to be performed by both client and servers on
   received requests and responses.  For example, JSON Schema can define
   the expected structure of a domain object, including required fields
   and data types, allowing clients to validate their requests before
   sending them and servers to ensure incoming data conforms to the
   expected format.  The schemas must support both strict and lenient
   processing of requests and responses and support protocol
   extensibility.

5.2.4.  Media Type definition

   Together data structure and data format would define the whole media
   type.  So application/rpp+json would be the primary media type with
   "rpp" payloads in plain json format. application/epp+xml would be epp
   payload as per [RFC5730].

5.3.  Resource Definition Layer

   Each resource type, no matter if on a top level, being an independent
   provisioning object, or a subresource, being a part of another
   resource, shall be well defined including data elements and possible
   operations.  A resource definition shall on the first level of
   abstraction be composable out of data elements, without any reference
   to the media type or representation.  This will allow for easy
   extensibility and compatibility with different media types.

   All resource types shall be defined in IANA registry in a way that
   allows fully automated processing of the resource definition,
   including data elements, operations and media type representation.

5.3.1.  Data Elements

   This part defines logical data elements for each resource type, which
   can also be re-used across resource types.  It is abstracted from the
   actual transport and media type, focusing on the structure and
   constraints of data elements.  Data element definition includes:

   *  Identification of logical data units (e.g. a stable identifier of
      a data element, which is independent of the representation)

   *  Definition of logical data units (e.g., domain name, contact
      details)




Kowalik & Wullink       Expires 31 December 2025               [Page 20]

Internet-Draft              rpp-architecture                   June 2025


   *  Format and schema for primitive data elements or reference to
      other resource type definitions

   *  Constraints on data elements (e.g., data type, length, allowed
      values)

   *  Mechanisms for extensibility, if applicable

   Data elements shall be defined in IANA registry in a way that allows
   for automated processing of the data element definition, including
   constraints and references to other data elements.

5.3.2.  Mapping

   This layer defines the mapping of Data Elements onto the Data
   Representation Layer.  For example in case of application/rpp+json
   media type, the mapping layer would define how the logical data units
   are represented in JSON format.

   This additional level of indirection would allow usage of data
   formats defined outside of rpp specifications - for example usage of
   Verifiable Credentials or Verifiable Presentations as first class
   resource types for contacts in RPP, and mapping appropriate data
   elements.

   The mapping layer shall be defined in IANA registry in a way that
   allows for automated processing of the mapping definition, including
   reading and writing operations.  Mechanisms, such as defined for
   JavaScript Object Notation (JSON) Patch [RFC6902], may be used to
   define the mapping.

5.3.3.  Operations

   Each resource type shall define operations possible on this resource
   type.  This may encompass any of the mechanisms defined on the HTTP
   transport layer and be constrained by those extensibility rules.

   Operations shall be defined in IANA registry in a way that allows for
   automated processing of the operation definition, including
   constraints and references to other resource types.

5.4.  Extension mechanisms

   The RPP architecture is designed to be extensible, allowing for the
   addition of new resource types, data elements, and operations without
   breaking existing implementations.  This extensibility is achieved
   through:




Kowalik & Wullink       Expires 31 December 2025               [Page 21]

Internet-Draft              rpp-architecture                   June 2025


   *  *Layered Design:* Each architectural layer (HTTP Transport, Data
      Representation, Resource Definition) is defined independently,
      allowing new features or technologies to be introduced at one
      layer without impacting others.

   *  *IANA Registries:* Resource types, data elements, mappings, and
      operations are registered in IANA registries using machine-
      readable formats.  This enables automated processing, discovery,
      and extension of protocol elements without requiring changes to
      the core specifications.

   *  *Resource and Operation Extension:* New resource types and
      operations can be defined and registered.  Existing resources can
      be extended with additional data elements or operations in a
      backward-compatible manner.

   *  *Profile and Compatibility Layers:* Compatibility profiles can be
      defined to support subsets of RPP for specific use cases (such as
      EPP compatibility)

   *  *Discovery and Negotiation:* Service discovery endpoints and
      content negotiation mechanisms allow clients and servers to
      dynamically discover and utilise new capabilities, resource types,
      and representations as they are introduced.

   *  *Status codes:* New RPP status codes can be defined and registered
      including their mapping to HTTP status codes.

   These extensibility mechanisms ensure that RPP can evolve to meet
   future requirements, integrate with emerging technologies, and
   support a wide range of provisioning scenarios while maintaining
   interoperability and stability.

5.4.1.  Name Management and Collision Avoidance

   RPP extensions MUST define unique names for all extension elements to
   prevent conflicts with other extensions and with core protocol
   elements.  These names are used consistently in resource identifiers,
   data element identifiers, and URL path segments.












Kowalik & Wullink       Expires 31 December 2025               [Page 22]

Internet-Draft              rpp-architecture                   June 2025


   Standardised RPP extensions MUST register their names in a dedicated
   IANA registry for RPP extensions to ensure global uniqueness and
   avoid collisions.  Private (non-standardised) extensions are also
   required to use unique names, but are not required to register with
   IANA.  This allows private extensions to be developed and used within
   specific implementations or organisations without impacting the
   global RPP ecosystem.  Private extensions should use names that are
   unlikely to conflict with other extensions or with RPP core elements,
   for example by using reverse domain notation as a prefix (e.g.,
   org.example.rpp).

   This naming mechanism ensures that new resource types, data elements,
   and operations can be introduced independently and safely, supporting
   the extensibility goals of the RPP architecture while maintaining
   interoperability and clarity across implementations.

6.  Change History

6.1.  -01 to -02

   *  Added responses must contain links to relevant object to
      Section 5.1.2

   *  Added round trip minimisation principle to Section 5.1.15

   *  Added description of lenient versus strict request validation to
      Section 4.2.3.

   *  Added description of asynchronous handling to Section 4.2.1 and
      Section 5.1.

   *  Added Operation Singularity to Section 4.1.

   *  Added Versioning chapter to Section 5.1.

   *  Added Profiles chapter to Section 5.1.

   *  Added Security section to Section 5.1.1.

   *  Added Relationship between clients and authentication credentials
      to Section 5.1.1.

   *  Add Data Validation (Section 5.2.3) section with schema language
      support for RPP to Section 5.2

   *  Added Name Management and Collision Avoidance section to
      Section 5.4.




Kowalik & Wullink       Expires 31 December 2025               [Page 23]

Internet-Draft              rpp-architecture                   June 2025


   *  Added Section about dereferenced related object representation to
      Section 5.1.11.

6.2.  -00 to -01

   *  Removed requirements and replaced with a reference to RPP WG

   *  Encapsulation removed as a primary extension point and part of
      architecture

   *  Added reference to JSContact as a possible contact representation

   *  Added HEAD verb to basic operations

   *  Updated RPP specific status codes and relation to HTTP status
      codes

   *  Added Extension mechanisms section to Protocol Details

7.  References

7.1.  Informational References

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

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

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

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

   [RFC7231]  Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
              (HTTP/1.1): Semantics and Content", IETF,
              DOI 10.17487/RFC7231, RFC 7231, June 2014,
              <https://www.rfc-editor.org/info/rfc7231>.





Kowalik & Wullink       Expires 31 December 2025               [Page 24]

Internet-Draft              rpp-architecture                   June 2025


   [REST]     "Fielding, R., "Architectural Styles and the Design of
              Network-based Software Architectures", Doctoral
              Dissertation, University of California, Irvine, September
              2000, >.".

   [SemVer]   ""Semantic Versioning 2.0.0",".

   [RFC7240]  Snell, J., "Prefer Header for HTTP", IETF,
              DOI 10.17487/RFC7240, RFC 7240, June 2014,
              <https://www.rfc-editor.org/info/rfc7240>.

   [RFC8259]  Bray, T., "The JavaScript Object Notation (JSON) Data
              Interchange Format", IETF, STD 90, DOI 10.17487/RFC8259,
              BCP 90, RFC 8259, December 2017,
              <https://www.rfc-editor.org/info/rfc8259>.

   [RFC6570]  Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
              and D. Orchard, "URI Template", IETF,
              DOI 10.17487/RFC6570, RFC 6570, March 2012,
              <https://www.rfc-editor.org/info/rfc6570>.

   [RFC6749]  Hardt, D., "The OAuth 2.0 Authorization Framework", IETF,
              DOI 10.17487/RFC6749, RFC 6749, October 2012,
              <https://www.rfc-editor.org/info/rfc6749>.

   [RFC6750]  Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
              Framework: Bearer Token Usage", IETF,
              DOI 10.17487/RFC6750, RFC 6750, October 2012,
              <https://www.rfc-editor.org/info/rfc6750>.

   [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
              (JWT)", IETF, DOI 10.17487/RFC7519, RFC 7519, May 2015,
              <https://www.rfc-editor.org/info/rfc7519>.

   [RFC9082]  Hollenbeck, S. and A. Newton, "Registration Data Access
              Protocol (RDAP) Query Format", IETF, STD 95,
              DOI 10.17487/RFC9082, BCP 95, RFC 9082, June 2021,
              <https://www.rfc-editor.org/info/rfc9082>.

   [RFC6902]  Bryan, P. and M. Nottingham, "JavaScript Object Notation
              (JSON) Patch", IETF, DOI 10.17487/RFC6902, RFC 6902, April
              2013, <https://www.rfc-editor.org/info/rfc6902>.

   [XML]      "Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E. and
              Yergeau, F., "Extensible Markup Language (XML) 1.0 (Fifth
              Edition)", World Wide Web Consortium Recommendation REC-
              xml-20081126, November 2008, []().".




Kowalik & Wullink       Expires 31 December 2025               [Page 25]

Internet-Draft              rpp-architecture                   June 2025


   [I-D.draft-ietf-oauth-selective-disclosure-jwt]
              "Fett D., Yasuda K. and Campbell B. , "Selective
              Disclosure for JWTs (SD-JWT)", Work in Progress, Internet-
              Draft, draft-ietf-oauth-selective-disclosure-jwt, 16
              January 2025 >".

   [RFC9396]  Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0
              Rich Authorization Requests", IETF, DOI 10.17487/RFC9396,
              RFC 9396, May 2023,
              <https://www.rfc-editor.org/info/rfc9396>.

   [RFC9205]  Nottingham, M., "Building Protocols with HTTP", IETF,
              DOI 10.17487/RFC9205, BCP 56, RFC 9205, June 2022,
              <https://www.rfc-editor.org/info/rfc9205>.

   [RPPReq]   ""RPP Requirements (Work in progress 7.3.2025)", https:/ /
              github.com/ietf/wiki.ietf.org/blob/157294ff0fdfb2715da5a28
              7dfba6c641a1bad67/group/rpp/requirements.md".

   [RFC8949]  Bormann, C. and P. Hoffman, "Concise Binary Object
              Representation (CBOR)", IETF, STD 94,
              DOI 10.17487/RFC8949, BCP 94, RFC 8949, December 2020,
              <https://www.rfc-editor.org/info/rfc8949>.

   [OpenAPI]  ""OpenAPI Specification",".

   [W3C-VC]   "Verifiable Credentials Data Model v2.0,".

   [I-D.draft-ietf-oauth-sd-jwt-vc]
              "SD-JWT-based Verifiable Credentials (SD-JWT VC) >".

   [RFC9553]  Stepanek, R. and M. Loffredo, "JSContact: A JSON
              Representation of Contact Data", IETF,
              DOI 10.17487/RFC9553, RFC 9553, May 2024,
              <https://www.rfc-editor.org/info/rfc9553>.

Authors' Addresses

   P Kowalik
   DENIC eG
   Theodor-Stern-Kai 1
   Frankfurt am Main
   Germany
   Email: pawel.kowalik@denic.de
   URI:   https://denic.de






Kowalik & Wullink       Expires 31 December 2025               [Page 26]

Internet-Draft              rpp-architecture                   June 2025


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














































Kowalik & Wullink       Expires 31 December 2025               [Page 27]
