Scott, Thank for the precise update.
For the transports, if we can't get to consensus on including them in the EPP extension registry, maybe we can go with Pawel's suggestion in creating a new EPP transports IANA registry, which would include RFC 5734 to start for EoT and can include registrations for EoH and EoQ. The registry would need to be defined in one of the new transport drafts. Would we define the EPP transport registry in both and then remove it from the transport that progresses last? I don't believe removing the text is necessary unless there is a better proposal on the purpose of the EPP extension registry to replace it with. Thanks, -- JG James Gould Fellow Engineer [email protected] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 3/11/26, 12:06 PM, "Hollenbeck, Scott" <[email protected] <mailto:[email protected]>> 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. The last call for this draft ended on 9 March. I'm going to publish an updated draft on 14 March (we're currently in the draft lockout period ahead of IETF-125) that includes the following: Updated "XML schemas, XML schema URIs, and XML namespace URIs" wording in Section 2.2.1. Noted that the value of "TLDs" can be "N/A" in Section 2.2.2. Updated "removed or deactivated" wording in Section 2.2.3. Changed RFC 3735 from an informative reference to a normative reference. In my opinion as editor, we had support for all of these changes. There were two other topics raised during the last call for which I don't believe we had support to make changes. These include: Adding text to describe how to register new EPP transports in the extension registry. A suggestion to remove this text from Section 1: > RFCs 3735 and 5730 do not describe how extension development can be managed > and coordinated. This has led to a situation in which server operators can > develop different extensions to address similar needs, such as the > provisioning of Value Added Tax (VAT) information. Clients then need to > support multiple extensions that serve similar purposes, and interoperability > suffers as a result. > > An IANA registry can be used to help manage and coordinate the development of > protocol extensions. This document describes an IANA registry that will be > used to coordinate the development of EPP extensions. Did I miss anything? Scott _______________________________________________ regext mailing list -- [email protected] <mailto:[email protected]> To unsubscribe send an email to [email protected] <mailto:[email protected]> _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
