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://www.rfc-editor.org/search. --> 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. --> 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. --> 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. --> 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. --> 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 --> 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 --> 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]. ... 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. ... This extension defines additional elements to extend the EPP <update> command of an object mapping like [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. 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. --> 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]. --> 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]. --> 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://www.iana.org/assignments/idna-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://www.iana.org/assignments/idna-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://www.iana.org/assignments/idna-tables). --> 12) <!-- [rfced] Would you like the references to be alphabetized or left in their current order? --> 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 local-part localpart ASCII alternate email address alternate ASCII email address all-ASCII 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) --> 15) <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_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. --> 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://www.rfc-editor.org/faq/). 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://trustee.ietf.org/license-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://authors.ietf.org/rfcxml-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://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc * The archive itself: https://mailarchive.ietf.org/arch/browse/auth48archive/ * 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://www.rfc-editor.org/authors/rfc9873.xml https://www.rfc-editor.org/authors/rfc9873.html https://www.rfc-editor.org/authors/rfc9873.pdf https://www.rfc-editor.org/authors/rfc9873.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9873-diff.html https://www.rfc-editor.org/authors/rfc9873-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://www.rfc-editor.org/authors/rfc9873-alt-diff.html Diff of the XML: https://www.rfc-editor.org/authors/rfc9873-xmldiff1.html Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9873 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]
