Who are you waiting for? If one is me, I approve.

Scott

> -----Original Message-----
> From: Sarah Tarrant <[email protected]>
> Sent: Monday, October 6, 2025 9:20 AM
> To: Dmitry Belyavsky <[email protected]>
> Cc: Orie <[email protected]>; Hollenbeck, Scott <[email protected]>; RFC
> Editor <[email protected]>; Gould, James <[email protected]>;
> [email protected]; regext-chairs <[email protected]>; Jody Kolker
> <[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.
>
> Hi Dmitry,
>
> Thank you for the approval! It's been noted at: https://secure-
> web.cisco.com/1Qz7Ro9B5TmCMJOaxEQQcbAFuuQfSw3y8ZDQ9L6g_JBBZE6R8
> 9nkllhaDYRD400cVsMQBppg2mSJyWpYfOxIzgFbtD2jJ8SIipMWouraec15AIk42C7
> YNuBkF-w88qaqJQla3zBlsnvn7PydUTh8ROhaT-R5VjlbfSNrhlVGh1P6A9kwV2-
> htd5HNHTnB6V9fw1m-
> 3PzsOyWeGM531uKEH0qOJK15vtK8WS7cIDHuwODWADeYTZD4dosBEugFQDq2
> 7KTuAfGdHgkAwpTMJMsBw5FR9hEi_G8Hrhg5qXJ3pEcvdnHrkjvjbkRTaxYkBeXP/
> https%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc9873
>
> We now only await two remaining approvals.
>
> Sincerely,
> Sarah Tarrant
> RFC Production Center
>
> > On Oct 6, 2025, at 7:53 AM, Dmitry Belyavsky <[email protected]> wrote:
> >
> > Certainly I do
> >
> > SY, Dmitry Belyavsky
> >
> > Dne po 6. 10. 2025 14:49 uživatel Sarah Tarrant <[email protected]
> editor.org> napsal:
> > Hi Dimitry,
> >
> > To approve, just reply that you approve :)
> >
> > Thank you,
> > Sarah Tarrant
> > RFC Production Center
> >
> > > On Oct 5, 2025, at 10:14 AM, Dmitry Belyavsky <[email protected]>
> wrote:
> > >
> > > How do I approve the RFC as the author?
> > >
> > > On Wed, Oct 1, 2025 at 3:20 PM Sarah Tarrant
> > > <[email protected]> wrote:
> > >>
> > >> Hi Orie,
> > >>
> > >> Thank you for the approval! It's been noted at:
> > >> https://secure-
> web.cisco.com/1Qz7Ro9B5TmCMJOaxEQQcbAFuuQfSw3y8ZDQ9L
> > >>
> 6g_JBBZE6R89nkllhaDYRD400cVsMQBppg2mSJyWpYfOxIzgFbtD2jJ8SIipMWoura
> e
> > >> c15AIk42C7YNuBkF-w88qaqJQla3zBlsnvn7PydUTh8ROhaT-
> R5VjlbfSNrhlVGh1P6
> > >> A9kwV2-htd5HNHTnB6V9fw1m-
> 3PzsOyWeGM531uKEH0qOJK15vtK8WS7cIDHuwODWAD
> > >>
> eYTZD4dosBEugFQDq27KTuAfGdHgkAwpTMJMsBw5FR9hEi_G8Hrhg5qXJ3pEcvd
> nHrk
> > >> jvjbkRTaxYkBeXP/https%3A%2F%2Fwww.rfc-
> editor.org%2Fauth48%2Frfc9873
> > >>
> > >> 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]
> editor.org> 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://secure-
> web.cisco.com/1bimPcfrUSAh9B0nFB4gS5xmKHoNvV62rC1YM
> > >>> ywyIx1jL23y1zAvNT2-
> pIKD1T7OQnjXRX7Cd6VT8UEgrxzeYTOCseeCZQlMiUGQMKw
> > >>> Uz24qA-s-kgqlNGvzPhK2sA8OAqzYA6WRy--veV3rxEwXwWpE-
> K8uNxio3xePsdrpm
> > >>>
> gDEvNDh9IBW7PHUHqEbcKUCqaH_BU28HQuRS84l6F_FPYIrX_yw0MrG5yEuFzaJ
> 7xS
> > >>> SL0CcuX_i3KHfoGNy44qVEQgpPUJY7sa-
> CbONoEteHDJYx7KGeqkwhad8h18V7pI0T
> > >>> YGwggPe-JxC3qZfOZCMX/https%3A%2F%2Fwww.rfc-
> editor.org%2Fauthors%2F
> > >>> 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://secure-
> web.cisco.com/1F_6FGoNNiZC1NUPi2mwARwH8msHLJJ7u_8gF
> > >>> 0QHVUO99lT4YQkCYv83a6v0rH3-
> wNmfPAWDb7QIBa3JAiwAAuB51sp7zQzNFZGHgoG
> > >>>
> rF5Bv36Bo1KVOjJMUE7R8qD6Zjc9CuQLbJCJsg1agpHpcALOzgqVbUpB5V8yXLA6k
> E
> > >>>
> hHPCrrHavKVYVjQscYCAMW1iOWhd4BQw9yK2YLeIErRoAhIpWIOGfIIvmTWmvf
> dLpy
> > >>> FRQm0UOk-
> QPI96rrM_6CmrF4RG8K6_F46JPAFWIrHaPQ97mdtOzsaC4C9-X75TJxnB
> > >>> NDVVlmPUz-4K44-mdJmF/https%3A%2F%2Fwww.rfc-
> editor.org%2Fauthors%2F
> > >>> rfc9873.txt
> > >>> https://secure-
> web.cisco.com/1Y9dbRH3LvEB7tRZ8vDLC_CtA_oOL6Y92Dxp5
> > >>> LhewmvFPK4LDBwq-UTO-n8OcTPMyVF1-
> MAPzjSQz98zJq36NlWs0G9E0BLukxsw8Nd
> > >>>
> fUCdH37kqCN0hRx5bouWNNbuL7udQigX3K8Dsdq7KnzLLQvGKJ5a9DqNaBt4z9aF
> C2
> > >>> OfWLjfnauDeiBKM2PYhXrCZUgu_G6a-7Q9TNMh-
> T7oa0xkpImeuzMB4UaLcTiC5HD9
> > >>>
> 6x3PswnGjgCVDkUmBlLCUSCCTIaV9FhAYF0xjY1YDBFhtKABK46TEgyMS8b55pTLi
> v
> > >>> K79uZD15w-LvG4BQq6pz/https%3A%2F%2Fwww.rfc-
> editor.org%2Fauthors%2F
> > >>> rfc9873.pdf
> > >>> https://secure-
> web.cisco.com/1u7bwfm0HFNM2tzLxAIOuxkiIHPXHSOl0EaJi
> > >>> 3yt2cXSCDBjbAaWSEIqzK2fffcXxnXsw0gfMEnbPrlmwniN-
> ZBeckqU6yB_1U5z7Ij
> > >>> hslHvNUbRZYugQuV9bhbo3FpV3EgcfY5q32S7VnunSKc4LVMCFN6K0EqWT-
> 5QTMRt0
> > >>> 6eg3ofg0JtCxyM3YhBz1G-vIomyJmsh3N6XdyhisvLb93Olvo8EhS0lmeJAzGf-
> v8u
> > >>>
> k9EPXh2xyy5CgpCEuGBEzzEi__HR7m6L1IctCxkUHlYKmWTEzjGGmZkUeJLbK_kq
> 8c
> > >>> wqDlRmixmCCOwnO_QQev/https%3A%2F%2Fwww.rfc-
> editor.org%2Fauthors%2F
> > >>> rfc9873.html
> > >>> https://secure-
> web.cisco.com/1M_lJDKvw1GLBvieoeEpI_z9rf51Q2DjG0Won
> > >>>
> 2lFlDthHTdIlQcaUHn3jxCMEtjEHSnIzrex9jgoFgwQjmaQCKt3Btyi64iMzK_WIdt
> > >>> znxKe_-GEkPHN9hTD5gRMmKsHKULHsWkxYtUvROzmRG-
> _jkNyFzAVk6DZIxg5EYTrZ
> > >>>
> ytgjeZeN0DInCiD_NGEB0vfsJhrgxT3JE9m9ouQnGJemWuKaGcGStUtobUtg06KVz
> q
> > >>>
> Ek0ETSiYHKlodHrTY3QHKqUx89CwUxONAFtIbi4r8uXa_GCHLeRfsDrG_4NN5KPs
> D-
> > >>> J0FG09okXrqh36wp-Pgm/https%3A%2F%2Fwww.rfc-
> editor.org%2Fauthors%2F
> > >>> rfc9873.xml
> > >>>
> > >>> The relevant diff files have been posted here (please refresh):
> > >>> https://secure-
> web.cisco.com/1gEskyEWcgyXgKUfvKjZTvg_qIwPbd2rQgHao
> > >>> VjW79iqkmBjC9LI37zL-
> EDdUhio0EOOaMjaJ42BS3lwF5CkBXnBhonqXLTbQ-elZEh
> > >>> Sq7DMZkEgLp5FFWJ_VvUVesdZBimWBwUj1BKOB0D7qa3o-
> kvE7yiK6Kz1MhKWVMEr5
> > >>>
> asuzNi0dJZNvhviORCV1uGnDUQQkPrlJc2kW_V8sC1gw97nbCIyGowp1_JAAE3nlr
> Z
> > >>> hA_WqInb0twXHqiiMo7ez6UnKVnJSNkJ9I9psgfaC6TNtHT4Rpj2sDydZ-
> rDgbOMWh
> > >>> 3t7u5uUGiuLQEGKcmDoX/https%3A%2F%2Fwww.rfc-
> editor.org%2Fauthors%2F
> > >>> rfc9873-diff.html (comprehensive diff)
> > >>> https://secure-
> web.cisco.com/1bimPcfrUSAh9B0nFB4gS5xmKHoNvV62rC1YM
> > >>> ywyIx1jL23y1zAvNT2-
> pIKD1T7OQnjXRX7Cd6VT8UEgrxzeYTOCseeCZQlMiUGQMKw
> > >>> Uz24qA-s-kgqlNGvzPhK2sA8OAqzYA6WRy--veV3rxEwXwWpE-
> K8uNxio3xePsdrpm
> > >>>
> gDEvNDh9IBW7PHUHqEbcKUCqaH_BU28HQuRS84l6F_FPYIrX_yw0MrG5yEuFzaJ
> 7xS
> > >>> SL0CcuX_i3KHfoGNy44qVEQgpPUJY7sa-
> CbONoEteHDJYx7KGeqkwhad8h18V7pI0T
> > >>> YGwggPe-JxC3qZfOZCMX/https%3A%2F%2Fwww.rfc-
> editor.org%2Fauthors%2F
> > >>> 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://secure-
> web.cisco.com/1Qz7Ro9B5TmCMJOaxEQQcbAFuuQfSw3y8ZDQ9
> > >>>
> L6g_JBBZE6R89nkllhaDYRD400cVsMQBppg2mSJyWpYfOxIzgFbtD2jJ8SIipMWour
> > >>> aec15AIk42C7YNuBkF-w88qaqJQla3zBlsnvn7PydUTh8ROhaT-
> R5VjlbfSNrhlVGh
> > >>> 1P6A9kwV2-htd5HNHTnB6V9fw1m-
> 3PzsOyWeGM531uKEH0qOJK15vtK8WS7cIDHuwO
> > >>>
> DWADeYTZD4dosBEugFQDq27KTuAfGdHgkAwpTMJMsBw5FR9hEi_G8Hrhg5qXJ
> 3pEcv
> > >>> dnHrkjvjbkRTaxYkBeXP/https%3A%2F%2Fwww.rfc-
> editor.org%2Fauth48%2Fr
> > >>> fc9873
> > >>>
> > >>> 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_Mpd713QOiokMK
> > >>>>> t
> > >>>>> mX-DTM9CMYXKJTnWO2JMly51l2wU5UiVy29IY8elM6XJQB6r-
> > >>>>> qOcS0EFbqisRIwH1gJ62BjM6ddzDPy5eRGJb2fxYehs3pt1-UZMvSKWzD-
> > >>>>>
> JdACt2khJb5zW3oXNOfGhGvuNQBtKIfwCZ9FIEuSfmtsusZcvlPeujOupeOro2fm
> > >>>>> 4D
> > >>>>>
> w3M6Hgc7a5rPuPj4qd1Xe2_vvdNXktC8z4pyF2vdg8_gD8OF5z___rWwS90cbYIy
> > >>>>> f 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_onz2uI49JAfv8s3LJ2eaizVJYKH1EmZPy2yTqzKb7bS2xKwggi7fTd
> > >>>>> Eg8hUG
> > >>>>> 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_onz2uI49JAfv8s3LJ2eaizVJYKH1EmZPy2yTqzKb7bS2xKwggi7fTd
> > >>>>> Eg8hUG
> > >>>>> 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-
> WjBVrf6PbAKJWlemKY66
> > >>>>> 66-
> > >>>>> LVqc7AP5Hw8Yx4-
> > >>>>>
> PC7WNNcNf8ca5GNaoN9ZWfudjr_o_5FxHfWhm62gviz3MtWMsxwWvM0u8wQ
> > >>>>> yp07c5MjDVy3owwZEqpgrfLBnPf-
> > >>>>>
> 7fJ_rID3J_onz2uI49JAfv8s3LJ2eaizVJYKH1EmZPy2yTqzKb7bS2xKwggi7fTd
> > >>>>> Eg8hUG
> > >>>>> 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_xXs77r5iDr0IxJH8rDbwRj
> > >>>>> GoJ
> > >>>>> Cttj7vhViX3oclmCBN1EBVn4Cx5U39cniNr2HwK4Jtx3vPzraPFY91-
> kDXjPan4f
> > >>>>> iBO-
> > >>>>>
> 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_u63P
> > >>>>> 0Ga3
> > >>>>> 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-
> > >>>>>
> ilF07DsHDwM7rEJdJ4bw7WI6dJ2gvurt4oNgeZ7CZAbZbIgDRFYTQygl2YfQa4zz
> > >>>>> MH
> > >>>>>
> 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_PjezxAM92Fuy7
> > >>>>> J1
> > >>>>> _F1-vcETGHeLM2IJt-VYY6oueRl_eXCFG7W1bNgz-
> > >>>>>
> QH32qh7M0NOOf07XlQZnfba5u3HkZOi7WeechNWZGVbwd5qzUkmH9SlfLEki8f
> > >>>>>
> xa5j9AYzZ1r3VgOZXTQMzU2zYWnosLdia3j7e1dwDX6S0tStUO8cdG6aI0jAAYX1
> > >>>>> y6
> > >>>>> 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_l0iYiU6bmoEFN5p
> > >>>>> Df
> > >>>>> 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/http
> > >>>>> s%
> > >>>>>
> 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_gqZEeEDjG9Wr
> > >>>>> H
> > >>>>> KXm-
> > >>>>>
> S9R0KPjuBiCIG5EdxLI00bzn53sOrizFWlCtFQt7rWQyZqegdh8hUT6wrn50cBz1
> > >>>>> 0zV
> > >>>>> 4QG_3ciCH44xkhl3ZtjyVoH2IuFl-
> > >>>>>
> 3wC69lCjwUsmDpf8HasQntep5JfnwlQPIlHzNtPeDj60K8EHXJ5nfYYzDKnaD9k1
> > >>>>> As
> > >>>>> 6yu9Q/https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9873.xml
> > >>>>> https://secure-
> > >>>>>
> web.cisco.com/1aov7ozWUKJ1e6UvJbaH4OgFj1UEOjpa8sFyeMdG8DXzV5Uxxu
> > >>>>> 7
> 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_KXjXOwtSaJakSbTczCe0RTR2wg6Nwl0VelEjvmXEbe
> > >>>>> T-
> > >>>>> 4YxNhRErMKd3W1evOMpeHJLiFuU-
> > >>>>>
> Lbe1pipqiRVerLBy5XUwO2LtmF5CaSZDICxYLXESmZvmeGyY8tI5Iyx9a5tKbiPC
> > >>>>> nu7
> > >>>>> -
> > >>>>>
> oRvYwP4eFpI7oSs_8pPwSrawZixeVdbzLRQ72FbpMdE7EsFsHd3neFyCIzUE2Mc5
> > >>>>> Ht
> > >>>>>
> m0V4p_xWaqDiJsClOjGxWyKjxKsIwzmsY9UCXFsjkmUo37NkVFMROtQIZYe4hpER
> > >>>>> Va3afDJAIqySgFhKgPoux4/https%3A%2F%2Fwww.rfc-
> > >>>>> editor.org%2Fauthors%2Frfc9873.pdf
> > >>>>> https://secure-
> > >>>>>
> web.cisco.com/17q74dIkjQHVpNQdfQWmyXQoPSxUIEpY4FkePbIB3268WY6KrQ
> > >>>>> r
> > >>>>>
> Hw6FMffUTXUMTD0m2Wjmsnnnh52RbiWQXbb96nCvJ8XwHSxofqXrJ3LAgVON4
> > >>>>>
> 3naAJLvLBKjjS06vSVmzUfPnIOv8Wk57QjSEnZlWB23_7VAUzYt8OrIhVhDZPpKS
> > >>>>> W8
> > >>>>>
> 71OCB4kF2PAjj7C_ySXHb3dgBTfOwckVWVzNbwssHvoOJAUjTXBxmyLOGusi3ycx
> > >>>>> 0
> > >>>>> qltp2JGokZ3qRVrkUH2rsiZCJ4M__cUTDzShtFH4WbYl-
> > >>>>> Y7T729cJGlGQ/https%3A%2F%2Fwww.rfc-
> editor.org%2Fauthors%2Frfc987
> > >>>>> 3.txt
> > >>>>>
> > >>>>> Diff file of the text:
> > >>>>> https://secure-web.cisco.com/1vF1CXnVPqrBUQzQUqOOruKVFpG-
> > >>>>>
> O0sGXtCZYiT2PgPHkSVLGNLzZs7y8PXH3dOSaQpLHdb5IPh_er_2MLvoGGWyn8zX
> > >>>>> d8yKJBNUaH7D6zLNm248V-
> > >>>>>
> QFmDm3ilvP5wwr4SQ8o5wVdJEtvLXMingYI0WmKr575QZT9TzokKEq3n9Kyx7dtX
> > >>>>>
> eXBy_LmJa5j_PxZiRyixlZ9Y9yXQC1jKmY9xSfx_XvCEnpVBAA0anCCdTi6HjBAz
> > >>>>> 1PY
> > >>>>>
> pF71lr9OiWBAClSNyXn0jKIJ69ZokmHmMcOiZXFOHvJUc7qU7wOcZK8/https%3A
> > >>>>> %2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9873-diff.html
> > >>>>> https://secure-
> > >>>>>
> web.cisco.com/1suXYshBTkNkJVTMrtcBxfUXNlWG9KQY0lsao8oq66aUVIOhtL
> > >>>>> A5i
> > >>>>> PGvJZaYmbLnlEpeQ_-i7LgLRtGWoDchy_-
> > >>>>> ZHyHg4CNEyAs1ZNXBFmLmVm3ebwTUlRDQ3H-
> > >>>>> pT0I4ezGr2dNSV2UZxPcEOeFnXoH0UPyjR4TK5sa-fye7-
> > >>>>> qP_B328TNAmmU4uwiq0ocSq82xZqIlJ4jV_Xv5mKQv0wIDcQlFydj-
> > >>>>>
> FVw4HGQcHNqhxnvmPtJe7O13R1zhdbGwUOBHDTq4qLxHzJCKalDb03lJGe9w9U
> > >>>>> HG07coX7ycIgcyU/https%3A%2F%2Fwww.rfc-
> editor.org%2Fauthors%2Frfc
> > >>>>> 9873-
> > >>>>> 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_FTqsi7IN7510Oat
> > >>>>> c
> > >>>>>
> gBDiNrTksxYwcbFKIQRdGn86erG04CLa9Dfqc5YDuGaIdc9GcZO5dk7xAW_MegJY
> > >>>>>
> kvzrQydifJVLSQt4a1qKill9tZlJ7k5O04xNo_S4ztploVGiNYYMAama5ZVjAmjm
> > >>>>> Np0
> > >>>>> M5Dx1-
> > >>>>>
> L7o73JbYZZx4u24fmqXP5qqsPUjV7DfpPVHLFdzob_scqsqVzJ3JM/https%3A%2
> > >>>>> F%2 Fwww.rfc-editor.org%2Fauthors%2Frfc9873-alt-diff.html
> > >>>>>
> > >>>>> Diff of the XML:
> > >>>>> https://secure-web.cisco.com/1RnKtMmFg3ckDhh_j3PP-
> > >>>>> WWG5v3GhhUboraAr5dxNBF-
> > >>>>>
> m40DBOQ0pIj7WXcoBsSWLJyGlah1ZRjisxJcXuJmCXijBMn7aqzNvHjz1RPqTdFg
> > >>>>> IG
> > >>>>>
> nXQCpz_LIxWENC9VYJpr1eAw40kiZp5Wf9zgf5ng0JMmLNhaaFSSNjzapO7uuJbt
> > >>>>> h
> > >>>>> 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_t2Rh4gkwz20YL8BViQoBj76fUBwtnnfzbxAzrV4f8ZJFkDA0wOOyZNtNfbq
> > >>>>> 0dt
> > >>>>> 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
> > >>>>
> > >>>
> > >>
> > >
> > >
> > > --
> > > SY, Dmitry Belyavsky
> >

-- 
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to