Hi Orie, Thank you for the approval! It's been noted at: https://www.rfc-editor.org/auth48/rfc9873
Sincerely, Sarah Tarrant RFC Production Center > On Oct 1, 2025, at 8:16 AM, Orie <[email protected]> wrote: > > I approve these changes. > > OS > > On Wed, Oct 1, 2025 at 8:08 AM Sarah Tarrant <[email protected]> > wrote: > Hi Scott and *Orie, > > *AD Orie - Could you please verify that the following update to BCP14 > language is approved? > > "employ" updated to "MUST employ" (parallel structure with "MUST NOT depend") > in: > > Original: > The XML namespace prefix "addlEmail" is used for the namespace > "urn:ietf:params:xml:ns:epp:addlEmail-1.0", but implementations MUST > NOT depend on it and instead employ a proper namespace-aware XML > parser and serializer to interpret and output the XML documents. > > Current: > The XML namespace prefix "addlEmail" is used for the namespace > "urn:ietf:params:xml:ns:epp:addlEmail-1.0", but implementations MUST > NOT depend on it and instead MUST employ a proper namespace-aware > XML parser and serializer to interpret and output the XML documents. > > Also viewable at: https://www.rfc-editor.org/authors/rfc9873-auth48diff.html > ---- > > Scott - Thank you for your reply. We have updated accordingly and have no > further questions. > > Please review the document carefully to ensure satisfaction as we do not make > changes once it has been published as an RFC. Contact us with any further > updates or with your approval of the document in its current form. We will > await approvals from each author prior to moving forward in the publication > process. > > The updated files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9873.txt > https://www.rfc-editor.org/authors/rfc9873.pdf > https://www.rfc-editor.org/authors/rfc9873.html > https://www.rfc-editor.org/authors/rfc9873.xml > > The relevant diff files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9873-diff.html (comprehensive diff) > https://www.rfc-editor.org/authors/rfc9873-auth48diff.html (AUTH48 changes > only) > > Note that it may be necessary for you to refresh your browser to view the > most recent version. > > For the AUTH48 status of this document, please see: > https://www.rfc-editor.org/auth48/rfc9873 > > Thank you, > Sarah Tarrant > RFC Production Center > > > > On Sep 25, 2025, at 7:19 AM, Hollenbeck, Scott > > <[email protected]> wrote: > > > >> -----Original Message----- > >> From: [email protected] <[email protected]> > >> Sent: Wednesday, September 24, 2025 8:18 PM > >> To: [email protected]; Gould, James <[email protected]>; Hollenbeck, > >> Scott <[email protected]> > >> Cc: [email protected]; [email protected]; [email protected]; > >> [email protected]; [email protected]; [email protected] > >> Subject: [EXTERNAL] Re: AUTH48: RFC-to-be 9873 > >> <draft-ietf-regext-epp-eai-27> > >> for your review > >> > >> 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. > >> > >> Authors, > >> > >> While reviewing this document during AUTH48, please resolve (as necessary) > >> the following questions, which are also in the source file. > >> > >> > >> 1) <!-- [rfced] Please insert any keywords (beyond those that appear in > >> the title) > >> for use on https://secure- > >> web.cisco.com/1ZsR3tGYN7sGtmWyn9l95Z7TcV61KEXYrZeD_Mpd713QOiokMKt > >> mX-DTM9CMYXKJTnWO2JMly51l2wU5UiVy29IY8elM6XJQB6r- > >> qOcS0EFbqisRIwH1gJ62BjM6ddzDPy5eRGJb2fxYehs3pt1-UZMvSKWzD- > >> JdACt2khJb5zW3oXNOfGhGvuNQBtKIfwCZ9FIEuSfmtsusZcvlPeujOupeOro2fm4D > >> w3M6Hgc7a5rPuPj4qd1Xe2_vvdNXktC8z4pyF2vdg8_gD8OF5z___rWwS90cbYIyf > >> sbuGZZsvGro/https%3A%2F%2Fwww.rfc-editor.org%2Fsearch --> > >> > >> > >> 2) <!-- [rfced] Should "employ" be updated to "MUST employ" (parallel > >> structure with "MUST NOT depend")? Or is the current correct? > >> > >> Original: > >> The XML namespace prefix "addlEmail" is used for the namespace > >> "urn:ietf:params:xml:ns:epp:addlEmail-1.0", but implementations MUST > >> NOT depend on it and instead employ a proper namespace-aware XML > >> parser and serializer to interpret and output the XML documents. > >> > >> Perhaps: > >> The XML namespace prefix "addlEmail" is used for the namespace > >> "urn:ietf:params:xml:ns:epp:addlEmail-1.0", but implementations MUST > >> NOT depend on it and instead MUST employ a proper namespace-aware > >> XML parser and serializer to interpret and output the XML documents. > >> --> > > > > [SAH] The proposed update is correct. > > > >> 3) <!-- [rfced] This sentence is a bit hard to follow because of the many > >> commas. We added parentheses rather than commas around the "defined in" > >> phrases and added "to support" before "U-label" in this sentence. Please > >> let us > >> know any concerns. > >> > >> Original: > >> [RFC6531] extends the > >> Mailbox, Local-part and Domain ABNF rules in [RFC5321] to support > >> "UTF8-non-ascii", defined in Section 3.1 of [RFC6532], for the local- > >> part and U-label, defined in Section 2.3.2.1 of [RFC5890], for the > >> domain. > >> > >> Current: > >> [RFC6531] extends the > >> Mailbox, Local-part, and Domain ABNF rules in [RFC5321] to support > >> "UTF8-non-ascii" (defined in Section 3.1 of [RFC6532]) for the local- > >> part and to support U-label (defined in Section 2.3.2.1 of [RFC5890]) > >> for the > >> domain. > >> --> > > > > [SAH] The proposed update is fine. > > > >> 4) <!-- [rfced] Should "that support" here be updated to just "support"? > >> Is is > >> another meaning intended? > >> > >> Original: > >> * Any address included in an extension is intended to be an > >> additional address that's associated only with the primary > >> <contact:email> address, and that support for any other additional > >> email addresses MUST explicitly describe how the additional > >> addresses are associated with the existing addresses. > >> > >> Perhaps: > >> * Any address included in an extension is intended to be an > >> additional address that is associated only with the primary > >> <contact:email> address, and support for any other additional > >> email addresses MUST explicitly describe how the additional > >> addresses are associated with the existing addresses. > >> --> > > > > [SAH] The proposed update is fine. > > > >> 5) <!-- [rfced] In the first bulleted list in Section 4.2.1, the list > >> items all begin > >> with a verb except for the following one. How may we update this one to > >> create > >> parallel structure? > >> > >> Original: > >> * Storage of email properties that support internationalized > >> characters. > >> > >> Perhaps: > >> * Store email properties that support internationalized > >> characters. > >> > >> Or: > >> * Maintain storage of email properties that support internationalized > >> characters. > >> --> > > > > [SAH] I prefer "Store email properties". Please make that change. > > > >> 6) <!-- [rfced] This document includes 8 figures. For each of them, the > >> text > >> introducing the figure and the figure title are almost identical. We > >> suggest > >> removing the intro text and keeping the figure title to avoid redundancy. > >> Let us > >> know your thoughts. > >> > >> Example: > >> > >> The following is an example <info> contact response using the > >> <addlEmail:addlEmail> extension with no alternate email address: > >> ... > >> Figure 1: Example <info> Contact Response Using the > >> <addlEmail:addlEmail> Extension with No Alternate Email Address > >> --> > > > > [SAH] The proposed update is fine. > > > >> 7) <!-- [rfced] Should the title of Section 5.1.3 be updated from "Query > >> Command" > >> to just "Command" for consistency with the other titles in this section? > >> > >> Original: > >> 5.1. EPP Query Commands > >> 5.1.1. EPP <check> Command > >> 5.1.2. EPP <info> Command > >> 5.1.3. EPP <transfer> Query Command > >> > >> Perhaps: > >> 5.1. EPP Query Commands > >> 5.1.1. EPP <check> Command > >> 5.1.2. EPP <info> Command > >> 5.1.3. EPP <transfer> Command > >> --> > > > > [SAH] Please keep the text as-is. The current text is consistent with the > > core EPP RFCs and helps distinguish query commands from transform commands. > > > >> 8) <!-- [rfced] How may we update "an object mapping like [RFC5733]" > >> in these sentences? Is the intended meaning "an object mapping like the one > >> described in [RFC5733]" or something else? > >> > >> Original: > >> This extension defines additional elements to extend the EPP <create> > >> command of an object mapping like [RFC5733]. > > > > [SAH] Please use this: "This extension defines additional elements to > > extend the EPP <create> command described in [RFC5733]." > > > >> ... > >> In addition to the EPP > >> command elements described in an object mapping like [RFC5733], the > >> command MUST contain a child <addlEmail:addlEmail> element > >> (Section 3) for the client to set an alternate email address. > > > > [SAH] Please use this: "In addition to the EPP command elements described > > in [RFC5733]..." > > > >> This extension defines additional elements to extend the EPP <update> > >> command of an object mapping like [RFC5733]. > > > > [SAH] Please use this: "This extension defines additional elements to > > extend the EPP <update> command described in [RFC5733]." > > > >> In addition to the EPP > >> command elements described in an object mapping like [RFC5733], the > >> command MUST contain a child <addlEmail:addlEmail> element > >> (Section 3) for the client to set or unset an alternate email > >> address. > >> > > [SAH] Please use this: "In addition to the EPP command elements described > > in [RFC5733]..." > > > >> Perhaps: > >> This extension defines additional elements to extend the EPP <create> > >> command of an object mapping like the one described in [RFC5733]. > >> ... > >> In addition to the EPP > >> command elements described in an object mapping > >> (like the one in [RFC5733]), the > >> command MUST contain a child <addlEmail:addlEmail> element > >> (Section 3) for the client to set an alternate email address. > >> ... > >> This extension defines additional elements to extend the EPP <update> > >> command of an object mapping like the one described in [RFC5733]. > >> ... > >> In addition to the EPP > >> command elements described in an object mapping > >> (like the one in [RFC5733]), the > >> command MUST contain a child <addlEmail:addlEmail> element > >> (Section 3) for the client to set or unset an alternate email > >> address. > >> --> > > > > [SAH] See above. > > > >> 9) <!-- [rfced] Should this sentence be updated to include "XML schemas"? > >> We > >> ask because we see this in other RFCs (e.g., RFCs 9167, 9095, 9022). > >> > >> Original: > >> This document uses URNs to describe XML namespaces conforming to a > >> registry mechanism described in RFC 3688 [RFC3688]. > >> > >> Perhaps: > >> This document uses URNs to describe XML namespaces and XML schemas > >> conforming to a > >> registry mechanism described in [RFC3688]. > >> --> > > > > Yes, please make that change. > > > >> 10) <!-- [rfced] Would including a citation for "IDNA2008" be helpful for > >> readers? Perhaps to [RFC5895]? Also, how may we clarify what the > >> domain-part > >> should conform to? > >> > >> Original: > >> The domain-part of these SMTPUTF8 email addresses SHOULD > >> conform to IDNA2008. > >> > >> Perhaps: > >> The domain-part of these SMTPUTF8 email addresses SHOULD > >> conform to the guidelines in IDNA2008 [RFC5895]. > >> --> > > > > Please cite RFC 5891. It describes the protocol for label syntax. > > > >> 11) <!-- [rfced] May we revise "of the code points allowed by IDNA Rules > >> and > >> Derived Property Values" in one of the following ways? > >> > >> Original: > >> To reduce the risk of the use of invalid domain names in email > >> addresses, registries SHOULD validate the domain name syntax in > >> provided email addresses and validate whether the domain name > >> consists of the code points allowed by IDNA Rules and Derived > >> Property Values (https://secure-web.cisco.com/1QFzD_XnkNpfB- > >> WjBVrf6PbAKJWlemKY6666-LVqc7AP5Hw8Yx4- > >> PC7WNNcNf8ca5GNaoN9ZWfudjr_o_5FxHfWhm62gviz3MtWMsxwWvM0u8wQ > >> yp07c5MjDVy3owwZEqpgrfLBnPf- > >> 7fJ_rID3J_onz2uI49JAfv8s3LJ2eaizVJYKH1EmZPy2yTqzKb7bS2xKwggi7fTdEg8hUG > >> aEhpYmt_k9MFsa4Pzzw-m8U3CvdNHBYGIb3RALPhCcCW2AUc- > >> 6bMf7mF9jWYtRNDuAJwCVkVHmwvvFDrEk- > >> 5q4MibRE/https%3A%2F%2Fwww.iana.org%2Fassignments%2Fidna-tables). > >> > >> Perhaps: > >> To reduce the risk of the use of invalid domain names in email > >> addresses, registries SHOULD validate the domain name syntax in > >> provided email addresses and validate whether the domain name > >> consists of the code points listed in the "IDNA Rules and Derived > >> Property Values" registry (https://secure-web.cisco.com/1QFzD_XnkNpfB- > >> WjBVrf6PbAKJWlemKY6666-LVqc7AP5Hw8Yx4- > >> PC7WNNcNf8ca5GNaoN9ZWfudjr_o_5FxHfWhm62gviz3MtWMsxwWvM0u8wQ > >> yp07c5MjDVy3owwZEqpgrfLBnPf- > >> 7fJ_rID3J_onz2uI49JAfv8s3LJ2eaizVJYKH1EmZPy2yTqzKb7bS2xKwggi7fTdEg8hUG > >> aEhpYmt_k9MFsa4Pzzw-m8U3CvdNHBYGIb3RALPhCcCW2AUc- > >> 6bMf7mF9jWYtRNDuAJwCVkVHmwvvFDrEk- > >> 5q4MibRE/https%3A%2F%2Fwww.iana.org%2Fassignments%2Fidna-tables). > >> > >> Or: > >> To reduce the risk of the use of invalid domain names in email > >> addresses, registries SHOULD validate the domain name syntax in > >> provided email addresses and validate whether the domain name > >> consists of the allowed code points, i.e., those allocated in the > >> "IDNA Rules and Derived Property Values" registry > >> (https://secure-web.cisco.com/1QFzD_XnkNpfB-WjBVrf6PbAKJWlemKY6666- > >> LVqc7AP5Hw8Yx4- > >> PC7WNNcNf8ca5GNaoN9ZWfudjr_o_5FxHfWhm62gviz3MtWMsxwWvM0u8wQ > >> yp07c5MjDVy3owwZEqpgrfLBnPf- > >> 7fJ_rID3J_onz2uI49JAfv8s3LJ2eaizVJYKH1EmZPy2yTqzKb7bS2xKwggi7fTdEg8hUG > >> aEhpYmt_k9MFsa4Pzzw-m8U3CvdNHBYGIb3RALPhCcCW2AUc- > >> 6bMf7mF9jWYtRNDuAJwCVkVHmwvvFDrEk- > >> 5q4MibRE/https%3A%2F%2Fwww.iana.org%2Fassignments%2Fidna-tables). > >> --> > > > > [SAH] I like the first option. Please use it. > > > >> 12) <!-- [rfced] Would you like the references to be alphabetized or left > >> in their > >> current order? > >> --> > > > > [SAH] Alphabetized, please. > > > >> 13) <!-- [rfced] We note inconsistencies in the terms below throughout the > >> text. > >> Should these be uniform? If so, please let us know which form is preferred. > >> > >> command-response extension > >> command and response extension > > > > [SAH] Please use "command-response extension". > > > >> local-part > >> localpart > > > > [SAH] Please use "local-part". > > > >> ASCII alternate email address > >> alternate ASCII email address > > > > [SAH] Please use "alternate ASCII email address". > > > >> all-ASCII > >> ASCII-only > >> --> > > > > [SAH] Please use "ASCII-only". > > > >> 14) <!-- [rfced] FYI - We have added expansions for the following > >> abbreviation(s) per Section 3.6 of RFC 7322 ("RFC Style Guide"). > >> Please review each expansion in the document carefully to ensure > >> correctness. > >> > >> Registration Data Access Protocol (RDAP) > >> --> > > > > [SAH] That's fine. > > > >> 15) <!-- [rfced] Please review the "Inclusive Language" portion of the > >> online > >> Style Guide <https://secure- > >> web.cisco.com/1EpIBqSv2djqdFD93a4O8wDFONc_xXs77r5iDr0IxJH8rDbwRjGoJ > >> Cttj7vhViX3oclmCBN1EBVn4Cx5U39cniNr2HwK4Jtx3vPzraPFY91-kDXjPan4fiBO- > >> wbUcxyruUWBvQ_g6vEc6XjiZtCnubr9ameNHduVMbuqjbj24CK38hS5D9qWtPpZ > >> _POtDEVL7q3flhYzM6HphC30lVgRmEb1e_u3KTGplalMRcXxLtU60y8- > >> 499SM5GeTzO_a9uMCavuMOD4EjxPB2zLIx21bzV9ypOMqI9ocH- > >> KuQGo_E18/https%3A%2F%2Fwww.rfc- > >> editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language> > >> and let us know if any changes are needed. Updates of this nature > >> typically > >> result in more precise language, which is helpful for readers. > >> > >> For example, please consider whether "natively" should be updated: > >> > >> Original: > >> The Extensible Provisioning Protocol (EPP) does not natively support > >> internationalized email addresses because the specifications for > >> these addresses did not exist when the EPP was developed. > >> --> > > > > [SAH] Please change "natively" to "inherently". > > > >> Thank you. > >> > >> Sarah Tarrant and Rebecca VanRheenen > >> RFC Production Center > >> > >> > >> > >> On Sep 24, 2025, at 5:13 PM, [email protected] wrote: > >> > >> *****IMPORTANT***** > >> > >> Updated 2025/09/24 > >> > >> RFC Author(s): > >> -------------- > >> > >> Instructions for Completing AUTH48 > >> > >> Your document has now entered AUTH48. Once it has been reviewed and > >> approved by you and all coauthors, it will be published as an RFC. > >> If an author is no longer available, there are several remedies available > >> as listed > >> in the FAQ (https://secure- > >> web.cisco.com/1SMDEezwBs_KZJJS2lPui3tlV6zSuw5ZvQ1TnfVZbL1Qf_u63P0Ga3 > >> VZTkSEix5kzgiysmVi- > >> IiLgRQXPaoG9L6Vhr3DKws29IBfIBcG3sz3PgP8KNnKlQrz7qRpbveCanQ6- > >> 8LvlVsGgra58UI8f3rMJT7FLgH8_ud3H7_xaW- > >> ucDI1QFSFApgC2SnmVB4ZmqOw7_E8XqVLYePO6VNkDDincRKqArlvlo5TQsl7uek > >> Qf5rsE5eUC0NpRoZO4a- > >> EivKv0B0SbDCSVoRzfzLVlUP9MblIKIkAbAs3r5dGi6fE/https%3A%2F%2Fwww.rfc- > >> editor.org%2Ffaq%2F). > >> > >> You and you coauthors are responsible for engaging other parties (e.g., > >> Contributors or Working Group) as necessary before providing your approval. > >> > >> Planning your review > >> --------------------- > >> > >> Please review the following aspects of your document: > >> > >> * RFC Editor questions > >> > >> Please review and resolve any questions raised by the RFC Editor > >> that have been included in the XML file as comments marked as > >> follows: > >> > >> <!-- [rfced] ... --> > >> > >> These questions will also be sent in a subsequent email. > >> > >> * Changes submitted by coauthors > >> > >> Please ensure that you review any changes submitted by your > >> coauthors. We assume that if you do not speak up that you > >> agree to changes submitted by your coauthors. > >> > >> * Content > >> > >> Please review the full content of the document, as this cannot > >> change once the RFC is published. Please pay particular attention to: > >> - IANA considerations updates (if applicable) > >> - contact information > >> - references > >> > >> * Copyright notices and legends > >> > >> Please review the copyright notice and legends as defined in > >> RFC 5378 and the Trust Legal Provisions > >> (TLP – https://secure- > >> web.cisco.com/1Bl31SM1PL4FeEsFoc62h3C3DZpYU_IynOdIK- > >> SfwKLER5l3jPbClR9XUIRg_lC6t4yDqwn8Bp9AAl7LPeSgTstqXAQkg- > >> P5SkVRwr9QwMWzSfNfRsBG-fWEmr_X-bmB7RqxbE7aH_rHEMVCxmwFNo- > >> 4As95V9ueztFUlgBundjmgegmctF3- > >> ilF07DsHDwM7rEJdJ4bw7WI6dJ2gvurt4oNgeZ7CZAbZbIgDRFYTQygl2YfQa4zzMH > >> sKIv90QwAgL5VpVhD2YjbXksucJ5EyVzS27esGVQ8jqKhwNb8O94pSQI5EE_6GIb_A > >> rpfDt49h/https%3A%2F%2Ftrustee.ietf.org%2Flicense-info). > >> > >> * Semantic markup > >> > >> Please review the markup in the XML file to ensure that elements of > >> content are correctly tagged. For example, ensure that <sourcecode> > >> and <artwork> are set correctly. See details at > >> <https://secure- > >> web.cisco.com/12sdMCyHc7pYxvWwY3NeiV7uSCsLjOnFg7gn_PjezxAM92Fuy7J1 > >> _F1-vcETGHeLM2IJt-VYY6oueRl_eXCFG7W1bNgz- > >> QH32qh7M0NOOf07XlQZnfba5u3HkZOi7WeechNWZGVbwd5qzUkmH9SlfLEki8f > >> xa5j9AYzZ1r3VgOZXTQMzU2zYWnosLdia3j7e1dwDX6S0tStUO8cdG6aI0jAAYX1y6 > >> kTQY-Q0685DWZerGmpNAblDgCTsGP- > >> SIbPgOdUmGOFIrLB2h0pZwXmiChyq7BfVoJJK- > >> _cqcOvg41doCzNd0ZFekRt0dmpFpFuJ5/https%3A%2F%2Fauthors.ietf.org%2Frfcx > >> ml-vocabulary>. > >> > >> * Formatted output > >> > >> Please review the PDF, HTML, and TXT files to ensure that the > >> formatted output, as generated from the markup in the XML file, is > >> reasonable. Please note that the TXT will have formatting > >> limitations compared to the PDF and HTML. > >> > >> > >> Submitting changes > >> ------------------ > >> > >> To submit changes, please reply to this email using ‘REPLY ALL’ as all the > >> parties > >> CCed on this message need to see your changes. The parties > >> include: > >> > >> * your coauthors > >> > >> * [email protected] (the RPC team) > >> > >> * other document participants, depending on the stream (e.g., > >> IETF Stream participants are your working group chairs, the > >> responsible ADs, and the document shepherd). > >> > >> * [email protected], which is a new archival mailing list > >> to preserve AUTH48 conversations; it is not an active discussion > >> list: > >> > >> * More info: > >> https://secure- > >> web.cisco.com/1gGvT3G5FYK57VrPulrNDqWgIFnNxCUISnWKiGSbYV93FiR- > >> aUI3DTXRzujqd6sXms-JhMeQGeiL4h83UuqtTtovSVALbLVxzL- > >> sSNlEgmCcPPeUFK2R9kaeoXGVHXI0oTfbXXGrAluayAmaDzYqyu- > >> bY8ZfDoW5TQwT-- > >> Gi421h1Mav8peZSjuJEsrNN8PoySQyzJTFqlOcboUy80ggm5_l0iYiU6bmoEFN5pDf > >> Q9-REZm- > >> HyKmuu5s_iG1oB9HOp0JGG3Znw8VxYscoJPneEsmKbfMH9rLnrq0iw3W75g- > >> P7Uq6iRyUwhl_Q8gzbThC/https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg > >> %2Fietf-announce%2Fyb6lpIGh-4Q9l2USxIAe6P8O4Zc > >> > >> * The archive itself: > >> https://secure- > >> web.cisco.com/1dMdiH4Ww9O4fozg6fIQm7NNVrz2FVKAwv3nf_hiHjA5SvUY1V > >> QexD6yblQ4hETrHjUXBEzo2N- > >> SdALsf7NF7ynbZOEQfzHiqSsS50ImtUQ2K_qZR8MxSC8YXrUCSiyr8RES61c- > >> p4G9m1mmSMa8qifaZcZxRoc0OEk9Fb6_TJun73nWBrSAaSeGRQ7mFN3qveba0t > >> ZRJnDLbd873bv0yO2wyE_Iw39gy9WxoqDfDywniWugsZVZ8JdfRIO8KUu-akmTi- > >> feWnnFSr32bqQXURBJ9hChgWadWD_fjmL8zfw6Pxuxx2dRV2PTlIk1NurDI/https% > >> 3A%2F%2Fmailarchive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F > >> > >> * Note: If only absolutely necessary, you may temporarily opt out > >> of the archiving of messages (e.g., to discuss a sensitive matter). > >> If needed, please add a note at the top of the message that you > >> have dropped the address. When the discussion is concluded, > >> [email protected] will be re-added to the CC list and > >> its addition will be noted at the top of the message. > >> > >> You may submit your changes in one of two ways: > >> > >> An update to the provided XML file > >> — OR — > >> An explicit list of changes in this format > >> > >> Section # (or indicate Global) > >> > >> OLD: > >> old text > >> > >> NEW: > >> new text > >> > >> You do not need to reply with both an updated XML file and an explicit > >> list of > >> changes, as either form is sufficient. > >> > >> We will ask a stream manager to review and approve any changes that seem > >> beyond editorial in nature, e.g., addition of new text, deletion of text, > >> and > >> technical changes. Information about stream managers can be found in the > >> FAQ. Editorial changes do not require approval from a stream manager. > >> > >> > >> Approving for publication > >> -------------------------- > >> > >> To approve your RFC for publication, please reply to this email stating > >> that you > >> approve this RFC for publication. Please use ‘REPLY ALL’, as all the > >> parties CCed > >> on this message need to see your approval. > >> > >> > >> Files > >> ----- > >> > >> The files are available here: > >> https://secure- > >> web.cisco.com/15cD5SQVJ0QC9wMhyG4ZfCEMC6og4GtyFRUl2Y1xGFDkWfhQc > >> gVHwvx1FdfvelF- > >> ZsY1ROjyOpdFI5ZE8sezuKzG9UNvq5CQX5EfKc4vmPumnxsldAa_gqZEeEDjG9WrH > >> KXm- > >> S9R0KPjuBiCIG5EdxLI00bzn53sOrizFWlCtFQt7rWQyZqegdh8hUT6wrn50cBz10zV > >> 4QG_3ciCH44xkhl3ZtjyVoH2IuFl- > >> 3wC69lCjwUsmDpf8HasQntep5JfnwlQPIlHzNtPeDj60K8EHXJ5nfYYzDKnaD9k1As > >> 6yu9Q/https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9873.xml > >> https://secure- > >> web.cisco.com/1aov7ozWUKJ1e6UvJbaH4OgFj1UEOjpa8sFyeMdG8DXzV5Uxxu7 > >> r0ACwFZZXAooJ8EhPzi2KXC4pmmy78BOHw3I097APdKGy4_virvaP_MeQEFMkm > >> d672cCAmBRGZ7LpdPmZVyLslYT03- > >> Br94vcg2RpVyOBhrRLb4y1zHn8K0CnE7IkQizdDWQhr_w- > >> cQmdTuMm6mWbExRelrBSc8hSUyYyAWswM1X6mwMWpXuD9pq7k9HyLneKM > >> Nx87yuHq- > >> 6Sa8CJh8iWBMojWchMBD9lON6ytaaNAXXsyrlDY4ks7jd4/https%3A%2F%2Fww > >> w.rfc-editor.org%2Fauthors%2Frfc9873.html > >> https://secure- > >> web.cisco.com/16_b4T6_KXjXOwtSaJakSbTczCe0RTR2wg6Nwl0VelEjvmXEbeT- > >> 4YxNhRErMKd3W1evOMpeHJLiFuU- > >> Lbe1pipqiRVerLBy5XUwO2LtmF5CaSZDICxYLXESmZvmeGyY8tI5Iyx9a5tKbiPCnu7 > >> - > >> oRvYwP4eFpI7oSs_8pPwSrawZixeVdbzLRQ72FbpMdE7EsFsHd3neFyCIzUE2Mc5Ht > >> m0V4p_xWaqDiJsClOjGxWyKjxKsIwzmsY9UCXFsjkmUo37NkVFMROtQIZYe4hpER > >> Va3afDJAIqySgFhKgPoux4/https%3A%2F%2Fwww.rfc- > >> editor.org%2Fauthors%2Frfc9873.pdf > >> https://secure- > >> web.cisco.com/17q74dIkjQHVpNQdfQWmyXQoPSxUIEpY4FkePbIB3268WY6KrQr > >> Hw6FMffUTXUMTD0m2Wjmsnnnh52RbiWQXbb96nCvJ8XwHSxofqXrJ3LAgVON4 > >> 3naAJLvLBKjjS06vSVmzUfPnIOv8Wk57QjSEnZlWB23_7VAUzYt8OrIhVhDZPpKSW8 > >> 71OCB4kF2PAjj7C_ySXHb3dgBTfOwckVWVzNbwssHvoOJAUjTXBxmyLOGusi3ycx0 > >> qltp2JGokZ3qRVrkUH2rsiZCJ4M__cUTDzShtFH4WbYl- > >> Y7T729cJGlGQ/https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9873.txt > >> > >> Diff file of the text: > >> https://secure-web.cisco.com/1vF1CXnVPqrBUQzQUqOOruKVFpG- > >> O0sGXtCZYiT2PgPHkSVLGNLzZs7y8PXH3dOSaQpLHdb5IPh_er_2MLvoGGWyn8zX > >> d8yKJBNUaH7D6zLNm248V- > >> QFmDm3ilvP5wwr4SQ8o5wVdJEtvLXMingYI0WmKr575QZT9TzokKEq3n9Kyx7dtX > >> eXBy_LmJa5j_PxZiRyixlZ9Y9yXQC1jKmY9xSfx_XvCEnpVBAA0anCCdTi6HjBAz1PY > >> pF71lr9OiWBAClSNyXn0jKIJ69ZokmHmMcOiZXFOHvJUc7qU7wOcZK8/https%3A > >> %2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9873-diff.html > >> https://secure- > >> web.cisco.com/1suXYshBTkNkJVTMrtcBxfUXNlWG9KQY0lsao8oq66aUVIOhtLA5i > >> PGvJZaYmbLnlEpeQ_-i7LgLRtGWoDchy_- > >> ZHyHg4CNEyAs1ZNXBFmLmVm3ebwTUlRDQ3H- > >> pT0I4ezGr2dNSV2UZxPcEOeFnXoH0UPyjR4TK5sa-fye7- > >> qP_B328TNAmmU4uwiq0ocSq82xZqIlJ4jV_Xv5mKQv0wIDcQlFydj- > >> FVw4HGQcHNqhxnvmPtJe7O13R1zhdbGwUOBHDTq4qLxHzJCKalDb03lJGe9w9U > >> HG07coX7ycIgcyU/https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9873- > >> rfcdiff.html (side by side) > >> > >> Alt-diff of the text (allows you to more easily view changes where text > >> has been > >> deleted or moved): > >> https://secure- > >> web.cisco.com/1Vy0YPAxThzplZn_o_brqIxPoxZW5_MFoK7DMQfBEb9K- > >> CEIhaAQYGtbmS6cyqCyNfZ4Xg7VlnWQz4ya9E43ym93Kd2QC_FTqsi7IN7510Oatc > >> gBDiNrTksxYwcbFKIQRdGn86erG04CLa9Dfqc5YDuGaIdc9GcZO5dk7xAW_MegJY > >> kvzrQydifJVLSQt4a1qKill9tZlJ7k5O04xNo_S4ztploVGiNYYMAama5ZVjAmjmNp0 > >> M5Dx1- > >> L7o73JbYZZx4u24fmqXP5qqsPUjV7DfpPVHLFdzob_scqsqVzJ3JM/https%3A%2F%2 > >> Fwww.rfc-editor.org%2Fauthors%2Frfc9873-alt-diff.html > >> > >> Diff of the XML: > >> https://secure-web.cisco.com/1RnKtMmFg3ckDhh_j3PP- > >> WWG5v3GhhUboraAr5dxNBF- > >> m40DBOQ0pIj7WXcoBsSWLJyGlah1ZRjisxJcXuJmCXijBMn7aqzNvHjz1RPqTdFgIG > >> nXQCpz_LIxWENC9VYJpr1eAw40kiZp5Wf9zgf5ng0JMmLNhaaFSSNjzapO7uuJbth > >> 3HKBRh69a4nBkZzEhvERhbBhDR- > >> L3UCBGVuFF6SA5cUoHiGomIFFjOZYUM09mEmZmaRC69pjOXGci8owkoToPOr4Y > >> nu_KZetx-_YwSfLLC-oJFhU0ko8yuM8HmINk/https%3A%2F%2Fwww.rfc- > >> editor.org%2Fauthors%2Frfc9873-xmldiff1.html > >> > >> > >> Tracking progress > >> ----------------- > >> > >> The details of the AUTH48 status of your document are here: > >> https://secure- > >> web.cisco.com/1F3mmFN6jW2rMOmMHTNhUXaDWBFn0lFosMJGtrpiJYQtPcez > >> OJDQKPSkM7NupCQ1RVWSOng81kXXsATb8xcqGIJz6CE99tywd6mAbKgC6ercJFrt > >> bL6Fo549k1zRlj5fHNYlNI8dAL8Rwnwfg17SEz- > >> oR3i_t2Rh4gkwz20YL8BViQoBj76fUBwtnnfzbxAzrV4f8ZJFkDA0wOOyZNtNfbq0dt > >> E6FO70tqtwoqTRbgTMGonmtucP0n-ltzn-M44vVUGR3KNGwaT1dI5ek- > >> Lbj7Bth9Az-BXgJ4QL1wF_Agjk/https%3A%2F%2Fwww.rfc- > >> editor.org%2Fauth48%2Frfc9873 > >> > >> Please let us know if you have any questions. > >> > >> Thank you for your cooperation, > >> > >> RFC Editor > >> > >> -------------------------------------- > >> RFC9873 (draft-ietf-regext-epp-eai-27) > >> > >> Title : Additional Email Address Extension for the Extensible > >> Provisioning > >> Protocol (EPP) > >> Author(s) : D. Belyavsky, J. Gould, S. Hollenbeck > >> WG Chair(s) : James Galvin, Antoin Verschuren, Jorge Cano > >> Area Director(s) : Andy Newton, Orie Steele > > > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
