[rpp] Re: RPP -05 feedback

[Pawel Kowalik <[e-mail]>]

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

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

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

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. Happy to hear opinions from the WG.

Kind Regards,
Pawel