Markdown Version | Transcript | Session Recording | Session Materials
Session Date/Time: 16 Mar 2026 08:30
RPP
IETF 125 - Shenzhen, China / Remote Session: RPP (Restful Provisioning Protocol) Working Group Chairs: Gavin Brown, Marco Hoffmann
## Summary
The RPP working group met to discuss progress on the protocol's core architecture, data objects, and JSON mapping. Key milestones were reviewed, noting that consensus has been reached on draft-ietf-rpp-requirements. The session focused on refining technical details in the architecture and core documents, including bootstrapping mechanisms, discovery, security for authorization information, and the transition from EPP-centric models to a more native RESTful approach.
## Key Discussion Points
### WG Status and Milestones
Gavin Brown noted that draft-ietf-rpp-requirements has reached consensus. The group is now prioritizing the core architecture, extension mechanisms, and domain provisioning specifications. There was a brief discussion regarding the milestone for mapping RPP to EPP; chairs will look to the working group for guidance on whether a separate document is needed or if existing drafts satisfy this requirement.
### Architecture Update
Pawel Kowalik presented updates on draft-ietf-rpp-architecture. Slides: IETF 125 RPP Architecture Update
- Discovery Document Handling: Discussion on whether discovery should be static or dynamic. Jim Gould questioned the benefit of caching in a provisioning protocol. Pawel clarified that caching is intended for the discovery document (features/policies), similar to RDAP help resources.
- Login Security: Discussion focused on carrying over functionality from RFC 8807 (EPP Login Security). Since RPP is sessionless, the group discussed using the
User-Agentheader and generic warning mechanisms in responses rather than a dedicated login command. - Transfer Process: The group discussed supporting an inline approval process for transfers to replace shared secrets. Jim Gould and Rick Wilhelm supported "parking" this complex requirement for now to focus on higher priorities.
- HTTP Methods: Jim Gould suggested leveraging the HTTP
QUERYmethod (draft-ietf-httpbis-query) to support message bodies in queries, which would facilitate complex "check" commands like those in the registry fee extension.
### Data Objects Update
Pawel Kowalik presented updates on draft-ietf-rpp-data-objects. Slides: IETF 125 Kowalik RPP Data Objects
- DNSSEC Urgent Flag: The group debated whether to keep the "urgent" flag from EPP. Consensus leaned toward it being unnecessary in modern environments where zone publication cycles are short.
- AuthInfo Security: Strong support was expressed for not including
authInfo(credentials) in clear text in every "info" response. Suggestions included moving this to a sub-resource queried on demand to align with modern security practices (referencing RFC 9154). - Contact Localization: Discussion on the legacy EPP model of "internationalized" (all-ASCII) vs "localized" addresses. Participants suggested that "internationalized" should not imply ASCII-only in a modern Unicode context, though maintaining both fields may be necessary for operational reasons (e.g., postal delivery).
### Core Protocol Updates
Maarten Wullink presented updates on draft-ietf-rpp-core. Slides: RPP - Core Updates
- Bootstrapping: Two methods were proposed: IANA registry and DNS SRV records. Stefan Botzmayer and Jim Gould suggested dropping bootstrapping entirely, arguing that the existing business/contractual relationship between registrars and registries makes manual configuration sufficient.
- Profiles: The draft introduces "profiles" to group protocol features. Discussion centered on how to signal profile usage. Stefan Botzmayer preferred using an HTTP header over media type parameters.
- URNs: Pawel Kowalik questioned the need for URN namespaces for identifying profiles or extensions, suggesting simpler naming schemes are sufficient.
### JSON Mapping Update
Maarten Wullink presented updates on draft-ietf-rpp-json. Slides: RPP - JSON Update
- JSON Schema: The draft uses JSON Schema for validation. Pawel Kowalik noted the potential risk of a normative dependency on JSON Schema while it is still being standardized at the IETF.
- Contact Formats: Maarten suggested investigating jCard for contact data to improve alignment with RDAP.
- Object Ordering: Werner Staub suggested recommending a specific order for JSON keys to assist developers. Andy Newton cautioned against this, noting that RDAP avoided mandatory ordering to remain flexible for different use cases.
## Decisions and Action Items
- Decision: The proposal to implement an inline transfer approval process (Requirement R9.3) is parked due to complexity and lack of immediate priority.
- Decision: The "urgent" flag in DNSSEC data objects will likely be removed or made optional, pending final list confirmation.
- Action Item (Authors): Request an early review of the architecture draft from the HTTP Directorate.
- Action Item (Authors): Re-evaluate the necessity of the bootstrapping mechanism in draft-ietf-rpp-core based on session feedback.
- Action Item (Authors): Update draft-ietf-rpp-data-objects to move
authInfoto a sub-resource or on-demand query rather than including it in standard info responses.
## Next Steps
- Continue syncing the draft-ietf-rpp-core and draft-ietf-rpp-json documents with the updates in draft-ietf-rpp-data-objects.
- Establish whether draft-ietf-rpp-architecture is ready for Working Group Last Call (WGLC) after the HTTP Directorate review.
- Discuss the potential adoption of draft-ietf-rpp-core, draft-ietf-rpp-data-objects, and draft-ietf-rpp-json on the mailing list.
- Stefan Botzmayer to send a report on the RPP-related hackathon activities to the mailing list.
Related Documents
draft-ietf-httpbis-query, draft-ietf-rpp-architecture, draft-ietf-rpp-core, draft-ietf-rpp-data-objects, draft-ietf-rpp-json, draft-ietf-rpp-requirements