<?xml version='1.0'encoding='utf-8'?>encoding='UTF-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.19 (Ruby 3.0.2) --><rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-extra-6855bis-04" number="9755" category="std" consensus="true" submissionType="IETF" xml:lang="en" tocInclude="true" obsoletes="6855"version="3"> <!-- xml2rfc v2v3 conversion 3.24.0 -->updates="" version="3" symRefs="true" sortRefs="true"> <front> <title abbrev="UTF8=ACCEPT">IMAP Support for UTF-8</title> <seriesInfoname="Internet-Draft" value="draft-ietf-extra-6855bis-04"/>name="RFC" value="9755"/> <author initials="P." surname="Resnick" fullname="Pete Resnick"> <organization>Episteme Technology Consulting LLC</organization> <address> <postal> <street>503 West Indiana Avenue</street> <city>Urbana</city><code>IL 61801-4941</code> <country>US</country><region>IL</region> <code>61801-4941</code> <country>United States of America</country> </postal> <email>resnick@episteme.net</email> </address> </author> <author initials="J." surname="Yao" fullname="Jiankang Yao"> <organization>CNNIC</organization> <address> <postal> <street>No.4 South 4th Zhongguancun Street</street> <city>Beijing</city> <code>100190</code> <country>China</country> </postal> <email>yaojk@cnnic.cn</email> </address> </author> <author initials="A." surname="Gulbrandsen" fullname="Arnt Gulbrandsen"> <organization>ICANN</organization> <address> <postal> <street>6 Rond Point Schumann, Bd. 1</street> <city>Brussels</city> <code>1040</code> <country>Belgium</country> </postal> <email>arnt@gulbrandsen.priv.no</email> </address> </author> <dateyear="2024" month="November" day="13"/> <area>Applications</area> <workgroup>EXTRA</workgroup>year="2025" month="February"/> <area>ART</area> <workgroup>extra</workgroup> <keyword>IMAP</keyword><abstract> <?line 64?> <t>This<abstract><t>This specification extends the Internet Message AccessProtocol (IMAP4rev1, RFC 3501)Protocol, specifically IMAP4rev1 (RFC 3501), to support UTF-8 encoded international characters in user names, mail addresses, and message headers. This specification replaces RFC 6855. This specification does not extend IMAP4rev2<xref target="RFC9051"/>,(RFC 9051), since that protocol includes everything in this extension.</t> </abstract> </front> <middle><?line 73?><section anchor="introduction"> <name>Introduction</name> <t>This specification forms part of the Email Address Internationalization protocols described in the Email Address Internationalization Framework document <xref target="RFC6530"/>. It extends IMAP <xref target="RFC3501"/> to permit UTF-8 <xref target="RFC3629"/> in headers, as described in "Internationalized Email Headers" <xref target="RFC6532"/>. It also adds a mechanism to support mailbox names using the UTF-8 charset. This specification creates two new IMAP capabilities to allow servers to advertise these new extensions.</t> <t>This specification assumes that the IMAP server will be operating in a fully internationalized environment, i.e., one in which all clients accessing the server will be able to accept non-ASCII message header fields and other information, as specified inSection 3.<xref target="utf8accept-imap-capability-and-utf-8-in-imap-quoted-strings"/>. At least during a transition period, that assumption will not be realistic for many environments; the issues involved are discussed inSection 7<xref target="utf8only-capability"/> below.</t> <t>This specification replaces an earlier, experimental approach to the sameproblemproblem; see <xref target="RFC5738"/> as well as <xref target="RFC6855"/>.</t> </section> <section anchor="requirements-language"> <name>Requirements Language</name><t>The<t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t> <?line -18?>here. </t> </section> <section anchor="utf8accept-imap-capability-and-utf-8-in-imap-quoted-strings"> <name>"UTF8=ACCEPT" IMAP Capability and UTF-8 in IMAP Quoted-Strings</name> <t>The "UTF8=ACCEPT" capability indicates that the server supports the ability to open mailboxes containing internationalized messages with the "SELECT" and "EXAMINE" commands, and the server can provide UTF-8 responses to the "LIST" and "LSUB" commands. This capability also affects other IMAP extensions that can return mailbox names or their prefixes, such as NAMESPACE <xref target="RFC2342"/> and ACL <xref target="RFC4314"/>.</t> <t>The "UTF8=ONLY" capability, described inSection 7,<xref target="utf8only-capability"/>, implies the "UTF8=ACCEPT" capability. A server is said to support "UTF8=ACCEPT" if it advertises either "UTF8=ACCEPT" or "UTF8=ONLY".</t> <t>A client <bcp14>MUST</bcp14> use the "ENABLE" command <xref target="RFC5161"/> with the "UTF8=ACCEPT" option (defined inSection 4<xref target="append-command"/> below) to indicate to the server that the client accepts UTF-8 in quoted-strings and supports the "UTF8=ACCEPT" extension. The "ENABLE UTF8=ACCEPT" command is only valid in the authenticated state.</t> <t>The IMAP base specification <xref target="RFC3501"/> forbids the use of 8-bit characters in atoms or quoted-strings. Thus, a UTF-8 string can only be sent as a literal. This can be inconvenient from a coding standpoint, and unless the server offers IMAP non-synchronizing literals <xref target="RFC2088"/>, this requires an extra round trip for each UTF-8 string sent by the client. When the IMAP server supports "UTF8=ACCEPT", it supports UTF-8 in quoted-strings with the followingsyntax:</t> <t>quotedABNF syntax <xref target="RFC5234"/>:</t> <sourcecode type="abnf"><![CDATA[ quoted =/ DQUOTE *uQUOTED-CHAR DQUOTE ; QUOTED-CHAR is not modified, as it will affect ; other RFC 3501 ABNFnon-terminals.</t> <t>uQUOTED-CHARnon-terminals. uQUOTED-CHAR = QUOTED-CHAR / UTF8-2 / UTF8-3 /UTF8-4</t> <t>UTF8-2UTF8-4 UTF8-2 =<Defined<Defined in Section 4 of RFC3629></t> <t>UTF8-33629> UTF8-3 =<Defined<Defined in Section 4 of RFC3629></t> <t>UTF8-43629> UTF8-4 =<Defined<Defined in Section 4 of RFC3629></t>3629> ]]></sourcecode> <t>When this extended quoting mechanism is used by the client, the server <bcp14>MUST</bcp14> reject, with a "BAD" response, any octet sequences with the high bit set that fail to comply with the formal syntax requirements of UTF-8 <xref target="RFC3629"/>. The IMAP server <bcp14>MUST NOT</bcp14> send UTF-8 in quoted-strings to the client unless the client has indicated support for that syntax by using the "ENABLE UTF8=ACCEPT" command.</t> <t>If the server supports "UTF8=ACCEPT", the client <bcp14>MAY</bcp14> use extended quoted syntax with any IMAP argument that permits a string (including astring and nstring). However, if characters outside the US-ASCII repertoire are used in an inappropriate place, the results would be the same as if other syntactically valid but semantically invalid characters were used. Specific cases where UTF-8 characters are permitted or not permitted are described in the following paragraphs.</t><t>All<!--[rfced] Regarding the term "UTF8-quoted": We note this term was also used in RFC 6855, which is the only RFC where this term has appeared in this form. Does it refer to the ABNF rule 'utf8-quoted' as defined in RFC 5738 (which is obsolete), or to another concept? Should it be replaced with 'utf8-quoted' or should the concept be written in prose? Original: All IMAP servers that support "UTF8=ACCEPT"<bcp14>SHOULD</bcp14>SHOULD accept UTF-8 in mailbox names, and those that also support the Mailbox International Naming Convention described in RFC 3501, Section 5.1.3, MUST accept UTF8-quoted mailbox names and convert them to the appropriate internal format. --> <t>All IMAP servers that support "UTF8=ACCEPT" <bcp14>SHOULD</bcp14> accept UTF-8 in mailbox names, and those that also support the Mailbox International Naming Convention described in <xref section="5.1.3" sectionFormat="comma" target="RFC3501"/>, <bcp14>MUST</bcp14> accept UTF8-quoted mailbox names and convert them to the appropriate internal format. Mailbox names <bcp14>MUST</bcp14> comply with the Net-Unicode Definition (<xreftarget="RFC5198"/>, Section 2)section="2" sectionFormat="comma" target="RFC5198"/>) with the specific exception that they <bcp14>MUST NOT</bcp14> contain control characters(U+0000-U+001F(U+0000 - U+001F andU+0080-U+ 009F),U+0080 - U+009F), a delete character (U+007F), a line separator (U+2028), or a paragraph separator (U+2029).</t> <!-- [rfced] There is one Verified Technical errata report for RFC 6855: https://www.rfc-editor.org/errata/eid4029 This document contains the old text from Section 3 mentioned in that report. Please review whether any updates are needed for this document. --> <t>Once an IMAP client has enabled UTF-8 support with the "ENABLE UTF8=ACCEPT" command, it <bcp14>MUST NOT</bcp14> issue a "SEARCH" command that contains a charset specification. If an IMAP server receives such a "SEARCH" command in that situation, it <bcp14>SHOULD</bcp14> reject the command with a "BAD" response (due to the conflicting charset labels).</t> </section> <section anchor="append-command"> <name>"APPEND" Command</name> <t>If the server supports "UTF8=ACCEPT", then the server accepts UTF-8 headers in the "APPEND" command message argument.</t> <t>If an IMAP server supports "UTF8=ACCEPT" and the IMAP client has not issued the "ENABLE UTF8=ACCEPT" command, the server <bcp14>MUST</bcp14> reject, with a "NO" response, an "APPEND" command that includes any 8-bit character in message header fields.</t> </section> <section anchor="login-command-and-utf-8"> <name>"LOGIN" Command and UTF-8</name> <t>This specification does not extend the IMAP "LOGIN" command <xref target="RFC3501"/> to support UTF-8 usernames and passwords. Whenever a client needs to use UTF-8 usernames or passwords, it <bcp14>MUST</bcp14> use the IMAP "AUTHENTICATE" command, which is already capable of passing UTF-8 usernames and credentials.</t> <t>Although using the IMAP "AUTHENTICATE" command in this way makes it syntactically legal to have a UTF-8 username or password, there is no guarantee that the user provisioning system utilized by the IMAP server will allow such identities. This is an implementation decision and may depend on what identity system the IMAP server is configured to use.</t> </section> <section anchor="fetch-bodystructure-and-messageglobal"> <name>FETCH BODYSTRUCTURE and message/global</name> <t><xref section="7.5.2" sectionFormat="comma" target="RFC9051"/>section 7.5.2treats message/global like message/rfc, which means that for some messages, the response to FETCH BODYSTRUCTURE varies depending on whether IMAP4rev1 or IMAP4rev2 is in use.</t> <t><xref target="RFC6855"/> does not extend <xref target="RFC3501"/> in this respect. This document extends the media-message ABNF production to match <xref target="RFC9051"/>.</t><t>media-message<sourcecode type="abnf"><![CDATA[ media-message = DQUOTE "MESSAGE" DQUOTE SP DQUOTE ("RFC822" / "GLOBAL")DQUOTE</t>DQUOTE ]]></sourcecode> <t>When IMAP4rev1 and UTF8=ACCEPT has been enabled, the server <bcp14>MAY</bcp14> treat message/global like message/rfc822 when computing the body structure, but <bcp14>MAY</bcp14> also treat it as described in <xref target="RFC3501"/>. Clients <bcp14>MUST</bcp14> accept both cases.</t> <t>When IMAP4rev2 and UTF8=ACCEPT are in use, the server <bcp14>MUST</bcp14> behave as described in <xref target="RFC9051"/>.</t> </section> <section anchor="utf8only-capability"> <name>"UTF8=ONLY" Capability</name> <t>The "UTF8=ONLY" capability indicates that the server supports "UTF8=ACCEPT" (seeSection 3)<xref target="utf8accept-imap-capability-and-utf-8-in-imap-quoted-strings"/>) and that it requires support for UTF-8 from clients. In particular, this means that the server will send UTF-8 in quoted-strings, and it will not accept the older international mailbox name convention (modified UTF-7 <xref target="RFC3501"/>). Because these are incompatible changes to IMAP, explicit server announcement and client confirmationisare necessary: clients <bcp14>MUST</bcp14> use the "ENABLE UTF8=ACCEPT" command before using this server. A server that advertises "UTF8=ONLY" will reject, with a "NO [CANNOT]" response <xref target="RFC5530"/>, any command that might require UTF-8 support and is not preceded by an "ENABLE UTF8=ACCEPT" command.</t> <t>IMAP clients that find support for a server that announces "UTF8=ONLY" problematic are encouraged to at least detect the announcement and provide an informative error message to theend-user.</t>end user.</t> <t>Because the "UTF8=ONLY" server capability includes support for "UTF8=ACCEPT", the capability string will include, at most, one of those and never both. For the client, "ENABLE UTF8=ACCEPT" is always used -- never "ENABLE UTF8=ONLY".</t> </section> <section anchor="dealing-with-legacy-clients"> <name>Dealing with Legacy Clients</name> <t>In most situations, it will be difficult or impossible for the implementer or operator of an IMAP (or POP) server to know whether all of the clients that might access it, or the associated mail store more generally, will be able to support the facilities defined in this document. In almost all cases, servers that conform to this specification will have to be prepared to deal with clients that do not enable the relevant capabilities. Unfortunately, there is no completely satisfactory way to do so other than for systems that wish to receive email that requires SMTPUTF8 capabilities to be sure that all components of those systems -- including IMAP and other clients selected by users -- are upgraded appropriately.</t> <t>When a message that requires SMTPUTF8 is encountered and the client does not enable UTF-8 capability, choices available to the server include hiding the problematic message(s), creating in-band or out-of-band notifications or error messages, or somehow trying to create a surrogate of the message with the intention of providing useful information to that client about what has occurred. Such surrogate messages cannot be actual substitutes for the original message: they will almost always be impossible to reply to (either at all or without loss of information) and the new header fields or specialized constructs for server-client communications may go beyond the requirements of current email specifications (e.g., <xref target="RFC5322"/>). Consequently, such messages may confuse some legacy mail user agents (including IMAP clients) or not provide expected information to users. There are also trade-offs in constructing surrogates of the original message between accepting complexity and additional computation costs in order to try to preserve as much information as possible (for example, in "Post-Delivery Message Downgrading for Internationalized Email Messages" <xref target="RFC6857"/>) and trying to minimize those costs while still providing useful information (for example, in "Simplified POP and IMAP Downgrading for Internationalized Email" <xref target="RFC6858"/>).</t> <t>Implementations that choose to perform downgrading <bcp14>SHOULD</bcp14> use one of the standardized algorithms provided inRFC 6857<xref target="RFC6857"/> orRFC 6858.<xref target="RFC6858"/>. Getting downgrade algorithms right, and minimizing the risk of operational problems and harm to the email system, is tricky and requires careful engineering. These two algorithms are well understood and carefully designed.</t> <t>Because such messages are really surrogates of the original ones, not really "downgraded" ones (although that terminology is often used for convenience), they inevitably have relationships to the originals that the IMAP specification <xref target="RFC3501"/> did not anticipate. This brings up two concerns in particular: First, digital signatures computed over and intended for the original message will often not be applicable to the surrogate message, and will often fail signature verification. (It will be possible for some digital signatures to be verified, if they cover only parts of the original message that are not affected in the creation of the surrogate.) Second, servers that may be accessed by the same user with different clients or methods (e.g., POP or webmail systems in addition to IMAP or IMAP clients with different capabilities) will need to exert extreme care to be sure that UIDVALIDITY <xref target="RFC3501"/> behaves as the user would expect. Those issues may be especially sensitive if the server caches the surrogate message or computes and stores it when the message arrives with the intent of making either form available depending on client capabilities. Additionally, in order to cope with the case when a server compliant with this extension returns the same UIDVALIDITY to both legacy and "UTF8=ACCEPT"-aware clients, a client upgraded from being non-"UTF8=ACCEPT"-aware <bcp14>MUST</bcp14> discard its cache of messages downloaded from the server.</t> <t>The best (or "least bad") approach for any given environment will depend on local conditions, local assumptions about user behavior, the degree of control the server operator has over client usage and upgrading, the options that are actually available, and so on. It is impossible, at least at the time of publication of this specification, to give good advice that will apply to all situations, or even particular profiles of situations, other than "upgrade legacy clients as soon as possible".</t> </section> <section anchor="issues-with-utf-8-header-mailstore"> <name>Issues with UTF-8 Header Mailstore</name> <t>When an IMAP server uses a mailbox format that supports UTF-8 headers and it permits selection or examination of that mailbox without issuing "ENABLE UTF8=ACCEPT" first, it is the responsibility of the server to comply with the IMAP base specification <xref target="RFC3501"/> and the Internet Message Format <xref target="RFC5322"/> with respect to all header information transmitted over the wire. The issue of handling messages containing non-ASCII characters in legacy environments is discussed inSection 8.</t><xref target="dealing-with-legacy-clients"/>.</t> </section> <section anchor="IANA"> <name>IANA Considerations</name> <t>the "IMAP4Capabilities" registrycontainscontained a number of references toRFC6855. IANA, please change<xref target="RFC6855"/>. IANA has updated themtopoint to this documentinstead of RFC6855.instead. The affected references are:</t> <ul spacing="normal"> <li> <t>UTF8=ACCEPT</t> </li> <li> <t>UTF8=ALL (OBSOLETE)</t> </li> <li> <t>UTF8=APPEND (OBSOLETE)</t> </li> <li> <t>UTF8=ONLY</t> </li> <li> <t>UTF8=USER (OBSOLETE)</t> </li> </ul> </section> <section anchor="SECURITY"> <name>Security Considerations</name> <t>The security considerations of UTF-8 <xref target="RFC3629"/> and SASLprep <xref target="RFC4013"/> apply to this specification, particularly with respect to use of UTF-8 in usernames and passwords. Otherwise, this is not believed to alter the security considerations of IMAP.</t> <t>Special considerations, some of them with security implications, occur if a server that conforms to this specification is accessed by a client that does not, as well as in some more complex situations in which a given message is accessed by multiple clients that might use different protocols and/or support different capabilities. Those issues are discussed inSection 8.</t><xref target="dealing-with-legacy-clients"/>.</t> </section> </middle> <back> <references anchor="sec-combined-references"> <name>References</name> <references anchor="sec-normative-references"> <name>Normative References</name><reference anchor="RFC2119"> <front> <title>Key words for use in RFCs to Indicate Requirement Levels</title> <author fullname="S. Bradner" initials="S." surname="Bradner"/> <date month="March" year="1997"/> <abstract> <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="2119"/> <seriesInfo name="DOI" value="10.17487/RFC2119"/> </reference> <reference anchor="RFC3501"> <front> <title>INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1</title> <author fullname="M. Crispin" initials="M." surname="Crispin"/> <date month="March" year="2003"/> <abstract> <t>The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev1 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev1 also provides the capability for an offline client to resynchronize with the server. IMAP4rev1 includes operations for creating, deleting, and renaming mailboxes, checking for new messages, permanently removing messages, setting and clearing flags, RFC 2822 and RFC 2045 parsing, searching, and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev1 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers. IMAP4rev1 supports a single server. A mechanism for accessing configuration information to support multiple IMAP4rev1 servers is discussed in RFC 2244. IMAP4rev1 does not specify a means of posting mail; this function is handled by a mail transfer protocol such as RFC 2821. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="3501"/> <seriesInfo name="DOI" value="10.17487/RFC3501"/> </reference> <reference anchor="RFC3629"> <front> <title>UTF-8, a transformation format of ISO 10646</title> <author fullname="F. Yergeau" initials="F." surname="Yergeau"/> <date month="November" year="2003"/> <abstract> <t>ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279.</t> </abstract> </front> <seriesInfo name="STD" value="63"/> <seriesInfo name="RFC" value="3629"/> <seriesInfo name="DOI" value="10.17487/RFC3629"/> </reference> <reference anchor="RFC4013"> <front> <title>SASLprep: Stringprep Profile for User Names and Passwords</title> <author fullname="K. Zeilenga" initials="K." surname="Zeilenga"/> <date month="February" year="2005"/> <abstract> <t>This document describes how to prepare Unicode strings representing user names and passwords for comparison. The document defines the "SASLprep" profile of the "stringprep" algorithm to be used for both user names and passwords. This profile is intended to be used by Simple Authentication and Security Layer (SASL) mechanisms (such as PLAIN, CRAM-MD5, and DIGEST-MD5), as well as other protocols exchanging simple user names and/or passwords. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="4013"/> <seriesInfo name="DOI" value="10.17487/RFC4013"/> </reference> <reference anchor="RFC5161"> <front> <title>The IMAP ENABLE Extension</title> <author fullname="A. Gulbrandsen" initials="A." role="editor" surname="Gulbrandsen"/> <author fullname="A. Melnikov" initials="A." role="editor" surname="Melnikov"/> <date month="March" year="2008"/> <abstract> <t>Most IMAP extensions are used by the client when it wants to and the server supports it. However, a few extensions require the server to know whether a client supports that extension. The ENABLE extension allows an IMAP client to say which extensions it supports. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="5161"/> <seriesInfo name="DOI" value="10.17487/RFC5161"/> </reference> <reference anchor="RFC5198"> <front> <title>Unicode Format for Network Interchange</title> <author fullname="J. Klensin" initials="J." surname="Klensin"/> <author fullname="M. Padlipsky" initials="M." surname="Padlipsky"/> <date month="March" year="2008"/> <abstract> <t>The Internet today is in need of a standardized form for the transmission of internationalized "text" information, paralleling the specifications for the use of ASCII that date from the early days of the ARPANET. This document specifies that format, using UTF-8 with normalization and specific line-ending sequences. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="5198"/> <seriesInfo name="DOI" value="10.17487/RFC5198"/> </reference> <reference anchor="RFC5322"> <front> <title>Internet Message Format</title> <author fullname="P. Resnick" initials="P." role="editor" surname="Resnick"/> <date month="October" year="2008"/> <abstract> <t>This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="5322"/> <seriesInfo name="DOI" value="10.17487/RFC5322"/> </reference> <reference anchor="RFC6530"> <front> <title>Overview and Framework for Internationalized Email</title> <author fullname="J. Klensin" initials="J." surname="Klensin"/> <author fullname="Y. Ko" initials="Y." surname="Ko"/> <date month="February" year="2012"/> <abstract> <t>Full use of electronic mail throughout the world requires that (subject to other constraints) people be able to use close variations on their own names (written correctly in their own languages and scripts) as mailbox names in email addresses. This document introduces a series of specifications that define mechanisms and protocol extensions needed to fully support internationalized email addresses. These changes include an SMTP extension and extension of email header syntax to accommodate UTF-8 data. The document set also includes discussion of key assumptions and issues in deploying fully internationalized email. This document is a replacement for RFC 4952; it reflects additional issues identified since that document was published. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="6530"/> <seriesInfo name="DOI" value="10.17487/RFC6530"/> </reference> <reference anchor="RFC6532"> <front> <title>Internationalized Email Headers</title> <author fullname="A. Yang" initials="A." surname="Yang"/> <author fullname="S. Steele" initials="S." surname="Steele"/> <author fullname="N. Freed" initials="N." surname="Freed"/> <date month="February" year="2012"/> <abstract> <t>Internet mail was originally limited to 7-bit ASCII. MIME added support for the use of 8-bit character sets in body parts, and also defined an encoded-word construct so other character sets could be used in certain header field values. However, full internationalization of electronic mail requires additional enhancements to allow the use of Unicode, including characters outside the ASCII repertoire, in mail addresses as well as direct use of Unicode in header fields like "From:", "To:", and "Subject:", without requiring the use of complex encoded-word constructs. This document specifies an enhancement to the Internet Message Format and to MIME that allows use of Unicode in mail addresses and most header field content.</t> <t>This specification updates Section 6.4 of RFC 2045 to eliminate the restriction prohibiting the use of non-identity content-transfer- encodings on subtypes of "message/". [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="6532"/> <seriesInfo name="DOI" value="10.17487/RFC6532"/> </reference> <reference anchor="RFC8174"> <front> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <author fullname="B. Leiba" initials="B." surname="Leiba"/> <date month="May" year="2017"/> <abstract> <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="8174"/> <seriesInfo name="DOI" value="10.17487/RFC8174"/> </reference><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3501.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3629.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4013.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5161.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5198.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5322.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6530.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6532.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> </references> <references anchor="sec-informative-references"> <name>Informative References</name><reference anchor="RFC2088"> <front> <title>IMAP4 non-synchronizing literals</title> <author fullname="J. Myers" initials="J." surname="Myers"/> <date month="January" year="1997"/> <abstract> <t>The Internet Message Access Protocol [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="2088"/> <seriesInfo name="DOI" value="10.17487/RFC2088"/> </reference> <reference anchor="RFC2342"> <front> <title>IMAP4 Namespace</title> <author fullname="M. Gahrns" initials="M." surname="Gahrns"/> <author fullname="C. Newman" initials="C." surname="Newman"/> <date month="May" year="1998"/> <abstract> <t>This document defines a NAMESPACE command that allows a client to discover the prefixes of namespaces used by a server for personal mailboxes, other users' mailboxes, and shared mailboxes. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="2342"/> <seriesInfo name="DOI" value="10.17487/RFC2342"/> </reference> <reference anchor="RFC4314"> <front> <title>IMAP4 Access Control List (ACL) Extension</title> <author fullname="A. Melnikov" initials="A." surname="Melnikov"/> <date month="December" year="2005"/> <abstract> <t>The Access Control List (ACL) extension (RFC 2086) of the Internet Message Access Protocol (IMAP) permits mailbox access control lists to be retrieved and manipulated through the IMAP protocol.</t> <t>This document is a revision of RFC 2086. It defines several new access control rights and clarifies which rights are required for different IMAP commands. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="4314"/> <seriesInfo name="DOI" value="10.17487/RFC4314"/> </reference> <reference anchor="RFC5530"> <front> <title>IMAP Response Codes</title> <author fullname="A. Gulbrandsen" initials="A." surname="Gulbrandsen"/> <date month="May" year="2009"/> <abstract> <t>IMAP responses consist of a response type (OK, NO, BAD), an optional machine-readable response code, and a human-readable text.</t> <t>This document collects and documents a variety of machine-readable response codes, for better interoperation and error reporting. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="5530"/> <seriesInfo name="DOI" value="10.17487/RFC5530"/> </reference> <reference anchor="RFC5738"> <front> <title>IMAP Support for UTF-8</title> <author fullname="P. Resnick" initials="P." surname="Resnick"/> <author fullname="C. Newman" initials="C." surname="Newman"/> <date month="March" year="2010"/> <abstract> <t>This specification extends the Internet Message Access Protocol version 4rev1 (IMAP4rev1) to support UTF-8 encoded international characters in user names, mail addresses, and message headers. This document defines an Experimental Protocol for the Internet community.</t> </abstract> </front> <seriesInfo name="RFC" value="5738"/> <seriesInfo name="DOI" value="10.17487/RFC5738"/> </reference> <reference anchor="RFC6855"> <front> <title>IMAP Support for UTF-8</title> <author fullname="P. Resnick" initials="P." role="editor" surname="Resnick"/> <author fullname="C. Newman" initials="C." role="editor" surname="Newman"/> <author fullname="S. Shen" initials="S." role="editor" surname="Shen"/> <date month="March" year="2013"/> <abstract> <t>This specification extends the Internet Message Access Protocol (IMAP) to support UTF-8 encoded international characters in user names, mail addresses, and message headers. This specification replaces RFC 5738.</t> </abstract> </front> <seriesInfo name="RFC" value="6855"/> <seriesInfo name="DOI" value="10.17487/RFC6855"/> </reference> <reference anchor="RFC6857"> <front> <title>Post-Delivery Message Downgrading for Internationalized Email Messages</title> <author fullname="K. Fujiwara" initials="K." surname="Fujiwara"/> <date month="March" year="2013"/> <abstract> <t>The Email Address Internationalization (SMTPUTF8) extension to SMTP allows Unicode characters encoded in UTF-8 and outside the ASCII repertoire in mail header fields. Upgraded POP and IMAP servers support internationalized messages. If a POP or IMAP client does not support Email Address Internationalization, a POP or IMAP server cannot deliver internationalized messages to the client and cannot remove the message. To avoid that situation, this document describes a mechanism for converting internationalized messages into the traditional message format. As part of the conversion process, message elements that require internationalized treatment are recoded or removed, and receivers are able to recognize that they received messages containing such elements, even if they cannot process the internationalized elements.</t> </abstract> </front> <seriesInfo name="RFC" value="6857"/> <seriesInfo name="DOI" value="10.17487/RFC6857"/> </reference> <reference anchor="RFC6858"> <front> <title>Simplified POP and IMAP Downgrading for Internationalized Email</title> <author fullname="A. Gulbrandsen" initials="A." surname="Gulbrandsen"/> <date month="March" year="2013"/> <abstract> <t>This document specifies a method for IMAP and POP servers to serve internationalized messages to conventional clients. The specification is simple, easy to implement, and provides only rudimentary results.</t> </abstract> </front> <seriesInfo name="RFC" value="6858"/> <seriesInfo name="DOI" value="10.17487/RFC6858"/> </reference> <reference anchor="RFC8620"> <front> <title>The JSON Meta Application Protocol (JMAP)</title> <author fullname="N. Jenkins" initials="N." surname="Jenkins"/> <author fullname="C. Newman" initials="C." surname="Newman"/> <date month="July" year="2019"/> <abstract> <t>This document specifies a protocol for clients to efficiently query, fetch, and modify JSON-based data objects, with support for push notification of changes and fast resynchronisation and for out-of- band binary data upload/download.</t> </abstract> </front> <seriesInfo name="RFC" value="8620"/> <seriesInfo name="DOI" value="10.17487/RFC8620"/> </reference> <reference anchor="RFC9051"> <front> <title>Internet Message Access Protocol (IMAP) - Version 4rev2</title> <author fullname="A. Melnikov" initials="A." role="editor" surname="Melnikov"/> <author fullname="B. Leiba" initials="B." role="editor" surname="Leiba"/> <date month="August" year="2021"/> <abstract> <t>The Internet Message Access Protocol Version 4rev2 (IMAP4rev2) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev2 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev2 also provides the capability for an offline client to resynchronize with the server.</t> <t>IMAP4rev2 includes operations for creating, deleting, and renaming mailboxes; checking for new messages; removing messages permanently; setting and clearing flags; parsing per RFCs 5322, 2045, and 2231; searching; and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev2 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers.</t> <t>IMAP4rev2 does not specify a means of posting mail; this function is handled by a mail submission protocol such as the one specified in RFC 6409.</t> </abstract> </front> <seriesInfo name="RFC" value="9051"/> <seriesInfo name="DOI" value="10.17487/RFC9051"/> </reference><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2088.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2342.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4314.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5530.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5738.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6855.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6857.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6858.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8620.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9051.xml"/> </references> </references><?line 372?><section anchor="design-rationale"> <name>Design Rationale</name> <t>This non-normative section discusses the reasons behind some of the design choices in this specification.</t> <t>The "UTF8=ONLY" mechanism simplifies diagnosis of interoperability problems when legacy support goes away. In the situation where backwards compatibility is not working anyway, the non-conforming "just-send-UTF-8 IMAP" has the advantage that it might work with some legacy clients. However, the difficulty of diagnosing interoperability problems caused by a "just-send-UTF-8 IMAP" mechanism is the reason the "UTF8=ONLY" capability mechanism was chosen.</t> </section> <sectionanchor="acknowledgments"> <name>Acknowledgments</name> <t>This document is an almost unchanged copy of <xref target="RFC6855"/>, which was written by Pete Resnick, Chris Newman and Sean Shen. Sean has since changed jobs and the current authors do not have a new email address for him. We cannot be sure that he would approve of the changes in this document, so we did not list him as author, but do gratefully acknowledge his work on <xref target="RFC6855"/>. Jiankang Yao replaces him.</t> <t>The next paragraph is a straight copy of the acknowlegements in <xref target="RFC6855"/>:</t> <t>The authors wish to thank the participants of the EAI working group for their contributions to this document, with particular thanks to Harald Alvestrand, David Black, Randall Gellens, Arnt Gulbrandsen, Kari Hurtta, John Klensin, Xiaodong Lee, Charles Lindsey, Alexey Melnikov, Subramanian Moonesamy, Shawn Steele, Daniel Taharlev, and Joseph Yee for their specific contributions to the discussion.</t> <t>Many of them also reread the document during this revision.</t> </section> <sectionanchor="changes-since-rfc-6855"> <name>Changes since RFC 6855</name> <t>This non-normative section describes the changes made since <xref target="RFC6855"/>.</t> <section anchor="append-utf8"> <name>APPEND UTF8</name> <!--[rfced] Here, does "UTF8-related" mean related to the UTF8 data item or related to the UTF-8 character encoding? If the former, may the sentence be updated as follows? Original: This document removes APPEND's UTF8 data item, making the UTF8-related syntax compatible with IMAP4rev2 ... Perhaps: This document removes APPEND's UTF8 data item, making the syntax related to that data item compatible with IMAP4rev2 ... --> <t>This document removes APPEND's UTF8 data item, making the UTF8-related syntax compatible with IMAP4rev2 as defined by <xref target="RFC9051"/> and making it simpler for clients to support IMAP4rev1 and IMAP4rev2 with the same code.</t> <t>IMAP4rev2 <xref target="RFC9051"/> provides roughly the same abilities as <xref target="RFC6855"/> but does not include APPEND's UTF8 item. None of <xref target="RFC6855"/>,IMAP4rev2IMAP4rev2, or JMAP <xref target="RFC8620"/> specify any way to learn whether a particular message was stored using the UTF8 data item. As of today, an IMAP client cannot learn whether a particular message was stored using the UTF8 data item, nor would it be able to trust that information even if IMAP4rev1/2 were extended to provide that information.</t> <!--[rfced] Please clarify the "/" in "IMAP4rev1/2" here. Is the intended meaning "and" or "or" or otherwise? Original: As of today, an IMAP client cannot learn whether a particular message was stored using the UTF8 data item, nor would it be able to trust that information even if IMAP4rev1/2 were extended to provide that information. Perhaps: ... even if IMAP4rev1 and 2 were extended to provide that information. --> <t>In July 2023, one of the authors found only one IMAP client that uses the UTF8 data item, and that client uses it incorrectly (it sends the data item for all messages if the server supports UTF8=ACCEPT, without regard to whether a particular message includes any UTF8 at all).</t> <t>For these reasons, it was judged best to revise <xref target="RFC6855"/> and adopt the same syntax as IMAP4rev2.</t> </section> <section anchor="fetch-bodystructure"> <name>FETCH BODYSTRUCTURE</name> <!--[rfced] In general in RFCs, the term "MIME type" should be "media type". Please review whether these updates convey the intended meaning. a new MIME type -> a new media type the MIME structure of a message -> the media type of the body of a message --> <t><xref target="RFC6532"/> defines a new MIME type, message/global, which is substantially like message/rfc822 except that the submessage may (also) use the syntax defined in <xref target="RFC6532"/>. <xref target="RFC3501"/> and <xref target="RFC9051"/> define a FETCH item to return the MIME structure of a message, which servers usually compute once and store.</t> <t>None of the RFCs point out to implementers that IMAP4rev1 and IMAP4rev2 areslighlyslightly different, so storing the BODYSTRUCTURE in the way servers and clients often do can easily lead to problems.</t> <t>This document makes the syntax optional, making it simple for server authors to implement this extension correctly. This implies that clients need to parse and handle both varieties, which they need to do anyway if they want to support both IMAP4rev1 and IMAP4rev2.</t> </section> </section></back><section anchor="acknowledgments" numbered="false"> <name>Acknowledgments</name> <t>This document is an almost unchanged copy of <xref target="RFC6855"/>, which was written by <contact fullname="Pete Resnick"/>, <contact fullname="Chris Newman"/>, and <contact fullname="Sean Shen"/>. Sean has since changed jobs and the current authors do not have a new email address for him. We cannot be sure that he would approve of the changes in this document, so we did not list him as author, but do gratefully acknowledge his work on <xref target="RFC6855"/>. <contact fullname="Jiankang Yao"/> replaces him.</t> <t>The next paragraph is a straight copy of the acknowledgments in <xref target="RFC6855"/>:</t> <blockquote> <t>The authors wish to thank the participants of the EAI working group for their contributions to this document, with particular thanks to <contact fullname="Harald Alvestrand"/>, <contact fullname="David Black"/>, <contact fullname="Randall Gellens"/>, <contact fullname="Arnt Gulbrandsen"/>, <contact fullname="Kari Hurtta"/>, <contact fullname="John Klensin"/>, <contact fullname="Xiaodong Lee"/>, <contact fullname="Charles Lindsey"/>, <contact fullname="Alexey Melnikov"/>, <contact fullname="Subramanian Moonesamy"/>, <contact fullname="Shawn Steele"/>, <contact fullname="Daniel Taharlev"/>, and <contact fullname="Joseph Yee"/> for their specific contributions to the discussion.</t> </blockquote> <t>Many of them also reread the document during this revision.</t> </section> <!--[rfced] Pete, would you like to provide an abbreviated organization name, which would appear in the first-page header? This is optional. Current: Internet Engineering Task Force (IETF) P. Resnick Request for Comments: 9755 Episteme Technology Consulting LLC Obsoletes: 6855 J. Yao Category: Standards Track CNNIC ISSN: 2070-1721 A. Gulbrandsen ICANN February 2025 --> <!--##markdown-source: H4sIAAAAAAAAA51c6XIjN5L+j6fA0j9W8pK0ru5Wa07qaLc8uixKO9M7MbEB VoEkrGIVpw6xOY5+l32WfbLNCygUybZntiNsleoAEok8vjygwWCgqtrk6X+b rMjtma7Lxiq3LOmqqo8ODt4fHKnE1Ge6qlNVNZOFqypX5PV6Ca9fXz19UKa0 5kyPlsvMwYvwrFKr2Zm++svT40gVk6rIbG2rM/329M0bpdIiyc0Cvk1LM60H ztbTgf1cl2aAzyeuGhycKFW7OsPxb0cPetwsl0VZ62lR6uenD4NTZSaT0r6e 4W+nvxtdXFw9PKnM5DCpzdXL6kxpPaBvlWnqeVGeqYHmSR+AFP1oq9wlL/BW USKhS1fVdmH1k03meZEVs7W+gFU0We3ymb65uYA3q7q0Frjw5uBY/9lWtb7O U2dyo0evNgeeaZ24eg0klRO4i78WKS7gRr89PD04HJy8Pzmku01el/jeGH6z C+OyM10yPX+0Qsgwt3Wg+AeY5QXWpj+ZwlN8cXd3HRN1VwxP9LiAteoT+O+/ 5kU+mzUmT5pcj+mdQN+5dT/BqgKBhwcHh+8PYsou5o4WIMStTfHTyx+THCgc Jnkga1Tmtf6+ySYlSE8FbBfSri9Gd3cRaW/1Y5Gn+qFw8P44mTcLk+d9fZ4O 9WFLFMhaZbMqouqkQ9O5zWauWbRUGZj+j7N2+uGydK/DvFBK5UW5ADF8tSgG jx8ujg4P38vl8ZuDQ3/59sjfPTk4PJbLN4dvD8Pl+1N/eXx0JJdv3xwftJdw V7l8ujnhwan/8uj4xH95cnx44sdrB3nz7ti/i+LfXr5rL/0Lp2+P/GfvD94A nWowGGgzAVabpFbqae4qXS1t4qaiiBoUywJ/dD23ILC1LUGy9K2tKjOzepQk cKUfyqIukiJTe6gxJ6BYh32cQyO39nVd6EoUkJQPVAz3KNWOxqN5TKaSuUEq bFnBA91UtiRBqfoaN0ybNAUpr/B32DC9EBLm1qTwyVBrJF51iS/tMjNAIhGD 3BnqHUtMC3gjL2pZq/KLONI//yyc+vKlryuXJxb4YGq9lAUDoUnWpPC5fbXl up6jtgPxNZJCo6GhGzKbFy5NM6vUN8jHskibBGffyXSUh0ovDXCsmBLrr4gH I+aBuo4Z5/7BH3miKg0EJaWbEIf/2a8/lMDrVVG+ADuSZmFB12j1KK5fvgB7 r+sgC2QX6Slu8JcvuMNLWy6c32B+BvoBz4AE2SPYuC5tqrdBCtxlUj/yF71A w5GnwWRVgbJQaaMWYG1N7qpFLGL4/aT4zLIDYoRbgjxgylDIKlvvFpcE3BD4 GV2vCp3bFfuOxCzNxGWudvgE5s6yYqVBOl9RUutCmRSualehbFj4P34Z9r4a 7txgU1UNkkfSRKqFU/GgeuWyTE+sLoCnpmaRUkZPmyxbd3WGOGbzV1cWOW5Z X7uhHfY1OGLk+2rukjkSrJPMweNKGVJYz5KN+cwks7RCeGlZg0bkg9H44vp6 Q9fU1NkM+Q9aWMAwpQ4GrMhpj2WtLH9jS3Kuj4Hno1pn1lS1SpsSiTCAEQzw ieXXlq5I+8wTYtCS7hN5qJ5AImxQBh7OJagiChzBOl5+9RtaFsCLxqIReS2y VyAC0IVOXZWgh+iQ9E5NLGzm7i0KtsOAETQlMLDsw74ilTiXAYu0BJUzwGHg GcyrKpA41EJg44IFF20zqACwZGVhEfCT5RksEcgzmoJH+/fGlZao1zfgpBtg NNJj9Ytda1BI4HTv9nn81OvzT313T9ePVz8+Xz9eXeL1+OPo5iZcKHlj/PH+ +eayvWq/vLi/vb26u+SP4a7u3FK929GnHpvZ3v3D0/X93eim5+1aax+Qr7D0 iWWhXJaAjIDblerYn/OLh//9n8MTWPm/iSsFjvAvp4fvTuCX1dzmPFuRg4Tz r8DQtQIOA+txFBJis3TAd7Yj1bxYoWUpLfDx278iZ/52pn87SZaHJ7+XG7jg zk3Ps85N4tn2na2PmYk7bu2YJnCzc3+D0116R586v3u+Rzd/+4fMgWIPDk// 8HuFwtOL0GuPTciFt1ZrYigbPeAfPfyxKWCHBoDnQPkqlrLuGEn7uQN0mrA5 9EZK7IVYWsIEyr8OggD2KvfmFz5LAOIbl7P92jRaYlJAMVw9Vzh4b3x1c3UB NJDYXf1ldHt9dwUUFYsFAjQWkIiKxJDLe3Wp2HYFzm0JFpfNNA15cz32A96M n8/b0cT+x+tFx6LMdAq2oRK7RkxrTTkzAucFSW/KfMPVQGwBX7lSgSJM3WcE KlWD9rfSd6Pbq/HD6OKK9R8xHZoFoGt0ccP3ENyRTWg35f7u5lO8Jf2uYw9W DKz+AiInyxvytQ1F8+t5h8bOuDR2m53PlJtqcObBswG+ccSR7uBFGVMKtI/E 0WjSvoZdImzm3ej8pt1LsY0AlFH5YeAddBds+/dSYGXeXe+JJqtNuNILaTDB vL4gsUIOe7SqVYe/syZUrAm0E16qWRg7xLRIDsUmLEh3OS2LA1RBZuwVJD0A MAwigRCiFaaq4YdsNcnYxACruu4nhlfg6yZOMDgyFTDh6WDi6g3IbOpiQWLY XR0R3aACyfr5PgkyUgpOEOQCuQSM0CAqgDqyVkFyNvCgzRCmEjenZbGANwHD YxhIwf8SgzNW0SbPMCaINLUApSoZNRKoqNZ5MgeX7f6B38uE4hox8kGwTZ6m ZOfILhgDfF1COAdiW7olxfIWvS8rvyyKFjJZR5sPK/kz8H4LZYX97ux1H+U+ GLivyYsXWiAC0SCxYQ3W7jNEVFrL21r+/e47ffnj8/3Tlf62oZ+Xg4uPo0e5 qXT49xsdP3YckyyAywilyOkBbYSG2Ex1PmWL5YMuPTq/+0DMrhGXg9VFIAov dijQv+vM+B0J9ODIXxz7ixP6VB76VcF/v73cpZ0gnUQGwP/ftx8e/38/PPlX P5TdBv5xvAJv44agdLQBg8PQAJ50RKUf2xAyYaX9CWbp84Yb3TsfXfa09zMo 72tdgP6ByICoQlgbO7S5m831BMXJ1myRphjagKUCU7FEoNNKEaDnTLMIqTKG hLC0rZBKrFAszB7toPyL11fbYituUYxipKhyZ44iJhYVM3Vt0ozIZ/qQZW1U 9UumECTueroTOGyoXEQCwCAycX7rlOiSzM37AFynxZtyxkiUg3KKQNGGiS3Y 4+gctdPILTRQOV/vAxs/FisM3EHppzqypUVTVwgrKGwccxAE2wIT1AXsDAHf RmIJME2gXhgJLEuHnoiiBl4TCEqTAUWroslA1CyJBUUJyOip6CwtLUHfkAW3 MWlQbICJ/jYEM/ggtvgrK2TAQsbiO8Beo7deIS6OIl75AuhWzCVkKWwrGpj2 BsVJm6mDYOEwHWFmpVnO0ZSMwApFAijYaCeY0IKSJaz0NlV10JOHd0UlKRaK 8/14SMitvN5JGag7s0DaLsg7cTYnXoG3h/1gLd4MD4fHfVYYpkiRmRE560I6 pIkcH9Ow8BoU7bcSbJuxFqO7ue2MQTNtavydrQfPucM0mCKTxiHwniCj9+QD PclH++2HHiSAgiDt+BjZhZK1bq2AQG/6WRZZLAN7z/9xAP8G+OPwAwcJcHmK d9TBwfsP+wgUUosZ9/Y7/uwdP6QopLIoD3VBj44Ojk7hEfxiVBCTrVfe74Pg 3GMSzUhAEtkdm2P6wUcsfuPDusXOqF12hnx2WDtF/2irx1ejx4uPLTAjPgln 0EpIKqiLuzDJNA30id0qbWLdK+wl43m1NbTLRf5d3UgaBEgSuWcfwkZO3icf selOAOw2NtjoIp9mLiGv5QnNDADfap/yBr3RwwMEkT2QfBryXzC1efxeBxkr SdR53Q+TeLp9IsgbXrbwG9zaPXUI3zY3HmyQoj1Lf9Wh9GPKt/wzMvTuvuue t5dA+xTStuhKNqA0Lr6b8NKc8GK+39x/f30X2N4G2TtzSBuZ5Xb9fphORMRo X22lyzEV3tqjpakqSgsJsLW0jZ6jubUpZSXRiW5+DpoYvm6VxodpTNjo+enj 1d3T9cXo6aqnAuM5lQgLNFkJTFlzYJlRLIJjopzuoFYlpU3RMDMAHWVg4RuA RS2A2DFrV61gzpVZg2F+wZxerbruMrMzQ5hqbl5tiHA8DfGKSXhKy7hazRrY brDcto0VqeJAGQUM9SiYWGMxTTe146SFgEVKf8e5U0kJo3FwtFrMFfsIylH4 ghE6QToSDJWClFSUCEatguWlgC4oAQacRgHlYdaehM3gBYJMtBBu1pSWwngg nuTzw9XTxUd9fn/5afz0+Hzx9Px4FZdLvptlxQTcpooqGzCmJBKGb4ZHEFxZ A8rb/QBs/osN98pp0lcsEQtrfGIEcWJVLMJrVQBBbN6ASqJOdal7NSWmLpgB yHXigQ0JGCon4Ua2ZRlYPVeIhrIQTqhuqVscQ3tZQnJgvVII8rlMFZe5FjZ1 ZuBtAEVSy1CvwWWAm4elRyzk2Kr7HQYsEvf1bq/G49H3INlyY/wQxW7RP3m8 18Pk6NFRDwKw3vc39+ejm96+jxc5vmk5IxbIG0uyqRMLr4hH7RpNgNe0wepX 9hdmp0QsIZem9to6KUD1AT8DL0Dy+gpxKo5JaI0GprzRRgkq2oehvuBSRAeB TQAJM3QdbqzvaGt9iFJ597fdwcSyGdhIQXd36ptOeq1NmP5S6u2fyIZuJLD2 KrAtofaxr1vfU7d5jWqrL4FyK1KtQSySUxXQJU1mSsmKRCq3WcTB6E99JWnB CNtnEFBLBJDjIEWGhZ1OmrYDhRkFM8De8ykJIvldvLuATc5tYppQC+PNQhmC UdFdYPw94wwtbjFVVADnUJSM61Amz4sGMCJXGBB/s2MjcydFJrLhFitZBkv7 SSxRMLf6NRwBcgIct8ELod+m2aMcqeIopM2AxoJBLNzMDdzd679i68L90996 IRctuU4qonK+oANEFm42D/KwgX3RfUoSaIkINGUPhKDmV4LuFmF50+zaBCcJ m9FxptTz3MswL1IqWQarbbiPWLVvANuzwzFSygNNrwXebu+dz89TkByaHLQt S6DBG0pJ3YLoDtAFwwIiGeqwPWT+I7UUIBctbjOhR3C6/UQyAbSF8nkfV7Mo qporp8VUcSBK2QLCV2igQDg+cI4/pIt2bgSBJIAslaIcwWAgY3Re9hnzb/Ql ljSJIBCjG4AzydrbSNjKnOhqAwvGbb5iC3o4RdtQo38EiFEAEEMt45QNxKYe dWAWtpSCMl60oH0Pfn24f9gPAlHolxzQjLhghYU36UHoiBRLLteTgaS+lD+w cFskzvhYGtgNmqYWqG4zAKslorb+Vsk5DvSnJvHl9jb7rzqlR7aMJiPecGmQ GkM6yQi0GCByLF9btX6igLwFlzBBxcDSsmynsCW8H50lp4UicJEz1YRtMvtq 0DpFTQJA3DPOXDdgSi2uNgaelAmweF9XQEkFqwUOrQnj4tTAi0ISQzBpzqiK QKBQsXLVHGMECUq5nYkfBb8yvn16QDHbal7AVH9TMuilrUVyQOYl1chi76cD yQ0ZNEm4hZK/byiogANJzZYJtZe+ovzYclYaNFlRriRbe/duWu3fTThmb3Nq 3rK4KT545GlVC/R4LyTTFVXKknnhqHj/CtzxUta6SyWar+cu9dgmtndC3V61 3+euEK5iDibEgVIVTT0opvwr0BHEimKsjnmrSDMQF89Bq+pyTdMVintN0BA3 8PoMr0XNPGdC7gPdMrteDLbIpGJOE9g9bbK4+YLXiKIvZa8J0MkBBaLCIklg Ls4XQqyi2plDNTZBE06dFiCWDeakm0kFgUiDyEesCqzHzbCk4DHkGRXrfSgk OokGkCpHrVUiocU0GFzsSUFRxLAoablIbgav40Kjde2H/cfemk5QjptBii11 ZVB6hqdMLu/2IGCIxaLJw1Zh3DVDnVgX4GpZn7upd+IXfMg61jEgFSxhOBv2 xcEfHx0R/MGuTyoF1Kj4FBIG5uJ8aJTQtVGglLG1p8Ep+oTXUKn2NtROlG0/ pGzFrWI3CilfVwYUKSJXCSRbLfgcGAdiO6UET+AURbpeFMQMWOU3OYjjxNYr DCsYNVJeikzZZ99rYNLU+VY+ChqkqQrkgSaEGJz9CygBdYyBwuP2YLiwoNg5 WgVA+CA3e1Tq+2xwtj6O1HuAMQeXNnPYdRe6ES+LVY5GB2lDHPC15jJ5P3SX nb55B3vHMub1E/xb7hbwkUABXgXEvEAPKASIbFBEvUMRN0lWvTHV6Ak2g7ul yWhvN4jWXyG6FwLdU5Izdd1JKHiXNy8KjrTB05PzS6PhJR9JFWQPc3A1QIsp U5rLZDPY+HqO3YcsZCGNjmxCAZTr06H63tYkB34OG39eIj6QVk1mpbezpate cHJpb6NYQ2wvZ7jmpgyZdtE88kh99AqA3pIXEjgVvEYCIo47YHMQWWsR37H0 Iy9WRUwWKgP2Yqkmx0xnXRTsXGSIDDMxlZsB6IhwaFeNcQjsQ0MPvqk2wTYi h8H0Y3JT3u0FNqU9eqr3jE+HcTBHlVpuHnc4IFh9LjOhMIf6e2L3uTsKNsa+ uhqc25qBDKARFoa5W4ZinyeoUhu9hl/tNkhdyuEhFp/cElsVpFtywmXEZklc BYoSEFXS7TZIPdMfXIlIOoV5sUsOuWkwW1CJWcDSE+Usc+4Apgrtpm+JvCAB UOQFeyZsCsNjArFP33RkLHfRp1R5DZQomD7O+O9dt5C6g6HJSm8vhJGUjIIZ FjflHUloYdT+gRzZlooO6sFyHDGaqvltyY0BB7v7zvKG+xpTCgUmZGOoq9Cz kM9GNN4mKqnUSI6FsARGC5b8mYe1BFNABlPwOezN0DahM7aTSPG4u0TMuw/d fUouQMHNOSLouS9JB8v42n7Gghp2dOCZiST0EaqATfXz9eV/jm6uL6+fPnWE kzM8FfqMkLPl8io7w6F6InstPaDCGCsQAVXWUr8pqIvrFEwSk8ylg2pLnHCp IrvSK4RBDbdj+HpKWxopsVSkNtAb7uXCvKANFORD5rmFp538p8DcjahiFBws YovYoyZgS1u8iMEQE2Z8mppctcNIRd7y3REVt7piO1vVykzMfcATlJ4TsELN dHG8OzAr3ECRgn5biggRAOa01MTi2rAjZdfXlLrBHl1wRBqL+LQdxDQxuwrN Z1aEAaO9k06qCZ6pwXC2x4mJiUl7+22TLqU9ckB8sD153DVMsqnaBHxWJAYD o5y5DUviO21LciXImqSPJNIVZZ+8aWpnpSXCfe01boTy8Teh8dcQRsFAJDrg 05hpwCrOWxTLyLsTkCNYDnIcJIdtHQaNOXfIY3Y8gO5+m6gR61+7BVdtmok/ bcWGZjNE7qNkIbcAJKOXTF+dP//AUH8pWB4BfJSgUAh9kMetU0D/PgXoRAYx zmVEgW5P5EUETXkbhb2+BSHCYJs5cXLNKk4CzQEgnxqg+junHSTY7NYnG8zm mZDeZNDW6V/wjV9SDlWSOPUNJhzzEt8Y5Lk8YqNpjyBISEPlTZT+nemiKbtL VxO6aQsmTvJVgsfb9MxmL8E/00Eo8ZPaOsHzgVcfBTE8sJRJ/PZK538nzsDO fd9KwqlEtEGllfYkrsMD9bC5KWa4VBtltp3B7SGDbi+jWJu4uR8Fe2cb/ymL w+huRIfuALSWAop//gbvflGcESZGnbQZf4chQGlnrsKIJOoMyJvFhPoW4Sl5 s4R8vpJK05Dm6usl6pVPaYf+EGqF9EmntlkeRq6BiQh8wzDIpuD8o6lA0c+U +rZzONH/dnOj9+7Px/c3V09X++EuFbl3PMA0o79+Hl89xq8Az4CDTYlCtsW3 8dXF8yOY/y9sWyv/YtJ9cVd7GgnbeDS+wZQahy14Pg4feItRb5XK+5G18MLd yqCSrtdQ2vh6SfweLcrKcXWIy68IwicQLNpXSV1ntYjrLywLhQXkaszAYeOF PiNDVs0FUxvGokAvCRYOky7YT91NuUtystrNDcohR2DOiDX0eUjOfvXjgyXA FC6+YqZVIvPI1GIMKseBxAN6wLIx1QLPrC6zndlerK20AK89bwZ78F0RKmFf wYBkFgCaKYFmXz2Vcyrn5SYmeeEEOSJv/SixopVOC7Qc4aBmqGH7Eb0pNRUu Hnw0VUDaTVMc5oU8oS8Pd5uBtkuCbQdp5QN6UHJnZnlROclbgXSRp5eyYoht CZKJYfO8muFeAgZac0qbhNJvGrfxKeQDgKS00r6OJrUPToHimT1ubVzDMAwb kDciYWh4ez81VT3A4uCANQiFu0cohFL2KeawQ1ji/HbTaUCWbWCcEsrb4mTo niTg40sR5LE8R2DyTX60sT4F1yzf+iskBnYrF+/oVmUoqu+0O7SC9SUocjk5 iFGChY3MprMFF1eeugaa+jQkf9nkbNUxobikFUV9Br4bBsZXqxI9YI6LiA+G 9/XFvIQR7+xqYbjLY2zhYgwiMORL5D4dKVV+qp+KSdVmuiX1yMfPkU7abWlz oTOG8bFYhfB27hZD/WcbZXHbgAqdM8VJBIhfQ7bZF2Q3Syxo4sC4hGwAHrvD CeiUANHUpy5VoAtgW83JE2UCjzG1XrEIeSwix94659HbY3ZIPOtbDpFJ221K G4NVO0NC6feDBFdmm0nGFtYQTXTGo3kGYt1EEuT5Cyf8yeO4pcnbSP1qdB00 alYWzVJN/bkeRvQOFs2QfMPDSyE4Ar00EwGHj7AYYP0og8gQcRPE75cQNKT6 HNYOwvKIKTiw49+DMbfoNTbPxvfVn0zp9MemrGvT1z8U81z/CV914Dn/4kyR Fvh3BqxFwQMPCvy8cfglGIQReAK7Vrc2y91L8drX4waGBbGEbdC3BaaizALe G8/NCg/7W4thwyU8t5l+MjTcK0UZ6gdQJtiRTzaUGIEtoSV1B3+CiWdreksN 8+I1KSddWmwn4ze9JsrhUGnX4XYs0uALkVU+ie3PdP+yP5A+kKoj7AuMM1j5 Ng5kgplgLIXGZdNElHZRYPKBX/l3ChNOdWpqA0YT85MS4eNU1FRMGTlspefu 9agPgmQlanJpa51gSeLmLG4QeyFLWrPT4eRB66Db8mm3K6gdPhyyqriXI7XS JrB1zN2nfSs8ajObZ1EiqS0kgt2L267YDEhFzhfWujxC9gz1naSdO7a0JQPW 9ANCdHqMf6oAe9NIuNYUuUuJFFB3iWCGW8RMrHEhaYi2FSPAtHsAPNqsoR5V CkWxSNFrbnQkiwWlqfSvTaV+ZSpMA/sslavjsjf9hRRO4cWhFUXPbtpu53dH 3O0fDrRQ+YSLQJtfD6lr4IcGtu7o4OjYtzSwwRRbOKVjVJSnxKfxyslZYIis di0kNK6ExAWnwbDHB/xVUsOIe9TMI810KnzMCZgsaxPpbnfHchT19EMIDWEa poZg3b+4G53GXiKejhJkWDGR5o0qwEJupQBR+alJ0f9SAomKlK/Od+6IiHN9 q1jW7REO0WlTtRLMBmRHC6ZvU6S/YyCaXokbv72+vdL4t3D6Gz2XbdOtoiqs oTZa7Hnd0avHxwF02xXWTDxPFmat9tDY7odWX6E9OlzZ+TsLG5mDTrMofwO0 8zJpZ4lndCIWB6cFhR5B6jVRIS/PS/LJ66biZJYkV3XBhwMkwQrsvIuEF2io JLrG5Bue/mzbWyRO6RjAyMJhsFFljgxaCE8I4uBMXm27jamcjVdodTy9bT+a r88A/EnoDwRUjrqRjddNgrjDTQ/CXczRFnCCDzdbfEcw8lH9Wnm9jde8mcQN Ciitre2ZYDz2IET7DPwSTxRIsS1PM0sNTtyKixbe7xMVNfw3aaE4xgjljpXh TId3PzTIV3zQUP0fAyuiCCpKAAA=[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. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> </back> </rfc>