Markdown Version | Session Recording

Session Date/Time: 25 Jul 2025 12:30

rpp

Summary

The RPP (Registry Provisioning Protocol) working group met to discuss the ongoing development of a new HTTP-based registry provisioning protocol. The session focused primarily on requirements gathering and consensus building, with reports from hackathon activities, Tiger Team analysis of EPP extensions, and interactive polling on key design decisions. The group aims to achieve consensus on requirements by the next meeting in Montreal to proceed with core architecture and specifications.

Key Discussion Points

Working Group Operations

• GitHub Integration: The working group successfully uses GitHub for collaborative work, with weekly automated digests sent to the mailing list and selective notifications for important discussions
• Timeline: Target consensus on requirements by Montreal meeting, with core architecture and specifications delivery by February 2027
• Logo: New RPP working group logo debuted at this meeting

Hackathon Results

• Multiple Implementations: Four working end-to-end implementations were developed during the hackathon
• Architecture Models: Both native RPP integration and EPP proxy approaches were successfully demonstrated
• Data Modeling: Two different approaches emerged - EPP-style modeling and JS Contact structure integration
• Open API Specifications: Published specifications available via GitHub pages for implementation reference

RPP Design Challenges

• Object Creation: Debate between PUT (for known URLs) vs POST (universal approach) - current implementations favor POST based on developer feedback
• Check Command Modeling: Moved from simple HEAD requests to separate availability resource supporting both HEAD and GET methods
• Processing Resources: Adopted resource-oriented architecture for operations like transfers, with extensible process namespace
• Authorization: Proposed custom header for auth codes due to limitations of standard HTTP authorization for dual authorization scenarios

Tiger Team EPP Extension Analysis

• 65 Extensions Analyzed: Comprehensive review of existing EPP extensions categorized by extensibility types
• Recommendations:
  • Embed 8 extensions directly into RPP core
  • Create standard RPP extensions for key EPP extensions
  • Support 33 extensions through design patterns
• EPP Enhancement Suggestions: Single-step restore, consolidated IDN extensions, standardized balance extensions

Requirements Discussion and Polling

Interactive polling was conducted on eight key requirements issues:

1. Data Validation: Split between strict vs lenient validation approaches, with security concerns favoring strict validation
2. Response Caching: Generally supported for applicable operations using standard HTTP mechanisms
3. Historical Data: Mixed response on supporting historical object data as extensions
4. Bodiless Requests: Strong support for using HTTP methods/headers where message bodies aren't necessary
5. Password Management: Preference for delegating to HTTP layer rather than protocol-specific commands
6. Transaction Information: Debate on placing transaction IDs in headers vs message body
7. Client Data Omission: Support for allowing clients to indicate intentionally omitted data
8. Developer-Friendly Requirement: Question about necessity of subjective usability requirements
9. Profiles: Discussion on complexity vs utility of RDAP-style profiles for RPP

DNS Data Representation

• Unified Structure: Proposal for consistent DNS record representation across different RPP objects
• Resource Record Model: Based on RFC 1035 structure with name, TTL, type, and R-data components
• Extensibility: Framework supports existing and future DNS record types including experimental records
• Delegation Support: Addresses current EPP use cases while preparing for future developments like DELEG

Decisions and Action Items

Immediate Actions

• All polling results and discussions to be posted to mailing list for broader community input
• Requirements document to be updated based on feedback from this session
• Tiger Team recommendations to be incorporated into requirements document
• Weekly GitHub digest to continue for mailing list integration

Technical Decisions

• Bodiless requests/responses approach has strong support
• Response caching should be considered for applicable operations
• Password management should leverage HTTP layer capabilities
• Check command will use separate availability resource approach

Next Steps

1. Requirements Consensus: Achieve working group consensus on requirements document by Montreal meeting
2. Mailing List Discussion: Continue technical discussions on all polled topics via mailing list
3. Implementation Work: Continue hackathon-style development and testing of prototype implementations
4. Architecture Document: Consider adoption of architecture document to facilitate requirements discussion
5. Registrar Engagement: Increased efforts to involve registrar community in requirements and design process
6. Tiger Team Analysis: Complete final recommendations and prepare for next IETF presentation

The working group demonstrated significant progress in both technical development and consensus building, with active participation from registry operators, implementers, and technical experts. The interactive polling format proved effective for gauging community sentiment on contentious technical issues.