Certainly I do SY, Dmitry Belyavsky
Dne po 6. 10. 2025 14:49 uživatel Sarah Tarrant < [email protected]> 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://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 <shollenbeck= > [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 > >>>> > >>> > >> > > > > > > -- > > SY, Dmitry Belyavsky > >
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
