[rpp] Re: RPP -05 feedback

[Jasdip Singh <[e-mail]>]

Hi Pawel,

Please find my comments below.

Thanks,
Jasdip


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


Hi Jasdip,

also few comments / clarifications from me on the points of items we adopted from EPP [PK].

On 18.03.26 11:40, Maarten Wullink wrote:

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?


[PK] we described this in the architecture document 5.1.16. in great detail. HTTP codes do not offer enough of level of granularity which is needed to transport information needed by the clients.
Therefore RPP-Code is always required, but HTTP code is also mapped to the operation outcome that allows first level of processing by for example only http-aware framework layers.

From the two paths: define a whole new set of codes, or use the set of codes from EPP and extend on it, we decided to reuse EPP codes. It does not mean that the server behind needs to know or implement EPP, it just uses the same codes.

For example: "Object is not eligible for renewal" is RPP-Code 02105, which is derived from EPP 2105 and not re-defined, but it is a fully valid RPP code.

There is a clear benefit for EPP operators in the transition if the codes can be mapped by just adding/removing leading "0”.

[JS] Agreed. As long as there is room for RPP codes for future non-EPP usage scenarios in RPP, and AFAICT it looks so. :)


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

[PK] I will contradict what Maarten is telling. The headers happen to have the same name and happen to serve the same function as EPP-equivalents, but they are independent from EPP.

RPP-Cltrid is an audit trail and idempotency key same time. RPP-Svtrid is an audit trail which is critical in the provisioning system. The headers will work same way if there is no EPP server behind. Both are mandatory btw.

[JS] OK. For further clarity, good to include above rationale in the spec. Essentially, an implementer who has no prior EPP experience should be able to clearly follow this spec.


[...]
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?
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
[PK] so far we made some pragmatic choices, by referencing EPP RFCs at places, we limited the chances that EPP users have to make line-by-line comparison whether things are same.

We may set a goal of removing all normative dependency to EPP and copy-paste whatever is derived. This is basically editorial work. An additional Informational drafts for transition from EPP would be then needed to help people identify elements which are actually not changed.

[JS] Good idea.


This would be for sure better for non EPP adopters (like RIRs), but more work to EPP operators. Right now the charter with its focus on domain provisioning let us believe that the second group shall be served with focus.

[JS] Right, thanks.


 Happy to hear opinions from the WG.