RPP Extensibility Points

[anewton1998]

From James Gould on the list:

4. Change "The working group may also consider RPP extensions that are functional equivalents of registered EPP extensions" to "The working group will consider RPP extensibility points and identify functional equivalents to the EPP extensions"
   a. I want this to be a stronger goal, since as noted by Jody Kolker at the RDAP BOF, RPP must be a superset of EPP.

[pawel-kow]

From https://mailarchive.ietf.org/arch/msg/rpp/ABcz4Ga2mRWGUBO8uV9ip8VDnBU/

[PK] Actually after the discussions we had and what I presented in the BoF we indeed need to account for the situation that we we would build in some of functionality of EPP extensions directly into RPP core but also still remain flexible that some of the registered EPP extensions are very little or not used at all and therefore would not be of primary focus of the working group.

This would be my proposal to phrase it:
"The working group may also consider functional equivalents of commonly used registered EPP extensions, either by providing RPP extensibility points or incorporating them into core of the protocol."

[JG2] I will mirror what I stated at the BOF mic, that everything beyond the base protocol elements should be an extension just like EPP. EPP RFC 5730 provides the base with the extension points, and the domain name, host, and contact RFCs are object extensions compliant with EPP RFC 5730. This model has proven to be very successful and should be considered for RPP. I noted above that the set of EPP extensions that have been created need to be analyzed for applicability in RPP. I’m not saying that every extension needs to be fully supported in RPP, but the goal needs to be functional equivalence with the features used in EPP. How about adding the analysis work in the charter that can be captured on the wiki and can be used as the basis for the requirements?

[PK2] I would be supportive to perform an analysis, but I rather consider the requirements to refer to the analysis rather than being a prerequisite for the requirements.

[JG3] There could be overlap of the analysis with the requirements, but in the end the analysis will be very important with completing the requirements.

The only change I would make is to change the “may also” to a “will” in "The working group will consider functional equivalents of commonly used registered EPP extensions, either by providing RPP extensibility points or incorporating them into core of the protocol." This is a hard requirement to set the scope appropriately.

[PK2] I can go with "will" as this is the right thing to do to maintain compatibility. What would others say?

[JG3] My hope is that there will be agreement that we should consider all the registered EPP extensions for applicability in RPP either as embedded directly into the RPP objects (e.g., RGP in domain name) or created as an optional RPP extension (e.g., launch phase extension or registry fee extension). I don’t believe we’ll want to re-invent all the work we did in creating some of the EPP extensions and focus on the core aspects of RPP.