Andy, How about we add to draft-yao-regext-epp-quic and draft-loffredo-regext-epp-over-http registration in the EPP extension registry, per RFC 7451? RFC 7451 references both RFC 3735 for guidelines for extending EPP but also references RFC 5730. RFC 3735 covers guidelines for extending the EPP packet protocol and RFC 5730 covers extensibility of transports and the packet protocol. I view all the EPP RFC's beyond EPP RFC 5730 as defining extensions, which includes RFC 5734 for EoT. I don't believe there should be any debate that EPP transports is a supported form of extensibility in RFC 5730 and therefore the transports should be registered in the EPP extension registry, and we can move on without touching the charter.
-- JG James Gould Fellow Engineer jgo...@verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 2/11/25, 5:10 PM, "Andrew Newton (andy)" <a...@hxr.us <mailto:a...@hxr.us>> wrote: Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. On Tue, Feb 11, 2025 at 2:49 PM Hollenbeck, Scott <shollenb...@verisign.com <mailto:shollenb...@verisign.com>> wrote: > > [SAH] Andy, I don't believe that the argument cuts against the current RFCs. > RFC 5734 exists because EPP was designed to be transport-independent. If that > wasn't the case, TCP transport would have been specified in RFC 5730. > > Section 2.1 of 5730 describes considerations for an EPP transport mapping. It > exists because the design assumption was that additional transport mappings > would be specified in the future. They're not protocol extensions per se, > because they're not adding or changing protocol functionality. That's why > they're not directly addressed in RFC 3735, but the ability to define new > transport mappings is definitely a feature of EPP. There is no disagreement that EPP as defined by RFC 5730 can be used over new transports. But as you said "They're not protocol extensions, per se." They are not covered under Section 2.7 of 5730, which is titled "Protocol Extension Framework". > > Our charter could be interpreted to limit our work to extensions that would be > registered in the IANA extension registry. A new transport mapping wouldn't be > registered in the extension registry, so a strict interpretation of the > charter might preclude work on these drafts. That's a topic worthy of an AD > opinion. The charter references RFC 7451 which is the document that created the IANA registry into which EPP extensions are registered. > > > As there does appear to be energy in the group to work on new EPP > > transports, would the group be willing to recharter to include the scope of > > I-Ds > > under discussion? > > [SAH] Yes, I'm willing to do that. If our charter precludes work on new > transport mappings, that's a defect that needs to be fixed. I'm hoping, > though, that a more liberal interpretation of the charter will recognize > that EPP was designed to be extended by defining new transport mappings, > and that design decision means that such mappings are in-scope. I think such an interpretation would blatantly ignore the THREE explicit charter references to RFC 7451, and RFC 7451's explicit reference to RFC 3735. -andy _______________________________________________ regext mailing list -- regext@ietf.org <mailto:regext@ietf.org> To unsubscribe send an email to regext-le...@ietf.org <mailto:regext-le...@ietf.org> _______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
