[rpp] Re: RPP -05 feedback

[Maarten Wullink <[e-mail]>]

Hi Jasdip,

Thank you for the review!

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.

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

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?

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?


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.

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.

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?

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

-
Maarten