[rpp] RPP -05 feedback

[Jasdip Singh <[e-mail]>]

Hi Pawel, Maarten,

Read this draft with great interest. :) Please find below some preliminary, high-level feedback, in case it helps.

Bootstrapping:

Wonder if it’d be better to use modern SVCB/HTTPS RRs, instead of SRV RRs, for an HTTP-based protocol like RPP?

Knowing the RPP focus (per the charter) is presently on the domain name use cases, it might help to still emulate the IANA RDAP Bootstrap (RFC 9224) model with equivalent RPP service URIs. As well as add the .well-known URIs in another array. Something like:

{
  "description": "RPP bootstrap file for Domain Name System registrations",
  "publication": "2026-03-16T00:00:00Z",
  "services": [
    [
      [
        “example"
      ],
      [
        "https://rpp.example/"
      ],
      [
        "https://rpp.example/.well-known/rpp"
      ]
    ],
    …
  ],
  "version": "1.0"
}

That way, there could be similar bootstrap files for number registrations, if needed. That said, not sure if the RDAP Bootstrap model could be extended beyond names and numbers for a general-purpose provisioning protocol like RPP.

Discoverability:

Like the idea of using .well-known URIs to publish RPP service metadata. As a case of reverse innovation, wonder if this is something we should also start doing for RDAP?

So that RPP can be extended for non-domain name scenarios, should the “tlds” member in the JSON document be optional?

Error handling:

“The RPP result codes are based on the EPP result codes defined in [RFC5730].”

For non-domain name use cases in the future, is it expected that HTTP status codes should suffice and there would not be any expectation to return either RPP or EPP codes?

Media types:

Re: the word “types”. Beyond “application/rpp+json” what other media types do we envision for RPP? “application/rpp+cbor”, etc.?

Request Headers:

There are some headers that, IIUC, seem to connote EPP semantics, like “RPP-Cltrid” and “RPP-Svtrid”. Why not have them prefixed with “EPP-" to distinguish from the actual RPP headers like "RPP-Profile”?  Also, is it safe to assume that they are optional for non-EPP use cases in RPP?

Knowing the need for client- and server-side transaction ids in EPP, wonder if it would help to elaborate how they are different from a JWT-based session in RPP?

General:

Acknowledging that the near-term adopters of RPP would be EPP actors, to ensure that the RPP core protocol reads more generic for other actors in the future, not sure how but it might help to address the EPP constructs in RPP in a separate set of sections, or even in a separate document. Sorry if this sounds a bit heretic, given the current charter. :)

Thanks,
Jasdip