I think most of use assume that extending EPP XML through XML namespaces would not result in security issues. Even if one did, the blast radius would likely be limited. The same is not true for transports. EPP relies on the layers beneath it for the security properties necessary to make EPP usable. The security concerns for each are not the same.
Furthermore, the guidance on the XML extensions is contained in an entire RFC, whereas the guidance for EPP transports is one page of high-level bullet points, one of which laughably mentions SMTP as a possible choice. The guidance for the DEs is not nearly the same. Plus, the EPP extension registry DEs are EPP experts, not security and transport experts. It is inappropriate for them to making judgements of this type. -andy, as an individual On 04-03-2026 4:43 PM, Gould, James wrote:
Andy, We need to consider the purpose of the EPP Extension Registry for any form of EPP extension. I believe the purpose of the EPP Extension Registry is to provide visibility for EPP extension specifications to help encourage consolidation, which is the case of EoH. I don't see EPP transports any differently from EPP XML extensions, since both can include security and private issues, which are not factors for consideration of the DE in draft-ietf-regext-ext-registry-epp. Please clarify your statement "security and transaction semantics wrong" with EoH since I haven't seen any supporting feedback on the mailing list. Please clarify your statement " EPP-over-HTTP discussion has focused a lot on the costs to the registries but nobody has mentioned the costs to the registrars" since I haven't seen any discussion on the mailing list associated with this. Your statement " New EPP transports should only be encouraged when the costs to all parties are weighed" doesn't align with the language in RFC 5730, where the intend was to support the extensibility of EPP transports. We presented multiple times to the REGEXT WG of the perceived value in adding the two new EPP transports for HTTPS and QUIC with draft-ietf-regext-epp-https and draft-ietf-regext-epp-quic. We should allow for the registration of all forms of EPP extensions in the EPP Extension Registry, where there are no additional hurdles defined in RFC 5730 for EPP transports other than meeting the recommendations in Section 2.1 of RFC 5730. Thanks,
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
