> -----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]
