[rpp] Re: RPP -05 feedback

[Jasdip Singh <[e-mail]>]

Hi Maarten,

Thanks for considering my input. Please find my comments below.

Jasdip


From: Maarten Wullink <maarten.wullink=[e-mail]>
Date: Wednesday, March 18, 2026 at 6:41 AM
To: Jasdip Singh <[e-mail]>, [e-mail] <[e-mail]>
Subject: [rpp] Re: RPP -05 feedback

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

MW: That's a good suggestion i'm not sure why we did not use the HTTPS RR in the first place, i will see if i can use the HTTPS in the next version.

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

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.

MW: I will look into this, we have not decided the format of the IANA RPP service registry, the RDAP format could be a possible solution.

[JS] OK. But, before evolving bootstrapping per above suggestions, good to discuss if bootstrapping indeed would have a value-add, per Stéphane’s input in his response.


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?

MW: What would be in the discovery document for RDAP? , maybe server version,.supported extensions and their versions and …

[JS] Right, something along these lines. At one point Andy had proposed having such server-level metadata for RDAP, but would be good to follow up in REGEXT if this .well-known URI approach or a dedicated JSON structure as part of some RDAP response (say, for /help) would be useful to do for RDAP.


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

MW:  maybe we should rename it to something like "scope" where a scope can be a tld zone or something else?

[JS] That should work.


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?

MW:  there is a mapping from RPP code to appropriate HTTP code, currently the RPP-Code is required to be present in all responses. we can always add additional rpp codes for new use cases where there is no  suitable RPP code?

[JS] OK.


Media types:

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

MW: The current architecture uses a format agnostic data model ( data objects draft) the charter says we should only do json. but RPP may be used for a long time, it may be good idea to already have support for additional formats even though its not clear at the moment what these are going to be.

[JS] Liked Stéphane’s suggestion to just focus on JSON-related media type for now and include some verbiage for future representations.


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?

MW: If a header is only used for EPP (using RPP as proxy) then it must be optional , we can change the header name to make explicit that the header is for  EPP only.

[JS] Good point.


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?

MW: i think the client/server ids serve different pupose than the JTW, the JWT cannot be used for example for auditingtrail because its not added to the request/response messages?

[JS] OK. For implementors of this provisioning protocol, might help to elaborate on these ids' audit trail purpose.


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

MW: Are you refering to EPP users using only RPP, or those using RPP as proxy in front of EPP?

[JS] Defer to you on who those early EPP-to-RPP adopters could be. TBH, I was thinking more about new RPP users down the line. :)


we should minimise  EPP-only features in RPP, maybe we can make a separate informational best practices/howto document for EPP operators that want to migrate to RPP

[JS] That seems a good idea if it helps keep the core RPP more focused and generic.